Schema in zwei Ebenen: oben das Anwendungsprogramm im eingeschränkten Benutzermodus, unten der Kernel im privilegierten Modus, dazwischen eine Grenzlinie. Ein Pfeil vom Programm nach unten trägt die Beschriftung Syscall-Nummer plus Argumente, ein Rückpfeil nach oben das Ergebnis. Unter dem Kernel führen Pfeile zu Festplatte, Netzwerk und Arbeitsspeicher.

Syscall

Ein Syscall ist die Anfrage eines Programms an das Betriebssystem, etwas zu tun, das das Programm nicht selbst darf – etwa eine Datei öffnen oder Daten übers Netz schicken. Über diese kontrollierte Schnittstelle laufen praktisch alle Zugriffe auf Festplatte, Netzwerk und Speicher.

Auf jedem Computer läuft ein Verwaltungsprogramm, das über allem anderen steht: das Betriebssystem, also Windows, macOS, Linux oder Android. Normale Programme wie ein Browser oder ein Spiel dürfen die Hardware nicht direkt anfassen. Sie können also nicht selbst auf die Festplatte schreiben oder Daten ins Internet schicken. Stattdessen stellen sie eine formale Anfrage an das Betriebssystem, und diese Anfrage heißt Syscall, auf Deutsch Systemaufruf. Das Betriebssystem prüft die Anfrage, erledigt die Arbeit und gibt das Ergebnis zurück. Man kann sich das wie einen Schalter in einer Behörde vorstellen: Man geht nicht selbst ins Archiv, sondern füllt ein Formular aus und bekommt die Akte gereicht.

Die Grenze zwischen Programm und Betriebssystem

Diese Trennung ist der Grund, warum ein abgestürztes Programm nicht gleich den ganzen Rechner mitreißt. Jedes Programm arbeitet in seinem eigenen abgeschotteten Bereich. Es kennt weder den Speicher anderer Programme noch die Details der Hardware. Nur das Betriebssystem hat den vollen Zugriff, und es gibt ihn nur portionsweise über Syscalls weiter.

Damit ist der Syscall auch die zentrale Stelle für Sicherheit. Wenn eine App auf dem Handy dein Mikrofon einschalten will, muss sie das über einen Systemaufruf tun. Genau dort kann das Betriebssystem einhaken und dich um Erlaubnis fragen. Ohne diese Engstelle gäbe es keinen sinnvollen Punkt, an dem Rechte überhaupt geprüft werden könnten. Schadsoftware wird deshalb häufig daran erkannt, welche merkwürdigen Syscall-Muster sie erzeugt.

Ein verbreiteter Irrtum ist, ein Syscall sei einfach ein normaler Funktionsaufruf im Programmcode. Technisch ist er etwas anderes: Der Prozessor wechselt dabei in einen privilegierten Betriebsmodus. Dieser Moduswechsel kostet Zeit, und genau daraus ergeben sich die Leistungsfragen weiter unten.

Was beim Umschalten in den Kernel passiert

Der Kern des Betriebssystems heißt Kernel. Er läuft in einem Modus, in dem der Prozessor alles darf. Normale Programme laufen in einem eingeschränkten Modus. Ein Syscall ist der geregelte Übergang zwischen beiden Welten.

Ablauf: Das Programm legt eine Nummer in ein Register des Prozessors, also in einen sehr kleinen, sehr schnellen Speicherplatz. Die Nummer sagt, welche Aktion gewünscht ist. Daneben legt es die Argumente ab, etwa den Dateinamen. Dann führt es einen speziellen Befehl aus, der den Prozessor in den Kernel-Modus schaltet. Der Kernel prüft die Rechte, erledigt die Aufgabe und schaltet zurück.

Als Programmierer sieht man davon meist nichts. Man schreibt eine gewöhnliche Zeile wie open(« datei.txt »), und eine Bibliothek erledigt den technischen Teil. Linux kennt rund 350 solcher Aufrufe, darunter read, write, open und fork. Jeder einzelne kostet ungefähr ein bis zwei Mikrosekunden – winzig, aber bei Millionen Aufrufen pro Sekunde spürbar.

Syscalls in Servern, Containern und KI-Systemen

Wer Software benutzt, löst permanent Syscalls aus, ohne es zu merken. Eine einzige geladene Webseite erzeugt tausende davon. Interessant wird das Thema dort, wo es um Geschwindigkeit oder Sicherheit geht. Datenbanken und Webserver werden gezielt so gebaut, dass sie möglichst wenige Systemaufrufe brauchen, weil jeder Moduswechsel Zeit frisst.

In den Nachrichten taucht der Begriff vor allem bei Containern auf. Ein Container ist eine abgeschottete Umgebung, in der Software auf fremden Servern läuft. Cloud-Anbieter beschränken dort per Filter, welche Syscalls überhaupt erlaubt sind. So kann ein Programm auch nach einem erfolgreichen Angriff kaum Schaden anrichten.

Auch bei KI-Systemen spielt das eine wachsende Rolle. Wenn ein Sprachmodell selbst Code schreibt und ausführt, will niemand, dass dieser Code frei auf das System zugreift. Solcher Code läuft deshalb in einer Sandbox, also einem stark eingeschränkten Bereich mit gefilterten Systemaufrufen. Der Syscall ist damit die Stelle, an der man einer KI praktische Grenzen setzt.

Subscribe free. Unsubscribe the second it sucks.

High-signal news across AI, business, UX, and tech. Every morning.