Für solch eine Schutzinfrastruktur werden hardwareseitig mehrere Typen von Schutzeinheiten bereitgestellt. Einer der drei vorhandenen Typen ist die Speicherschutzeinheit (MPU). Jedem Master im System ist eine dedizierte MPU zugeordnet, die dessen ausgehende Zugriffe ins System kontrolliert.
Zum Schutz auf Ressourcenseite sind zwei Typen von Einheiten sinnvoll: die »shared MPU« (SMPU) zum Schutz gemeinsam genutzten Speichers und die Peripherieschutzeinheit (PPU) zum Schutz der einzelnen Peripherien. Der Unterschied zwischen den beiden Schutzeinheiten besteht darin, dass durch SMPUs der Speicher in Regionen mit variabler Größe und unterschiedlichen Zugriffsrechten aufgeteilt werden kann, mit PPUs lässt sich hingegen der Zugriff auf bereits definierte Ressourcenbereiche wie Peripheriemodule festlegen. Abhängig von Adresse und Zugriffsattributen wie Lesen/Schreiben/Ausführen, Secure/Nicht-Secure und Privilegiert/Nicht-Privilegiert werden Zugriffe durchgelassen oder geblockt. Im Fall einer Zugriffsverletzung kann eine Fehlerbenachrichtigung an die Applikation gesandt werden, um eine entsprechende Behandlung zu ermöglichen.
Kontextbasierte Schutzinfrastruktur
Partitionen bestehen aus Ressourcen wie Software-Elementen auf Prozessoreinheiten, DMA-Kanälen, Speicherbereichen und Peripherien. Sie benötigen eine statische und dynamische Konfiguration von Schutzmechanismen. Für jeden Zugriff eines Masters müssen die Schutzeinrichtungen wissen, welche Rechte maximal erlaubt sind. Eine zeitaufwendige Rekonfiguration beim Operationswechsel zwischen verschiedenen Partitionen muss möglichst vermieden werden, da sie die Prozessor- und Systemleistungsfähigkeit stark reduziert. Sämtliche MPUs, SMPUs und PPUs müssten neu konfiguriert werden, was sehr viele Buszugriffe und somit Zeit bedeutet. Eine weitere Herausforderung ist, die Schutzrekonfiguration für asynchron laufende Aufgaben innerhalb einer Partition zu realisieren, zum Beispiel ein Task auf einer Prozessoreinheit und ein DMA-Transfer.
Die Verwendung eines sogenannten »Schutzkontexts« (Protection Context; PC) erlaubt ein effizientes Ausrollen (Umschalten) von Zugriffsrechten. Er dient dazu, eine Menge an benutzerkonfigurierbarer Rechte für Ressourcen in einer Partition zu gruppieren. Jeder Speicher-/Peripheriezugriff wird von den verschiedenen Schutzeinrichtungen (zum Beispiel verteilte Speicherschutzeinheit, Peripherieschutzeinheit) hinsichtlich der für den Schutzkontext definierten Zugriffsrechte überprüft. Diese initiale Konfiguration muss einmal beim Starten des Systems geschrieben werden. Ein Betriebssystem kann dann die aktive Konfiguration der Schutzeinrichtungen durch einen einzelnen Registerschreibzugriff auf den momentanen Schutzkontext der Prozessoreinheit umschalten. Dies geschieht durch Setzen des mastereigenen PC-Registers, dessen Wert anschließend transparent für die Applikation bei sämtlichen Buszugriffen mitgeführt wird. Er entscheidet, welche Konfiguration auf Seite der Schutzeinheit Anwendung findet.
Andere Bus-Master wie ein DMA-Controller erben ihre Schutzattribute von der kontrollierenden Prozessoreinheit, was einen zur Prozessorausführung asynchronen Betrieb erlaubt. Schutzeinheiten müssen nicht ständig umkonfiguriert werden, da die aktive Konfiguration immer nur selektiert vorliegt. Dieses Konzept ermöglicht einen effizienten Wechsel zwischen verschiedenen Partitionen, jede mit unterschiedlichen Schutzkonfigurationen für die Ressourcen.
Bild 1 illustriert die Problematik der Schutzrekonfiguration bei asynchronen Aufgaben. Prozessor 1 führt verschiedene Aufgaben mit den Schutzkontexten PC1 und PC2 aus, Prozessor 2 führt Aufgaben mit PC3 und PC4 aus. Aufgaben der beiden Prozessoren konfigurieren DMA-Kanäle, um eventbasiert Daten zwischen Peripherie und Speicher auszutauschen, ohne den Prozessor zu involvieren. Da es keinen zeitlichen Zusammenhang zwischen Ausführung auf dem Prozessor und Transfer durch den DMA-Controller gibt, können die Prozessoren nicht dafür sorgen, dass immer die richtigen Zugriffsrechte für den DMA-Controller in den Schutzeinrichtungen konfiguriert sind. Erbt allerdings jeder DMA-Kanal den Schutzkontext seiner kontrollierenden Prozessoreinheit, können Zugriffsrechte zu jedem Zeitpunkt korrekt angewandt werden. Möglich wäre auch ein kryptografischer Coprozessor, der die Hauptprozessoren entlastet und gegebenenfalls Zugriff auf sensible Daten benötigt.
Welcher Schutzkontext von einem Bus-Master überhaupt verwendet werden kann, ist durch ein Maskierungsregister eingeschränkt. Dies lässt sich jedoch innerhalb der Vertrauenskette von einer sicheren Instanz konfigurieren und so vor weiteren Änderungen schützen. So können sich kompromittierte Bus-Master nicht mehr Rechte verschaffen, als ihnen maximal zugesprochen worden sind.
Schutz der Schutzinfrastruktur
Um eine Vertrauenskette aufzubauen und aufrechtzuerhalten, ist es nötig, dass nachfolgende Glieder in der Kette ihre zugeteilten Rechte nicht selbstständig ausweiten können. Es gilt demnach, sowohl Zugriffsrechte für Ressourcen festlegen zu können (Slave-Schutzstruktur), als auch Zugriffsrechte auf Zugriffsrechte festlegen zu können (Master-Schutzstruktur). Diese Master- und Slave-Schutzstrukturen kommen deshalb als Paar (Bild 2). Erstere regelt hierbei nicht nur den Zugriff auf die zugehörige Slave-Struktur, sondern auch auf sich selbst. Es ist nicht sinnvoll, dass in jedem Schutzkontext die eigenen Rechte verändert werden können, insbesondere aus Security-Sicht.
Das lässt sich lösen, indem die Konfigurationsregister der Schutzstrukturen ebenfalls als Ressourcen behandelt werden. Es gibt also auch Schutzmechanismen für diese Konfigurationsregister. Somit ist es möglich, einen Schutzkontext zu definieren, der Schutzstrukturen konfigurieren darf, und weitere Schutzkontexte für den eigentlichen Betrieb. PCs können auf diese Art auch dauerhaft abgeschaltet werden, um zum Beispiel die Rekonfiguration unveränderbar zu machen. Je nach Security-Anforderungen können Partitionen so voneinander getrennt werden, dass keine Information von der einen in die andere Partition gelangen kann.