Systemaufrufe unter Linux sind keine zulässigen Einträge in den Kernel

Unter Linux sind Systemaufrufe die einzige Möglichkeit für den Benutzerbereich, auf den Kernel zuzugreifen. Sie sind der einzige legale Zugang zum Kernel. Tatsächlich werden andere Methoden wie Gerätedateien und /proc letztendlich über Systemaufrufe ausgeführt.

Normalerweise werden Anwendungen über Anwendungsprogrammier-Sockets (APIs) und nicht direkt über Systemaufrufe programmiert, und diese Programmier-Sockets müssen nicht unbedingt den vom Kernel bereitgestellten Systemaufrufen entsprechen. Eine API definiert eine Reihe von Programmier-Sockets, die von Anwendungen verwendet werden. Sie können als ein Systemaufruf oder durch den Aufruf mehrerer Systemaufrufe implementiert werden. Auch wenn keine Systemaufrufe verwendet werden, stellt dies kein Problem dar. Tatsächlich können APIs auf einer Vielzahl unterschiedlicher Betriebssysteme implementiert werden und stellen genau die gleichen Sockets für Anwendungen bereit, ihre Implementierung auf solchen Systemen kann jedoch sehr unterschiedlich sein.

In der Unix-Welt basieren die beliebtesten Anwendungsprogrammier-Sockets auf dem POSIX-Standard und Linux ist POSIX-kompatibel.

Aus Sicht der Programmierer müssen sie sich nur mit der API befassen, und der Kernel befasst sich nur mit Systemaufrufen. Wie Bibliotheksfunktionen und Anwendungen Systemaufrufe verwenden, ist nicht die Angelegenheit des Kernels.

Systemaufrufe (in Linux oft als Systemaufrufe bezeichnet) werden im Allgemeinen über Funktionen aufgerufen. Sie erfordern im Allgemeinen die Definition eines oder mehrerer Parameter (Eingaben) und können einige Nebenwirkungen haben. Dieser Nebeneffekt wird durch einen langen Rückgabewert dargestellt, der Erfolg (0-Wert) oder Fehler (negativer Wert) anzeigt. Wenn bei einem Systemaufruf ein Fehler auftritt, wird der Fehlercode in die globale Variable errno geschrieben. Durch Aufruf der Funktion perror() kann diese Variable in einen für den Benutzer verständlichen Fehlerstring übersetzt werden.

Bei der Implementierung von Systemaufrufen gibt es zwei Besonderheiten: 1) In der Funktionsdeklaration gibt es einen Asmlinkage-Qualifizierer, der verwendet wird, um den Compiler zu benachrichtigen, nur die Parameter der Funktion aus dem Stapel zu extrahieren. 2) Der Systemaufruf getXXX() ist im Kernel als sys_getXXX() definiert. Dies ist die Namenskonvention, der alle Systemaufrufe unter Linux folgen sollten.

Systemaufrufnummer: Unter Linux wird jedem Systemaufruf eine Systemaufrufnummer zugewiesen, und der Systemaufruf kann dieser eindeutigen Nummer zugeordnet werden. Wenn ein User-Space-Prozess einen Systemaufruf ausführt, wird die Systemaufrufnummer verwendet, um anzugeben, welcher Systemaufruf ausgeführt werden soll. Der Name des Systemaufrufs wird vom Prozess nicht angegeben. Sobald die Systemaufrufnummer zugewiesen ist, kann sie nicht mehr geändert werden (andernfalls stürzt die kompilierte Anwendung ab). Wenn ein Systemaufruf gelöscht wird, darf die von ihm belegte Systemaufrufnummer nicht wiederverwendet werden. Linux verfügt über einen „unbenutzten“ Systemaufruf sys_ni_syscall(), der nicht nur -ENOSYS zurückgibt, sondern auch keine andere Arbeit ausführt. Diese Fehlernummer ist speziell für ungültige Systemaufrufe gedacht. Es scheint selten, aber wenn ein Systemaufruf gelöscht wird, ist diese Funktion dafür verantwortlich, „die Lücke zu füllen“.

Der Kernel zeichnet eine Liste aller registrierten Systemaufrufe in der Systemaufruftabelle auf und speichert sie in sys_call_table. Es ist architekturbezogen und wird normalerweise in Eintrag.s definiert. Diese Tabelle weist jedem gültigen Systemaufruf eine eindeutige Systemaufrufnummer zu.

Für User-Space-Programme ist es schwierig, Kernel-Code direkt auszuführen. Sie können Funktionen im Kernelraum nicht direkt aufrufen, da sich der Kernel in einem geschützten Adressraum befindet. Die Anwendung sollte das System in irgendeiner Form benachrichtigen und dem Kernel mitteilen, dass sie einen Systemaufruf ausführen muss, und das System wechselt in den Kernelstatus Linux-Kernel-Aufruf, damit der Kernel den Systemaufruf im Namen der Anwendung ausführen kann. Diese Mechanismen zur Benachrichtigung des Kernels werden durch Soft-Interrupts implementiert. Soft-Interrupts auf x86-Systemen werden durch die Anweisung int$0x80 gebildet. Diese Anweisung löst eine Ausnahme aus, wodurch das System in den Kernelmodus wechselt und den Ausnahmehandler Nr. 128 ausführt. Dieses Programm ist der Systemaufrufhandler und heißt system_call(). Es hängt eng mit der Hardwarearchitektur zusammen und ist allgemein gültig im Eintrag In Assemblersprache in .s-Datei kompiliert.

Alle Systemaufrufe werden im Kernel in der gleichen Form abgefangen wie beim Linux-System mit der roten Flagge, daher reicht es nicht aus, nur den Kernelraum abzufangen. Daher muss die Systemrufnummer an den Kernel übergeben werden. Auf x86 wird diese Übertragung dadurch erreicht, dass die Rufnummer vor dem Auslösen des Softirq in das EAX-Register eingetragen wird. Auf diese Weise können die Daten von eax abgerufen werden, sobald der Systemaufruf-Handler ausgeführt wird. Der oben erwähnte system_call() überprüft die Gültigkeit der angegebenen Systemrufnummer, indem er sie mit NR_syscalls vergleicht. Wenn es kleiner oder gleich NR_syscalls ist, gibt die Funktion -ENOSYS zurück. Andernfalls wird der entsprechende Systemaufruf ausgeführt: call*sys_call_table(,%eax,4);

Da die Einträge in der Systemaufruftabelle im 32-Bit-Typ (4 Byte) gespeichert sind, muss der Kernel die angegebene Systemaufrufnummer durch 4 teilen und dann das Ergebnis verwenden, um die Position des Geräts in der Tabelle abzufragen . Wie in Abbildung 1 dargestellt:

Es wurde bereits erwähnt, dass nicht nur die Systemrufnummer, sondern auch einige externe Parametereingaben erforderlich sind. Der einfachste Weg besteht darin, diesen Parameter in einem Register zu speichern, genau wie die Übergabe der Systemrufnummer. Auf x86-Systemen speichern ebx, ecx, edx, esi und edi die ersten 5 Parameter der Reihe nach. Im unwahrscheinlichen Fall, dass sechs oder mehr Parameter erforderlich sind, sollte ein separates Register verwendet werden, um Zeiger zu speichern, die auf die User-Space-Adressen aller dieser Parameter zeigen. Rückgabewerte an den Benutzerbereich werden ebenfalls über Register übergeben. Auf x86-Systemen wird es im EAX-Register gespeichert.

Systemaufrufe müssen sorgfältig prüfen, ob alle Parameter zulässig und gültig sind. Systemaufrufe werden im Kernel-Space ausgeführt. Wenn Benutzern erlaubt wird, illegale Eingaben an den Kernel weiterzuleiten, wird die Sicherheit und Stabilität des Systems auf eine harte Probe gestellt. Der wichtigste Test besteht darin, festzustellen, ob der vom Benutzer bereitgestellte Überwachungszeiger gültig ist. Bevor der Kernel einen Benutzerraum-Überwachungszeiger erhält, muss der Kernel Folgendes sicherstellen:

1) Der Videospeicherbereich, auf den der Zeiger zeigt, gehört zum Benutzerbereich

2) Der Speicherbereich, auf den die Zählernadel zeigt, befindet sich im Adressraum des Prozesses

3) Beim Lesen sollte der Lesespeicher als lesbar markiert werden. Beim Schreiben sollte der Speicher als beschreibbar markiert sein.

Der Kernel bietet zwei Möglichkeiten, die erforderliche Erkennung durchzuführen und Daten zwischen Kernel- und Benutzerraum hin und her zu kopieren. Eine dieser beiden Methoden muss aufgerufen werden.

copy_to_user(): Daten in den Benutzerbereich schreiben, hierfür sind 3 Parameter erforderlich. Der erste Parameter ist die Zielspeicheradresse im Prozessraum. Die zweite ist die Quelladresse im Kernel-Space

.Der dritte Wert ist die Datenbreite (Anzahl der Bytes), die kopiert werden muss.

copy_from_user(): Das Lesen von Daten aus dem Benutzerbereich erfordert 3 Parameter. Der erste Parameter ist die Zielspeicheradresse im Prozessraum. Die zweite ist die Quelle im Kernel-Space

Adresse. Die dritte ist die Datenbreite (Anzahl der Bytes), die kopiert werden muss.

Hinweis: Beides kann zu Verstopfungen führen. Diese Situationen treten auf, wenn Seiten mit Benutzerdaten auf die Festplatte und nicht im Rechenspeicher ausgelagert werden. Zu diesem Zeitpunkt ruft der Linux-Kernel auf und der Prozess ruht, bis der Seitenfehlerbehandler die Seite von der Festplatte zurück in den chemischen Speicher ersetzt.

Der Kernel befindet sich beim Ausführen eines Systemaufrufs im Prozesskontext und der aktuelle Zeiger zeigt auf die aktuelle Aufgabe, also den Prozess, der den Systemaufruf verursacht hat. Im Kontext eines Prozesses kann der Kernel schlafen (z. B. wenn ein Systemaufruf blockiert oder explizit Schedule() aufruft), aber er kann belegt sein. Wenn der Systemaufruf zurückkehrt, verbleibt die Kontrolle bei system_call(), das letztendlich dafür verantwortlich ist, in den Benutzerbereich zu wechseln und dem Benutzerprozess die weitere Ausführung zu ermöglichen.

Es ist sehr einfach, eine Systemaufrufzeit zu Linux hinzuzufügen. Wie man einen Systemaufruf entwirft und implementiert, ist das Dilemma. Der erste Schritt bei der Implementierung eines Systemaufrufs besteht darin, seinen Zweck zu bestimmen. Dieser Zweck sollte klar und eindeutig sein. Versuchen Sie nicht, einen Mehrzweck-Systemaufruf zu schreiben. ioctl ist ein Back-End-Lehrmaterial. Die Parameter, Rückgabewerte und Fehlercodes des neuen Systemaufrufs sind sehr wichtig. Sobald ein Systemaufruf kompiliert ist, ist die Registrierung als bevorstehender Systemaufruf eine mühsame Aufgabe, die normalerweise den folgenden Schritten folgt:

1) Fügen Sie einen Eintrag am Ende der Systemaufruftabelle hinzu (normalerweise in Eintrag.s). Von 0 an ist die Position eines Systemeintrags in der Tabelle seine Systemrufnummer. So wie das erste

Der Systemrufnummer 9 sind 10 Systemaufrufe zugeordnet

2) Für jede Architektur muss die Systemaufrufnummer in include/asm/unistd.h

definiert werden

3) Systemaufrufe müssen in das Kernel-Image kompiliert werden (können nicht in Module kompiliert werden). Dies muss nur in eine entsprechende Datei unter kernel/ eingefügt werden.

Im Allgemeinen werden Systemaufrufe von der C-Bibliothek unterstützt. Benutzerprogramme können Systemaufrufe verwenden (oder Bibliotheksfunktionen verwenden, die tatsächlich von den Bibliotheksfunktionen aufgerufen werden), indem sie Standard-Header-Dateien einbinden und mit der C-Bibliothek verknüpfen. Glücklicherweise bietet Linux selbst eine Reihe von Makros für den direkten Zugriff auf Systemaufrufe. Es setzt das Register und ruft die Anweisung int$0x80 auf. Dieses Makro heißt _syscalln(), wobei n zwischen 0 und 6 liegt. Es stellt die Anzahl der Parameter dar, die an den Systemaufruf übergeben werden müssen. Dies liegt daran, dass das Makro genau wissen muss, wie viele Argumente in welcher Reihenfolge in die Register geschoben werden. Nehmen Sie als Beispiel den offenen Systemaufruf:

Der Systemaufruf open() ist wie folgt definiert:

longopen(constchar*filename,intflags,intmode)

Der Weg, das Makro dieses Systemaufrufs direkt aufzurufen, ist:

#defineNR_open5

_syscall3(long,open,constchar*,filename,int,flags,int,mode)

Auf diese Weise kann die Anwendung open() direkt verwenden. Rufen Sie einfach den Systemaufruf open() auf und platzieren Sie das Makro direkt in der Anwendung. Für jedes Makro gibt es 2+2*n Parameter. Die Bedeutung jedes Parameters ist einfach und klar und wird hier nicht im Detail erläutert.

Das obige ist der detaillierte Inhalt vonSystemaufrufe unter Linux sind keine zulässigen Einträge in den Kernel. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!