System call — দেয়ালের দরজাটা ভেতর থেকে খোলা

ধাপ ১ — syscall instruction কী করে তা দেখুন।

AMD64 ম্যানুয়াল (Vol 2, §6.1) অনুযায়ী syscall-এর pseudo-code-এর প্রথম দুই লাইন:

RCX ← next_RIP        (কোথায় ফিরতে হবে)
R11 ← RFLAGS          (কী অবস্থায় ফিরতে হবে)

ধাপ ২ — প্রশ্ন করুন: এটা ছাড়া উপায় ছিল কি?

Return address কোথাও তো রাখতেই হবে। বিকল্পগুলো:

AMD চতুর্থ বিকল্প বেছেছে — গতির জন্য। আর rcx বেছেছে কারণ rcx ঐতিহাসিকভাবে “counter” register, C ABI-তে caller-saved।

ধাপ ৩ — এখন ABI-র সীমাবদ্ধতা।

C-র System V ABI (যা syscall-এর অনেক পরে নয়, কিন্তু স্বাধীনভাবে) argument দেয়: rdi, rsi, rdx, rcx, r8, r9।

যদি Linux syscall-এও rcx ব্যবহার করত:

mov $257, %rax     # openat
mov $-100, %rdi    # AT_FDCWD
mov $path, %rsi
mov $2, %rdx       # O_RDWR
mov $0644, %rcx    # mode      ← চতুর্থ argument
syscall            # ← এই মুহূর্তে RCX ← RIP, mode হারিয়ে গেল

Kernel rcx-এ পেত return address, আর সেটাকে mode ভেবে একটা ফাইল তৈরি করত 0x00007f8a3b2c1234 permission-এ।

ধাপ ৪ — কেন r10?

শর্তগুলো: (ক) C ABI-তে argument register নয় (নাহলে wrapper লিখতে বাড়তি কাজ), (খ) callee-saved নয় (নাহলে kernel-কে সংরক্ষণ করতে হতো), (গ) syscall নষ্ট করে না।

r10 তিনটাই মেটায়। r11ও মেটাত (খ) আর (ক), কিন্তু syscall সেটা নষ্ট করে। তাই r10।

ফলে glibc-র wrapper-এ ঠিক একটা লাইন লাগে:

mov %rcx, %r10      /* C-র চতুর্থ arg → syscall-এর চতুর্থ arg */
syscall

ধাপ ৫ — ARM64-এ কেন সমস্যা নেই।

ARM64-এ svc return address রাখে ELR_EL1-এ, আর flags রাখে SPSR_EL1-এ। দুটোই আলাদা system register, general-purpose register নয়।

কেন ARM এমন করতে পারল? কারণ ARM64 (২০১১) নকশা করার সময় তারা ৩১টা GPR রেখেছে (x86-64-এ ১৬), আর exception model-টা শুরু থেকেই banked system register দিয়ে সাজিয়েছে। x86-এর syscall (১৯৯৭) একটা ৩২-bit ISA-তে বসানো হয়েছিল যেখানে মাত্র ৮টা GPR ছিল — নতুন register যোগ করার বিলাসিতা ছিল না।

ফল:

সাধারণ শিক্ষা: ABI-র “অদ্ভুত” নিয়মগুলো প্রায় সবসময় hardware-এর একটা সীমাবদ্ধতার ছাপ। Level 5-এ compiler backend লেখার সময় আমরা বারবার এই ধরনের সিদ্ধান্তের মুখোমুখি হব — register allocation-এ কোনটা “free” আর কোনটা “নষ্ট হবে” তা জানাই অর্ধেক কাজ।

নিয়মটা: [-4095, -1] সীমার ভেতরে হলে error, নাহলে বৈধ ফলাফল।

দ্বিতীয়টা কীভাবে সম্ভব? কিছু syscall ঋণাত্মক মান ফেরত দিতে পারে বৈধভাবে — যেমন lseek একটা ফাইলে ঋণাত্মক offset-এ (সাধারণত অসম্ভব), অথবা getpriority যা -20 থেকে 19 ফেরত দেয়। getpriority-র জন্যই libc আলাদা কৌশল নেয়: errno = 0 করে call করে, তারপর errno দেখে।

সঠিক wrapper:

#include <errno.h>
#include <stdint.h>

static inline long syscall_ret(long r) {
    /* unsigned তুলনা: -4095 → 0xFFFFFFFFFFFFF001, একটা বিশাল সংখ্যা।
       তাই "উপরের ৪০৯৫টা মান" একটাই তুলনায় ধরা পড়ে।           */
    if ((unsigned long)r >= (unsigned long)-4095L) {
        errno = (int)(-r);
        return -1;
    }
    return r;
}

কেন unsigned cast-টা জরুরি — সংখ্যায় দেখুন:

দুটো তুলনার (r < 0 && r >= -4095) বদলে একটা — এটা kernel আর libc দুই জায়গাতেই hot path, তাই এই ধরনের সূক্ষ্মতা গুরুত্বপূর্ণ।

mmap-এর বিশেষ ক্ষেত্র:

void *mmap_raw(size_t len) {
    long r = sys6(SYS_mmap, 0, len, PROT_READ|PROT_WRITE,
                  MAP_PRIVATE|MAP_ANONYMOUS, -1, 0);
    if ((unsigned long)r >= (unsigned long)-4095L) {
        errno = (int)(-r);
        return MAP_FAILED;       /* (void *)-1, NULL নয়! */
    }
    return (void *)r;
}

MAP_FAILED NULL নয় কারণ mmap(NULL, ..., MAP_FIXED) দিয়ে সত্যিই address 0-তে map করা সম্ভব (যদিও /proc/sys/vm/mmap_min_addr সাধারণত সেটা আটকায় — একটা NULL-dereference exploit প্রতিরোধ)।

যেখানে এই বিবরণটা বাস্তবে কামড়ায়: Rust-এর libc crate, Go-র syscall package, Zig-এর std.os — প্রত্যেকের নিজস্ব errnoErr ফাংশন আছে যা ঠিক এই যাচাইটা করে। Go-তে সেটা runtime/sys_linux_amd64.s-এ, আর সেখানে সীমাটা 0xfffffffffffff001-এর সাথে তুলনা হিসেবে লেখা।

Level 5-এ যখন আমরা একটা ভাষার runtime লিখব, এই সীমানাটা নিজেদের হাতে বাস্তবায়ন করতে হবে।

পার্থক্যের উৎস তিন শ্রেণির।

শ্রেণি ১ — hardware যা করতেই হয় (~১০০–২০০ cycle)

একটা call instruction-এ এর একটাও লাগে না — শুধু RIP push আর jump, দুটোই out-of-order engine-এ প্রায় free।

শ্রেণি ২ — নিরাপত্তা প্রশমন (~২০০–৬০০ cycle)

এই পুরো শ্রেণিটা ২০১৮-র আগে ছিল না। ২০১৭-তে একটা getpid ছিল ~৭০ ns; আজ একই মেশিনে ~৪০০ ns। syscall পাঁচ গুণ ধীর হয়েছে, আর তার কারণ কোনো OS পরিবর্তন নয় — CPU-র speculative execution-এর নিরাপত্তা ঋণ শোধ করা।

শ্রেণি ৩ — পরোক্ষ, অদৃশ্য (~১০০–৩০০ cycle সমতুল্য)

Kernel-এর কোড আপনার cache-এর জায়গা দখল করে, TLB entry সরিয়ে দেয়, branch predictor-এর ইতিহাস দূষিত করে। ফেরার পরে আপনার নিজের কোড ধীরে চলে। এটা benchmark-এ syscall-এর খরচ হিসেবে দেখা যায় না, কিন্তু বাস্তব।

লেসন ৭-এ context switch-এ আমরা দেখব এই পরোক্ষ খরচই আসলে প্রধান, আর সেটা মাপার কৌশল শিখব।

তিনটা নকশাগত পরিণতি:

পরিণতি ১ — Batching সবসময় জেতে।

১০০০টা byte এক এক করে লেখা : ১০০০ × ৪০০ ns = ৪০০ μs
একবারে ১০০০ byte লেখা      :    ১ × ৪৫০ ns = ০.৪৫ μs
                                           ৯০০× দ্রুত

এটাই stdio buffer-এর অস্তিত্বের কারণ, writev-এর কারণ, sendmmsg-এর কারণ, আর ডাটাবেসে group commit-এর কারণ (Level 8-এ ফিরব)।

পরিণতি ২ — যে তথ্য গোপন নয়, তা শেয়ার করে দাও।

vDSO ঠিক এটাই করে: বর্তমান সময় গোপন নয়, তাই একটা read-only page-এ রেখে দিলে syscall লাগে না। ৪০০ ns → ২০ ns।

একই দর্শনের সাধারণীকরণ: শেয়ার্ড মেমরি। লেসন ২৪-এ আমরা দেখব দুটো process কীভাবে setup-এর পরে শূন্যটা syscall-এ গিগাবাইট বিনিময় করে।

পরিণতি ৩ — Interface-টাকেই asynchronous করে দাও।

সবচেয়ে চরম উত্তর: syscall-এর জন্য অপেক্ষাই করবেন না। io_uring-এ আপনি একটা shared ring buffer-এ কাজ লিখে রাখেন আর kernel সেটা তুলে নেয়। IORING_SETUP_SQPOLL mode-এ একটা kernel thread সারাক্ষণ ring টা দেখে, তাই হাজারটা I/O করতে শূন্যটা syscall লাগে।

লেসন ২১-এ (ইতিমধ্যে লেখা) এটা বিস্তারিত আছে; লেসন ২০-এ আমরা তার আগের প্রজন্ম epoll বানাব।

একটা সতর্কতা — অকাল optimization। ৪০০ ns শুনতে ভয়ংকর, কিন্তু সেকেন্ডে ১০০০টা syscall মানে ০.৪ ms/s = ০.০৪% CPU। তখন syscall কমানো সম্পূর্ণ অর্থহীন।

সিদ্ধান্তের নিয়ম: আগে মাপুন।

perf stat -e raw_syscalls:sys_enter -p <pid> -- sleep 10

সেকেন্ডে ১০০,০০০-এর নিচে হলে syscall আপনার সমস্যা নয়। ১০ লক্ষের উপরে হলে সেটাই আপনার প্রধান সমস্যা। Level 11-এ আমরা এই ধরনের performance যুক্তি পদ্ধতিগতভাবে শিখব — Amdahl-এর সূত্র থেকে শুরু করে।

seccomp-bpf যা দেখতে পায় — struct seccomp_data:

struct seccomp_data {
    int   nr;                    /* syscall number */
    __u32 arch;                  /* AUDIT_ARCH_X86_64 ইত্যাদি */
    __u64 instruction_pointer;   /* কোথা থেকে ডাকা হলো */
    __u64 args[6];               /* ছয়টা argument-এর কাঁচা মান */
};

ব্যস। এটুকুই।

যা filter করা যায়:

যা filter করা যায় না:

কেন pointer পড়া নিষিদ্ধ — এটাই মূল অন্তর্দৃষ্টি।

ধরুন seccomp args[1]-এ থাকা path পড়তে পারত:

সময়    Thread A                        Thread B
────────────────────────────────────────────────────────
t0     buf-এ "/tmp/safe" লেখে
t1     openat(AT_FDCWD, buf, O_RDWR)
t2       └→ seccomp filter চলে
t3          buf পড়ে: "/tmp/safe" ✓ allow
t4                                     buf-এ "/etc/shadow" লেখে
t5       └→ kernel buf পড়ে: "/etc/shadow"
t6     ফাইল খুলে গেল

ক্লাসিক TOCTOU। আর এটা প্রতিরোধ করা যায় না, কারণ filter আর kernel দুটো আলাদা সময়ে একই user memory পড়ছে, আর সেই memory-র মালিক attacker।

তাই Linux-এর নকশাগত সিদ্ধান্ত: filter শুধু register দেখবে, কারণ register copy করা হয়ে গেছে আর আর বদলানো যায় না।

নকশা কীভাবে বদলায় — চারটা ফলাফল:

১. Capability-ভিত্তিক নকশায় যান, path-ভিত্তিক নয়। Sandbox-এ ঢোকার আগে যেসব ফাইল/socket দরকার সেগুলো খুলে fd হিসেবে হাতে ধরিয়ে দিন, তারপর openat/socket সম্পূর্ণ নিষিদ্ধ করুন।

int data_fd = open("/data", O_RDONLY|O_DIRECTORY);
apply_seccomp_filter();     /* openat, socket, execve সব KILL */
/* এখন sandbox শুধু openat(data_fd, "rel/path", ...) করতে পারত —
   কিন্তু openat-ও বন্ধ, তাই শুধু আগে থেকে খোলা fd */

এটাই capability security-র মূল ধারণা, আর OpenBSD-র pledge/unveil আর Linux-এর Landlock LSM এই পথেই গেছে।

২. স্তরে স্তরে প্রতিরক্ষা।

একটাও যথেষ্ট নয়; সবগুলো একসাথে।

৩. SECCOMP_RET_TRAP না KILL — সিদ্ধান্তটা ভাবুন।

ERRNO বাছার বিপদ: প্রোগ্রাম error উপেক্ষা করে ভুল অবস্থায় চলতে থাকতে পারে। KILL বাছার বিপদ: একটা নিরীহ নতুন libc সংস্করণ একটা নতুন syscall ব্যবহার শুরু করলে সব ভেঙে পড়বে (বাস্তবে এটা বহুবার ঘটেছে — clone3, rseq, getrandom প্রতিটাই কোনো না কোনো sandbox ভেঙেছে)।

৪. Allowlist, denylist নয়। নতুন syscall প্রতি kernel release-এ যোগ হয়। Denylist মানে প্রতিটা নতুন syscall স্বয়ংক্রিয়ভাবে অনুমোদিত — অর্থাৎ আপনার নীতি সময়ের সাথে দুর্বল হতে থাকবে।

Level 10-এ আমরা একটা পূর্ণাঙ্গ seccomp filter লিখব (libseccomp আর কাঁচা BPF দুইভাবেই), আর Level 12-এ এটাকে namespace ও cgroup-এর সাথে জুড়ে একটা container runtime বানাব (লেসন ২৯-এ তার ভিত্তি)।

ধাপ ০ — খরচটা হিসাব করুন।

৫০ লক্ষ × ৪০০ ns = ২ সেকেন্ড প্রতি সেকেন্ডে। অর্থাৎ ২টা CPU core শুধু দেয়াল পার হতেই খরচ হচ্ছে। এটা নিশ্চিতভাবে প্রধান সমস্যা।

ধাপ ১ — কোন syscall?

perf top -e raw_syscalls:sys_enter -p <pid>
# অথবা কম overhead-এ:
sudo bpftrace -e 'tracepoint:raw_syscalls:sys_enter /pid == '$PID'/
                  { @[args->id] = count(); }
                  interval:s:5 { print(@); clear(@); exit(); }'

সাধারণ ফলাফল:

@[1]: 2500000     /* write  */
@[0]: 2400000     /* read   */
@[228]: 100000    /* clock_gettime — vDSO নয় কেন? */

ধাপ ২ — প্রতিটার কারণ নির্ণয়।

তৃতীয়টা একটা চমৎকার বাস্তব ফাঁদ: যদি clocksource hpet বা acpi_pm হয় (কিছু VM-এ ঘটে), তাহলে vDSO কাজ করে না আর প্রতিটা clock_gettime একটা আসল syscall হয়ে যায়। শুধু clocksource tsc-এ বদলালেই বড় লাভ।

ধাপ ৩ — সমাধান, কম খরচ থেকে বেশি খরচের ক্রমে।

প্রায় সবসময় ১ আর ২-ই যথেষ্ট। ৬৪ KB buffer-এ ১০০ byte-এর লাইন মানে ৬৪০ লাইনে একটা syscall — ৫০ লক্ষ থেকে ৮ হাজারে নেমে এল, ৬০০ গুণ।

ধাপ ৪ — durability-র প্রশ্নটা এড়াবেন না।

Write buffer করা মানে crash-এ ডেটা হারানো। এটা একটা সচেতন সিদ্ধান্ত হতে হবে, দুর্ঘটনা নয়:

লেসন ১৮-এ আমরা দেখব write করা মানেই durable নয়, আর fsync-এর প্রকৃত চুক্তি কী। Level 8-এ ডাটাবেসের WAL এই ঠিক এই ভারসাম্যটাই পেশাদারভাবে সমাধান করে (group commit)।

ধাপ ৫ — মেপে প্রমাণ করুন।

# আগে
perf stat -e raw_syscalls:sys_enter -p $PID -- sleep 10
# পরে — একই কমান্ড, তুলনা করুন

আর সবচেয়ে গুরুত্বপূর্ণ: শেষ পর্যন্ত throughput মাপুন, syscall count নয়। syscall কমিয়ে throughput না বাড়লে bottleneck অন্য কোথাও ছিল — হয়তো parsing (CPU), হয়তো disk। Level 11-এ আমরা এই “কোথায় সময় যাচ্ছে” প্রশ্নটার পদ্ধতিগত উত্তর শিখব।