Ein Systemaufruf ist ein festgelegter Einstieg in den Kernel, über den User-Space-Code einen Vorgang anfordert, etwa eine Datei zu öffnen, Speicher abzubilden, einen Prozess zu erzeugen oder Netzwerkdaten zu senden. Der Kernel prüft Argumente, Zugangsdaten, Objektzustand und Sicherheitsrichtlinie, bevor er die Anfrage ausführt.
Kernel · Lektion 3
Systemaufrufe
Erfahre, wie User-Space-Code Linux-Kerneldienste aufruft und wie du Aufrufe sicher mit `strace` untersuchst.
Bibliotheken und die Systemaufruf-ABI
Anwendungen rufen gewöhnlich Funktionen der C-Bibliothek auf, statt architekturspezifische Einstiegsanweisungen selbst zu schreiben. Eine Bibliothekskapselung bereitet Register und Speicher gemäß der Systemaufruf-ABI vor, tritt in den Kernel ein und übersetzt das Ergebnis in die Konvention der jeweiligen Sprache.
Die Beziehung ist nicht immer eine Funktion zu einem Systemaufruf:
- Eine Bibliotheksfunktion kann mehrere Systemaufrufe verbinden.
- Manche Funktionen arbeiten vollständig im User-Space.
- Eine optimierte vDSO-Funktion kann bestimmte vom Kernel gepflegte Daten ohne vollständigen Modusübergang beziehen.
- Ein Systemaufruf kann viele übergeordnete APIs unterstützen.
Was tut eine typische Systemaufrufkapselung von libc?
In den Kernel eintreten und zurückkehren
Die Kapselung legt eine Systemaufrufnummer und Argumente an architekturseitig festgelegten Orten ab und führt anschließend eine Einstiegsanweisung wie syscall auf x86-64 oder svc auf AArch64 aus. Der Prozessor wechselt zu einem konfigurierten privilegierten Einstiegspunkt, und der Kernel leitet die Anfrage weiter.
Nach dem Abschluss gibt der Kernel einen Wert oder eine Fehleranzeige zurück. Kapselungen der C-Bibliothek geben bei Fehlern gewöhnlich -1 zurück und setzen das Thread-lokale errno. Andere Sprachen und Laufzeiten stellen unterschiedliche Fehlertypen bereit.
Jeden Einstieg als „Software-Interrupt“ zu bezeichnen, ist auf aktuellen Architekturen ungenau. Traps, schnelle Systemaufrufanweisungen und Supervisor-Aufrufe implementieren verwandte kontrollierte Übergänge auf unterschiedliche Weise.
Wer validiert die Argumente und Autorisierung eines Systemaufrufs?
Nummern und Kompatibilität
Systemaufrufnummern und Aufrufkonventionen sind architekturspezifisch. Derselbe symbolische Aufruf kann in einer anderen ABI eine andere Nummer oder Strukturaufteilung besitzen. Kernelveröffentlichungen können Systemaufrufe hinzufügen, während stabile User-Space-ABIs bestehendes Verhalten bewahren sollen.
Ein unprivilegierter Prozess kann keine beliebigen neuen Handler in die Syscall-Tabelle des laufenden Kernels einfügen. Eine Erweiterung der Schnittstelle erfordert Kernelcode und einen sorgfältigen ABI-Entwurf. Funktionen wie seccomp können filtern, welche Aufrufe ein Prozess ausführen darf, erzeugen aber keine neuen Kernelimplementierungen.
Warum sollte eine Anwendung keine Systemaufrufnummern einer anderen Architektur fest codieren?
Mit `strace` verfolgen
Verfolge einen einfachen Befehl und speichere die Ausgabe getrennt:
$ strace -o trace.log -- ls
Folge autorisierten Kindprozessen mit -f oder begrenze die Ausgabe mit einem Ausdruck wie:
$ strace -f -e trace=%file -o trace.log -- command
strace kann Pfade, Argumente, aus der Umgebung stammende Daten, Netzwerkadressen, Fragmente von Dateiinhalten und fälschlich über Argumente übergebene Zugangsdaten offenlegen. Speichere Traces mit restriktiven Berechtigungen und entferne sie gemäß der Richtlinie für Vorfallsdaten.
Was beobachtet strace in erster Linie?
Traces sorgfältig interpretieren
Tracing verändert Zeitabläufe und kann erheblichen Mehraufwand verursachen. Ein fehlgeschlagener Aufruf kann eine erwartete Prüfung sein, und der am Ende sichtbare Fehler kann aus einem früheren Vorgang oder einer Anwendungsrichtlinie entstehen. Löse Dateideskriptoren auf, verfolge Prozessbeziehungen und setze die Angaben mit Anwendungsprotokollen in Beziehung.
Berechtigungen und ptrace-Sicherheitsrichtlinien schränken ein, welche Prozesse verfolgt werden können. Hänge dich nicht ohne Autorisierung an den Prozess eines anderen Benutzers oder einen Produktivprozess; Unterbrechungen und Zeitveränderungen können das Dienstverhalten beeinflussen.
Bedeutet ein einzelner fehlgeschlagener Systemaufruf in einem Trace zwangsläufig, dass die Anwendung defekt ist?
Lektion abgeschlossen
Sie haben Systemaufrufe abgeschlossen
Du kannst einen Systemaufruf nun von der Bibliotheks-API bis zur validierten Kernelarbeit verfolgen.
Trenne übergeordnete Funktionen von der Systemaufruf-ABI.
Setze architekturspezifische Einstiegsanweisungen mit kontrollierter Kernelweiterleitung in Beziehung.
Behandle Systemaufrufnummern und Strukturen als architekturspezifisch.
Verwende gefilterte
strace-Ausgaben und schütze dabei vertrauliche Daten.Interpretiere Fehler und Tracing-Mehraufwand im Anwendungskontext.
Lernfortschritt speichern
Erstellen Sie ein kostenloses Konto, um diese Lektion zu speichern und auf jedem Gerät weiterzulernen.
Kostenloses Konto erstellen