System Calls MCQ 60 Practice Tests With Answers (2026)

Incorrect·D: Passing parameters directly within the CPU registers

Register-based parameter passing is the fastest because it avoids any memory access — arguments are already in CPU registers when the SYSCALL instruction fires. The constraint is the limited number of general-purpose registers. On Linux x86-64 (System V ABI), 6 argument registers are available: RDI, RSI, RDX, R10, R8, R9 (with RAX holding the syscall number and R11/RCX used by SYSCALL/SYSRET internally). System calls with >6 arguments (rare on Linux) must fall back to passing a pointer to an in-memory structure.

Incorrect·B: The parameters are stored in a block or table in main memory, and the physical address of that block is passed as a pointer in a single register

When more parameters are needed than CPU registers can hold, the caller places all arguments in a contiguous struct/block in its address space and passes a single pointer (memory address) to that block in one register. The kernel then reads the parameters from that user-space memory using copy_from_user() — which validates and copies the data safely across the user/kernel boundary. This is how Linux implements syscalls like sigaction() and futex() with complex argument structures.

Incorrect·C: Pushing the parameters onto the stack by the program, which are then popped off by the operating system

The three standard parameter-passing methods in OS textbooks are: (1) Registers (fastest, limited count), (2) Block/Table in memory (pass a pointer), and (3) Stack-based (push args onto user stack, OS pops them). Some older systems (notably early UNIX on PDP-11) and some embedded OSes use the stack approach. Modern Linux exclusively uses registers (method 1) for its syscall ABI; Win32 historically used stack-based calling conventions (cdecl, stdcall) for user-mode API calls but uses register-based for the actual NT syscall layer.

Incorrect·A: `strace`

strace uses the ptrace() system call to attach to a process and intercept every system call it makes, printing the name, arguments, and return value. It is invaluable for debugging — diagnosing why a program fails to open a file (strace shows ENOENT), finding configuration file paths, tracing performance issues (which syscalls are slow), and security auditing. Usage: `strace -p <PID>` to attach to a running process, or `strace ./program` to trace from startup. The macOS/BSD equivalent is `dtruss`; Windows has Process Monitor.

Incorrect·B: It returns `0` to the newly created child process, and returns the child's Process ID (PID) to the parent

fork() is the unique syscall that returns twice from a single call — once in each process. In the parent, it returns the child's PID (a positive integer), allowing the parent to track or wait() for the child. In the newly created child process, fork() returns 0, allowing the child to identify itself and take a different code path. If fork() returns −1, it failed (e.g., EAGAIN if process limit reached). The standard idiom: `if ((pid = fork()) == 0) { /* child */ } else { /* parent, pid = child PID */ }`.

Incorrect·A: It entirely replaces the memory space and core image of the current process with a new, executable program

exec() replaces the calling process's entire address space (text, data, heap, stack segments) with a new executable — the PID stays the same but the program image changes completely. The ELF loader reads the new binary's headers, maps segments into virtual memory, and jumps to the entry point. Signal handlers are reset, open file descriptors may be preserved or closed depending on FD_CLOEXEC, and the process effectively becomes a brand-new program. The classic UNIX pattern is fork() + exec(): fork to clone, then exec to become a different program.

Incorrect·D: To suspend its own execution until the child terminates, allowing the parent to read the exit status and reap the child's "zombie" state

When a child process exits, its Process Control Block (PCB) is not immediately freed — it becomes a "zombie" process retaining only its exit status and PID. The parent must call wait() (or waitpid()) to read that exit status, after which the kernel removes the zombie from the process table. If the parent never calls wait(), the zombie persists until the parent itself exits (at which point init/systemd inherits and reaps it). A high zombie count indicates a programming error in the parent process.

Incorrect·C: Pushed onto the process's dedicated kernel stack

Every process has two stacks: a user-space stack (used for function calls, local variables) and a kernel stack (a small, fixed-size kernel-mode stack allocated per-thread). When SYSCALL executes, the CPU automatically saves RIP (return address), CS, RFLAGS, RSP, and SS; the kernel then saves all other general-purpose registers on the kernel stack. This saved context (called the pt_regs struct on Linux) is what the kernel restores when SYSRET returns control to the user process — ensuring transparent resumption.

Incorrect·C: It loads the specific system call number into a designated CPU register (like EAX/RAX) and executes a specialized trap instruction

A libc syscall wrapper typically: (1) Marshals arguments into the ABI-correct registers (RDI, RSI, RDX, R10, R8, R9 on Linux x86-64); (2) Loads the syscall number into RAX (e.g., 1 for sys_write); (3) Executes the SYSCALL instruction, which traps into the kernel; (4) On return, checks if RAX contains a negative value (indicating an error), and if so, negates it, stores it in errno, and returns −1 to the caller. The entire wrapper is typically just a few lines of inline assembly.

Incorrect·D: `mmap()`

mmap() (memory map) creates a mapping between a region of the process's virtual address space and either a file or anonymous memory. Once mapped, the process reads/writes the file by reading/writing memory — the kernel's page fault mechanism automatically fetches pages from disk on demand. This eliminates the syscall overhead of repeated read()/write() calls and is the mechanism behind memory-mapped databases (SQLite WAL, LMDB), dynamic linker loading ELF shared libraries, and Copy-on-Write in fork().

Incorrect·A: To send a specified asynchronous signal (such as SIGTERM or SIGSTOP) to a target process

kill() is a signal-delivery mechanism, not a process terminator. It takes a PID and a signal number and delivers the specified signal to the target process. SIGTERM (15) requests graceful shutdown; SIGKILL (9) forces immediate termination; SIGSTOP (19) suspends; SIGCONT (18) resumes; SIGUSR1/SIGUSR2 are application-defined. The name is historical — the default SIGTERM does terminate, but the syscall itself merely delivers whatever signal you specify. Sending `kill -0 PID` checks if a process exists without sending any signal.

Incorrect·B: They return control to the application immediately without blocking, allowing the process to execute other tasks while the I/O operation finishes in the background

Asynchronous I/O decouples the submission of an I/O request from its completion. The application calls aio_read() (POSIX AIO), io_submit() (Linux AIO), or io_uring_enter() (modern Linux) — all return immediately — then continues processing. When I/O completes, the kernel notifies via a signal, callback, or event queue. This allows a single thread to manage thousands of concurrent I/O operations without needing one thread per connection, making it the foundation of high-performance servers (Nginx, Node.js, Redis).

Incorrect·A: `CreateProcess()`

CreateProcess() is the Windows equivalent of fork()+exec() combined. It creates a new process object, allocates an address space, loads the specified executable, creates the primary thread, and starts execution — all atomically. It does not clone the calling process's address space like fork() does. CreateProcess() takes 10 parameters and maps to the NtCreateProcess/NtCreateThread NT kernel calls. Process creation was consequently more expensive on Windows than UNIX due to this combined approach.

Incorrect·B: `int 0x80`

On 32-bit x86 Linux (prior to Pentium II's SYSENTER optimization and AMD64's SYSCALL instruction), system calls used `int 0x80` — a software interrupt that transfers control to the interrupt handler registered at vector 0x80 in the IDT. The syscall number went in EAX; arguments in EBX, ECX, EDX, ESI, EDI. Linux 2.6 added SYSENTER/SYSEXIT (Intel) support via the linux-gate vDSO for 32-bit speed. Modern 64-bit Linux uses SYSCALL/SYSRET exclusively, which is ≈5× faster than INT 0x80.

Incorrect·D: `select()` and `poll()` (or `epoll`)

select(), poll(), and epoll() are I/O multiplexing syscalls that allow a single thread to wait on multiple file descriptors simultaneously. select() and poll() scan all monitored FDs on every call (O(n)); epoll (Linux-specific) uses an event-driven kernel data structure with O(1) notification — suitable for 100,000+ concurrent connections. epoll_create(), epoll_ctl(), epoll_wait() form the modern API used by Nginx, Redis, and Node.js event loops. Windows equivalent: IOCP (I/O Completion Ports).

Incorrect·C: `chroot()`

chroot() changes the process's root directory to a specified path. All subsequent pathname lookups starting with "/" are then relative to this new root — the process cannot traverse above it. This is the basis of "chroot jails" for lightweight sandboxing (FTP servers, build systems). However, chroot() is not a security boundary on its own — a privileged process can escape using chroot("../../.."). True container isolation requires combining chroot with Linux namespaces (unshare()) and cgroups.

Incorrect·B: To ensure the pointer directs to valid, accessible memory strictly within the user's address space, preventing malicious attempts to read or overwrite protected kernel memory

Unvalidated user-space pointers are a critical attack surface. A malicious process could pass a kernel-space address hoping the kernel dereferences it, leaking or corrupting kernel memory. Linux uses copy_from_user()/copy_to_user() which check that the source/destination falls within the user's virtual address space before copying. A NULL/invalid pointer causes EFAULT to be returned to the caller. Without this validation, a simple write() call with a crafted buffer address could read kernel secrets or overwrite kernel data structures.

Incorrect·C: `sbrk()` (or `brk()`)

brk()/sbrk() set or adjust the program break — the address marking the end of the process's heap segment. malloc() traditionally calls sbrk() to grow the heap when it needs more memory, then manages the returned region in user space. Modern glibc malloc() has shifted to using mmap(MAP_ANONYMOUS) for large allocations (>128 KB by default) because mmap() pages can be returned to the OS independently; sbrk() requires the heap to shrink from the top only. free() is a libc function, not a syscall.

Incorrect·A: In the EAX or RAX register

On both 32-bit x86 (EAX) and 64-bit x86-64 (RAX), the kernel places the system call return value in the accumulator register before executing SYSRET. A non-negative value indicates success (or the actual result, such as bytes read, a PID, or a file descriptor). A negative value in the range [-4095, -1] indicates an error — the libc wrapper negates it, stores it in errno, and returns −1 to the application. This register-based return is the fastest possible mechanism — no memory writes needed.

Incorrect·D: `ptrace()`

ptrace() (process trace) is the kernel's debugging primitive. With PTRACE_ATTACH, a parent (tracer) attaches to a target (tracee); then PTRACE_SYSCALL causes the kernel to stop the tracee at every syscall entry/exit. PTRACE_PEEKDATA reads the tracee's memory; PTRACE_POKEDATA writes to it; PTRACE_GETREGS reads CPU registers. GDB, strace, ltrace, and rr all use ptrace() as their foundation. seccomp-bpf (used by Chrome and Docker sandboxes) uses the PTRACE_O_SECCOMP sidetrack to filter system calls without full ptrace overhead.

Incorrect·D: `SYSCALL` and `SYSRET`

SYSCALL/SYSRET (AMD64 architecture, now universal on x86-64) replace the slow INT/IRET mechanism. SYSCALL: atomically saves RIP→RCX, RFLAGS→R11, loads RIP from LSTAR MSR (kernel entry point), loads CS/SS selectors, and switches to Ring 0 — in approximately 25 CPU clock cycles. SYSRET restores RIP from RCX, RFLAGS from R11, and returns to Ring 3. Intel's SYSENTER/SYSEXIT (32-bit) filled a similar role for 32-bit Linux. The speedup is ~5x over INT 0x80 for syscall-heavy workloads.

Incorrect·A: It maps safe, fast kernel routines directly into user space, allowing certain read-only system calls to execute without the costly overhead of switching into Kernel Mode

The vDSO is a small ELF shared library that the kernel maps into every process's address space at a random address (ASLR-compliant). It contains kernel-provided implementations of frequently called but read-only system calls — primarily gettimeofday(), clock_gettime(), and getcpu(). Since reading the current time only requires reading kernel variables (not modifying kernel state), the vDSO lets these execute entirely in user space without a SYSCALL trap. On modern x86-64, clock_gettime(CLOCK_MONOTONIC) via vDSO takes ~5 ns vs ~100 ns via SYSCALL.

Incorrect·C: `gettimeofday()`

gettimeofday() and clock_gettime() are the classic vDSO candidates because they only read kernel timekeeping variables (stored in a read-only shared memory region called vsyscall/vvar). The kernel updates these variables at interrupt time; the vDSO implementation reads them atomically using a sequence lock (seqlock) — no ring transition needed. fork() must create a new process (modifies process table — kernel-only). write() must write to kernel buffers (modifies kernel state). kill() must modify process signal state — all require Ring 0.

Incorrect·B: It acts as an application firewall, severely restricting the specific system calls a process is allowed to make to minimize its attack surface if compromised

seccomp (Secure Computing) was originally a simple mode (SECCOMP_MODE_STRICT) allowing only read(), write(), exit(), and sigreturn(). Modern seccomp-bpf (SECCOMP_MODE_FILTER) allows arbitrary BPF programs to filter syscalls — inspect the syscall number and any argument, then ALLOW, DENY (ENOSYS), KILL, or LOG the call. Chrome uses seccomp-bpf to sandbox renderer processes; Docker/runc applies a seccomp profile to containers; OpenSSH uses it. If a sandbox escape is attempted via an unexpected syscall, seccomp kills the process before it can cause harm.

Incorrect·C: By overwriting function pointers within the `sys_call_table`, redirecting standard system calls to malicious functions that hide processes, files, or network connections

Kernel rootkits operate by corrupting the sys_call_table — a kernel-space array of function pointers indexed by syscall number. A rootkit with kernel code execution (via a driver exploit or kernel module) overwrites, for example, the sys_call_table entry for __NR_getdents64 with a pointer to a malicious function that omits certain directory entries (hidden files/processes). Modern defenses: kernel modules require signing (CONFIG_MODULE_SIG_FORCE); sys_call_table is write-protected via CR0.WP; Secure Boot prevents unsigned kernels; integrity checking (IMA) detects table modifications.

Incorrect·B: `CLI` is a privileged instruction that alters fundamental hardware control states, strictly requiring execution within Ring 0 (Kernel Mode)

CLI (Clear Interrupt Flag) disables maskable hardware interrupts by clearing the IF flag in EFLAGS. This is an inherently dangerous operation — if User Mode code could disable interrupts, it could prevent the scheduler from preempting it, causing system-wide hangs. x86 enforces that CLI requires CPL=0 (Ring 0/Kernel Mode); executing it at Ring 3 raises a General Protection Fault (#GP). Similarly privileged instructions: STI, HLT, LGDT, LIDT, MOV CR0, WRMSR — all kernel-only, enforcing the isolation that makes preemptive multitasking possible.

Incorrect·D: `sendfile()`

sendfile() transfers data between two file descriptors within the kernel's page cache — no data is copied to user space. The traditional path (read() + write()) requires: disk→kernel buffer copy, kernel→user copy, user→socket buffer copy, socket buffer→NIC copy. sendfile() eliminates the two user-space copies: disk→kernel buffer→NIC, using DMA. Apache, Nginx, and HAProxy use sendfile() for static file serving. Linux 2.6.33+ also supports sendfile() between two sockets (splicing). TCP_SENDFILE_PERF shows 2-4× throughput improvements for large file transfers.

Incorrect·A: The parent and child initially share the exact same read-only memory pages; a duplicate physical page is only created when one of the processes attempts to modify the data

Copy-on-Write (CoW) makes fork() near-instantaneous regardless of address space size. After fork(), both parent and child point to the same physical page frames; the MMU marks all shared pages as read-only. When either process writes a page, the MMU triggers a page fault; the kernel allocates a new physical frame, copies the original page, maps it read-write in the writing process, and keeps the original for the other. CoW is critical for shell scripting: `bash` fork()s thousands of times — CoW means only actually-modified pages (typically just the stack) are ever copied.

Incorrect·A: The parent invokes `wait()`, the kernel reads the terminated child's exit status, and the kernel finally deallocates the child's Process Control Block (PCB) from the process table

A zombie (defunct) process has exited but its PCB remains in the process table because its exit status hasn't been collected. The cleanup sequence: (1) Child calls exit() — kernel frees its memory, closes file descriptors, but keeps the PCB with exit status and PID; (2) Kernel sends SIGCHLD to the parent; (3) Parent calls wait()/waitpid() — kernel transfers the exit status (WEXITSTATUS macro) to the parent; (4) Kernel removes the PCB from the process table, freeing the PID. Only wait() by the biological parent can reap a zombie — SIGKILL has no effect on zombies.

Incorrect·D: A set of mostly undocumented, internal system calls handled by `ntdll.dll`, traditionally prefixed with `Nt` or `Zw`, which sit below the standard Win32 API

The Windows Native API (NTAPI) is the actual kernel interface — the equivalent of Linux's raw syscall table. ntdll.dll implements functions like NtCreateFile, NtReadFile, NtWriteFile, NtCreateProcess, ZwQuerySystemInformation. The standard Win32 API (kernel32.dll) calls ntdll.dll, which makes the actual syscall via the SYSCALL instruction. The NTAPI is "mostly undocumented" officially but is well-documented by the community (ntsecapi.h, reactos source code). Malware and security tools often call NTAPI directly to bypass Win32 API hooks placed by EDR software.

Incorrect·B: `clone()` provides fine-grained control over exactly what execution context (memory space, file descriptors, signal handlers) is shared between the parent and child, serving as the underlying mechanism for implementing threads

clone() is the generalized process/thread creation syscall on Linux. The flags parameter controls exactly what is shared: CLONE_VM (share address space → thread), CLONE_FILES (share file descriptors), CLONE_FS (share current directory), CLONE_SIGHAND (share signal handlers), CLONE_THREAD (same thread group), CLONE_NEWPID / CLONE_NEWNET / CLONE_NEWNS (create new namespaces for containers). fork() is actually implemented as clone(SIGCHLD, ...) with no sharing flags. The POSIX thread libraries (pthreads via nptl) call clone(CLONE_VM|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD, ...).

Incorrect·C: Meltdown

Meltdown (CVE-2017-5754, Intel/ARM) exploited speculative execution to read kernel-mapped memory from user space — breaking the fundamental kernel/user isolation. The kernel fix was KPTI: when running in User Mode, the CR3 register points to a page table with almost no kernel mappings (only the syscall/interrupt entry stubs); transitioning to Kernel Mode switches CR3 to the full kernel page table. This CR3 switch flushes TLB entries, adding ~30-200 ns overhead per syscall on pre-PCID hardware. PCID (Process Context Identifiers) mitigates TLB flushing on modern CPUs.

Incorrect·B: DMA utilizes a dedicated controller to move data between peripherals and memory bypassing the CPU entirely, eliminating the heavy context-switching overhead of continuous system calls

Without DMA, every byte transferred from disk or NIC must be mediated by the CPU: the CPU reads a byte from the I/O port, stores it in a register, writes it to memory — occupying CPU cycles and causing syscall overhead for each transfer. DMA allows the peripheral's DMA controller to write directly to system RAM via the memory bus, completely bypassing the CPU. The CPU is notified only when the entire transfer is complete (via an interrupt). A 1 MB NVMe read might require 0 CPU cycles during transfer — only one interrupt on completion — vs. thousands of syscalls with PIO.

Incorrect·C: eBPF (Extended Berkeley Packet Filter)

eBPF is a revolutionary kernel technology (Linux 4.x+) that allows verified, sandboxed programs to run in the kernel. Programs are compiled to eBPF bytecode, verified by the kernel's in-kernel verifier (type safety, bounded loops, no null dereferences), JIT-compiled to native code, and attached to hooks: tracepoints, kprobes, syscall entry/exit, network packet paths. Used for: performance profiling (bpftrace/BCC), syscall filtering (seccomp-bpf), network packet filtering (XDP), observability (Cilium), and system call interception — all without writing kernel modules.

Incorrect·A: `unshare()`

unshare() allows a process to "unshare" specific namespaces from its parent: CLONE_NEWPID (new PID namespace — container process tree starts at PID 1), CLONE_NEWNET (new network namespace — isolated network stack), CLONE_NEWNS (new mount namespace — isolated file system view), CLONE_NEWUTS (new hostname), CLONE_NEWIPC, CLONE_NEWUSER. Docker's container runtime calls unshare() to create the isolated environment, then uses cgroups (via cgroupfs writes, not a single syscall) for resource limits. cgroups() is not a syscall; jail() is FreeBSD.

Incorrect·D: `futex` (Fast Userspace Mutex), which resolves uncontended locks entirely in user space and only invokes a system call if a thread actually needs to block/wait

futex (Fast Userspace Mutex) uses a 32-bit integer in shared memory as the lock state. When uncontended, the lock and unlock operations use atomic CPU instructions (LOCK CMPXCHG on x86) entirely in user space — zero syscalls, ~5 ns. Only when a thread fails to acquire the lock (contended) or needs to wait does it invoke futex() syscall to block in the kernel. On unlock, if the kernel waitqueue is non-empty, another futex() wakes a waiting thread. pthreads mutex, condition variables, rwlocks, and C++ std::mutex all use futex internally. This design makes uncontended locking essentially free.

Incorrect·C: `splice()`

splice() transfers data between two file descriptors (at least one must be a pipe) by moving page cache references in kernel space — no data is copied to user space at any point. Data moves from a file's page cache into the pipe's internal ring buffer via page-reference splicing, then from the pipe to the destination socket/file. This enables zero-user-copy network proxying. tee() duplicates data from one pipe to another (also without user-space copies); vmsplice() moves user-space memory pages into a pipe. Together these syscalls implement the Linux zero-copy I/O stack.

Incorrect·A: The execution of the privileged instruction in non-root mode triggers a hardware-assisted "VM Exit" (or trap), returning control to the Hypervisor to emulate or handle the request

With Intel VT-x or AMD-V hardware virtualization, the CPU supports two modes: VMX root mode (Hypervisor, Ring 0) and VMX non-root mode (Guest OS, ring 0/3). When the Guest OS executes a privileged instruction (VMCALL, MOV CR3, sensitive I/O) in non-root mode, the CPU triggers a "VM Exit" — automatically saving the guest register state in the VMCS (Virtual Machine Control Structure) and transferring control to the Hypervisor entry point. The Hypervisor inspects the exit reason, emulates the operation, updates guest state, and executes VMRESUME to return — all transparent to the guest OS.

Incorrect·D: It catches VFS system calls (like `open`, `read`) in the kernel and routes them back up to a specialized user-space daemon to handle the actual file operations

FUSE allows user-space programs to implement filesystems without writing kernel drivers. When the kernel's VFS receives a syscall targeting a FUSE-mounted path (e.g., open("/mnt/sshfs/file")), it routes the request through /dev/fuse to a user-space FUSE daemon (sshfs, Dropbox, EncFS, etc.) via a kernel↔userspace message protocol. The daemon performs the actual operation (SSH read, decrypt, cloud API call) and sends the result back. The overhead is two kernel/user boundary crossings per syscall vs zero for native filesystems — acceptable for network/encrypted FS where network latency dominates.

Incorrect·B: They are placed sequentially into six specific CPU registers: RDI, RSI, RDX, R10, R8, and R9 (with the syscall number in RAX)

The Linux x86-64 syscall ABI specifies: RAX = syscall number; RDI = arg1; RSI = arg2; RDX = arg3; R10 = arg4; R8 = arg5; R9 = arg6. Note that R10 is used instead of RCX (which SYSCALL overwrites with the return address). The user-mode function calling ABI uses RCX for arg4, but the syscall wrapper substitutes R10. Return value is in RAX. RCX and R11 are destroyed by SYSCALL/SYSRET (SYSRET restores RFLAGS from R11 and RIP from RCX). Any beyond the 6th argument must go via a pointer in one of these registers.