DE102016122375A1

DE102016122375A1 - Dynamischer containerisierter Systemspeicherschutz für Niedrigenergie-MCUs

Info

Publication number: DE102016122375A1
Application number: DE102016122375.1A
Authority: DE
Inventors: Sebastian Ahmed; Thomas David; Marius Grannaes
Original assignee: Silicon Laboratories Inc
Current assignee: Silicon Laboratories Inc
Priority date: 2016-01-28
Filing date: 2016-11-21
Publication date: 2017-08-03
Also published as: CN107017014A; CN107017014B; US20170220489A1; US9984009B2

Abstract

Ein Prozessor, z. B. eine preiswerte Mikrocontroller-Einheit, verwendet einen DMA-Controller, um direkte Speichertransaktionen zwischen Hardware-Untersystemen unabhängig von der CPU zu ermöglichen. Um zu ermöglichen, dass diese Transaktionen durchgeführt werden, werden für den DMA-Controller und die Peripheriebrücke Sicherheits-Gateways bereitgestellt. Die Gateways, welche auf mehrere Zugriffsstrategien Zugriff haben, schalten in Abhängigkeit von einem Hardware-Kontext und/oder Subkontext, z. B. dem Bus-Master, von dem die Transaktion stammt, und/oder dem zu der Transaktion gehörigen DMA-Kanal zwischen diesen Strategien um. Die Gateways sind so zu betreiben, dass sie diese Strategien unabhängig von der CPU verwalten. In verschiedenen Realisierungen werden Gateways für den DMA-Controller, die Peripheriebrücke und/oder einzelne Peripherieeinheiten bereitgestellt. Der Prozessor kann sichere, vollständig containerisierte Operationen, welche seine Peripherieeinheiten betreffen, ohne ständigen CPU-Eingriff unterstützen.

Description

GEBIET DER ERFINDUNG
Die vorliegende Erfindung betrifft das Gebiet des Speicherschutzes allgemein in Mikroprozessoren und insbesondere in Niedrigstrom-Mikrocontrollereinheiten.
HINTERGRUND
Dieser Hintergrund dient dem Zweck der allgemeinen Beschreibung des Zusammenhangs der Offenbarung. Insoweit, wie der Hintergrund die Arbeit der aktuell bezeichneten Elemente und anderer Elemente umfasst, die nicht als Stand der Technik zur Zeit der Einreichung zu qualifizieren sind, wird eine solche Beschreibung weder ausdrücklich noch implizit als Stand der Technik gegen die vorliegende Offenbarung zugelassen.
Viele Prozessortypen, z. B. viele Mikrocontrollereinheiten (Microcontroller Units, MCUs, enthalten Bus-Master/Beschleuniger, welche einen Speicherzugriff unabhängig von dem Prozessor durchführen können. Ein Beispiel ist ein Direktspeicherzugriffs(Direct Memory Access, DMA)-Controller. Ein DMA-Controller ist eine gemeinsame Systemressource, welche ermöglicht, dass andere Hardware-Untersysteme, z. B. Sensoren (welche häufig von MCUs eingesetzt werden), ohne Eingriff durch die CPU auf einen Systemspeicher zugreifen. In der Tat kann ein DMA Speichertransaktionen zwischen einem Sensor und einem Systemspeicher ermöglichen, während sich die CPU im Ruhezustand befindet. Hierdurch wird vorteilhafter Weise ermöglicht, dass MCUs sehr geringe Strommengen verbrauchen, während sie Sensordaten aufnehmen. Dies ist besonders wichtig für MCUs, z. B. ein wachsendes Feld von Internet-der-Dinge(IOT)-Vorrichtungen, welche mit Batteriestrom oder anderen Niedrigenergie-Stromversorgungen versorgt werden.
Die Fähigkeit eines DMA-Controllers, Speichertransaktionen asynchron zu der CPU zu ermöglichen, führt jedoch zu Sicherheitsproblemen, wenn sich die CPU im Ruhezustand befindet. Wenn die CPU nicht verfügbar ist, um eine Zugriffssteuerungsstrategie (oder Zugriffsmaske) zu verwalten, besteht ein Potenzial für Sicherheitsdurchbrüche über den Sensor. Da alle Kanäle ein vollständiges Sichtfeld auf verfügbaren DMA-Speicher aufweisen, ist es nicht möglich, die einzelnen DMA-Kanäle in Hinblick auf ihr Sichtfeld auf den Systemspeicher zu containerisieren. Auch könnte ein Angreifer einen niedrigschwelligen Dienstverweigerungsangriff starten, indem er den Peripheriebus über einen kompromittierten Sensoreingang mit ständigen Anforderungen flutet. Hierdurch könnte der Entscheidungs- und Planungsmechanismus des Peripheriebusses stark genug gedrosselt werden, um zu verhindern, dass der Prozessor eine andere Peripherieeinheit, beispielsweise ein mechanisches Stellelement, bedient oder steuert. Oder es könnten andere wichtige Speichertransaktionen – beispielsweise eine Kameraversorgung – verhindert werden.
Eine mögliche Lösung ist es, die CPU jedes Mal zu unterbrechen, wenn eine Peripherieeinheit oder ein anderes Hardware-Untersystem versucht, den DMA zu benutzen. Sobald sie erwacht ist, kann die CPU jede Speicherzugriffsanforderung blockieren, welche nicht die richtigen Sicherheitsattribute aufweist. Hierdurch wird jedoch der oben beschriebene Vorteil beseitigt – der CPU den Ruhezustand zu ermöglichen, während der Prozessor Sensordaten aufnimmt. Die CPU kann nicht im Ruhezustand bleiben, wenn DMA-Operationen durchgeführt werden. Eine andere mögliche Lösung wäre es, erforderlich zu machen, dass das RTOS die DMA-Operationsprogrammierung unwiederbringlich löscht. Dies wird schwierig für DMA-Operationen, bei denen komplexe Programmierungsmodelle verwendet werden, z. B. im Systemspeicher gespeicherte befehlsverbundene Listen. Die vorstehenden Lösungen würden auch einen großen Software-Zusatz/Eingriff erforderlich machen und die Energieeffizienz, die Leistungsfähigkeit und die Funktionalität des Prozessors stark einschränken.
KURZDARSTELLUNG DER ERFINDUNG
Diese Kurzdarstellung dient dazu, den Gegenstand einzuführen, der nachstehend in der detaillierten Beschreibung und in den Zeichnungen weiter beschrieben wird. Entsprechend sollte diese Kurzdarstellung weder so angesehen werden, dass sie wesentliche Merkmale beschreibt, noch verwendet werden, um den Umfang des beanspruchten Gegenstands zu beschränken.
Es werden Ausführungsformen eines Prozessors und eines Verfahrens zur Verwendung desselben beschrieben. Verschiedene Hardware-Untersysteme erstellen Zugriffsanforderungen oder leiten diese weiter, während eine oder mehrere speicheradressierbare Nicht-CPU-Schutzeinheiten (Protection Units, PU) diese Anforderungen auf der Basis von Zugriffsschutzstrategien, welche für das die Anforderung erstellende oder weiterleitende Hardware-Untersystem spezifisch sind, selbständig zulassen oder blockieren.
KURZBESCHREIBUNG DER ZEICHNUNGEN
Diese und andere Aufgaben, Merkmale und Vorteile der vorliegenden Erfindung werden besser verständlich unter Bezugnahme auf die folgende Beschreibung und die begleitenden Zeichnung, wobei:
1 ein Blockschaubild ist, welches eine Zusammenstellung aus Prozessor, Bus-Master, Peripherieeinheit und Register-Schutzeinheiten veranschaulicht;
2 ein Blockschaubild ist, welches Zugriffssteuerungsstrategie-Strukturen für eine Zentralprozessor-Schutzeinheit (CPUPU) veranschaulicht;
3 ein Blockschaubild ist, welches eine Zugriffssteuerungsstrategie-Struktur für eine Bus-Master-Schutzeinheit (BMPU) veranschaulicht;
4 ein Blockschaubild ist, welches eine Zugriffssteuerungsstrategie-Struktur für eine Peripherieschutzeinheit (PPU) veranschaulicht;
5 ein Blockschaubild ist, welches eine PPU-Steuerstruktur-Indexierungstopologie veranschaulicht;
6 ein Blockschaubild ist, welches eine Zugriffssteuerungsstrategie-Struktur für eine Register-Schutzeinheit (RPU) veranschaulicht;
7 ein Blockschaubild ist, welches detailliert Komponenten einer Speicherzugriffsanforderung darstellt;
8 ein Blockschaubild ist, welches detailliert Aspekte eines Hardware-Kontexts gemäß einer Ausführungsform der Erfindung darstellt;
9 ein Blockschaubild ist, welches eine Ausführungsform einer Sicherheitsattributstruktur veranschaulicht;
10 ein Ablaufplan ist, welcher ein Torwächterverfahren für Zugriffsanforderungen von einem CPU-Thread auf einen Hauptspeicher veranschaulicht;
11 ein Ablaufplan ist, welcher ein Torwächterverfahren für Zugriffsanforderungen von einem CPU-Thread oder einem Direktspeicherzugriffs(DMA)-Kanal auf eine Peripherieeinheit veranschaulicht;
12 ein Ablaufplan ist, welcher ein Torwächterverfahren für Zugriffsanforderungen auf eine Peripherieeinheit aus der Perspektive einer PPU veranschaulicht;
13 ein Ablaufplan ist, welcher ein Torwächterverfahren für Zugriffsanforderungen auf eine Peripherieeinheit aus der Perspektive einer BMPU veranschaulicht;
14 ein Zeitschaubild ist, welches ein Zusammenspiel von Ausführungszuständen, DMA-Zuständen und PPU-Zugriffskontexten veranschaulicht.
DETAILLIERTE BESCHREIBUNG
Nachstehend werden beispielhafte und veranschaulichende Ausführungsformen der Erfindung beschrieben. Im Interesse der Klarheit werden in dieser Beschreibung nicht alle Merkmale einer tatsächlichen Realisierung beschrieben, da der Fachmann erkennt, dass während der Entwicklung jeder solcher tatsächlichen Ausführungsform zahlreiche realisierungsspezifische Entscheidungen getroffen werden, um spezielle Ziele zu erreichen, z. B. Vereinbarkeit mit systembezogenen und geschäftsbezogenen Einschränkungen, welche von einer Realisierung zur anderen variieren. Ferner sei angemerkt, dass eine solches Entwicklungsanstrengung komplex und zeitaufwändig sein könnte, aber dennoch eine Routinemaßnahme für den Fachmann wäre, der aus der vorliegenden Offenbarung Nutzen zieht. Dem Fachmann werden verschiedene Modifikationen der bevorzugten Ausführungsform ersichtlich sein und die hierin definierten allgemeinen Prinzipien können auf andere Ausführungsformen angewendet werden. Daher soll die vorliegende Erfindung nicht auf die hierin dargestellten und beschriebenen speziellen Ausführungsformen beschränkt sein, sondern ihr ist der breiteste Umfang zu gewähren, der mit den hierin offenbarten Prinzipien und neuen Merkmalen übereinstimmt.
Die nachstehend beschriebenen Ausführungsformen sind von besonderer Bedeutung, wenn sie auf Niedrigenergie-Mikrocontroller-Einheiten (MCUs) angewendet werden, ohne darauf beschränkt zu sein. Eine sichere (geschützte) MCU-Anwendung nutz einen Hypervisor oder ein Echtzeit-Betriebssystem (Real Time Operating System, RTOS), welches für die Verwaltung der verschiedenen Ausführungs-Kontexte in dem System verantwortlich ist. Als solches bildet das RTOS selbst einen sicheren Aufgabenkontext, welcher typischerweise Zugriff auf den gesamten Systemspeicher hat, wenn er aktiv ist. Das RTOS steuert das Schalten der Prozessorausführung zwischen verschiedenen unsicheren Benutzeraufgaben-Kontexten. In einer Realisierung hat jede dieser Benutzeraufgaben Zugriff auf eine unabhängige Teilmenge des Systemspeichers. Hierdurch wird systemwichtiger Speicher (z. B. das RTOS) vor jeder Benutzeraufgabe geschützt, aber auch jede Benutzeraufgabe vor anderen Benutzeraufgaben geschützt (Containerisierung). In einem System, welches zwei Privilegierungs/Sicherheits-Stufen aufweist, maskiert das RTOS den Zugriff auf eine gegebene aktive Benutzeraufgabe durch Anheben der Sicherheitsanforderung der Schutzeinheit (PU) auf spezielle Speicherbereiche. Dieses Sichtfeld ändert sich mit jeder Aufgabenkontext-Umschaltung.
1 veranschaulicht eine Ausführungsform eines Prozessors 100 gemäß der vorliegenden Erfindung. Der Prozessor 100 umfasst eine Zentralprozessoreinheit (CPU) 102, einen Systemnus 104 und mehrere Bus-Master 106 und Bus-Slaves, die über eine Busverbindung 108, auch als Busmatrix bekannt, mit dem Bus 104 verbunden sind. Der Systembus 104 verbindet die CPU 102 mit dem Systemspeicher 112. Der Systembus 104 ist dafür konfiguriert, Speicherzugriffsanforderungen 160 (6) zwischen verschiedenen Hardware-Untersystemen des Prozessors 100 zu übermitteln. In einer Realisierung umfasst der Bus Signalleitungen, welche Hardware-Kontext und Unterkontextkennungen zum Identifizieren eines bestimmten Hardware-Untersystems oder einer Ressource, die eine Speicherzugriffsanforderung 160 vornimmt, übertragen.
Bus-Master 106 sind Vorrichtungen, welche Transaktionen auf dem Bus 104 auslösen können. Beispiele umfassen die CPU 102 und einen Direktspeicherzugriffs(DMA)-Controller 110. Bus-Slaves sind Vorrichtungen, welche Kommunikationen und Befehle aus dem Bus 104 empfangen, aber keine Transaktionen auf dem Bus 104 auslösen. Beispiele für Bus-Slaves sind ein Systemspeicher (SMEM) 112, z. B. ein dynamischer Direktzugriffsspeicher (DRAM) oder ein statischer Direktzugriffsspeicher (SRAM), sowie speicherabgebildete Peripherieeinheiten 114, welche Verfahren steuern, Eingaben empfangen oder Ausgaben erzeugen. Für Peripherieeinheiten 114, die über einen Peripheriebus 116 mit einer Peripheriebusbrücke 118 verbunden sind, die mit der Busverbindung 108 verbunden ist, dient die Peripheriebusbrücke 118 als der Bus-Slave.
Wie oben angegeben, ist ein DMA-Controller 110 ein Typ eines Bus-Masters. DMA ist ein alteingeführtes Merkmal von Computersystemen, welches ermöglicht, dass Speichertransaktionen zwischen bestimmten Hardware-Untersystemen (insbesondere Peripherieeinheiten) und dem Hauptsystemspeicher des Computers, z. B. einem Direktzugriffsspeicher (RAM), ohne Hilfe der CPU stattfinden. Ohne verfügbaren DMA ist für Speichertransfers typischerweise die CPU erforderlich, um einen vollständigen Lese- oder Schreib-Eingabe/Ausgabe-Zyklus durchzuführen. In Personal-Computern nutzen Soundkarten, Videokarten und Laufwerke häufig den DMA. In Mikrocontrollern (MCUs) nutzen Sensoren und Steuerungs-Peripheriegeräte häufig den DMA.
Ein DMA-Controller 110 ist typischerweise mit mehreren Kanälen 120 ausgestattet, um die DMA-Erfordernisse mehrerer Hardware-Untersysteme zu erfüllen. Jeder Kanal 120 ist eine programmierbare Konfiguration oder ein Betriebskontext für die Hardware-Untersysteme, welche den Kanal 120 nutzen. Durch die Verfügbarkeit mehrerer Kanäle 120 wird ermöglicht, dass eine CPU 102 mehrere Konfigurationen vorprogrammiert. Der DMA-Controller 110 kann durch einen Entscheidungs- und Planungsmechanismus und Entscheidungs- und Planungsalgorithmus effizient von einem Kanal 120 auf einen anderen schalten.
Als eine Alternative zu einem DMA-Controller 110 kann der DMA durch Bus-Mastering durchgeführt werden, wobei ein anderer Bus-Master 106 als die CPU 102 die Transaktionen auslöst. Der Prozessor 100 ist mit einem Busentscheidungsschema ausgerüstet, um zu verhindern, dass mehrere Bus-Master 106 gleichzeitig versuchen, den Bus 104 zu benutzen.
Es kann auch andere, Nicht-DMA-Bus-Master 106 geben, wobei einige ihre eigenen Unterkontexte aufweisen, andere als DMA-Kanäle 120. Beispielsweise weist in einer Realisierung ein integrierter Graphikprozessor mehrere interne Kontexte auf, umfassend einen für Graphikbefehle dedizierten und einen anderen zum Erhalten von Texturen.
Gemäß einer Ausführungsform der vorliegenden Erfindung sind verschiedene Hardware-Untersysteme mit Schutzeinheiten (PUs) ausgestattet. Eine PU ist selbst ein Hardware-Untersystem, welches als ein Torwächter fungiert, indem es einen Satz von Zugriffssteuerungsstrategien auf Systemspeicher und/oder Hardware-Untersysteme verwaltet, auf die über Systemspeicheradressen zugegriffen werden kann (z. B. auf den Systemspeicher abgebildete Peripherieeinheiten). Wie weiter unten herausgearbeitet, ist der Umfang jeder Zugriffssteuerungsstrategie (welche auch als eine Zugriffsmaske bezeichnet werden kann) auf einen bestimmten Software- oder Hardware-Kontext beschränkt. In einer Ausführungsform verwendet der Prozessor 100 ein mehrstufiges System von PUs, um Zugriffssteuerungsstrategien zu verwalten, die durch verschiedene Granularitätsgrade gekennzeichnet sind.
Die PU definiert Anforderungen für einen Zugriff auf verschiedene definierte Regionen im Speicher. Die PU setzt Zugriffsbeschränkungen auf solche Speicherregionen gemäß den Sicherheitsattributen des aktuell aktiven Prozessor-Threads/der aktuell aktiven Prozessor-Aufgabe (d. h. Kontexts) durch. Um die Ausführung mehrerer unsicherer Kontexte zu ermöglichen, wird das Speicher-Sichtfeld der PU für jede Kontextumschaltung neu konfiguriert. Dies kann als Software-gesteuerte Kontextumschaltung angesehen werden.
Einige Prozessortypen, z. B. eine Mikrocontroller-Einheit (MCU), enthalten Bus-Master/Beschleuniger, welche einen Speicherzugriff unabhängig vom Prozessor durchführen können. Ein Beispiel ist ein Direktspeicherzugriffs(DMA)-Controller. Ein DMA-Controller ist eine gemeinsam benutzte Systemressource, welche zwischen einem RTOS und verschiedenen Benutzeraufgaben mehrere Aufgaben erfüllen kann. Mit den verschiedenen Software-Aufgabenkontexten können verschiedene DMA-Kanäle verbunden sein. Die Konfiguration der DMA-Kanäle erfolgt typischerweise während der RTOS-Kontext-Zeit oder während spezieller Benutzeraufgaben-Kontextzeiten. Wenn sie einmal in Betrieb sind, werden die DMA-Kanäle jedoch zu Zeiten aktiv, die zu diesen SW-Kontexten asynchron sind, und hierdurch werden Probleme beim Verwalten einer Zugriffssteuerungsstrategie für die DMA-Zugriffe erzeugt.
In einer hohen Stufe ist die CPU 102 mit einer PU ausgestattet, welche hierin als die CPUPU 150 bezeichnet wird und welche einige Fachleute als eine Speicherschutzeinheit bezeichnen würden. Die CPUPU 150 definiert Anforderungen für den Zugriff auf verschiedene definierte Regionen im Speicher. Die CPUPU 150 setzt Zugriffsbeschränkungen auf solche Speicherregionen gemäß den Sicherheitsattributen des aktuell aktiven Prozessor-Ausführungs-Threads/der aktuell aktiven Prozessor-Ausführungs-Aufgabe (d. h. des Kontexts) durch. Um die Ausführung mehrerer unsicherer Kontexte zu ermöglichen, wird das Speicher-Sichtfeld der CPUPU 150 für jede Kontextumschaltung neu konfiguriert. Dies kann als Software-gesteuerte Kontextumschaltung angesehen werden.
In einer mittleren Stufe sind die meisten System-Bus-Master 106, einschließlich des DMA-Controllers 110, aber nicht einschließlich der CPU 102, mit einer PU ausgestattet, welche hierin als die Bus-Master-Schutzeinheit (BMPU) 152 bezeichnet wird. BMPUs 152 sind für Hardware-Module, z. B. Sekundärprozessoren, vorgesehen, welche unabhängig von der CPU 102 Speicherzugriffe erzeugen können. Einige Bus-Master 106, beispielsweise ein Bus-Master, der das System während des Urladens (bevor der Prozessor 100 die Ausführung von Befehlen gemäß der Befehlssatzarchitektur des Prozessors beginnt) initialisiert, sind möglicherweise nicht mit einer BMPU 152 ausgestattet, unter der Annahme, dass nicht erwartet wird, dass sie für eine direkte Verwendung durch Benutzer-Software verfügbar sind.
In einer unteren Stufe ist die Peripheriebusbrücke 118 mit einer PU ausgestattet, welche hierin als eine Peripherieschutzeinheit (PPU) 154 bezeichnet wird. Schließlich können in einer noch niedrigeren Stufe einzelne Peripherieeinheiten 156, welche eine interne Abgrenzung zwischen sicheren/unsicheren und/oder privilegierten/nicht-privilegierten Zugriffen benötigen, mit PUs ausgestattet sein, die hierin als Register-Schutzeinheiten 158 bezeichnet werden.
In Bezug auf Speicherzugriffsanforderungen 160, welche auf einige anvisierte Ressourcen gerichtet sind, z. B. eine Peripherieeinheit, wenden die CPUPU und BMPU Zugriffssteuerungsstrategien an, welche durch einen groben Granularitätsgrad gekennzeichnet sind. Speicherzugriffsanforderungen 160, welche die CPUPU 150 oder die BMPU 152 durch ihren groben Filter zulässt, werden dann durch eine oder mehrere nachgeschaltete PUs, deren Zugriffssteuerungsstrategien durch einen relativ feineren Granularitätsgrad gekennzeichnet sind, neu bewertet. Beispielsweise wäre eine Speicherzugriffsanforderung 160 von einer Bus-Master-Vorrichtung 106 oder einem CPU-Thread an eine Peripherieeinheit 114, die mit einer RPU 158 ausgestattet ist, Gegenstand einer Zugriffssteuerungsstrategie-Verwaltung erst durch die CPUPU 150 oder die BMPU 152, anschließend durch die PPU 154 und nochmals durch die RPU 158.
In einer Realisierung ist jede PU in ihr entsprechendes Hardware-Untersystem eingebaut. Gemäß ihrer Torwächterfunktion blockiert jede PU Speicherzugriffsanforderungen 160 dagegen, ihr entsprechendes Hardware-Untersystem zu erreichen, wenn die Quell- und Sicherheitsattribute der Speicherzugriffsanforderung 160 nicht den Anforderungen der Zugriffssteuerungsstrategie der PU für die anvisierte Speicherregion entsprechen.
Auch programmiert in einer Realisierung das RTOS eine Sicherheitsverwaltungseinheit (Security Management Unit, SMU) 162, eine Konfigurations-Peripherieeinheit, welche alle Konfigurationsregister aller anderen PUs als der CPUPU 150 beinhaltet. Die SMU 162 ist mit Konfig/Status-Leitungen 164 verbunden, welche die PU-Konfigurationen auf jede der BMPUs 152, der ein oder mehreren PPUs 154 und etwaige RPUs 158 verteilen. Die Konfig/Status-Leitungen 164 übertragen auch Statusinformationen, einschließlich etwaiger Fehlerinformationen, von den PUs zurück zu der SMU 162.
2 veranschaulicht eine Zugriffssteuerungsstrategie-Struktur 166 für eine CPUPU 102. Gemäß einer Realisierung umfasst die CPU-Zugriffssteuerungsstrategie-Struktur 166 mehrere Zugriffssteuerungsstrategien 0...q 168. Für jeden Thread oder jede Aufgabe ist eine separate und unterscheidbare Zugriffssteuerungsstrategie 168 vorgesehen, die jeweils mit einer Thread-Kennung oder einer anderen Software-Kontext-Kennung 170 verbunden oder markiert ist. Mit jeder Aufgabenumschaltung von einem vorhergehenden Thread auf einen folgenden Thread bewirkt das Echtzeit-Betriebssystem (RTOS), dass die CPU 102 die CPU-Thread-Kennung des folgenden Threads in die CPU-Zugriffssteuerungsstrategie-Struktur 166 indexiert, um die entsprechende Zugriffssteuerungsstrategie 168 auszuwählen oder abzurufen, welche dann in die CPUPU 150 geladen wird.
Jede Zugriffssteuerungsstrategie 168 sieht mehrere Speicherregionen 0...n 180, welche Regionen adressierbaren Systemspeichers (welche auf den Systemspeicher abgebildete Peripherieeinheiten umfassen können) identifizieren, und Sicherheitsattribute, welche mit jeder identifizierten Speicherregion verbunden sind, vor oder ist damit verbunden. Die Sicherheitsattribute 182 können umfassen, ob der Zugriff auf privilegierte und/oder sichere Threads beschränkt ist, ob der Zugriff ein Nur-Lese-Zugriff ist oder nicht, und beliebige andere Zugriffsbeschränkungen, die durch die Architektur des Prozessors und des Betriebssystems unterstützt werden. Ein „Sicherheitsattribut” kann ein beliebiges zu einer Speicherzugriffsanforderung 160 gehöriges Attribut umfassen, welches verwendet wird, um den Zugriff auf eine anvisierte Speicherregion 180 zu steuern.
In einigen Ausführungsformen ist eine CPU 102 mit mehreren CPUPUs ausgestattet, mindestens einer für jeden Kern, oder in einer Hyperthread-CPU einer CPUPU für jeden virtuellen Kern. Als Teil einer Virtualisierungsunterstützung auf Hardware-Basis können sogar noch mehr CPUPUs vorgesehen sein.
3 ist ein Blockschaubild, welches eine Zugriffssteuerungsstrategie-Struktur 184 für eine BMPU 152 für einen Bus-Master 106, z. B. einen DMA-Controller 110, veranschaulicht, welcher Hardware-Unterkontexte 186 unterstützt. Die BMPU 152 ist mit dem DMA 110 oder anderen Bus-Master 106 verbunden, verknüpft, diesem zugeordnet und/oder in diesen integriert.
Die BMPU 152 sieht mehrere Zugriffssteuerungsstrategien 0...P 188 für alle Hardware-Unterkontexte 186 des Bus-Masters 106 oder 110 vor, mit welchen sie verbunden ist. In einer Realisierung wird der Hardware-Unterkontext 186 durch ein Signal identifiziert – welches in einer sehr speziellen Realisierung als das MASTERSID-Signal 190 bezeichnet wird – welches auf Bussignalleitungen übertragen wird.
Vorteilhafter Weise ermöglicht eine feinkörnige Unterstützung für Hardware-Unterkontexte 186, z. B. DMA-Kanäle 120, dass der Prozessor 100 jeden Kanal 120 eines DMA-Controllers 110 auskapselt oder containerisiert, so dass Hardware-Untersysteme, welche beispielsweise den Kanal 1 verwenden, nicht Speicher oder Peripherieeinheiten stören können, die über den Kanal 0 gesteuert werden. Auf diese Weise unterstützt die BMPU 152 vollständig containerisierte DMA-Kanal-Operationen.
Wie die Zugriffssteuerungsstrategie-Struktur 166 der CPUPU sieht die Zugriffssteuerungsstrategie-Struktur 184 der BMPU mehrere Speicherregionen 0...n 180, welche Regionen adressierbaren Systemspeichers (welche auf den Systemspeicher abgebildete Peripherieeinheiten umfassen können) identifizieren, und zugehörige Sicherheitsattribute 182 vor oder ist damit verbunden. Aber anders als bei der Zugriffssteuerungsstrategie-Struktur 166 der CPUPU differenziert die Zugriffssteuerungsstrategie-Struktur 184 der BMPU Zugriffssteuerungsstrategien 188 nicht nach CPU-Thread. Stattdessen differenziert die Zugriffssteuerungsstrategie-Struktur 184 Strategien nach Hardware-Unterkontext 186. Vorteilhafter Weise arbeitet durch Verwalten der Strategien durch den DMA-Kanal 120 eine BMPU 152 für einen DMA-Controller 110 so, dass sie DMA-Operationen containerisiert, indem sie jedem Kanal 120 ein eingeschränktes Sichtfeld auf den Systemspeicher 112 gibt. Die BMPU 152 kann beispielsweise so programmiert werden, dass verhindert wird, dass eine Peripherieeinheit 114, die an den Kanal 1 gebunden ist, auf Speicher zugreift, der einer anderen Peripherieeinheit 114 zugeordnet ist, die an den Kanal 0 gebunden ist.
In einer BMPU 152, die einer Peripherieeinheit 114 oder einem DMA-Controller 110 dient, sind die Speicherregionen, die den Peripherieeinheiten 114 entsprechen, gewöhnlich so konfiguriert, dass die entsprechenden Speicherzugriffsanforderungen 160 zu der richtigen PPU 154 durchgeleitet werden. In einigen Realisierungen kann jedoch die BMPU 152 einen Kanal 120 aufweisen, welcher Hardware-Untersysteme vollständig dagegen blockiert, auf die Peripherieregion zuzugreifen, wodurch verhindert wird, dass Speicherzugriffsanforderungen 160 über diesen Kanal 120 jemals die Peripherieeinheiten 114 erreichen.
Speicherregionen, welche Systemspeicher 112 entsprechen, der nicht durch eine dedizierte PU geschützt ist, sind mit fein eingestellten Sicherheitsbeschränkungen konfiguriert, die für den Hardware-Unterkontext 186 geeignet sind. Wenn dem DMA-Controller 110 eine Speicherzugriffsanforderung 160 vorgelegt wird, versorgt er die BMPU 152 mit seinem HW-Unterkontext 186, welches die DMA-Kanal-Nummer 120 ist, und die BMPU wählt (in Echtzeit) den richtigen Speicherregions-Informationssatz aus, so dass sie die speziellen Speicherzugriffsrechte für diesen gegebenen DMA-Kanal 120 durchsetzen kann.
Die BMPU 152 indexiert den HW-Unterkontext 186 des Bus-Masters 106 in die BMPU-Zugriffssteuerungsstrategie-Struktur 184, um eine Zugriffssteuerungsstrategie 188 für diesen Bus-Master 106 zu identifizieren. Wenn die BMPU 152 eine Speicherzugriffsanforderung 160 verarbeitet, vergleicht die BMPU 152 die anvisierte Speicherstelle 192 und Sicherheitsattribute 194 der Zugriffsanforderung 160 mit der Zugriffssteuerungsstrategie 188 und ermöglicht oder blockiert selektiv die Anforderung 160. Die BMPU 152 enthält Zugriffssteuerungsstrategien 188 für alle Unterkontexte dieses Masters 106, welche über ein Hardware-Kontext-Signal 196 identifiziert und unterschieden werden (7). Die BMPU 152 verwaltet ihre Zugriffssteuerungsstrategien 198 automatisch, sobald sie konfiguriert ist. Dies ist anders als bei der CPUPU 150, welche jedes Mal umprogrammiert wird, wenn die CPU die Ausführung auf den folgenden Thread umschaltet. Sie führt die Zugriffssteuerung durch Vergleichen der Regionsattribute mit den Bustransaktionssignalen durch, die sich auf diese Attribute beziehen, z. B. Sicherheits-(ARM HNONSEC-Signal) oder Privilegierungsstufen (ARM HPROT-Signale).
Die BMPU 152 für einen DMA-Controller 110 stellt auch die Sicherheitsattribute einer Speicherzugriffsanforderung 160 ein, welche durch einen der DMA-Kanäle 120 gelangt. In einem Beispiel ist die BMPU 152 so konfiguriert, dass sie einen gesamten Kanal 120 als immer privilegiert markiert. Dieser Kanal 120 ist außerdem an das RTOS gebunden. Nachdem das RTOS eine Speicherzugriffsanforderung 160 an den DMA-Controller 110 ausgibt, behauptet die BMPU 152 Privilegierungs- und/oder Sicherheitsleitungen auf dem Systembus 104. Dann besitzt die Speicherzugriffsanforderung 160, wenn sie sich ihren Weg durch die PPU 154 und/oder die RPU 158 bahnt, was im Wesentlichen ein Gesamtzugriffsdurchlass ist.
4 ist ein Blockschaubild, welches eine Zugriffssteuerungsstrategie-Struktur 200 für eine PPU 154 veranschaulicht. Vor dem Beschreiben dieser Struktur 200 sei angemerkt, dass es verschiedene Typen von PPUs 154 geben kann. Beispielsweise dient ein Typ einer PPU 154 mehreren relativ langsamen Peripherieeinheiten, z. B. Peripherieeinheiten auf Advanced-Peripheral-Bus(APB)-Auswahl-Basis in einer Realisierung auf ARM-Basis. Ein anderer Typ einer PPU 154 dient einer einzigen Hochgeschwindigkeits-Peripherieeinheit, z. B. einer Advanced-High-Speed-Bus(AHB)-Slave-Peripherieeinheit in einer Realisierung auf ARM-Basis. Es ist ersichtlich, dass diese Unterschiede zu unterschiedlichen Zugriffssteuerungsstrategie-Strukturen 200 führen können.
Nun konzentrierend auf die Ausführungsform der 4, ist die Zugriffssteuerungsstrategie-Struktur 200 mit der Peripheriebusbrücke 118 oder Peripherieeinheit 156 verbunden, verknüpft, dieser zugeordnet und/oder darin integriert. Die PPU-Zugriffssteuerungsstrategie-Struktur 200 sieht mehrere Hardware-Kontexte 0...M 196, ein oder mehrere Hardware-Unterkontexte 0...P 186, die zu jedem Hardware-Kontext 196 gehören, eine oder mehrere Speicherregionen 0...n, die zu jedem Hardware-Unterkontext 186 gehören, und einen Satz von Sicherheitsattributen 182, die zu jeder Speicherregion 180 gehören, vor oder ist gemäß diesen organisiert. Beispielsweise könnte einer der Hardware-Kontexte 196 ein bestimmter CPU-Kern oder virtueller Kern sein. Ein anderer Hardware-Kontext 196 könnte ein DMA-Controller 110 sein, welcher mehrere Kanäle 120 aufweist, wobei jeder Kanal 120 einen Hardware-Unterkontext 186 bildet. Der Umfang der PPU 154 erstreckt sich auf alle Bus-Master 106, welche Zugriff auf den Satz der Peripherieeinheiten 114 haben, die von der PPU 154 bedient werden.
Wenn ihr eine Speicherzugriffsanforderung 160 vorgelegt wird, indexiert die PPU 154 in die PPU-Zugriffssteuerungsstrategie-Struktur unter Verwendung des HW-Kontextes und des HW-Unterkontextes des Bus-Masters, z. B. des DMA-Controllers 110 und der Peripherieeinheit, die einem DMA-Kanal zugeordnet ist. Die PPU 154 vergleicht dann die anvisierte Speicherstelle 192 und die Sicherheitsattribute 194 der Speicherzugriffsanforderung 160 mit der Zugriffsstrategie 200 und ermöglicht oder blockiert selektiv die Anforderung 160.
5 veranschaulicht eine Realisierung dieses Indexierungsansatzes. 5 ist der 4 eine weitere Komplexitätsschicht hinzugefügt, indem die Tatsache berücksichtigt wird, dass eine Peripheriebusbrücke 118 typischerweise mehreren Peripherieeinheiten 0...R 114 dient. Entsprechend kann die PPU-Zugriffssteuerungsstrategie-Struktur 200 so charakterisiert sein, dass sie mehrere Hardware-Kontext-differenzierte Gruppen 0...M 202 (hierin im Folgenden „Steuergruppen”) Unterkontext-differenzierter Sätze 0...P 204 (hierin im Folgenden „Steuersätze”) von Peripherieeinheit-differenzierten Zugriffssteuerungsstrategien 0...R 206 umfasst. Anders betrachtet, ist der Zugriff auf eine Peripherieeinheit 114 durch eine Zugriffssteuerungsstrategie 208 beschränkt, ausgewählt aus einem geeigneten Steuersatz 204, ausgewählt aus einer geeigneten Steuergruppe 202, wodurch sichergestellt wird, dass die ausgewählte Zugriffssteuerungsstrategie 206 der richtigen Peripherieeinheit 114, dem richtigen Hardware-Unterkontext 186 und dem richtigen Hardware-Kontext 196 entspricht.
Gemäß der Realisierung der 5 wählt eine PPU 154 für eine Peripherieeinheit unter Verwendung einer Auswahllogik erster Stufe 210 (z. B. eines Multiplexers oder einer Gruppe von Multiplexern) die geeignete Zugriffssteuerungsstrategie 208 aus, um aus jeder Steuergruppe 202 einen Satz von Zugriffssteuerungsstrategien 204 auszuwählen, die für eine gegebene MASTERSID-Kennung 190 erzeugt worden ist. Jeder der ausgewählten Sätze 212 (oder Adressen für jeden der ausgewählten Sätze 212) wird dann einer Auswahllogik zweiter Stufe 214 zugeführt, in welcher eine MASTERID-Kennung 216 verwendet wird, um einen einzelnen Satz von Zugriffssteuerungsstrategien 218 (oder eine Adresse davon) auszuwählen. Der einzelne ausgewählte Satz 218 umfasst eine individualisierte Strategie für jede Peripherieeinheit 114, die von der Peripheriebusbrücke 118 bedient wird. Schließlich wird in einer Auswahllogik dritter Stufe 220 eine (auf einer Peripherieauswahlleitung übertragene) Peripherieeinheitsnummer 222 verwendet, um aus dem einzelnen ausgewählten Satz 218 eine geeignete Zugriffssteuerungsstrategie 206 (oder eine Adresse davon) auszuwählen. Die PPU 154 wendet dann die ausgewählte Zugriffssteuerungsstrategie 206 an, um die Speicherzugriffsanforderung 160 zu blockieren oder zuzulassen.
Es versteht sich, dass es viele äquivalente Logik-Formen gibt. Beispielsweise könnte die Peripherienummer 222 als die Auswahllogik erster Stufe 210 verwendet werden und der Hardware-Unterkontext 186 könnte als die Auswahllogik dritter Stufe 220 verwendet werden. In einer Ausführungsform wird jede Schicht der Auswahllogik gleichzeitig angewendet, ähnlich der Weise, wie Reihe, Spalte und Tabellenattribute in einer Datenbank verwendet werden können, um einen bestimmten Eintrag auszuwählen.
6 veranschaulicht eine Zugriffssteuerungsstrategie-Struktur für eine Register-Schutzeinheit (RPU). Die Zugriffssteuerungsstrategie-Struktur 224 der RPU ähnelt der Zugriffssteuerungsstrategie-Struktur 200 der PPU, außer dass Registerregionen 226 den Platz der Speicherregionen 180 der PPU einnehmen. In einigen Ausführungsformen schützt die RPU 158 mit einer Bit-Stufen-Granularität. Eine spezielle Anwendung ist die für eine Peripherieeinheit, welche die allgemeine Eingabe/Ausgabe (General Purpose Input Output, GPIO) steuert. Typischerweise weist eine solche Peripherieeinheit 32-Bit-Register auf und jedes solcher Register kann zu einer gewissen Anzahl an IO-Pins gehören. Die RPU definiert dann mehrere Zugriffssteuerungsstrategien, welche die einzelnen Pins für einen gegebenen HW-Unterkontext containerisieren.
7 veranschaulicht Komponenten einer Speicherzugriffsanforderung 160, umfassend ein Hardware-Kontext-Feld 196 oder einen Hardware-Kontext-Satz 196 von Bussignalen, ein Sicherheitsattributfeld 194 oder einen Sicherheitsattributsatz 194 von Bussignalen und ein Ziel-Speicherstellen-Feld 192 oder einen Ziel-Speicherstellen-Satz 192 von Bussignalen. In einer Ausführungsform sind eine oder mehrere der Speicherzugriffsanforderungs-Komponenten 196, 194, 192 in einem Datenpaket verkapselt, das über den Bus 104 gesendet wird. In einer anderen Ausführungsform werden eine oder mehrere der Speicherzugriffsanforderungs-Komponenten 196, 194, 192 auf dem Systembus 104 und über die Busverbindung 108 übertragen.
8 ist ein Blockschaubild, welches detailliert Aspekte eines Hardware-Kontexts 196 gemäß einer Ausführungsform der Erfindung darstellt. Zumindest bezieht sich der Hardware-Kontext 196 auf die Master-Vorrichtung 106 (z. B. die CPU 102, den DMA-Controller 110 usw.), welche die Speicherzugriffsanforderung 160 ausgelöst hat. Gemäß einer Realisierung umfasst der Hardware-Kontext 196 eine Master-Kennung oder Markierung 216.
Die Master-Kennung/Markierung 216 kann so charakterisiert sein, dass sie nur eine äußere Schicht des Hardware-Kontexts 196 bereitstellt. Unter dieser Charakterisierung würde der Hardware-Kontext 196 auch eine innere Schicht oder einen Hardware-Unterkontext 186 umfassen. Gemäß einer Realisierung wird diese innere Schicht unter Verwendung einer Unterkontextkennung 190, z. B. eines DMA-Kanals 120, identifiziert.
9 veranschaulicht eine Ausführungsform einer Sicherheitsattributstruktur 194, welche ein Sicher-Feld 228, ein Privilegiert-Feld 230, ein Unsicher-aber-Nur-Lese-Feld 232 und ein Nicht-privilegiert-aber-Nur-Lese-Feld 232 umfasst. Es sind natürlich viele verschiedene Strukturen und Architekturen möglich. Wie bereits erwähnt, kann ein Sicherheitsattribut 194 ein beliebiges zu einer Speicherzugriffsanforderung 160 gehöriges Attribut sein, welches verwendet wird, um den Zugriff auf eine anvisierte Speicherregion 180 zu steuern.
10 ist ein Ablaufplan 250 einer Ausführungsform eines Torwächterverfahrens zum Behandeln von Zugriffsanforderungen 160 von einem CPU-Thread auf einen Hauptspeicher 112. Im Block 252 schaltet ein Kern oder virtueller Kern innerhalb einer CPU 102 von einem ersten Thread auf einen zweiten Thread um. Durch diese Umschaltung wird der Software-Kontext geändert. Im Block 253 identifiziert das RTOS in Reaktion auf die Software-Kontext-Umschaltung die für den speziellen Thread geeignete Zugriffssteuerungsstrategie 166 oder wählt diese aus und programmiert die CPUPU 150 um, diese zu verwenden. Irgendwann, während der zweite Thread läuft (Block 254), fordert es Speicherzugriff auf den Hauptspeicher 112 an. Im Block 256, und bevor irgendeine Busentscheidung ausgelöst ist, verwaltet die CPUPU 150 die Zugriffssteuerungsstrategie 166, die Speicherzugriffsanforderung 160 zuzulassen oder zu blockieren. Wenn die CPUPU 150 die Anforderung 160 blockiert, dann meldet sie im Block 258 einen Fehler, der dann vom RTOS behandelt wird. Wenn die CPUPU 150 die Anforderung 160 zulässt, dann entscheidet die CPU 102 im Block 260 für einen Zugriff auf den Systembus 104 und gibt die Speicherzugriffsanforderung 160 an den Bus 104 aus. Der Hauptspeicher 112 weist nicht seine eigene dedizierte PU auf, um eine zweite Torwächterstufe auf die Speicherzugriffsanforderung 160 anzuwenden. Im Block 262 wird auf den Speicher 112 zugegriffen.
11 ist ein Ablaufplan 300 einer Ausführungsform eines Torwächterverfahrens zum Verwalten von Zugriffsanforderungen 160 von einem CPU-Thread oder Direktspeicherzugriffs(DMA)-Kanal 120 auf eine Peripherieeinheit 114. Im Block 302 fordert ein CPU-Thread Speicherzugriff auf eine DMA-verbundene Peripherieeinheit an. Das Verfahren wird im Block 304 fortgesetzt. Bevor eine Busentscheidung ausgelöst wird, verwaltet die CPUPU 150 die Zugriffssteuerungsstrategie 168, die für den Thread geeignet ist, der die Anforderung 160 ausgegeben hat, um die Anforderung 160 zuzulassen oder zu blockieren. Gemäß dem Block 306 meldet die CPUPU 150 dann, wenn sie die Anforderung blockiert hat, im Block 308 einen Fehler. Wenn die CPUPU 150 die Anforderung zugelassen hat, wird das Verfahren mit dem Block 310 fortgesetzt.
Bevor die Blöcke 310 bis 312 beschrieben werden, sei die Aufmerksamkeit auf eine unabhängige Speicherzugriffsanforderung 160 gerichtet, die von einer BMPU 152 kommt. Es sei angemerkt, dass der Ablaufplan 300 nicht bedeutet, dass die Aktionen in den beiden Blöcken 302 und 314 zusammengehören oder dass beides geschehen muss. Die Verwendung eines Ablaufplans zur Darstellung der Behandlung von Speicherzugriffsanforderungen 160, die entweder von der CPU 102 oder einem anderen Bus-Master 106 stammen, soll eine prägnante Art der Veranschaulichung sein, wie ähnliche Ereignisketten beiden Typen von Anforderungen 160 folgen.
Im Block 314 empfängt eine BMPU 152 eine Speicherzugriffsanforderung 160 von der CPU 102 oder einem anderen Hardware-Untersystem. Die BMPU 152 indexiert den Hardware-Unterkontext 186 – beispielsweise die DMA-Kanalkennung 190 – in die Zugriffssteuerungsstrategie-Struktur 184 der BMPU, um eine geeignete Zugriffsstrategie 188 auszuwählen oder abzurufen. Es ist nicht erforderlich, die Master-Kennung/Markierung 216 zu indexieren, da sie implizit zur BMPU 152 gehört, welche nur Zugriffssteuerungsstrategien 184 speichert, die für den Bus-Master 106 relevant sind, mit welchem sie verbunden ist.
Die BMPU 152 vergleicht die Sicherheitsattribute 194 und die anvisierte Speicherstelle mit Zugriffsstrategie-Konfigurationsinformationen, die in der Zugriffssteuerungsstrategie 188 gespeichert sind, um zu bestimmen, ob die Anforderung 160 zuzulassen oder zu blockieren ist. Wenn die PPU 154 die abschließende Entscheidung trifft, an die Anforderung 160 zuzulassen oder zu blockieren ist, dann die Speicherregion, welche die Peripherieeinheit 114 betrifft, als für diesen speziellen Hardware-Unterkontext 186 ungeprüft markiert (d. h. keine auferlegte Sicherheitsbeschränkungen). Entsprechend gelangt die Speicherzugriffsanforderung 160 hindurch.
Gemäß dem Block 316 meldet die BMPU 152 dann, wenn sie die Anforderung blockiert hat, im Block 308 einen Fehler. Wenn die BMPU 152 die Anforderung zugelassen hat, dann wird das Verfahren mit dem Block 310 fortgesetzt. Nun den Blöcken 310 bis 312 zuwendend, entscheidet im Block 310 der relevante Bus-Master 106 oder die CPU 102 auf einen Zugriff auf den Bus 104 und gibt eine Anforderung 160 an die Peripherieeinheit 114 aus. Im Block 318 wird die Anforderung 160 von der PPU 154 aufgenommen, welche den Hardware-Kontext 196 (einschließlich des Hardware-Unterkontexts 186, falls vorhanden) und die Peripherienummer 222 in ihre Zugriffssteuerungsstrategie-Struktur 200 indexiert, um die geeignete Peripherie-Zugriffsstrategie 206 auszuwählen oder abzurufen.
Es ist erwähnenswert, dass die PPU 154 nicht in der Lage sein muss, die tatsächliche Peripherieeinheit 114, den tatsächlichen CPU-Kern oder Thread oder die andere Quelle der Speicherzugriffsanforderung 160 zu ermitteln, die zu dem Hardware-Kontext 196 gehört. Beispielsweise kann der Prozessor 100 die zu dem Hardware-Kontext 196 gehörigen Binärwerte einer anderen Hardware-Ressource neu zuordnen (an diese binden). Der Prozessor 100 könnte auch eine Peripherienummer 222 einer anderen Peripherieeinheit 114 neu zuordnen oder sie an diese binden. Die PPU 154 ist über solche Bindungen im Unklaren und stützt sich stattdessen auf den Hardware-Kontext 196 (einschließlich des Hardware-Unterkontexts 186, falls vorhanden) und die Peripherienummer 222 zum Auswählen oder Abrufen einer geeigneten Zugriffssteuerungsstrategie 206. Das RTOS hingegen verfolgt die Beziehung zwischen dem Hardware-Kontext 196 (einschließlich des Hardware-Unterkontexts 186, falls vorhanden) und der zugehörigen Hardware-Ressource und zwischen der Peripherienummer 222 und der Peripherieeinheit 114.
Da die PPU 154 über jeglichen Software-Thread, der zu dem CPU-Hardware-Kontext gehört, im Unklaren ist, aktualisiert die CPU 102 jedes Mal, wenn es eine Software-Aufgabenumschaltung gibt, die zu dem CPU-Hardware-Kontext 196 gehörige Zugriffssteuerungsstrategie 320 an der PPU 154, damit sie zu dem Thread passt.
Beispielsweise aktualisiert die CPU 102, gerade bevor der RTOS-Thread, der als eine sichere Einheit abläuft, inaktiv wird, die Zugriffssteuerungsstrategie 320 der PPUs 154 und RPUs 158, die zu dem CPU-Hardware-Kontext 196 gehören, um die gewünschten Zugriffssteuerungsstrategien für den unsicheren Benutzer-Thread widerzuspiegeln.
Im Block 322 vergleicht die PPU 154 nach dem Abrufen oder Auswählen der Zugriffssteuerungsstrategie 206 die Sicherheitsattribute 194 der Anforderung und die anvisierte Speicherstelle mit Zugriffsstrategie-Konfigurationsinformationen in der Zugriffssteuerungsstrategie 206, um zu bestimmen, ob die Anforderung 160 zuzulassen oder zu blockieren ist. Gemäß dem Block 32 meldet die PPU 154 dann, wenn sie die Anforderung blockiert hat, im Block 308 einen Fehler. Wenn die PPU 154 die Anforderung zugelassen hat, wird das Verfahren mit dem Block 312 fortgesetzt, wo die Anforderung erfüllt wird.
12 ist ein Ablaufplan 350, welcher ein Torwächterverfahren für Zugriffsanforderungen 160 auf eine Peripherieeinheit 114 aus der Perspektive einer PPU 154 oder RPU 158 veranschaulicht. Im Block 352 empfängt die PPU 154 oder RPU 158 eine Anforderung 160 zum Lesen oder Schreiben für ein oder mehrere Peripherieeinheits-114-Register oder Registerbits. Im Block 354 verwendet die PPU 154 – wenn die PPU 154 das Torwächterverfahren 350 anwendet – die Kennungen MASTERID 216, MASTERSID 190 und PERIPHERAL_NUM 222, um in ihre Zugriffssteuerungsstrategie-Struktur 200 zu indexieren, um die geeignete Zugriffssteuerungsstrategie 320 auszuwählen oder abzurufen, die Zugriffsrechte auf die anvisierte Peripherieeinheit 114 definiert. Alternativ verwendet die RPU 158 – wenn die RPU 158 das Torwächterverfahren 350 anwendet – die Kennungen MASTERID 216, und MASTERSID 190 (aber nicht PERIPHERAL_NUM 222, da der Umfang der Peripherieeinheit sie selbst ist, nicht auch die anderen Peripherieeinheiten), um in ihre Zugriffssteuerungsstrategie-Struktur 200 zu indexieren, um die geeignete Zugriffssteuerungsstrategie 320 für diese Peripherieeinheit 114 auszuwählen oder abzurufen.
Im Block 356 vergleicht die PPU 154 oder RPU 158 Charakteristika (hierin als „Sicherheitsattribute” bezeichnet) der Zugriffsanforderung 160 (z. B. sicher oder unsicher, Daten oder Befehl, Lesen oder Schreiben) mit den Zugriffsbeschränkungen, die von der Zugriffssteuerungsstrategie 320 für die Register oder Registerbits vorgesehen sind, die von der Zugriffsanforderung 160 anvisiert werden. Wenn im Block 358 und auf der Basis dieses Vergleichs die Zugriffsanforderung 160 zugelassen wird, dann wird die Zugriffsanforderung 160 im Block 360 erfüllt. Anderenfalls meldet die PPU 154 oder die RPU 158 im Block 308 einen Fehler.
13 ist ein Ablaufplan 400, welcher ein Torwächterverfahren für Zugriffsanforderung 160 auf eine Peripherieeinheit 114 aus der Perspektive einer BMPU 152 veranschaulicht. Im Block 402 empfängt die BMPU 152 eine Zugriffsanforderung 160. Im Block 404 verwendet die BMPU 152 die MASTERSID-Kennung 190 zum Indexieren in ihre Zugriffssteuerungsstrategie-Struktur 184, um die Zugriffssteuerungsstrategie 188 auszuwählen oder abzurufen, um sie über einen gegebenen DMA-Kanal 120 durchzusetzen. Im Block 406 vergleicht die BMPU 152 die Quellenattribute (z. B. sicher oder unsicher, Daten oder Befehl, Lesen oder Schreiben) mit den Zugriffsbeschränkungen, die von der Zugriffssteuerungsstrategie 188 für die Speicherregion(en) vorgesehen sind, die von der Zugriffsanforderung 160 anvisiert wird (werden). Wenn im Block 408 und auf der Basis dieses Vergleichs die Zugriffsanforderung 160 zugelassen wird, dann wird die Zugriffsanforderung 160 im Block 410 erfüllt. Anderenfalls meldet die PPU 154 im Block 308 einen Fehler.
14 ist ein Zeitdiagramm 412, welches ein Zusammenspiel von Ausführungszuständen, DMA-Zuständen und PPU-Zugriffskontexten veranschaulicht. Die obere Reihe veranschaulicht einen frühen Zeitpunkt 414, zu welchem die CPU 102 einen DMA-Controller 110 und eine BMPU 152 über die SMU 162 vorprogrammiert. Anschließend ist der DMA-Controller 110 dafür konfiguriert, selbständig DMA-Anforderungen zu bedienen, unabhängig vom und ohne den Eingriff der CPU 102. In ähnlicher Weise ist die BMPU 152 dafür konfiguriert, die Zugriffssteuerungsstrategien 184 selbständig, unabhängig vom und ohne den Eingriff der CPU 102 zu verwalten. Ein Entscheidungs- und Planungsmechanismus, welcher einigen DMA-Anforderungen gegenüber anderen Priorität gewähren kann, bestimmt zu jeder gegebenen Zeit, welcher DMA-Kanal 120 aktiv ist. Der Entscheidungs- und Planungsmechanismus handelt auch unabhängig von der CPU 102, nachdem er von der CPU 102 vorprogrammiert wurde.
Die zweite Reihe veranschaulicht den CPU-Ausführungszustand 416, wenn die CPU 102 von einer ersten unsicheren (Non-Secure, NS) Aufgabe A in einen Ruhezustand, in einen sicheren (S) RTOS-aktiven Zustand, zu einer zweiten unsicheren (NS) Aufgabe B übergeht. Die Aufgabe A weist Zugriffsrechte auf eine Teilmenge von Speichern und Peripherieeinheiten auf. Sie hat auch Zugriff zu DMA-Konfigurationsregistern, die auf den DMA-Kanal 0 bezogen sind. Der DMA-Kanal 0 weist in ähnlicher Weise Zugriff auf dieselbe Teilmenge von Speichern und Peripherieeinheiten wie die Aufgabe A auf. Die Aufgabe B weist Zugriffsrechte auf eine andere Teilmenge von Speichern und Peripherieeinheiten und auf DMA-Konfigurationsregister auf, die auf den DMA-Kanal 1 bezogen sind. Der DMA-Kanal 1 weist in ähnlicher Weise Zugriff auf dieselbe Teilmenge von Speichern und Peripherieeinheiten wie die Aufgabe B auf. Das RTOS weist Zugriffsrechte auf alle Speicher, Peripherieeinheiten sowie die DMA-Konfigurationsregister aller DMA-Kanäle 120 auf. Jedes Mal 418, wenn eine Aufgabenumschaltung erfolgt, konfiguriert die CPU 102 die SMU 162, die CPUPU 150, alle PPUs 154 und alle RPUs 158 mit Zugriffssteuerungsstrategien zu aktualisieren, die für diese Aufgabe geeignet sind.
Die dritte Reihe veranschaulicht den asynchronen Betrieb der CPU 102 und des DMA-Controllers 110, indem sie einen DMA-Kanalzustand 450 zeigt, der vom CPU-Ausführungszustand 416 unabhängig ist. Beispielsweise ist der DMA-Kanal 1 als inaktiv dargestellt, während die Aufgabe A aktiv ist, während sich die CPU 102 im Ruhezustand befindet und während ein RTOS-Thread aktiv ist. Der aktive Status des Kanals 1, während sich die CPU 102 im Ruhezustand befindet, veranschaulicht, wie die DMA-Hardware-Kontexte 196 aktiv bleiben können, auch wenn sich die CPU 102 in einem inaktiven Niedrigstromzustand befindet.
Eine DMA-Kanal-Umschaltung 452 auf den Kanal 0 – betrieben durch den oben beschriebenen Entscheidungs- und Planungsmechanismus – ist so dargestellt, dass sie zu derselben Zeit erfolgt, zu der der CPU-Ausführungszustand 450 auf die Aufgabe B umgeschaltet wird. Eine andere DMA-kanalumschaltung 454, ebenfalls von dem oben beschriebenen Entscheidungs- und Planungsmechanismus betrieben, und diesmal zurück zum Kanal 1, erfolgt, während die Aufgabe B weiter abläuft. Diese Umschaltungen erfolgen unabhängig von der CPU 102 und gemäß dem Entscheidungs- und Planungsmechanismus des DMA-Controllers 110.
Die vierte Reihe (als solche ein Satz von Reihen) ist eine beispielhafte Veranschaulichung von Peripherieeinheiten 456, welche so konfiguriert sind, dass verschiedene Kanäle 120 auf sie zugreifen können. In dieser speziellen Darstellung sind Peripherieeinheiten P3, P5 und P8 so dargestellt, dass auf sie zugegriffen werden kann, wenn der DMA-Kanal 1 aktiv ist, während nur die Peripherieeinheiten P0 und P8 so dargestellt sind, dass auf sie zugegriffen werden kann, wenn der DMA-Kanal 0 aktiv ist. Die vierte Reihe zeigt, wie sich die Gruppe von Peripherieeinheiten 456, auf die zugegriffen werden kann, mit jeder DMA-Kanalumschaltung ändert.
Die fünfte Reihe veranschaulicht den PPU/RPU-Zugriffskontext 458 gemäß dem Hardware-Kontext 196 einschließlich des Hardware-Unterkontexts 186, dargestellt in der Form MASTERID 216 „Punkt” MASTERSID 190. Diese Reihe veranschaulicht, dass der Zugriffskontext 458 an einer speicherabgebildeten Peripherieeinheit 114 zu beliebigen Zeiten asynchron zu dem Prozessor 100 zwischen der CPU 102 und verschiedenen DMA-Kanälen 120 umschalten kann. Der DMA-Controller 110 kann außerdem Zugriff auf dieselben Peripherieeinheiten 114 wie die Aufgabe A benötigen. Ferner kann eine CPU-Aufgabe, z. B. die Aufgabe A, ihre eigenen DMA-Operationen planen, und zeitlich vorab, so dass die DMA-Operationen ausgeführt werden, nachdem die Aufgabe A nicht mehr abläuft. Insbesondere nimmt die PPU 154 oder die RPU 158 nur die numerischen Codierungen MASTERSID 216 und MASTERSID 190 wahr, nicht, welche Aufgabe oder welcher Kanal zu diesen Kennungen gehört.
Die sechste Reihe veranschaulicht den PPU/RPU-Zugriffskontext 460 durch die Aufgabe oder den speziellen Kanal, die/der zu diesen Hardware-Kontexten 196 gehört. Da das RTOS vollständig kontrolliert, welcher Benutzeraufgabenkontext aktiv ist, und den Prozessor 100 und System-PUs für jede Umschaltung entsprechend aktualisieren kann, benötigt es möglicherweise nur eine einzige HW-Kontext-Ressource 196 bei jeder gegebenen PU und Zeiten seiner Auswahl binden verschiedene Software-Kontexte an diese Ressource. Beispielsweise gehört zu Beginn der Reihe die CPU-Aufgabe A zu der CPU.0-Hardware-Kontext-Kennung. Später, während sich die CPU 102 im Ruhezustand befindet, gehört die CPU-Aufgabe A immer noch zu der CPU.0-Hardware-Kontext-Kennung, obwohl die Aufgabe A bereits abgeschlossen ist. Wie oben in der Beschreibung der fünften Reihe angezeigt, ist es für die CPU-Aufgabe A möglich, eine später vorgelegte Zugriffsanforderung durch eine DMA-Operation aufzurufen. Hierdurch wird weiter veranschaulicht, wie die Zugriffskontexte einer DMA-verbundenen Peripherieeinheit 114 asynchron zu dem CPU-Aufgabenzustand sein können. Wenn das RTOS aktiv wird, gehört das RTOS zu der CPU.0-Hardware-Kontext-Kennung. Später gehört die CPU-Aufgabe B zu der CPU.0-Hardware-Kontext-Kennung.
Obwohl 14 einen vereinfachten Zeitstrahl für einen Einzelkern-, Einzel-Thread-Prozessor 100 veranschaulicht, ist die Erfindung auf Ausführungsformen anwendbar, welche komplexere Architekturen umfassen. In einem Multi-Core- oder Multi-Thread-Prozessor 100 weist jeder Kern oder virtuelle Kern seinen eigenen Aufgabenkontext auf. Wenn die Kerne und anderen Hardware-Untersysteme Transaktionen mit Peripherieeinheiten 114 aufrufen, werden diese Transaktionen trichterartig auf den Peripheriebus 116 geleitet. Wenn die Transaktionen in den Peripheriebus 116 kommen, werden sie serialisiert, genau wie sie es mit einem Einzelkern-, Einzel-Thread-Prozessor 100 werden (sofern der Peripheriebus 116 einen Mehrfachanschlussspeicher bereitstellt). Auch beim Mehrfachanschluss nimmt jeder Anschluss nur eine Transaktion zu einer Zeit auf, so kann sowohl in einfachen als auch in komplexen Architekturen ein Entscheidungsmechanismus bereitgestellt werden, um sie in einer Reihenfolge vorzulegen. Vorteilhafter Weise ermöglicht dieses Serialisierungsverfahren der PPU 154 auszuschalten, welche Zugriffsstrategie irgendein gegebener Kern auch immer aufweist, und jeder Kern kann auch seinen eigenen Software-Kontext oder Aufgabenkontext umprogrammieren, wenn umgeschaltet wird. In einem Prozessor 100 mit mehreren Peripherieuntersystemen, wobei jedes seine eigene PPU 154 aufweist, kann ein Zugriff auf die PPUs 154 parallel erfolgen. In einem solchen Fall serialisiert jedes Peripherieuntersystem die Transaktionen unabhängig von jedem anderen Peripherieuntersystem; und jede PPU 154 realisiert die Zugriffssteuerung für ihr Peripherieuntersystemunabhängig von jeder anderen PPU 154.
Es sei angemerkt, dass, obwohl Peripherieeinheiten 114 gewöhnlich als Bus-Slaves konfiguriert sind, einige Peripherieeinheiten 114 als Bus-Master 106 konfiguriert sind und einige Typen von Peripherieeinheiten 114 Bus-Master mit Slave-Anschlüssen sind. Die Erfindung ist auf all diese Konfigurationen anwendbar. Im Fall einer Peripherieeinheit 114, die als ein Bus-Master 106 konfiguriert ist, aber einen Slave-Anschluss aufweist, steuert eine BMPU 152 den Zugriff auf Speicherzugriffsanforderungen 160, die von der Peripherieeinheit 114 erzeugt werden, und eine PPU 154 am Slave-Anschluss der Peripherieeinheit überwacht Speicherzugriffsanforderungen 160, die versuchen, auf die Peripherieeinheit 114 zuzugreifen.
Die oben beschriebenen speziellen Ausführungsformen sind lediglich veranschaulichend und der Fachmann erkennt, dass er das offenbarte Konzept und spezielle Ausführungsformen einfach als eine Grundlage zum Entwerfen oder Modifizieren anderer Strukturen zur Verfolgung derselben Zwecke der vorliegenden Erfindung nutzen kann und dass hierin verschiedene Änderungen, Ersetzungen und Abwandlungen vorgenommen werden können, ohne vom Umfang der Erfindung abzuweichen, wie er durch die anhängenden Patentansprüche ausgeführt ist.

Claims

Prozessor, umfassend: eine Zentralprozessoreinheit (CPU); CPU-externen Systemspeicher; mehrere andere Hardware-Untersysteme als die CPU, welche in der Lage sind, eine Speicherzugriffsanforderung auszugeben; einen Systembus, welcher die CPU mit dem Systemspeicher verbindet, wobei der Systembus dafür konfiguriert ist, Speicherzugriffsanforderungen zwischen verschiedenen Hardware-Untersystemen des Prozessors zu übermitteln, wobei eine Speicherzugriffsanforderung eine Hardware-Kontext-Kennung, welche ein Hardware-Untersystem identifiziert, das die Speicherzugriffsanforderung ausgegeben hat, umfasst oder von dieser begleitet ist; und eine CPU-externe programmierbare speicheradressierbare Schutzeinheit (PU), welche dafür konfiguriert ist, mehrere Hardware-Kontext- und/oder Unterkontextspezifische Zugriffssteuerungsstrategien für Speicherzugriffsanforderungen unabhängig von der CPU zu verwalten; wobei die PU dafür konfiguriert ist, die Hardware-Kontext-Kennung und/oder Subkontext-Kennung zu verwenden, um eine geeignete Zugriffssteuerungsstrategie auszuwählen, um eine Speicherzugriffsanforderung gemäß der ausgewählten Zugriffssteuerungsstrategie zuzulassen oder zu blockieren.
Prozessor nach Anspruch 1, wobei die PU so zu betreiben ist, dass sie mehrere Hardware-Kontext- und/oder Unterkontext-spezifische Zugriffssteuerungsstrategien für Speicherzugriffsanforderungen verwaltet, während sich die CPU im Ruhezustand befindet, und ohne sie zu wecken.
Prozessor nach Anspruch 1, wobei: die Zugriffssteuerungsstrategie Zugriffskriterien für eine oder mehrere Speicherregionen definiert; die Speicherzugriffsanforderung eine Ziel-Speicherstelle identifiziert und die PU dafür konfiguriert ist, die Ziel-Speicherstelle mit einer entsprechenden der Speicherregionen zu vergleichen, um zu bestimmen, ob die Speicherzugriffsanforderung zuzulassen oder zu blockieren ist.
Prozessor nach Anspruch 1, wobei die Speicherzugriffsanforderung auf dem Systembus ein oder mehrere Sicherheitsattribute, welche eine Sicherheitsstufe und/oder Privilegierungsstufe der Speicherzugriffsanforderung definieren, umfasst oder davon begleitet ist.
Prozessor nach Anspruch 1, welcher ferner Signalleitungen in dem Systembus umfasst, die dafür konfiguriert sind, die Hardware-Kontext- oder Unterkontext-Kennung zu übertragen.
Prozessor nach Anspruch 1, wobei die PU für eine Peripheriebusbrücke dediziert ist.
Prozessor nach Anspruch 1, wobei die PU für einen DMA-Controller dediziert ist, die PU dafür konfiguriert ist, für verschiedene DMA-Kanäle verschiedene Zugriffssteuerungsstrategien zu verwalten, und die PU dafür konfiguriert ist, eine DMA-Kanalnummer zu verwenden, um die Zugriffssteuerungsstrategie entsprechend der DMA-Kanalnummer auszuwählen.
Prozessor nach Anspruch 1, wobei: der Prozessor sowohl erste als auch zweite PUs umfasst, wobei jede PU CPU-extern ist und dafür konfiguriert ist, mehrere Hardware-bezogene Zugriffssteuerungsstrategien für Speicherzugriffsanforderungen zu verwalten, während sich die CPU im Ruhezustand befindet, und ohne die CPU zu wecken; die erste PU für einen Systembus-Master dediziert ist, welcher Speicherzugriffsanforderungen auf Systemspeicher und speicherabgebildete Peripherieeinheiten ausgibt; und die zweite PU für eine oder mehrere Peripherieeinheiten dediziert ist, welche Speicherzugriffsanforderungen empfangen; die erste und zweite PU in Bezug aufeinander relativ grobe bzw. feinkörnige Zugriffssteuerungsstrategien für Speicherzugriffsanforderungen anwenden, die auf die eine oder die mehreren Peripherieeinheiten gerichtet sind.
Verfahren zum sicheren Handhaben von Speicherzugriffsanforderungen in einem Prozessor mit einer Zentralprozessoreinheit (CPU), CPU-externem Systemspeicher, einem Systembus, mehreren anderen Hardware-Untersystemen als der CPU, die in der Lage sind, eine Speicherzugriffsanforderung auszugeben, und einer programmierbaren speicheradressierbaren Schutzeinheit (PU), wobei das Verfahren umfasst: Ausgeben von Speicherzugriffsanforderungen auf den Systembus durch die Hardware-Untersysteme, wobei eine Speicherzugriffsanforderung eine Hardware-Kontext-Kennung, welche identifiziert, von welcher Einheit die Speicherzugriffsanforderung stammt, umfasst oder davon begleitet ist; und Verwenden der Hardware-Kontext-Kennung durch die PU zum Auswählen einer Hardware-Kontext- und/oder Unterkontext-spezifischen Zugriffssteuerungsstrategie und Zulassen oder Blockieren von Speicherzugriffsanforderungen gemäß der ausgewählten Zugriffssteuerungsstrategie.
Verfahren nach Anspruch 9, ferner umfassend Verwalten mehrerer Hardware-Kontext- und/oder Unterkontext-spezifischer Zugriffssteuerungsstrategien für Speicherzugriffsanforderungen, während sich die CPU im Ruhezustand befindet, und ohne sie zu wecken.
Verfahren nach Anspruch 9, ferner umfassend: Definieren von Zugriffskriterien für eine oder mehrere Speicherregionen durch die Zugriffssteuerungsstrategie; Identifizieren einer Ziel-Speicherstelle durch die Speicherzugriffsanforderung und Vergleichen der Ziel-Speicherstelle mit einer entsprechenden der Speicherregionen durch die PU, um zu bestimmen, ob die Speicherzugriffsanforderung zuzulassen oder zu blockieren ist.
Verfahren nach Anspruch 9, ferner umfassend Behaupten einer oder mehrerer Signalleitungen auf dem Systembus zum Anzeigen einer Sicherheitsstufe und/oder Privilegierungsstufe der Speicherzugriffsanforderung.
Verfahren nach Anspruch 9, ferner umfassend Behaupten mehrerer Signalleitungen auf dem Systembus zum Identifizieren des zu der Speicherzugriffsanforderung gehörigen Hardware-Kontexts und/oder Unterkontexts.
Verfahren nach Anspruch 9, wobei die PU für eine Peripheriebusbrücke dediziert ist.
Verfahren nach Anspruch 9, wobei die PU für einen DMA-Controller dediziert ist und die PU für verschiedene DMA-Kanäle verschiedene Zugriffssteuerungsstrategien verwaltet, wobei das Verfahren ferner umfasst, dass die PU eine DMA-Kanalnummer verwendet, um eine Zugriffssteuerungsstrategie entsprechend der DMA-Kanalnummer auszuwählen.
Prozessor, umfassend: eine Zentralprozessoreinheit (CPU); Systemspeicher; einen Peripherieanschluss für mindestens eine Peripherieeinheit; einen Systembus, welcher die CPU mit dem Systemspeicher verbindet, wobei der Systembus auch einen Weg zu dem Peripherieanschluss bereitstellet; und eine Peripherie-Schutzeinheit (PPU), wobei die PPU für Folgendes konfiguriert ist: Fungieren als ein Torwächter für Speicherzugriffsanforderungen, die auf den Peripherieanschluss gerichtet sind; Auswählen von Zugriffssteuerungsstrategien, die für Hardware-Ressourcen spezifisch sind, welche die Speicherzugriffsanforderungen zuführen; und Verwalten der Zugriffssteuerungsstrategie, um auf der Basis Speicherzugriffsanforderungen zuzulassen oder zu blockieren.
Prozessor nach Anspruch 16, welcher ferner einen DMA-Controller (DMA) mit mehreren Kanälen umfasst, wobei die PPU dafür konfiguriert ist, einen zu einer DMA-Speicherzugriffsanforderung gehörigen DMA-Kanal zu erfassen.
Prozessor nach Anspruch 16, ferner umfassend: einen CPU- und PPU-externen zentralen Sicherheitskonfigurations-Controller (SMU); wobei der SMU dafür konfiguriert ist, durch die CPU mit Zugriffssteuerungsstrategien programmiert zu werden; wobei der SMU ferner dafür konfiguriert ist, die Zugriffssteuerungsstrategien auf eine oder mehrere PPUs in dem Prozessor zu verteilen.
Prozessor nach Anspruch 16, welcher ferner Signalleitungen in dem Systembus umfasst, die dafür konfiguriert sind, eine Hardware-Kontext- und/oder Unterkontext-Kennung zu übertragen, welche einen Hardware-Kontext und/oder Unterkontext der Hardware-Ressource identifiziert, welche eine Speicherzugriffsanforderung zuführt.
Prozessor nach Anspruch 16, wobei die PPU so zu betreiben ist, dass sie mehrere Hardware-Kontext- und/oder Unterkontext-spezifische Zugriffssteuerungsstrategien für Speicherzugriffsanforderungen auf den Peripherieanschluss verwaltet, während sich die CPU im Ruhezustand befindet, und ohne sie zu wecken.