Syscall

On every computer runs a management program that stands above everything else: the operating system, i.e. Windows, macOS, Linux, or Android. Normal programs like a browser or a game aren’t allowed to touch the hardware directly. So they can’t write to the hard drive themselves or send data to the internet on their own. Instead, they submit a formal request to the operating system, and this request is called a syscall, in German “Systemaufruf”. The operating system checks the request, does the work, and returns the result. You can think of it like a counter at a government office: you don’t go into the archive yourself, but fill out a form and get the file handed to you.

The boundary between program and operating system

This separation is why a crashed program doesn’t immediately bring down the entire computer. Every program works in its own isolated area. It knows neither the memory of other programs nor the details of the hardware. Only the operating system has full access, and it hands it out only in portions via syscalls.

This makes the syscall the central point for security as well. If an app on your phone wants to turn on your microphone, it has to do so via a system call. That’s exactly the point where the operating system can step in and ask for your permission. Without this bottleneck, there would be no sensible point at which permissions could even be checked. Malware is therefore often recognized by the strange syscall patterns it produces.

A common misconception is that a syscall is simply a normal function call in program code. Technically it’s something different: the processor switches into a privileged operating mode. This mode switch costs time, and that’s exactly where the performance questions discussed below come from.

What happens when switching into the kernel

The core of the operating system is called the kernel. It runs in a mode in which the processor is allowed to do anything. Normal programs run in a restricted mode. A syscall is the regulated transition between the two worlds.

Sequence: The program places a number into a register of the processor, i.e. into a very small, very fast memory location. The number indicates which action is desired. Alongside it, the program places the arguments, such as the file name. It then executes a special instruction that switches the processor into kernel mode. The kernel checks the permissions, carries out the task, and switches back.

As a programmer, you usually don’t see any of this. You write an ordinary line like open(“file.txt”), and a library takes care of the technical part. Linux has around 350 such calls, including read, write, open, and fork. Each one costs roughly one to two microseconds – tiny, but noticeable at millions of calls per second.

Syscalls in servers, containers, and AI systems

Anyone who uses software constantly triggers syscalls without noticing. A single loaded webpage generates thousands of them. The topic becomes interesting where speed or security are concerned. Databases and web servers are specifically built to need as few system calls as possible, because every mode switch eats up time.

In the news, the term mainly comes up in connection with containers. A container is an isolated environment in which software runs on someone else’s servers. Cloud providers use filters there to restrict which syscalls are allowed at all. This way, a program can barely cause damage even after a successful attack.

This also plays a growing role in AI systems. If a language model writes and executes code itself, nobody wants that code to freely access the system. Such code therefore runs in a sandbox, i.e. a heavily restricted area with filtered system calls. The syscall is thus the point at which practical limits are placed on an AI.