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

CheckWhat does a typical libc system-call wrapper do?

Prepare ABI arguments, enter the kernel, and translate the result. Give the application unrestricted access to kernel memory. Recompile the kernel each time the function is called.

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.

CheckWho validates a system call's arguments and authorization?

The shell prompt before the process starts. The kernel implementation of the requested service. The disk partition table.

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.

CheckWhy should an application avoid hard-coding syscall numbers from another architecture?

Numbers and calling conventions are ABI-specific. System calls are named from the current working directory. Every process receives a random syscall table at startup.

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.

CheckWhat does strace primarily observe?

Only source-code lines executed inside the application. System calls and signals at the user-kernel boundary. The physical voltage of each CPU core.

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.

CheckDoes one failed syscall in a trace necessarily mean the application is broken?

Yes; every nonzero return immediately terminates Linux. No; programs often probe alternatives and handle expected errors. Yes; the kernel never returns expected errors.

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.