<?xml version="1.0"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="de">
	<id>https://wiki-de.moshellshocker.dns64.de/index.php?action=history&amp;feed=atom&amp;title=Privilegienstufe</id>
	<title>Privilegienstufe - Versionsgeschichte</title>
	<link rel="self" type="application/atom+xml" href="https://wiki-de.moshellshocker.dns64.de/index.php?action=history&amp;feed=atom&amp;title=Privilegienstufe"/>
	<link rel="alternate" type="text/html" href="https://wiki-de.moshellshocker.dns64.de/index.php?title=Privilegienstufe&amp;action=history"/>
	<updated>2026-06-25T13:50:12Z</updated>
	<subtitle>Versionsgeschichte dieser Seite in Wikipedia (Deutsch) – Lokale Kopie</subtitle>
	<generator>MediaWiki 1.43.8</generator>
	<entry>
		<id>https://wiki-de.moshellshocker.dns64.de/index.php?title=Privilegienstufe&amp;diff=214829&amp;oldid=prev</id>
		<title>imported&gt;BrunoBoehmler: /* ARM */ Halbgeviertstrich</title>
		<link rel="alternate" type="text/html" href="https://wiki-de.moshellshocker.dns64.de/index.php?title=Privilegienstufe&amp;diff=214829&amp;oldid=prev"/>
		<updated>2026-04-13T22:24:22Z</updated>

		<summary type="html">&lt;p&gt;&lt;span class=&quot;autocomment&quot;&gt;ARM: &lt;/span&gt; Halbgeviertstrich&lt;/p&gt;
&lt;p&gt;&lt;b&gt;Neue Seite&lt;/b&gt;&lt;/p&gt;&lt;div&gt;Die &amp;#039;&amp;#039;&amp;#039;Privilegienstufe&amp;#039;&amp;#039;&amp;#039; ([[Englische Sprache|engl.]] &amp;#039;&amp;#039;privilege level&amp;#039;&amp;#039;) bezeichnet (im Umfeld der [[Betriebssystem]]-Programmierung und des [[Multitasking]]s) eine Privilegierungs- bzw. Sicherheitsstufe des gerade laufenden [[Programmcode]]s. Es handelt sich um eine Funktion der Hardware, durch die der auf der [[Prozessor|CPU]] nutzbare [[Befehlssatz]] und der verwendbare [[Speicherbereich]] dynamisch eingeschränkt werden kann. Die Nutzung von Privilegierungsebenen ist sinnvoll, um die [[Hardwareabstraktionsschicht|Hardware zu abstrahieren]] und um [[Prozess (Informatik)|Prozesse]] voneinander und vom Betriebssystem und [[Gerätetreiber|Treibern]] abzuschotten.&lt;br /&gt;
&lt;br /&gt;
Je nach Prozessorarchitektur wird die Privilegienstufe auch &amp;#039;&amp;#039;&amp;#039;Ring&amp;#039;&amp;#039;&amp;#039;, &amp;#039;&amp;#039;Schutzring&amp;#039;&amp;#039; oder &amp;#039;&amp;#039;Domain&amp;#039;&amp;#039; genannt.&lt;br /&gt;
&lt;br /&gt;
== Privilegienstufen verschiedener Architekturen ==&lt;br /&gt;
{{Anker|Systemmodus}}Es gibt verschiedene Privilegienmodelle. Während manche Architekturen wie x86 sehr viele Privilegienstufen besitzen, existiert bei anderen Architekturen nur eine Zweiteilung in Benutzermodus ({{enS|user mode}}) und Systemmodus bzw. Kernelmodus ({{enS|kernel mode}}).&lt;br /&gt;
&lt;br /&gt;
=== x86 ===&lt;br /&gt;
[[Datei:CPU ring scheme.svg|mini|Schema der Ringe beim [[X86-Prozessor|x86]]-System mit Gates zur Kommunikation]][[Intel 80286|Intel-80286]]-kompatible Prozessoren unterscheiden vier Privilegierungsstufen: Ring&amp;amp;nbsp;0, 1, 2 und 3. Dabei stellt Ring&amp;amp;nbsp;0, genannt „{{lang|en|supervisor mode}}“, die höchste Privilegierungsstufe dar, die bis zur Stufe&amp;amp;nbsp;3 (Ring&amp;amp;nbsp;3) immer weiter eingeschränkt wird. Beispiele für [[Maschinenbefehl]]e, die im Ring&amp;amp;nbsp;0, jedoch nicht im Ring&amp;amp;nbsp;3 ausgeführt werden dürfen, sind z.&amp;amp;nbsp;B. „cli“ und „sti“. Mit diesen Anweisungen wird die Behandlung von (maskierbaren) [[Hardwareinterrupt]]s ab- bzw. eingeschaltet. Ursprünglich waren die Ringe für den Kernel (Ring 0), Treiber (Ring 1), Systemdienste (Ring 2) und Anwendungsprogramme (Ring 3) vorgesehen.&lt;br /&gt;
&lt;br /&gt;
Um Prozesse in einem geschützten Bereich (Ring&amp;amp;nbsp;&amp;gt; 0) ablaufen zu lassen, wird der physikalische [[Arbeitsspeicher]] in [[Virtuelle Speicherverwaltung|virtuelle Speicherseiten]] aufgeteilt. Zu jeder [[Speicherseite]] existiert eine Tabelle, in der unter anderem gespeichert ist, in welchem Level (Ring) der Programmcode, der innerhalb dieser Speicherseite gespeichert ist, ausgeführt wird. Diese Auswertung nimmt die [[Memory Management Unit|MMU]] meist extern vor.&lt;br /&gt;
&lt;br /&gt;
==== Wechsel zwischen den Ringen ====&lt;br /&gt;
Für einen Wechsel des Rings stehen drei Gate-Typen zur Verfügung, die bei ihrer Verwendung unterschiedlich viel Rechenzeit in Anspruch nehmen, da jeder Wechsel von einem Ring zum anderen auch einen [[Kontextwechsel]] zumindest einiger Zustände in der CPU darstellt:&lt;br /&gt;
# Call-Gates für den direkten Aufruf von Programmcode aus höheren Privilegierungsebenen. Das Call-Gate bestimmt dabei, an welcher Stelle und mit welchen Privilegien der aufgerufene Programmcode laufen wird. Aus Sicherheitsgründen wird hierbei dem Programmcode aus der höheren Privilegierungsebene ein eigener [[Stapelspeicher|Stapel]] zugewiesen, die Aufrufparameter vom Stapel des aufrufenden Codes werden in den neuen Stapel kopiert. Im Übrigen läuft der privilegierte Code im Kontext des aufrufenden Codes.&lt;br /&gt;
# Interrupt-Gates werden zum einen beim Auslösen eines so genannten Software-Interrupts verwendet, aber auch Hardware-Interrupts erfordern ein Interrupt-Gate. Zusätzlich zu allen Schritten, die beim Benutzen eines Call-Gates durchgeführt werden, wird zusätzlich das Flags-Register auf dem Stapel gespeichert und weitere Interrupts bis zur Rückkehr der Interrupt-Routine gesperrt.&lt;br /&gt;
# Task-Gates erlauben die Kontrolle an einen anderen Prozess abzugeben. Dies stellt die aufwändigste Form eines Kontextwechsels dar, da hier der vollständige Prozessorzustand des aufrufenden Prozesses gespeichert und des aufgerufenen Prozesses geladen werden muss.&lt;br /&gt;
&lt;br /&gt;
==== Betriebssysteme auf x86 ====&lt;br /&gt;
Die verbreiteten Betriebssysteme für x86 [[Linux]] und [[Microsoft Windows|Windows]] (sowie [[macOS]] für x64 und DOS mit [[EMM386.EXE]]-Speichermanager) nutzen lediglich zwei der vier möglichen CPU-Ringe. Im Ring&amp;amp;nbsp;0 werden der Kernel und alle Hardwaretreiber ausgeführt, während die Anwendungssoftware im unprivilegierten Ring&amp;amp;nbsp;3 arbeitet. Damit bleibt die [[Plattformunabhängigkeit|Portabilität]] des Betriebssystems auch auf Prozessorarchitekturen gewährleistet, die nur zwei Privilegierungsstufen unterscheiden können. [[OS/2]] benutzt allerdings Ring&amp;amp;nbsp;2 für Grafiktreiber.&amp;lt;ref name=&amp;quot;warpspeed_os2_drivers&amp;quot;&amp;gt;{{Webarchiv |url=http://www.warpspeed.com.au/cgi-bin/inf2html.cmd?..%5Chtml%5Cbook%5Cddk%5CPDRREF.INF+5 |text={{lang|en|Presentation Device Driver Reference for OS/2}} |wayback=20130616221644 |archiv-bot=2019-05-10 06:15:45 InternetArchiveBot}} auf warpspeed.com (englisch)&amp;lt;/ref&amp;gt; Eine speziell angepasste Version des Speichermanagers EMM386 aus dem Entwicklungskit für DOS [[Protected Mode]] Services (für [[Novell DOS]] 7, OpenDOS 7.01 und DR-DOS 7.02 und höher) lässt DPMS auf Ring&amp;amp;nbsp;1 statt auf Ring&amp;amp;nbsp;0 laufen und erleichtert so die Fehlersuche bei Software, die DPMS nutzt.&lt;br /&gt;
&lt;br /&gt;
Manche [[Virtualisierung (Informatik)|Virtualisierungslösungen]] verwenden auch Ring&amp;amp;nbsp;1. Hierbei wird der Betriebssystemkern aus Ring&amp;amp;nbsp;0 in Ring&amp;amp;nbsp;1 verschoben, der [[Hypervisor]] residiert dann als darüberliegende Schicht in Ring&amp;amp;nbsp;0 und verwaltet einen oder mehrere in Ring&amp;amp;nbsp;1 laufende Betriebssystemkerne. Dies kann allerdings auch durch [[Rootkit]]s ausgenutzt werden, um [[Schadcode]] unbemerkt vom Anwender auf dem Ring&amp;amp;nbsp;0 ausführen zu lassen (siehe auch [[Virtual Machine Based Rootkit]]).&lt;br /&gt;
&lt;br /&gt;
==== {{Anker|Ring 0|Kernel-Mode|Kernel-Modus}}Ring 0 (Kernel-Mode) ====&lt;br /&gt;
Im innersten Ring (höchste Berechtigungsstufe; privilegierte Ebene; System-Ebene; Kern-Ebene) läuft meist das [[Betriebssystem]], evtl. sogar nur dessen [[Kernel (Betriebssystem)|Kernel]] und damit dessen [[Kernel (Betriebssystem)#Bestandteile|Bestandteile]] wie &amp;#039;&amp;#039;[[Prozessverwaltung]]&amp;#039;&amp;#039;, &amp;#039;&amp;#039;[[Speicherverwaltung]]&amp;#039;&amp;#039;, &amp;#039;&amp;#039;[[Geräteverwaltung]]&amp;#039;&amp;#039;, &amp;#039;&amp;#039;[[Dateisysteme]]&amp;#039;&amp;#039; und &amp;#039;&amp;#039;[[Hardwareabstraktionsschicht|Schnittstellen zur Hardware]]&amp;#039;&amp;#039;. Das Betriebssystem &amp;#039;&amp;#039;darf alles,&amp;#039;&amp;#039; insbesondere direkte Hardwarezugriffe und das Eingreifen in die [[Random-Access Memory|RAM]]-Bereiche anderer Prozesse. Je nach Aufbau des Kernels werden [[Gerätetreiber|Treiber]] auch in Ring&amp;amp;nbsp;0 ausgeführt, was bei den meisten Betriebssystemen der Fall ist.&lt;br /&gt;
&lt;br /&gt;
Code auf dieser Stufe darf&amp;amp;nbsp;…&lt;br /&gt;
&lt;br /&gt;
* alle CPU-Anweisungen ausführen&lt;br /&gt;
* auf [[Speicherverwaltung|jeden Speicherbereich]] zugreifen&lt;br /&gt;
* auf [[Eingabe und Ausgabe|E-/A]]-Geräte zugreifen (über [[Gerätetreiber|Treiber]])&lt;br /&gt;
&lt;br /&gt;
==== {{Anker|Ring 1|Ring 2}}Ring 1 und 2 ====&lt;br /&gt;
Diese Ringe sind zwischen Kernel- und Benutzermodus. Programme, die in dieser Stufe laufen, dürfen daher zwar weniger als der Kernel, aber mehr als Programme im Benutzermodus. Da diese Ringe jedoch in vielen anderen [[Prozessorarchitektur]]en nicht vorhanden sind, werden sie bei den meisten Betriebssystemen nicht genutzt – so verwenden z.&amp;amp;nbsp;B. diverse [[Unix]][[Unixoides System|-Systeme]], [[Windows&amp;amp;nbsp;NT]] und [[Linux (Kernel)|Linux]] dasselbe Kernel-Design auf einer Vielzahl unterschiedlicher Befehlssatzarchitekturen, von denen die meisten nur einen privilegierten Modus (Kernelmodus, bei x86 Ring&amp;amp;nbsp;0) und einen unprivilegierten Modus (Benutzermodus, bei x86 Ring&amp;amp;nbsp;3) bieten.&lt;br /&gt;
&lt;br /&gt;
Ein Beispiel für ein Betriebssystem, das [[Gerätetreiber]] im Ring 2 ausführt, ist [[OS/2]] auf der 32-Bit-x86-Architektur [[IA-32]].&amp;lt;ref name=&amp;quot;warpspeed_os2_drivers&amp;quot; /&amp;gt;&lt;br /&gt;
&lt;br /&gt;
==== {{Anker|Ring 3|User-Mode|Benutzer-Modus}}Ring 3 (User-Mode) ====&lt;br /&gt;
[[Computerprogramm|Anwendungsprogramme]] sind üblicherweise auf den äußersten Ring beschränkt (niedrigste Berechtigungsstufe). Für Operationen, welche einen Hardwarezugriff erfordern, müssen Anwendungsprogramme Betriebssystem-Dienste beauftragen.&lt;br /&gt;
&lt;br /&gt;
==== {{Anker|Ring -1|Hypervisor-Mode|Hypervisor-Modus}}Ring −1 (Hypervisor-Modus) ====&lt;br /&gt;
Um die Verwendung von [[Hypervisor]]en zu vereinfachen, führen neuere CPUs von [[Intel]] und [[AMD]] einen neuen „Ring&amp;amp;nbsp;–1“ ein, so dass der Betriebssystemkern in Ring&amp;amp;nbsp;0 verbleibt, während der Hypervisor als darüberliegende Schicht in Ring&amp;amp;nbsp;–1 residiert. Dabei verwaltet er einen oder mehrere Betriebssystemkerne in Ring&amp;amp;nbsp;0.&lt;br /&gt;
&lt;br /&gt;
==== {{Anker|Ring -2|System Management Mode|Systemverwaltungsmodus}}Ring −2 (Systemverwaltungsmodus) ====&lt;br /&gt;
Da moderne Systeme immer komplexer wurden, begannen CPUs ab dem Intel 386SL einen [[System Management Mode|Systemverwaltungsmodus]] zu implementieren, der, [[firmware]]ähnlich, grundlegende „interne“ Hardwarefunktionalität implementierte. Dieser wird unter anderem für Systemereignisse, Temperatur- und Energieverwaltung, [[SMBIOS]], [[ACPI]] und Sicherheitsfunktionen verwendet.&lt;br /&gt;
&lt;br /&gt;
==== {{Anker|Ring -3|Intel Management Engine|Platform Security Processor}}Ring −3 (Intel Management Engine / AMD Platform Security Processor) ====&lt;br /&gt;
Seit 2008 besitzen moderne Computer zudem ein unsichtbares, vollständig unabhängiges System mit nicht genau bekannter Funktionalität, mit noch höheren Privilegien, das selbst im „ausgeschalteten“ Zustand weiterläuft. Auf Intel-Systemen ist dies die [[Intel Active Management Technology|Management Engine]] und auf AMD-Systemen der [[AMD Security Processor|Platform Security Processor]].&lt;br /&gt;
&lt;br /&gt;
=== ARM ===&lt;br /&gt;
Auf den [[Arm-Architektur|ARM-Architekturen]] werden die Privilegienstufen als &amp;#039;&amp;#039;Exception Levels&amp;#039;&amp;#039;, d.&amp;amp;nbsp;h. Ausnahmestufen, bezeichnet. Dies ist darin begründet, dass der Übergang zwischen Privilegienstufen nur mittels Auftreten einer Ausnahme oder Rückkehr von einer [[Ausnahmebehandlung]] möglich ist.&amp;lt;ref&amp;gt;{{Internetquelle |url=https://developer.arm.com/documentation/102412/0103/Privilege-and-Exception-levels |titel=Learn the architecture – AArch64 Exception Model: Privilege and Exception levels |werk=ARM Developer Documentation |hrsg=Arm Limited |datum=2022 |sprache=en |abruf=2023-12-15}}&amp;lt;/ref&amp;gt; Auf AArch64 (Armv8 und später) gibt es vier Exception Levels, die mit EL0 bis EL3 bezeichnet werden. Dabei ist EL0 das unprivilegierte Exception Level und die anderen Exception Levels sind privilegiert. Die [[virtuelle Speicherverwaltung]] weist den Speicherbereichen entsprechend privilegierte (für Zugriffe aus EL1-EL3) und unprivilegierte (für Zugriffe aus EL0) Zugriffsrechte zu. Jedem Systemregister ist ein kleinstes Exception Level zugewiesen, aus welchem der Zugriff auf dieses erlaubt ist. Dies ist auch im Registernamen angegeben, so beispielsweise &amp;lt;code&amp;gt;VBAR_EL1&amp;lt;/code&amp;gt; für die Startadresse der Ausnahmevektortabelle, auf die nur aus Exception Level 1 und höher zugegriffen werden kann.&lt;br /&gt;
&lt;br /&gt;
Je nach Implementierung können EL2 und EL3 auch nicht implementiert sein, nur EL0 und EL1 sind verpflichtend auf allen ARM-Plattformen. Falls EL3 nicht implementiert ist, besitzt der Prozessor einen nicht änderbaren Sicherheitszustand, da dieser nur aus EL3 geändert werden könnte.&lt;br /&gt;
&lt;br /&gt;
==== {{Anker|EL0}}Exception Level 0 ====&lt;br /&gt;
EL0 ist für [[Anwendungsprogramm]]e vorgesehen. Der Zugriff auf die meisten Systemregister ist aus EL0 nicht möglich. EL0 teilt sich die MMU-Konfiguration mit EL1. Um Funktionen des Betriebssystems abzurufen ([[Systemaufruf]]), kann ein Programm unter EL0 eine synchrone Ausnahme mittels &amp;lt;code&amp;gt;svc&amp;lt;/code&amp;gt; (&amp;#039;&amp;#039;Supervisor Call&amp;#039;&amp;#039;) auslösen, welche den Prozessor in EL1 versetzt und die EL1-Ausnahmebehandlung aufruft.&lt;br /&gt;
&lt;br /&gt;
==== {{Anker|EL1}}Exception Level 1 ====&lt;br /&gt;
EL1 ist für [[Betriebssystem]]e vorgesehen. EL1 kann seine eigene MMU-Konfiguration (entsprechend der MMU-Konfiguration von EL0) ändern und auf Systemregister zugreifen, die EL1 und EL0 beeinflussen. Zur Kommunikation mit einem Hypervisor in EL2 dient der &amp;lt;code&amp;gt;hvc&amp;lt;/code&amp;gt;-Befehl.&lt;br /&gt;
&lt;br /&gt;
==== {{Anker|EL2}}Exception Level 2 ====&lt;br /&gt;
EL2 ist für [[Hypervisor]]en vorgesehen. EL2 hat Zugriff auf Konfigurationen zur [[Virtualisierung (Informatik)|Virtualisierung]] mehrerer Betriebssysteme. Es können Aufrufe an den Secure Monitor (via &amp;lt;code&amp;gt;smc&amp;lt;/code&amp;gt;) aus EL1 abgefangen werden, um beispielsweise einen Secure Monitor zu emulieren.&lt;br /&gt;
&lt;br /&gt;
==== {{Anker|EL3}}Exception Level 3 (ARM TrustZone) ====&lt;br /&gt;
EL3 ist für [[Firmware]] oder einen &amp;#039;&amp;#039;Secure Monitor&amp;#039;&amp;#039; vorgesehen. Aus EL3 kann der Sicherheitsmodus des Prozessors umgeschaltet werden, sodass Betriebssysteme und [[Hypervisor]]en verwaltet werden können, die in einer sicheren Betriebsart (oder &amp;#039;&amp;#039;Modus&amp;#039;&amp;#039;) ausgeführt werden (bei [[Arm-Architektur|ARM]] in der &amp;#039;&amp;#039;{{lang|en|TrustZone}}&amp;#039;&amp;#039;, also in [[ARM Holdings Limited|ihrem]] eigenen Sicherheits- oder auch [[Vertrauen]]sbereich). EL3 selbst wird (außer auf manchen Armv9-Systemen) immer im sicheren Modus ausgeführt. Ist der sichere Modus implementiert, kann Software aus EL2 Funktionen des Secure Monitor mittels des &amp;lt;code&amp;gt;smc&amp;lt;/code&amp;gt;-Befehls (&amp;#039;&amp;#039;Secure Monitor Call&amp;#039;&amp;#039;) abrufen.&lt;br /&gt;
&lt;br /&gt;
=== RISC-V ===&lt;br /&gt;
Der &amp;#039;&amp;#039;Privilege Mode&amp;#039;&amp;#039;, oft einfach Mode, von [[RISC-V]] hat drei Stufen, genannt U-Mode (für „User“), S-Mode (für „Supervisor“) und M-Mode (für „Machine“). Dabei müssen nicht alle Modi implementiert sein; die folgenden Konfigurationen sind möglich:&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot;&lt;br /&gt;
|+&lt;br /&gt;
!Implementierte Modi&lt;br /&gt;
!Vorgesehen für&lt;br /&gt;
|-&lt;br /&gt;
|M&lt;br /&gt;
|einfache Embedded-Systeme&lt;br /&gt;
|-&lt;br /&gt;
|M, U&lt;br /&gt;
|sichere Embedded-Systeme&lt;br /&gt;
|-&lt;br /&gt;
|M, S, U&lt;br /&gt;
|übliche Betriebssysteme&lt;br /&gt;
|}&lt;br /&gt;
Dazu kommt die Hypervisor-Erweiterung, die U- und S-Mode in VU, HU, VS und HS aufteilt. Die virtuellen Modi werden von virtualisierten Betriebssystemen genutzt, während die Hypervisor-Modi vom Hypervisor-Betriebssystem und seinen Anwendungsprogrammen genutzt wird. Auch der Debug-Modus einer debugbaren Implementierung ist streng genommen ein eigener Privilegienmodus, der Zugriff auf Register und Speicherbereiche hat, die aus dem M-Mode nicht benutzt werden können.&lt;br /&gt;
&lt;br /&gt;
Die Kommunikation zwischen den Modi geschieht mittels Umgebungsaufrufen durch den &amp;lt;code&amp;gt;ecall&amp;lt;/code&amp;gt;-Befehl, was jeweils eine Anfrage an den nächstniedrigeren Modus stellt. Ein Umgebungsaufruf vom U-Mode an den S-Mode ist also ein [[Systemaufruf]], ein Umgebungsaufruf vom S-Mode an den M-Mode ein Aufruf an die Firmware, und ein Umgebungsaufruf vom VS-Mode an den HS-Mode ein Aufruf an virtuelle Firmware, also ein &amp;#039;&amp;#039;Hypercall&amp;#039;&amp;#039; bzw. Hypervisor-Aufruf. Außerdem werden Interrupts von niedrigeren Modi behandelt. Standardmäßig behandelt M-Mode alle Interrupts, die Behandlung einzelner Interrupts kann von dort an S-Mode abgegeben werden.&lt;br /&gt;
&lt;br /&gt;
==== U-Mode ====&lt;br /&gt;
Der U-Mode (&amp;#039;&amp;#039;User/Application&amp;#039;&amp;#039;) ist für [[Anwendungsprogramm]]e gedacht, was auch die Anwendungssoftware in sicheren Embedded-Systemen einschließt. U-Mode hat keinen Zugriff auf Kontroll- und [[Statusregister]] (CSRs), die Hardwarefunktionen konfigurieren, und unterliegt (falls implementiert) der [[Virtuelle Speicherverwaltung|virtuellen Speicherverwaltung]], sodass der Zugriff auf Speicherbereiche eingeschränkt ist. Es ist nicht möglich, Interrupts im U-Mode zu behandeln.&lt;br /&gt;
&lt;br /&gt;
==== S-Mode ====&lt;br /&gt;
S-Mode (&amp;#039;&amp;#039;Supervisor&amp;#039;&amp;#039;) ist für [[Betriebssystem]]e gedacht. S-Mode kann jeden Speicher aller Programme lesen und schreiben, einen Großteil des Systems konfigurieren, sofern M-Mode dies zulässt, und Traps (Interrupts und Ausnahmen) behandeln. Auch ein Hypervisor wird im S-Mode ausgeführt, dieser kann zusätzlich auf die CSRs zur Konfiguration der virtualisierten Systeme zugreifen und ihren Speicher lesen. S-Mode hat keinen Zugriff auf PMP (&amp;#039;&amp;#039;Physical Memory Protection&amp;#039;&amp;#039;), was es M-Mode erlaubt, bestimmte Speicherbereiche auch vor dem Betriebssystem abzusichern.&lt;br /&gt;
&lt;br /&gt;
==== M-Mode ====&lt;br /&gt;
M-Mode (&amp;#039;&amp;#039;Machine&amp;#039;&amp;#039;) ist für [[Firmware]] gedacht, bzw. für die Software in sehr einfachen Embedded-Systemen oder [[Mikrocontroller]]n, die effektiv keine Privilegienmodi besitzen. M-Mode hat als einziger Modus uneingeschränkt Zugriff auf alle Speicherbereiche und CSRs. Eine CPU wird im M-Mode gestartet, und die Firmware übergibt im Laufe des Bootprozesses die Kontrolle an ein Betriebssystem im S-Mode. Standardmäßig werden alle Traps im M-Mode behandelt, was z.&amp;amp;nbsp;B. die Emulation fehlender Befehle oder Hardwarefunktionen in Firmware erlaubt. M-Mode kann allerdings bestimmte Traps an S-Mode-Software delegieren (mittels &amp;lt;code&amp;gt;mideleg&amp;lt;/code&amp;gt; und &amp;lt;code&amp;gt;medeleg&amp;lt;/code&amp;gt;), beispielsweise für die virtuelle Speicherverwaltung. In der Regel ist der Code, der im M-Mode ausgeführt wird, nicht veränder- oder beeinflussbar, ähnlich wie [[Intel Management Engine|IME]] oder [[AMD Platform Security Processor|PSP]]. Eine verbreitete Softwareplattform für M-Mode-Firmware ist das [[Open Source|offene]] [[OpenSBI]].&lt;br /&gt;
&lt;br /&gt;
=== Andere ===&lt;br /&gt;
Die bei x86-Prozessoren vorgenommene Einteilung in vier Privilegienstufen bzw. Ringe wurde schon früher eingesetzt, z.&amp;amp;nbsp;B. bei der [[Virtual Address eXtension|VAX]]. Der [[Alpha-Prozessor]] unterstützt einen zusätzlichen geschützten Bereich für dessen [[PAL-Code]], welcher mit Ring&amp;amp;nbsp;−1 auf x86 oder M-Mode auf RISC-V vergleichbar ist. Die [[Honeywell 6180]], das erste System mit Hardware-Unterstützung für dieses Konzept, kannte acht Privilegienstufen.&lt;br /&gt;
&lt;br /&gt;
== {{Anker|Kernelmodus|Benutzermodus|Kernelspace|Systemspace|Userspace}}Umsetzung ==&lt;br /&gt;
Der Befehlssatz wird für unprivilegierte Prozesse –&amp;amp;nbsp;auch als &amp;#039;&amp;#039;&amp;#039;userspace&amp;#039;&amp;#039;&amp;#039; oder &amp;#039;&amp;#039;&amp;#039;userland&amp;#039;&amp;#039;&amp;#039; bezeichnet bzw. teils vollständig als [[User-Thread]] implementiert&amp;amp;nbsp;– derart eingeschränkt, dass sie nicht direkt auf die Hardware zugreifen können und sich auch nicht aus ihrer Privilegierungsebene befreien können. Der Zugriff auf den [[Speicherbereich]] anderer Prozesse wird meist durch [[Virtuelle Speicherverwaltung|Speichervirtualisierung]] verhindert. Somit wird gewährleistet, dass Programmcode in niedrigeren Privilegienstufen nicht eigenmächtig auf Programmcode oder Daten des Kernels und anderer Systemdienste in höheren Privilegienstufen zugreifen kann. Die gleiche Speichervirtualisierung wird üblicherweise auch eingesetzt, um unterschiedliche Prozesse voneinander zu isolieren. Da die unprivilegierten Prozesse auf Hardware nicht direkt zugreifen können, existieren sogenannte „{{lang|en|Gates}}“, mit denen Programmcode aus höheren Stufen Programmcode aus niedrigeren Stufen aufrufen kann, insbesondere ist so die [[Programmierschnittstelle]] des [[Kernel (Betriebssystem)|Kernels]] erreichbar, um die notwendigen Aktionen anzufordern.&lt;br /&gt;
&lt;br /&gt;
In der CPU und ggf. [[Memory Management Unit|MMU]] müssen Schaltungen bestehen, die bei jedem Befehl bzw. [[Speicherzugriff]] prüfen, ob dieser in der aktuellen Privilegienstufe erlaubt ist. Falls ein Prozess etwas nicht Erlaubtes durchführen möchte, wird er unterbrochen und eine Betriebssystem-Routine aufgerufen, deren Aufgabe es ist, entsprechend zu reagieren.&lt;br /&gt;
&lt;br /&gt;
Die meisten Prozessor-Architekturen bieten mindestens zwei Privilegienstufen:&lt;br /&gt;
Programmcode in der höchstprivilegiertesten Stufe befindet sich im &amp;#039;&amp;#039;&amp;#039;Kernelmodus&amp;#039;&amp;#039;&amp;#039; (engl. &amp;#039;&amp;#039;„{{lang|en|kernel mode}}“&amp;#039;&amp;#039;), &amp;#039;&amp;#039;&amp;#039;Kernelraum&amp;#039;&amp;#039;&amp;#039; (engl. &amp;#039;&amp;#039;„{{lang|en|kernel space}}“&amp;#039;&amp;#039;) oder ist &amp;#039;&amp;#039;&amp;#039;Superuser-Code&amp;#039;&amp;#039;&amp;#039; (engl. &amp;#039;&amp;#039;„{{lang|en|super user code}}“&amp;#039;&amp;#039;) – alle anderen im &amp;#039;&amp;#039;&amp;#039;Benutzermodus&amp;#039;&amp;#039;&amp;#039; (engl. &amp;#039;&amp;#039;„{{lang|en|user mode}}“&amp;#039;&amp;#039;) oder &amp;#039;&amp;#039;&amp;#039;Benutzerraum&amp;#039;&amp;#039;&amp;#039; (engl. &amp;#039;&amp;#039;„{{lang|en|user space}}“&amp;#039;&amp;#039;).&lt;br /&gt;
&lt;br /&gt;
=== Ablauf eines Betriebssystemaufrufs ===&lt;br /&gt;
Ein (mit niedriger Berechtigung laufender) Prozess wählt durch geeignetes Setzen von CPU-Registern und Speicherbereichen die auszuführende Funktion des Betriebssystems und setzt die benötigten Parameter. Anschließend löst er per CPU-Befehl einen [[Softwareinterrupt]] aus. Der Prozess wird dadurch unterbrochen, die CPU wechselt in eine höhere Privilegienstufe („Kernel mode“) und setzt die Ausführung mit einer speziellen Betriebssystem-Routine fort. Diese sichert zunächst weitere (CPU-)Zustände, die nicht von der CPU selbst im Rahmen des Softwareinterrupts bereits gesichert wurden, um beispielsweise freie Register für das eigene Ablaufen zu haben. Anschließend agiert sie gemäß dem angeforderten Auftrag: Sie übergibt ihn an den zuständigen Treiber, reiht ihn in eine Warteschlange zur Abarbeitung durch einen Kernel-Thread ein oder kann evtl. den Auftrag selbst ausführen. In den ersten beiden Fällen wird anschließend meist ein vollständiger [[Kontextwechsel]] zu einem anderen Prozess durchgeführt, da der aufrufende Prozess erst weiter laufen kann, wenn das Betriebssystem den Auftrag vollständig abgearbeitet hat. Sobald der Auftrag vollständig abgearbeitet wurde, legt die Betriebssystem-Routine die Rückgabewerte in die Speicherbereiche des Prozesses ab und vermerkt ggf. weitere Rückgabewerte für bestimmte CPU-Register in dessen Prozesskontext. Der anfordernde Prozess wird als „bereit“ markiert und später im Rahmen des regulären [[Scheduling]]s wieder (mittels Kontextwechsel) fortgesetzt: Eine spezielle CPU-Instruktion schließt den Kontextwechsel ab, die CPU „kehrt aus dem Softwareinterrupt zurück“, wodurch die CPU wieder in den User-Mode (niedrigste Privilegienstufe) zurück wechselt und die Ausführung des niedrig-berechtigten Prozesses direkt nach der Unterbrechungsstelle fortsetzt.&lt;br /&gt;
&lt;br /&gt;
== Einzelnachweise ==&lt;br /&gt;
&amp;lt;references /&amp;gt;&lt;br /&gt;
&lt;br /&gt;
== Weblinks ==&lt;br /&gt;
* https://stackoverflow.com/questions/18717016/what-are-ring-0-and-ring-3-in-the-context-of-operating-systems&lt;br /&gt;
&lt;br /&gt;
[[Kategorie:Betriebssystemtheorie]]&lt;/div&gt;</summary>
		<author><name>imported&gt;BrunoBoehmler</name></author>
	</entry>
</feed>