Wie genau schützt das Betriebssystem den Kernel?

Question

Meine Frage ist, wie genau das Betriebssystem seinen Kernelteil schützt.

Nach dem, was ich gefunden habe, gibt es grundsätzlich 2 Modi: Kernel und Benutzer. Und es sollte einige Bits in Speichersegmenten geben, die anzeigen, ob ein Speichersegment ein Kernel- oder ein User-Space-Segment ist. Aber woher kommen diese Bits? Gibt es einen "Schalter" im Compiler, der Programme als Kernel-Programme kennzeichnet? Und wenn sich beispielsweise ein Treiber im Kernel-Modus befindet, wie verwaltet das Betriebssystem seine Integration in das System, damit keine bösartige Software als Treiber hinzugefügt wird?

Wenn mich jemand in dieser Angelegenheit aufklären könnte, wäre ich sehr dankbar, danke

Answer 1

Die übliche Technik ist die Verwendung einer Funktion des virtuellen Speichermanagers, der in den meisten modernen CPUs vorhanden ist.

Die Funktionsweise dieser Hardware besteht darin, dass sie eine Liste von Speicherfragmenten in einem Zwischenspeicher (Cache) speichert und eine Liste der Adressen, denen sie entsprechen. Wenn ein Programm versucht, einen Speicher zu lesen, der nicht in diesem Cache vorhanden ist, holt die MMU den Speicher nicht einfach aus dem Hauptspeicher, da die Adressen im Cache nur "logische" Adressen sind. Stattdessen ruft sie ein anderes Programm auf, das die Adresse interpretiert und den Speicher von dort abruft, wo er sein sollte.

Dieses Programm, ein so genannter Pager, wird vom Kernel bereitgestellt, und spezielle Flags in der MMU verhindern, dass dieses Programm überschrieben wird.

Wenn dieses Programm feststellt, dass die Adresse dem Speicher entspricht, den der Prozess nutzen soll, liefert es der MMU die physikalische Adresse im Hauptspeicher, die der logischen Adresse entspricht, die das Benutzerprogramm angefordert hat, die MMU holt sie in ihren Cache und setzt die Ausführung des Benutzerprogramms fort.

Wenn es sich bei dieser Adresse um eine "spezielle" Adresse handelt, z. B. für eine im Speicher abgebildete Datei, dann holt der Kernel den entsprechenden Teil der Datei in den Cache und lässt das Programm damit laufen.

Wenn die Adresse in einem Bereich liegt, der zum Kernel gehört, oder wenn das Programm diese Adresse noch nicht für sich selbst reserviert hat, löst der Pager einen SEGFAULT aus und beendet das Programm.

Da es sich bei den Adressen um logische und nicht um physikalische Adressen handelt, können verschiedene Benutzerprogramme dieselben logischen Adressen für verschiedene physikalische Adressen verwenden. Das Kernel-Pager-Programm und die MMU machen dies alles transparent und automatisch.

Dieser Schutz ist bei älteren CPUs (z. B. 80286-CPUs) und einigen Geräten mit sehr geringem Stromverbrauch (z. B. ARM CortexM3- oder Attiny-CPUs) nicht möglich, da es keine MMU gibt; bei diesen Systemen sind alle Adressen physikalische Adressen mit einer 1:1-Entsprechung zwischen Ram und Adressraum.

Answer 2

Der "Schalter" befindet sich eigentlich im Prozessor selbst. Einige Befehle sind nur im Kernel-Modus (auch bekannt als Ring 0 bei i386) verfügbar. Der Wechsel vom Kernel-Modus in den Benutzermodus ist einfach. Allerdings gibt es nicht so viele Möglichkeiten, wieder in den Kernel-Modus zu wechseln. Sie können entweder:

• eine Unterbrechung an den Prozessor senden
• einen Systemaufruf tätigen.

In beiden Fällen hat der Vorgang den Nebeneffekt, dass die Kontrolle an einen vertrauenswürdigen Kernel-Code übertragen wird.

Answer 3

Wenn ein Computer hochfährt, beginnt er mit der Ausführung von Code von einem bekannten Ort aus. Dieser Code lädt schließlich einen Betriebssystemkern in den Speicher und übergibt die Kontrolle an ihn. Der Betriebssystem-Kernel richtet dann die CPU-Speicherabbildung über eine CPU-spezifische Methode ein.

Answer 4

Und wenn sich der Treiber beispielsweise im Kernelmodus befindet, wie verwaltet das Betriebssystem seine Integration in das System, damit keine bösartige Software als Treiber hinzugefügt wird?

Das hängt von der Architektur des Betriebssystems ab. Ich werde Ihnen zwei Beispiele nennen:

1. Linux-Kernel: Ein Treibercode kann sehr leistungsfähig sein. Das Niveau der Schutzmaßnahmen sind folgende:

a) Ein Treiber darf auf eine begrenzte Anzahl von Symbolen im Kernel zugreifen, die mit EXPORT_SYMBOL angegeben werden. Bei den exportierten Symbolen handelt es sich im Allgemeinen um Funktionen. Aber nichts hindert einen Treiber daran, einen Kernel mit wilden Zeigern zu zerstören. Und die Sicherheit bei Verwendung von EXPORT_SYMBOL ist nominell.

b) Ein Treiber kann nur von dem privilegierten Benutzer geladen werden, der die Root-Berechtigung auf der Box hat. Solange also die Root-Rechte nicht verletzt werden, ist das System sicher.

1. Mikrokernel wie QNX: Das Betriebssystem exportiert genügend Schnittstellen zum Benutzer, so dass ein Treiber als User-Space-Programm implementiert werden kann. Daher kann der Treiber zumindest nicht einfach das System zerstören.