Protected Mode

Aus Lowlevel

Inhaltsverzeichnis 1 Vorwort 2 Der Protected Mode 3 Segmente im Protected Mode 4 Deskriptoren 4.1 Segmentbasisadresse 4.2 Segmentgröße 4.3 Zugriff/Segmenttyp 4.3.1 P = Present Bit 4.3.2 DPL = Deskriptor Privilege Level 4.3.3 S = Segment Bit 4.3.4 Type 4.3.5 A = Accessed Bit 4.4 Zusatz 4.4.1 G = Granular Bit 4.4.2 D 4.4.3 0 4.4.4 AVL = Available 5 Segmenttypen 5.1 Datensegment (Expand-Down) 5.2 Conforming Codesegment 6 Systemsegmente 6.1 Local Deskriptor Table Segment 6.2 Task State Segment (TSS) 6.3 Call Gates 6.3.1 Offset 31 - 16 6.3.2 P = Present 6.3.3 DPL = Deskriptor Privilege Level 6.3.4 0 = Reserviert 6.3.5 Type = Deskriptor Typ 6.3.6 Param = Parameter Count 6.3.7 Selektor 6.3.8 Offset 15 - 0 6.4 Interrupt Gate 6.4.1 Offset 31 - 16 6.4.2 P = Present 6.4.3 DPL = Deskriptor Privilege Level 6.4.4 0 = Reserviert 6.4.5 D = Size 6.4.6 Type = Deskriptor Typ 6.4.7 Selektor 6.4.8 Offset 15 - 0 7 Beispielcode

Vorwort

Dieses Tutorial wird wohl wieder etwas umfangreicher und vor allem mit viel Theorie bestückt sein. Auch wenn Theorie oft langweilig scheint. Bei diesem Thema ist es unerlässlich, da man sich im Protected Mode doch recht gut auskennen sollte, wenn man ein eigenes Betriebssystem schreiben möchte.

Und für die Praxisleute werde ich am Ende auch noch etwas Code bereitstellen, wie man in den Protected Mode wechselt und dort herumspielen kann.

Der Protected Mode

Wenn der PC neu gestartet wird, so befindet er sich im sogenannten Real Mode. In diesem Modus wird nur 16-Bit Code benutzt, sowie der Speicher, der adressierbar ist, auf 1 MiB begrenzt, da im Real Mode nur 20 Bit Adressen zur Adressierung des Speichers gebildet werden können.

Im Real Mode gibt es entscheidende Nachteile. Die verschiedenen laufenden Programme werden alle gleich behandelt. Das heißt, jedes Programm kann ohne Einschränkung auf den kompletten Speicher zugreifen und diesen verändern. Auch der Kernel eines Betriebssystems ist nicht geschützt. Somit ist ein Betriebssystem das im Real Mode läuft anfällig für jegliche Art von Viren und Programmierfehlern. Selbst ein einfacher Programmierfehler, welcher verursacht, dass an eine ungewollte Speicheradresse Daten geschrieben werden, kann dazu führen, dass das komplette System zum Absturz gebracht wird oder instabil läuft. Auch könnten Ergebnisse anderer Programme die im Speicher sind verändert werden, was den korrekten Ablauf jenes Programms erheblich stören kann.

Microsoft DOS ist ein Betriebssystem das im Real Mode läuft. Da dieses System früher hauptsächlich von Privatpersonen als Single-User-System genutzt wurde, waren die eben aufgezeigten Sicherheitsrisiken zu vernachlässigen. Zudem kam noch hinzu, dass das Internet noch sehr wenig verbreitet war und daher die Gefahr von Viren und dergleichen ebenfalls zu vernachlässigen war.

Microsoft DOS ist ein gutes Beispiel um die Entwicklung bis hin zum Protected Mode aufzuführen. DOS ist eines der ersten Betriebssysteme die für den Heim-PC entworfen wurden. Dieses war im Gegensatz zu vielen Anderen sehr leicht bedienbar. An Sicherheitsrisiken war damals noch nicht zu denken, da es diese einfach noch nicht gab, mal abgesehen von Programmierfehlern. Zu jener Zeit als DOS erschien, dürfte der Intel 8086 mit 64 KiB Speicher wohl gerade das Maß der Dinge gewesen sein. Da die Rechenleistung und der Arbeitsspeicher begrenzt waren, und es wohl eh kaum in Frage kam, dass mehrere Anwendungen „gleichzeitig“ laufen würden, war der Entwurf von DOS als Single-Task Betriebssystem wohl ausreichend. Später erschien dann der 80186 und der 80286, welcher schon einen größeren Vorteil mit sich brachte. Zum einen war hier schon ein 20 Bit-Adressbus (dieser wurde soweit, ich mich Erinnern kann, bereits schon vor dem 286 eingeführt) mit welchem man einen 1 MiB großen Arbeitsspeicher ansprechen konnte, sowie eine erste Version des Protected Mode. Da dieser Entwurf des Protected Mode wohl nicht sehr gut durchdacht war und auch (meines Wissens nach) nicht sehr oft genutzt wurde, wurde dieser nochmal kräftig überholt und im schließlich erscheinenden 386 eingeführt, welcher nun auch einen Adressbus von 32 Bit besaß, womit man einen 4 GiB (zu dieser Zeit wohl utopisch) großen Arbeitsspeicher ansprechen konnte. Bevor ich nun jedoch aufzähle und im kurzen erkläre, wozu der Protected Mode dient und was er so kann, möchte ich jedoch noch einmal kurz auf einen oft hinterfragtem Umstand eingehen; Die Abwärtskompatibilität. Ja, wer hat diesen Begriff denn nicht schon einmal gehört. Damit ist schlichtweg (in diesem Fall) gemeint, dass neue Hardware so entworfen wird, dass diese auch mit älterer Software zusammenarbeitet. Dies ist auch der hauptsächliche Grund, warum selbst ein Pentium 4 (der wohl üblich meist mit Windows2000 und „besser“ ausgeliefert wird) heute immer noch im Real Mode startet. Man könnte also selbst DOS noch auf einem Pentium 4 betreiben, was natürlich eine Verschwendung der Rechenleistung wäre, mal abgesehen von einem Arbeitsspeicher der heutzutage wohl standardmäßig um die 512 MiB umfassen dürfte. Aus Gründen besagter Abwärtskompatibilität trifft man gerade als Programmierer immer wieder auf komische Software und vor allem Strukturkonstrukte, die etwas merkwürdig vom Aufbau und Inhalt erscheinen mögen. Dies hat selten etwas mit Effizienz, sondern meist vielmehr mit Abwärtskompatibilität zu tun. Daher erscheint es auch meist mehr als witzig, wenn die Intel-Entwickler in einem Register das eine oder andere Bit als „reserved“ ungenutzt lassen um evtl. später bei einem „kleinen“ Prozessorupdate dieses auch noch zu nutzen. Witzig ist es gerade deshalb, weil es selten vorkommt, das ein neu entwickelter Prozessor nur so wenig Änderungen mit sich bringt, bei denen gerade dieses bisher ungenutzte Bit nun benutzt wird. Meistens werden gleich komplette neue Register erstellt. Aber soviel dazu.

So, nun aber zu den Vorteilen die der Protected Mode mit sich bringt:

• Es ist es nun möglich, Programmen eine Privilegstufe zuordnen zu können. Dadurch kann schon einmal zwischen den Programmen unterschieden werden (Beispiel: Anwendungen, Treiber, Kernel).

• Nicht jedes Programm darf jeden Befehl, den der Prozessor zur Verfügung stellt, ausführen. Dazu gehören Befehle, die hauptsächlich vom Kernel benutzt werden, um den Arbeitsablauf des Prozessors zu steuern. Ein normales Anwenderprogramm benötigt diese Befehle meist auch gar nicht. Jedoch ist es einfach sicherer diese erst gar nicht zuzulassen. Man denke nur an Viren.

• Auch wie im Real Mode „kann“ der Arbeitsspeicher in Segmente unterteilt werden. Dieses Unterteilen dient hier nicht mehr dazu, um den kompletten Arbeitsspeicher ansprechen zu können, sondern um Speicherbereiche voneinander abgrenzen zu können. Dazu jedoch später mehr.

• Multitasking wäre theoretisch auch schon im Real Mode möglich gewesen, jedoch bietet der Protected Mode wesentlich bessere Voraussetzungen dafür.

• Ein Programmfehler (sofern nicht im Kernel oder in den Treibern) bringt nun nicht mehr das komplette System zum Absturz. Dies kann zwar auch im Protected Mode noch auftreten, jedoch nur wenn man diesen so einsetzt, das alle Programme (Anwendungen, Kernel, Treiber) mit den gleichen Privilegien ausgestattet sind.

• Ein Programm (sofern nicht der Kernel) kann nun nicht mehr in den Speicher eines anderen Programms schreiben. Auch dies gilt nur bei einer korrekten Anwendung des Protected Mode.

Sicherlich gibt es auch noch weitere Vorteile die der Protected Mode mit sich bringt, jedoch würde es wohl den Rahmen dieses Tutorials sprengen, diese alle bis ins letzte Detail aufzuzählen.

Segmente im Protected Mode

Wie oben schon erwähnt, gibt es auch im Protected Mode Segmente. Diese haben jedoch eine andere Bedeutung als im Real-Mode. Segmente dienen auch im Protected Mode zur Unterteilung des Speichers, jedoch kann die größe und die Anzahl der Segmente "nahezu" beliebig gewählt werden.

Zudem erhalten Segmente eine ganze Reihe von Attributen die bei jedem Speicherzugriff eines Programms innerhalb eines Segmentes überprüft werden.

So wird einem Segment beispielsweise eine Privilegstufe zugeordnet. So kann ein Programm NUR DANN auf ein Segment zugreifen, wenn die Privilegstufe des Programms höher oder gleich hoch ist. Wenn dem nicht so ist, erkennt der Prozessor diesen Fehler und startet automatisch eine Unterroutine (Exception) die vom Kernel bereitgestellt wird. Im einfachsten Falle veranlasst der Kernel dann einfach, das das betreffende Programm beendet wird und aus dem Speicher entfernt wird. Dies garantiert, das das restliche System ohne Beinträchtigung weiterlaufen kann. Damit der Prozessor weiß welche Attribute ein Segment hat, muss dieses dem Prozessor mitgeteilt werden. Dazu wird eine Tabelle (die Global Deskriptor Table, kurz GDT) erstellt. In dieser Tabelle werden sogenannte Deskriptoren eingetragen. Diese Deskriptoren sind 8 Byte lange Speicherbereiche die Ihrerseits nochmal in einzelnen Bereiche unterteilt werden. Diese Bereiche beschreiben dann im einzelnen die Attribute der Segmente. Die Deskriptoren (to describe) beschreiben also die Eigenschaften der Segmente.

Deskriptoren

Hier werde ich nun nochmal im Detail auf Deskriptoren eingehen. Dabei werde ich genauer beschreiben, wie diese Aufgebaut sind und welche Aufgaben die einzelnen Attribute die dort eingetragen werden haben. Dazu schauen wir uns zuerst einmal den allgemeinen Aufbau eines Deskriptoren an.

	Bit 15															Bit 0
Word 1	Segmentgröße Bit 0-15
Word 2	Segmentbasisadresse Bit 0-15
Word 3	Zugriff / Segmenttyp								Segmentbasisadresse Bit 16-23
Word 4	Segmentbasisadresse Bit 24-31								Zusatz				Segmentgröße Bit 16-19
	High Byte								Low Byte

Hier fällt gleich auf, das die Segmentgröße und die Segmentbasisadresse etwas wild verstreut auf die 4 WORDs verteilt sind. Das kommt daher, weil man den Deskriptor zum 286-Prozessor möglichst kompatibel halten wollte.

Um nicht zu viel drum herum zu erzählen werde ich nun mal die einzelnen Felder in diesem Deskriptor erläutern:

Segmentbasisadresse

Das ist die lineare Adresse an welcher das Segment im Speicher beginnt.

Segmentgröße

Das ist die Größe des Segments. Für die Größe werden lediglich 20 Bits verwendet. Diese Bits werden jedoch unterschiedlich interpretiert. Entscheidend ist hierfür das Granular-Bit. Dazu jedoch weiter unten mehr.

Zugriff/Segmenttyp

Hier wird festgelegt welcher Typ(Code,Daten,Stack,System) Segment vorliegt und wie Zugriffsrechte für dieses Segment aussehen.

Zugriff/Segmenttyp (BITs)

7	6	5	4	3	2	1	0
P	DPL		S	Type			A

P = Present Bit

Gibt an ob das Segment im Arbeitsspeicher present ist.

DPL = Deskriptor Privilege Level

Gibt die Privilegstufe an die ein Programm mindestens besitzen muss um auf dieses Segment zugreifen zu dürfen.

S = Segment Bit

Gibt an ob es sich um ein normales Segment(1) oder um ein System-Segment(0) handelt.

Type

Gibt an um was für ein Segment es sich handelt. Dazu eine Tabelle weiter unten.

A = Accessed Bit

Dieses Bit wird beim Zugriff auf das Segment automatisch vom Prozessor gesetzt. Im Falle der Nutzung eines virtuellen Adressraums, kann anhand dieses Bits entschieden werden, ob ein Segment auf die Festplatte ausgelagert werden kann.

Zusatz

Die Bits in diesem Feld geben ebenfalls Charakteristika für das Segment an.

Zusatz (BITs)

7	6	5	4
G	D	0	AVL

G = Granular Bit

Gibt an ob die Segmentgröße in Bytes(0) oder in 4KB(1) Schritten angegeben werden.

D

Dieses Bit gibt an ob es sich um ein Segment für den 286 (Datensegment max 64 KB, Code = 16 Bit, Stack = 16 Bit) oder ein Segment für den 386 (Datensegment max 4 GB, Code = 32 Bit, Stack = 32 Bit) handelt.

0

Dieses Bit ist reserviert und sollte immer auf 0 gesetzt sein.

AVL = Available

Dieses Bit kann vom Systemprogrammierer frei für eigenen Gebrauch benutzt werden oder einfach ignoriert werden.

Segmenttypen

Hier eine Tabelle der normalen Segmenttypen. Systemsegmente werden später erläutert.

TYPE-Feld (BITs)	Beschreibung
000	Datensegment (Schreibgeschützt)
001	Datensegment (Beschreibbar, Lesbar)
010	Reserviert (Nicht benutzen)
011	Datensegment (Expand-Down)
100	Codesegment (Nur Ausführbar, nicht lesbar)
101	Codesegment (Ausführbar und lesbar)
110	Conforming Codesegment (Nur Ausführbar, nicht lesbar)
111	Conforming Codesegment (Ausführbar und lesbar)

Sicherlich sind ein paar Erklärungen zu einzelnen Segmenttypen notwendig, weshalb ich das hier auch gleich mache:

Datensegment (Expand-Down)

Dieses Datensegment "wächst" nach unten. Es ist extra für Stacks entworfen. Ein Stack beginnt in einem Segment am Ende und wächst nach unten. Sollte es nun vorkommen das der Stack über die Grenzen des Segments hinauswächst, so ist es mit diesem Segmenttyp möglich das Segment nach unten zu vergrößern. Beim anlegen dieses Segmentes ist allerdings etwas zu beachten. Das Segment sollte NICHT die lineare Basisadresse 0 haben. Das würde nämlich bedeuten das das Segment nicht mehr vergrößerbar ist. Also muss das Segment irgendwo im Speicher beginnen, so das die Segmenbasisadresse nicht bei 0 sondern an irgendeinem Wert beginnt.

Conforming Codesegment

Normalerweise ist es so, das ein Programm das eine Privilegstufe 3 (niedrigste) über ein sog. Call-Gate in ein Codesegment springen kann, das eigentlich nur für ein Programm der Privilegstufe 0 (höchste) gedacht ist. Sollte nun dieser Sprung erfolgen, so erhält das Programm für die Dauer, in der es sich in diesem Codesegment befindet um dort Code auszuführen, die Privilegstufe 0. In einem Conforming Codesegment ist das nicht so. Es ist zwar auch hier möglich durch ein Call-Gate in dieses Codesegment zu springen, jedoch wird das Program weiterhin mit der Privilegstufe 3 ausgeführt. Wozu das im einzelnen dienlich sein kann, kann ich im Moment noch nicht sagen ,weshalb ich dazu rate sich erst einmal mit den normalen Codesegmenten zu begnügen.

Um das erstellen von Deskriptoren etwas zu vereinfachen, habe ich ein kleines Konsolenprogramm für Windows geschrieben, mit dem man sich bequem über eine Auswahl den Deskriptor zusammenbauen kann und bekommt diesen dann zum direkten abtippen fertig geliefert.

Systemsegmente

Wie im obigen Abschnitt schon erwähnt gibt es auch sogenannte Systemsegmente. Diese haben alle eine spezielle Aufgabe und stellen auch nicht alle ein Segment im Sinne eines Arbeitsspeicherabschnitts dar. Genauer gesagt handelt es sich bei den meisten Systemsegmenten vielmehr um lediglich Deskriptoren die Informationen für spezielle Zwecke beinhalten.

Hier eine Liste der Systemsegmente und deren Verwendungszweck:

Local Deskriptor Table Segment

Dieses Segment stellt einen Speicherabschnitt dar, der eine Local Deskriptor Table (LDT) beinhaltet. Um diese LDT zu laden wird der Befehl LLDT mit der Angabe des Selektors für dieses Segment benutzt.

Task State Segment (TSS)

Siehe: Task State Segment

Call Gates

In der Regel ist es so, das lediglich das Betriebssystem das mit der Privilegstfue 0 arbeitet zugang zu der Hardware und dem gesamten Speicher hat. Ein Benutzerprogramm, das für gewöhnlich mit der Privilegstufe 3 arbeitet, ist daher sehr eingeschränkt und darf von Haus aus lediglich Standardbefehle ausführen und auch nur Daten im eigenen Adressraum verändern und benutzen. Folglich wäre das Benutzerprogramm sehr unattraktiv und hätte kaum einen nützlichen Verwendungszweck. Daher gibt es die Call Gates. Das sind Deskriptoren in der GDT, die auf ein Codesegment zeigen das eine höhere Privilegstufe besitzt als das Benutzerprogramm. Das Benutzerprogramm kann nun einen Call zu diesem Call Gate machen, was zur Folge hat das es dem Benutzerprogramm gestattet wird, Code in einer höheren Privilegstufe auszuführen. Dieser Code stammt jedoch nicht vom Benutzerprogramm selbst, sondern vom Betriebssystem oder einem Treiber. Außerdem definiert ein Call Gate nicht nur das Code Segment in dem sich der ausführbare, höher privilegierte Code, befindet, sondern auch die genaue Adresse. Sprich das Offset des Codes innerhalb des Segmentes. Somit ist es möglich einem Benutzerprogramm auf eine kontrollierte Art und Weise Zugang zu Systemfunktionen zu gewähren. Hier gibt es noch eine kleine Besonderheit die zu beachten ist. Bei einem Wechsel der Privilegstufe, der für gewöhnlich die Folge eines Call Gate Aufrufs ist, wird ein anderer Stack benutzt. Für jeden Task gibt es für jede Privilegstufe einen eigenen Stack. Damit nun Parameter die VOR dem Call Gate Aufruf auf den alten Stack gepusht wurden, auch in dem neuen Segment benutzt werden können, werden diese beim Aufruf des Call Gates vom alten Stack in den neuen Stack kopiert. Der Deskriptor des Call Gates beinhaltet ein Feld das angibt, wie viele Parameter zwischen den Stacks kopiert werden sollen. Wenn die Routine in dem neuen Segment abgearbeitet wurde und mittels des RET Befehls wieder zurückgesprungen wird, wird wieder der Stack gewechselt und das Programm erhält wieder seine ursprüngliche Privilegstufe.

Call Gate (BITs) Teil 1

31 - 16	15	14 - 13	12	11 - 8	7 - 5	4 - 0
Offset 31 - 16	P	DPL	0	Type	0	Param

Call Gate (BITs) Teil 2

31 - 24	16 - 0
Selektor	Offset 15 - 0

Offset 31 - 16

Gibt die Bits 31 bis 16 des 32-Bit Offsets innerhalb des Codesegmentes an in dem sich der Code befindet, zu dem über das Call Gate gesprungen werden soll.

P = Present

Gibt an ob das Call Gate gültig ist.

DPL = Deskriptor Privilege Level

Dieses Feld gibt an welche Privilegstufe ein Programm mindestens besitzen muß um dieses Call Gate nutzen zu können.

0 = Reserviert

Type = Deskriptor Typ

Gibt den Deskriptor Typ an. Für ein Call Gate muß hier 1100b eingetragen werden.

Param = Parameter Count

Gibt die Anzahl der Parameter an, die zwischen den Stacks kopiert werden soll, wenn das Call Gate benutzt wird.

Selektor

Hier wird der Selektor des Code Segmentes eingetragen in dem sich der Code befindet, zu dem über das Call Gate gesprungen werden soll.

Offset 15 - 0

Gibt die Bits 15 bis 0 des 32-Bit Offsets innerhalb des Codesegmentes an, in dem sich der Code befindet, zu dem über das Call Gate gesprungen werden soll.

Interrupt Gate

Diese haben in etwa den selben Sinn und Zweck eines Call Gates. Jedoch werden diese in der IDT abgelegt und ein Sprung zu einem Interrupt-Handler erfolgt mittels des Int Befehls. Zudem sind die Interrupt Gates hauptsächlich dazu gedacht Systemfunktionen bereitzustellen, mit der auf das Auftreten eines Hardware-Interrupts reagiert wird. Deshalb wird beim Aufurf eines Interrupt Gates auftomatisch das IF Flag im EFLAGS Register geändert, damit während der Abarbeitung des Interrupt Handlers kein weiterer Interrupt ausgelöst werden kann.

Interrupt Gate (BITs) Teil 1

31 - 16	15	14 - 13	12	11	10 - 8	7 - 0
Offset 31 - 16	P	DPL	0	D	Type	0

Interrupt Gate (BITs) Teil 2

31 - 24	16 - 0
Selektor	Offset 15 - 0

Offset 31 - 16

Gibt die Bits 31 bis 16 des 32-Bit Offsets innerhalb des Codesegmentes an in dem sich der Code befindet, zu dem über das Interrupt Gate gesprungen werden soll.

P = Present

Gibt an ob das Interrupt Gate gültig ist.

DPL = Deskriptor Privilege Level

Dieses Feld gibt an welche Privilegstufe ein Programm mindestens besitzen muß um dieses Interrupt Gate nutzen zu können.

0 = Reserviert

D = Size

Gibt an ob es sich um ein 32-Bit(1) oder ein 16-Bit(0) Segment handelt. Sprich ob sich 32-Bit oder 16-Bit Code darin befindet.

Type = Deskriptor Typ

Gibt den Deskriptor Typ an. Für ein Interrupt Gate muß hier 110b eingetragen werden.

Selektor

Hier wird der Selektor des Code Segmentes eingetragen in dem sich der Code befindet, zu dem über das Interrupt Gate gesprungen werden soll.

Offset 15 - 0

Gibt die Bits 15 bis 0 des 32-Bit Offsets innerhalb des Codesegmentes an, in dem sich der Code befindet, zu dem über das Interrupt Gate gesprungen werden soll.

Beispielcode

Eine knappe Variante in den Protected Mode zu schalten wird hier erklärt.