System calls need more than just identification—they need data. When you call write(fd, buffer, count), the kernel must receive three arguments: the file descriptor number, a pointer to the data buffer, and the byte count. When you call read(), the kernel must not only receive arguments but also return data to user-supplied buffers.

This data transfer across the privilege boundary is one of the most complex aspects of system call implementation. The kernel must receive arguments efficiently, validate that user-provided pointers are safe to access, copy data between address spaces without creating security vulnerabilities, and handle errors gracefully when things go wrong.

Passing arguments to system calls is more complex than passing arguments to regular functions. Several factors create this complexity:

1. Privilege Boundary

At the trap instruction, execution transitions from Ring 3 to Ring 0. Normal function calling conventions don't apply—there's no direct function call, just a privilege-level change. The kernel and user code have completely separate stacks.

2. Address Space Separation

With virtual memory, the kernel and user space may have different views of memory. A pointer valid in user space might not be directly usable in kernel space (depending on kernel memory model).

3. Security Validation

The kernel cannot trust any data from user space. Every pointer must be validated as pointing to user-accessible memory. Every size argument must be checked for overflow. Every piece of data must be treated as potentially malicious.

4. Performance Requirements

System calls happen billions of times per second globally. The parameter passing mechanism must be highly optimized while maintaining security.

Modern architectures pass system call arguments in registers—the fastest and most direct method. Each architecture defines a convention mapping arguments to specific registers:

*Note: x86-64 uses R10 instead of RCX for the fourth argument because SYSCALL uses RCX to store the return address.

Why Six Arguments?

Six register arguments cover the vast majority of system calls. Looking at Linux:

For the rare cases needing more than six arguments, a pointer to a structure is passed instead.

When system calls need more data than registers can hold, or when data must flow in both directions, memory buffers are used. A pointer to the data is passed in a register.

Common Patterns:

1. Fixed-Size Structures

Calls like stat() return data into a user-provided structure:

struct stat {
    dev_t     st_dev;      // Device ID
    ino_t     st_ino;      // Inode number
    mode_t    st_mode;     // File mode
    nlink_t   st_nlink;    // Number of links
    // ... many more fields (~144 bytes on x86-64)
};

int stat(const char *path, struct stat *statbuf);
// statbuf is a user-space pointer, kernel writes to it

2. Variable-Length Data

Calls like read() and write() transfer variable amounts of data:

ssize_t read(int fd, void *buf, size_t count);
// buf is user-space pointer, count is maximum bytes
// Returns actual bytes read, fills buffer partially or fully

3. String Arguments

Calls like open() take null-terminated path strings:

int open(const char *pathname, int flags);
// pathname is user-space pointer to C string
// Kernel must copy string, find null terminator

Before accessing any user-space memory, the kernel must validate that the pointer is safe. This validation has multiple layers:

Layer 1: Address Range Check

The kernel first verifies that the pointer falls within the user address range, not in kernel space:

// x86-64: User addresses are below 0x00007FFFFFFFFFFF
// Anything higher is kernel space

static inline bool __access_ok(unsigned long addr, unsigned long size)
{
    // Check that addr and addr+size-1 are both in user range
    return likely(addr + size <= TASK_SIZE_MAX) && 
           likely(addr <= addr + size);  // Overflow check
}

Layer 2: Page Table Verification

The memory must be mapped and accessible with appropriate permissions. This is handled during the actual access, not beforehand (because page tables can change).

Layer 3: SMAP (Supervisor Mode Access Prevention)

Modern CPUs (Intel Broadwell+, AMD Zen) implement SMAP, which causes a fault if kernel code tries to access user memory without explicitly enabling access. This provides hardware-level protection against accidental user memory access.

User memory might not be physically present when the kernel tries to access it—it could be swapped out, copy-on-write, or demand-zero. The kernel must handle page faults gracefully during user memory copies.

The Exception Table Mechanism

Linux uses an exception table that maps addresses where faults might occur to fixup code that handles them:

// During copy, if a page fault occurs at certain instructions,
// the kernel can look up what to do:

struct exception_table_entry {
    int insn;   // Relative address of instruction that might fault
    int fixup;  // Relative address of fixup code
};

// When page fault handler runs:
// 1. Look up faulting instruction in exception table
// 2. If found, redirect execution to fixup code
// 3. Fixup code returns error to caller (EFAULT)
// 4. If not found, it's a real kernel bug (panic)

Demand Paging and Kernel Copies

When the kernel accesses user memory that's not present:

1. Page fault occurs in kernel mode
2. Fault handler runs, determines it's a user page
3. If valid: Page is loaded (from disk, allocated, or copy-on-write)
4. Instruction restarts transparently, copy continues
5. If invalid: Look up exception table, jump to fixup which returns EFAULT

This means copy_from_user() can trigger disk I/O if user data is swapped out—the kernel must be prepared for this delay.

String parameters (like file paths) require special handling because their length isn't known until the null terminator is found. The kernel cannot simply call strlen() on a user pointer—this could read arbitrary amounts of kernel memory or crash if the string isn't terminated.

The strncpy_from_user() Function

Path Name Handling: getname()

For filesystem paths specifically, Linux provides optimized functions:

// getname_kernel() - path already in kernel space
// getname()        - path in user space, copies to kernel buffer
// putname()        - releases path buffer

SYSCALL_DEFINE2(stat, const char __user *, filename,
                struct stat __user *, statbuf)
{
    struct filename *name = getname(filename);
    int error;
    
    if (IS_ERR(name))
        return PTR_ERR(name);
    
    error = vfs_stat(name->name, &stat);  // Now safe to use
    putname(name);
    
    // Copy result to user space
    if (!error && copy_to_user(statbuf, &stat, sizeof(stat)))
        error = -EFAULT;
    
    return error;
}

getname() handles:

• Copying the string from user space
• Enforcing PATH_MAX limits
• Allocating kernel memory for the path
• Reference counting for path sharing

Many system calls pass complex data structures. The kernel must copy these safely while handling structure layout differences.

Copying Structures:

Array Arguments:

Some calls pass arrays of items:

// poll() takes an array of file descriptors to monitor
struct pollfd {
    int   fd;         // File descriptor
    short events;     // Events to watch for
    short revents;    // Events that occurred (output)
};

int poll(struct pollfd *fds, nfds_t nfds, int timeout);
// fds points to array of nfds items
// Kernel copies entire array in, modifies revents, copies back

The kernel must:

1. Validate that nfds * sizeof(struct pollfd) doesn't overflow
2. Ensure the total size is reasonable (to prevent denial of service)
3. Allocate kernel memory for the copied array
4. Copy input data in, process it
5. Copy output data back (revents fields)

One of the most subtle security issues in parameter handling is the TOCTOU race condition—where user data changes between when the kernel checks it and when the kernel uses it.

The Classic Attack:

Imagine a vulnerable kernel implementation:

// VULNERABLE CODE - DO NOT USE
SYSCALL_DEFINE2(open, const char __user *, path, int, flags)
{
    // Step 1: Check if user can access the file
    if (!access_ok_for_user(path))  // Reads path from user space
        return -EACCES;
    
    // <-- RACE WINDOW: Another thread changes 'path' in memory
    
    // Step 2: Actually open the file
    return do_open(path);  // Reads path AGAIN from user space
}

An attacker can:

1. Set path to /harmless/file
2. Call open() from thread A
3. Thread B immediately changes path to /etc/shadow
4. The kernel passes the access check for /harmless/file
5. But opens /etc/shadow!

System calls must communicate results back to user space—both success values and error conditions. Different conventions exist across operating systems.

Linux/UNIX Convention:

System calls return a single value in a register (RAX on x86-64):

• Success: Return value is meaningful (bytes read, file descriptor, PID, etc.)
• Error: Return value is negative, where -return_value is the errno

Return Value          Meaning
≥ 0                   Success (value is result)
-1 to -4095           Error (-value is errno)
< -4095               Should never happen (kernel bug)

The C library translates this:

// glibc syscall wrapper (simplified)
long syscall_wrapper(long syscall_num, ...) {
    long result = do_syscall(syscall_num, ...);
    
    if (result >= -4095UL && result <= -1UL) {
        // Error: convert to errno
        errno = -result;
        return -1;
    }
    return result;
}

We've explored the mechanisms for passing data between user space and the kernel—a seemingly simple operation that requires careful attention to security, correctness, and performance.

What's Next:

We've now covered how arguments get to the kernel and how errors are reported. The final piece of the system call mechanism is returning to user mode—how the kernel restores user state and transitions back to Ring 3 execution. We'll examine the return path, signal delivery, and the complete round-trip of a system call.