System Calls

A system call is a defined entry into the kernel through which user-space code requests an operation such as opening a file, mapping memory, creating a process, or sending network data. The kernel validates arguments, credentials, object state, and security policy before performing the request.

Libraries and the System-Call ABI

Applications commonly call C library functions rather than writing architecture-specific entry instructions. A library wrapper prepares registers and memory according to the system-call ABI, enters the kernel, and translates the result into its language-level convention.

The relationship is not always one function to one syscall:

• a library function can combine several system calls
• some functions operate entirely in user space
• an optimized vDSO function can obtain certain kernel-maintained data without a full mode transition
• one system call can support many higher-level APIs

Entering and Returning from the Kernel

The wrapper places a system-call number and arguments in architecture-defined locations, then executes an entry instruction such as syscall on x86-64 or svc on AArch64. The processor switches to a configured privileged entry point and the kernel dispatches the request.

After completion, the kernel returns a value or an error indication. C library wrappers commonly return -1 and set thread-local errno for errors. Other languages and runtimes expose different error types.

Calling every entry a “software interrupt” is imprecise on current architectures; traps, fast system-call instructions, and supervisor calls implement related controlled transitions differently.

Numbers and Compatibility

System-call numbers and calling conventions are architecture-specific. The same symbolic call can have a different number or structure layout on another ABI. Kernel releases can add system calls, while stable user-space ABIs aim to preserve existing behavior.

An unprivileged process cannot insert arbitrary new handlers into the running kernel's syscall table. Extending the interface requires kernel code and careful ABI design. Features such as seccomp can filter which calls a process is allowed to make, but do not create new kernel implementations.

Tracing with strace

Trace a simple command and save output separately:

$ strace -o trace.log -- ls

Follow child processes where authorized with -f, or narrow output with an expression such as:

$ strace -f -e trace=%file -o trace.log -- command

strace can reveal paths, arguments, environment-derived data, network addresses, file content fragments, and credentials passed incorrectly through arguments. Store traces with restrictive permissions and remove them according to incident-data policy.

Interpreting Traces Carefully

Tracing changes timing and can impose substantial overhead. A failed call may be an expected probe, and the final visible error can result from an earlier operation or application policy. Decode file descriptors, follow process relationships, and correlate with application logs.

Permissions and ptrace security policy restrict which processes can be traced. Do not attach to another user's or a production process without authorization; suspension and timing changes can affect service behavior.

Summary

You can now trace a system call from library API to validated kernel work.

1. Separate high-level functions from the system-call ABI.
2. Relate architecture entry instructions to controlled kernel dispatch.
3. Treat syscall numbers and structures as architecture-specific.
4. Use filtered strace output while protecting sensitive data.
5. Interpret failures and tracing overhead in application context.