DE112017003659T5

DE112017003659T5 - Kontextbasiertes schutzsystem

Info

Publication number: DE112017003659T5
Application number: DE112017003659.3T
Authority: DE
Inventors: Jan-Willem van de Waerdt; Kai Dieffenbach; Uwe Moslehner; Venkat Natarajan; Jens Wagner; Mathias Sedner
Original assignee: Cypress Semiconductor Corp
Current assignee: Cypress Semiconductor Corp
Priority date: 2016-07-19
Filing date: 2017-07-19
Publication date: 2019-04-04
Also published as: US11416421B2; CN109564555B; WO2018017702A1; JP2019525319A; US20180024945A1; CN109564555A; JP7001670B2

Abstract

Ein kontextbasiertes Schutzsystem verwendet gestaffelte Schutzstrukturen, die Master-Schutzeinheiten, geteilte Speicherschutzeinheiten, eine Peripherie-Schutzeinheiten umfassen, um Sicherheit für Bustransferoperationen zwischen zentralen Verarbeitungseinheiten (CPUs), Speichergruppierung oder Abschnitten von Gruppierungen und Peripherien bereitzustellen.

Description

VERWANDTE ANMELDUNGEN
Diese Anmeldung ist eine internationale Anmeldung der nicht vorläufigen US-Patentanmeldung Nr. 15/653,203 , eingereicht am 18. Juli 2017, die die Priorität der vorläufigen US-Patentanmeldung Nr. 62/364,652 , eingereicht am 20. Juli 2016, und der vorläufigen US-Patentanmeldung Nr. 62/364,246 , eingereicht am 19. Juli 2016, beansprucht, die durch Bezugnahme in ihrer Gesamtheit hierin einbezogen sind.
GEBIET DER ERFINDUNG
Die vorliegende Offenbarung bezieht sich allgemein auf eingebettete Systeme und insbesondere auf Sicherheit von Kommunikation und Daten innerhalb eingebetteter Systeme.
Figurenliste

1 illustriert ein eingebettetes System, das konfigurierbar ist, um ein kontextbasiertes Schutzsystem zu implementieren, gemäß einer einzelnen Ausführungsform.
2 illustriert ein kontextbasiertes Schutzsystem gemäß einer einzelnen Ausführungsform.
3 illustriert ein Verfahren zum Bewerten der Sicherheit von Transfers zu/von einer Peripherie unter Verwendung eines Schutzsystems gemäß einer einzelnen Ausführungsform.
4 illustriert ein Schema zum Ändern eines Schutzkontextes einer Peripherie gemäß einer einzelnen Ausführungsform.
5 illustriert ein Schema zum Ändern eines Schutzkontextes einer Peripherie gemäß einer einzelnen Ausführungsform.

ÜBERSICHT
Eingebettete Systeme funktionieren durch Übertragen von Informationen an und von verschiedenen Komponenten über eine Reihe von Bussen. Eine Verarbeitungseinheit eines eingebetteten Systems kann konfiguriert sein, um in einem Speicher oder in Speichern gespeicherte Anweisungen oder Zugriffsinformationen auszuführen. Die Verarbeitungseinheit kann auch mit anderen Systemkomponenten kommunizieren oder diese steuern, wie etwa digitale und analoge Blöcke oder Peripherievorrichtungen. Die digitalen oder analogen Blöcke oder sogar die Peripherievorrichtungen können hart codiert (feste Funktion) sein oder sie können programmierbar sein. Die Steuerung von Systemkomponenten und der Zugriff auf oder der Transfer von Informationen kann über die Reihe von Bussen oder Bus-Infrastrukturen realisiert werden.
Ein kontextbasiertes Schutzsystem kann eine zentrale Verarbeitungseinheit (Central Processing Unit, CPU) umfassen, die konfigurierbar ist, um in einer Vielzahl von Schutzkontexten zu arbeiten. Das kontextbasierte Schutzsystem kann mindestens ein Peripheriemodul umfassen, wobei das Peripheriemodul durch die CPU zugreifbar ist, wenn die CPU in einem ersten Schutzkontext der Vielzahl von Schutzkontexten konfiguriert ist, und durch die CPU nicht zugreifbar ist, wenn die CPU in einem zweiten Schutzkontext der Vielzahl von Schutzkontexten konfiguriert ist.
Das kontextbasierte Schutzsystem kann als Teil einer Bus-Infrastruktur implementiert werden, die Schutzstrukturen beinhaltet. Die Schutzstrukturen können eine Speicherschutzeinheit (Memory Protection Unit, MPU) umfassen, die einem einzelnen Bus-Master zugeteilt ist, wobei die MPU Benutzerzugriff und privilegierten Zugriff von dem Bus-Master differenziert. Die Schutzstrukturen können eine geteilte Speicherschutzeinheit (Shared Memory Protection Unit, SMPU) umfassen, die einer Vielzahl von Bus-Masters zugeteilt ist, wobei die SMPU zwischen unterschiedlichen Schutzkontexten differenziert und zwischen sicherem und nicht sicherem Zugriff auf einen Speicher differenziert. Die Schutzstrukturen können auch eine Peripherie-Schutzeinheit (Peripheral Protection Unit, PPU) umfassen, die einer Peripheriegruppe zugeteilt ist, wobei die PPU sichere und nicht sichere Zugriffe auf die Peripheriegruppe differenziert.
DETAILLIERTE BESCHREIBUNG
Ein Bus-Transfer kann zeitgleich mit anderen Bus-Transfers stattfinden. Unterschiedliche Verarbeitungseinheiten können auf unterschiedliche Systemkomponenten basierend auf den Systemanforderungen und den verschiedenen Aufgaben, die von dem System erfüllt werden können, zugreifen. Da auf den Bussen so viel zeitgleich geschieht, ist es wichtig, Transferoperationen und versuchte Transferoperationen zu verfolgen und zu steuern, um sicherzustellen, dass das System wie beabsichtigt mit optimaler Leistung und erforderlicher Sicherheit arbeitet.
Eingebettete Systeme können auch Schutz erfordern, um Sicherheit, Funktionssicherheit und Leistung zu verwirklichen. In Bezug auf die Sicherheit ist es notwendig, sichere Speicherregionen und MMIO-Adressregionen gegen nicht autorisierte Zugriffe zu schützen. Das heißt, Zugriffe auf Programme und Datenspeicher muss auf autorisierte Verwendungen beschränkt sein, dies gilt aber auch für Peripherievorrichtungen, die über einen Bus Befehle empfangen oder Daten teilen können. In Bezug auf die Funktionssicherheit muss es Aufgaben und Prozessen verboten sein, auf Speicherregionen und MMIO-Adressregionen zuzugreifen, die mit anderen Aufgaben und Prozessen assoziiert sind. Eine Isolation stellt sicher, dass die Operation von jedem einzelnen selbst in Gegenwart einer Bus-Störung stattfinden kann. Andererseits müssen Speicherregionen und MMIO-Adressregionen vor Aufgaben und Prozessen geschützt werden, die mit diesen nicht assoziiert sind, sodass sie für ihre designierten Aufgaben und Prozesse verfügbar sind. All dieser Schutz kann zu Bus-Latenz führen, wodurch die Leistung beeinträchtigt wird. Und eine Rekonfiguration eines Schutzsystems muss ebenfalls möglich sein, ohne Latenzprobleme zu erzeugen.
1 illustriert ein System 100, das konfiguriert werden kann, um Sicherheit über eine konfigurierbare Bus-Architektur 140 bereitzustellen. Das System 100 kann ein E/A-Teilsystem 105 umfassen, das mit einem CPU-Teilsystem 110 gekoppelt ist. Das CPU-Teilsystem 100 kann konfiguriert werden, um eine Anzahl von Eingängen und Ausgängen aufzuweisen, einschließlich jener von und zu dem E/A-Teilsystem 105 sowie von Peripheriegruppen (Elemente nicht gezeigt, Verbindungen mit Peripheriegruppen 1 und 2 werden jedoch gezeigt). Andere Verbindungen mit dem CPU-Teilsystem 110 können ebenfalls vorliegen, wie unten beschrieben.
Das CPU-Teilsystem 110 kann eine Debug-Infrastruktur 115 und einen Test-Controller 117 umfassen, die jeweils mit dem E/A-Teilsystem 105 und mit einem ersten Verarbeitungskern und einem zweiten Verarbeitungskern gekoppelt sind. Der erste Verarbeitungskern kann als ARM-Cortex-M4-Kern, CM4-Kern, 120 implementiert werden. Der CM4-Kern 120 kann eine zentrale CM4-Verarbeitungseinheit (CPU) 126, Unterbrechungsfunktionen 122 und Debug-Komponenten 124 umfassen. Der CM4-Kern 120 kann konfiguriert werden, um mit einer schnelleren Verarbeitungsgeschwindigkeit zu laufen und um höhere Verarbeitungs- und Leistungsanforderungen zu erreichen. Der zweite Verarbeitungskern kann als ARM-Cortex-M0+, CM0+-Kern, 130 implementiert werden. Der CM0+-Kern 130 kann eine CM0+CPU 136, Unterbrechungsfunktionen 132 und Debug-Komponenten 134 umfassen. Der CM0+-Kern 130 kann konfiguriert werden, um mit langsameren Verarbeitungsgeschwindigkeiten (Frequenzen) zu laufen, und kann als Hilfsprozessor wirken.
Das CPU-Teilsystem 110 kann auch eine konfigurierbare Bus-Architektur 140 umfassen, die eine schnelle Infrastruktur 142 und langsame Infrastruktur 144 umfassen kann. Die konfigurierbare Bus-Architektur 140 kann konfiguriert werden, um Sicherheit für Daten und Befehle bereitzustellen, die von Verarbeitungskernen, Speichern und Peripherieeinheiten übertragen werden. Die konfigurierbare Bus-Architektur 140 kann mit einem Flash-Controller 161 für Flash 162, mit einem ROM-Controller 163 für ROM 164 und mit SRAM-Controllers 165 für SRAM 166 gekoppelt werden. In einer einzelnen Ausführungsform kann es mehrere SRAM-Module und einen mit jedem assoziierten SRAM-Controller geben. Speicherorte können Teil des CPU-Teilsystems 110 oder Teil von getrennten Systemkomponenten in verschiedenen Ausführungsformen sein.
Eine schnelle Infrastruktur 142 kann mit einem CM4-Kern 120 über eine Systemschnittstelle (Sys-I/F) und eine Code-Schnittstelle (Code-I/F) gekoppelt werden, um Informationen und Befehle von dem CM4-Kern 120 zu empfangen. Die schnelle Infrastruktur 142 kann auch mit einer Peripherieschnittstelle und mit Slaves, die mit schnelleren Verarbeitungsgeschwindigkeiten laufen (schnelle externe Slaves), gekoppelt werden.
Eine langsame Infrastruktur 144 kann mit dem Test-Controller 117 und mit langsamen externen Masters sowie CRYPTO-Block 170 und einem Paar Datenleitungen: Datenleitung 0 172 und Datenleitung 1 174 gekoppelt werden. Die langsame Infrastruktur 144 kann auch mit langsamen externen Slave-Vorrichtungen, CM0+-Kern 130 und mit dem Paar Datenleitungen 172 und 175 gekoppelt werden. Die langsame Infrastruktur 144 kann auch mit Peripherieeinheiten extern zu dem CPU-Teilsystem 110 gekoppelt werden. Externe Peripherieeinheiten können langsame externe Slaves umfassen.
Die konfigurierbare Bus-Architektur 140, einschließlich der langsamen Infrastruktur 142 und schnellen Infrastruktur 144, kann Schutz oder Sicherheit durch Implementieren von Schutzlogik bereitstellen, die Transfers über die Busse basierend auf Bus-Transfer-Spezifika erlaubt oder einschränkt. Bus-Transfer-Spezifika können Bus-Adressbereiche und unterschiedliche Attribute, einschließlich Lese/Schreib-, Ausführungs-, privilegierten/Benutzer-, sicheren/nicht sicheren Attributs, und andere umfassen. Der Schutz für Speicher kann durch Speicherschutzeinheiten (MPUs) und geteilte Speicherschutzeinheiten (SMPUs) bereitgestellt werden. Der Schutz für Peripherien kann durch Peripherie-Schutzeinheiten (PPUs) bereitgestellt werden. SMPUs und PPUs können kontextbasierte Schutzverfolgung basierend auf Schutzkontextattributen eines Bus-Masters unterstützen. Mit dieser Konfiguration kann ein einzelner Bus-Master in mehreren Schutzrollen durch Reprogrammieren eines mit dem Schutzkontext assoziierten Feldes arbeiten.
Das CPU-Teilsystem 110 kann Schutz-MMIO-Register 150, Fehlerdetektions-MMIO-Register 180, CPU-Teilsystem(CPUSS)-MMIO-Register und Interprozessor-Kommunikations(IPC)-MMIO Register 184 umfassen, um verschiedene Elemente des CPU-Teilsystems zu steuern und zu konfigurieren und um eine Funktionalität eines Schutzsystems bereitzustellen.
2 illustriert ein Blockdiagramm eines Schutzsystems 200, das Schutzkontexte implementieren kann, gemäß einer einzelnen Ausführungsform der vorliegenden Erfindung. Das Schutzsystem 200 kann, teilweise, in der konfigurierbaren Bus-Infrastruktur 140 von 1, in einer einzelnen Ausführungsform, implementiert werden. Verschiedene Elemente des Schutzsystems 200 können als Registerorte implementiert werden, die durch die System-Bus-Architektur 210 und das CPU-Teilsystem 110 von 1 zugreifbar sind.
Das Schutzsystem 200 kann eine Reihe von Bus-Masters 201.0-201.n umfassen. Die Bus-Masters 201.0-201.n können Verkehr auf der System-Bus-Architektur 210 steuern, wenn Informationen von der Speichergruppierung 220 gelesen und auf diese und auf Peripherien, die Teil der Peripheriegruppen 250.0-250.n sein können, geschrieben werden. Die Bus-Masters 201.0-201.n können jeweils eine Speicherschutzeinheit (MPU) 203.0-203.n aufweisen. Die MPUs 203.0-203.n können in dem Bus-Master integriert werden, wie gezeigt in Bus-Masters 201.0 und 201.3, oder sie können getrennte Elemente sein, die als eigenständige Einheiten (Bus-Masters 201.1 und 201.2) oder als Teil der System-Bus-Architektur, nicht gezeigt, implementiert werden.
Wenn eine MPU als Teil eines Bus-Masters implementiert wird, wie es für Bus-Masters 201.1 und 201.2 der Fall ist, kann die MPU als Teil der CPU implementiert werden und kann unter der Kontrolle des Betriebssystems (OS) oder Kernels stehen. Wenn eine MPU getrennt von einem Bus-Master implementiert wird, wie es für MPUs 203.1 und 203.2 der Fall ist, kann die MPU als Teil der Bus-Architektur (wie etwa System-Bus-Infrastruktur 210) implementiert werden. In einer solchen Ausführungsformen kann die MPU unter der Kontrolle des OS oder Kernels der CPU stehen, die den Bus-Master „besitzt“ oder verwendet. Beispielsweise kann die MPU 203.1 unter der Kontrolle des OS oder Kernels einer CPU stehen, die den Bus-Master 201.1 besitzt. MPUs, die als Teil der System-Bus-Infrastruktur 210 implementiert werden, können mit Bus-Masters, wie etwa USB-Controllers, Ethernet-Controllers für Grafik-Controllers, assoziiert sein. Diese Liste ist nicht dazu gedacht, vollständig zu sein; andere Bus-Masters können mit der System-Bus-Infrastruktur 210 verwendet werden. In einer einzelnen Ausführungsform können MPUs, wie jene als MPU 203.1 und 203.2 illustrierte, als Teil einer CPU implementiert werden, um eine konsistente Softwareschnittstelle sicherzustellen. In einer solchen Ausführungsform kann die MPU mit einer spezifischen Speicherregion assoziiert sein und kann eine spezifische Zugriffsattributsdefinition zugeteilt erhalten. Spezifische Zugriffsattributsdefinitionen können definieren, wie und warum Zugriff auf verschiedene Systemkomponenten und Speicherorte bereitgestellt wird, wie unten beschrieben.
Die MPUs 203.0-203.n können zwischen Benutzerzugriff und privilegiertem Zugriff für einen einzelnen Bus-Master (respektive 201.1-201.n) unterscheiden. Die MPUs können auch eine Zugriffssteuerung des sicheren/nicht sicheren Attributs durchführen. Falls ein Bus-Master, wie etwa Bus-Masters 201.0-201.n, Aufgaben ändert oder falls ein Nicht-CPU-Master, der mit einer eigenständigen MPU assoziiert ist, den Besitz ändert, können die MPU von der OS- oder Kernel-Software angepasst werden.
In einer einzelnen Ausführungsform können Direktspeicherzugriffs(Direct Memory Access, DMA)-Controllers mit einer MPU implementiert werden. In dieser Ausführungsform kann der DMA-Controller Steuerungsattribute eines Bustransfers (oder von Bustransfers) erben, die den Kanal programmierten, mit dem der DMA-Controller verbunden ist.
Das Schutzsystem 200 kann auch eine Reihe von geteilten Speicherschutzeinheiten (SMPUs) 205.0-205.n umfassen. Die SMPUs 205.1-205.n können mit einem Bus-Master (respektive 201.1-201.n) assoziiert sein und zwischen einer MPU, falls implementiert, und System-Bus-Architektur 210 angeordnet sein. Die SMPUs können von allen Bus-Masters 201.1-201.n geteilt werden; dies steht im Kontrast zu MPUs 203.1-203.n, die für einen einzelnen Bus-Master zweckgebunden sein können. Die SMPUs 205.1-205.n können zwischen unterschiedlichen Schutzkontexten und zwischen sicheren und nicht sicheren Zugriffen unterscheiden. Die SMPUs 205.1-205.n können auch Zugriffsteuerung basierend auf dem Benutzerattribut/privilegierten Modusattribut durchführen.
Das Schutzsystem 200 kann eine System-Bus-Architektur 210 umfassen, die mit den Bus-Masters 201.1-201.n und mit einem Speicher-Teilsystem 220 gekoppelt ist. Das Speicher-Teilsystem 220 kann mindestens eine Speichergruppierung (illustriert als drei Speichergruppierungen, 223.0-223.2) und mindestens einen Speicher-Controller (illustriert als drei Speicher-Controllers, 221.0-221.2) umfassen. Die Speicher-Controllers 221.0-221.2 können Lese- und Schreiboperationen zu Speicherorten von Speichergruppierungen 223.0-223.2 basierend auf Bus-Transfers und Befehlen auf der System-Bus-Architektur 210, wie von den Bus-Masters 201.1-201.n angewiesen, steuern. Der Zugriff auf Speicherorte von Speichergruppierungen 223.0-223.2 kann von MPUs 203.1-203.n und SMPUs 205.1-205.n gesteuert werden.
Das Schutzsystem 200 kann auch eine Peripherie-Bus-Architektur 230 umfassen, die mit der System-Bus-Architektur 210 gekoppelt ist. Die Peripherie-Bus-Architektur 230 kann mindestens eine Master/(MS)-Schnittstelle 231.1-231.n umfassen, die mit der System-Bus-Architektur 210 für den Empfang von Bus-Transfers von Bus-Masters 201.1-201.n gekoppelt ist. Die MS-Schnittstellen 231.1-231.n können Peripherie-Schutzeinheiten (PPUs) 233.1-233.n umfassen.
Die Peripherie-Bus-Infrastruktur 230 kann Vermittler 235.0-235.n zum Handhaben von Verkehr zwischen MS-Schnittstellen 231.1-231.n und Peripheriegruppen 250.0-250.n umfassen. Zur leichteren Beschreibung wird unten nur die Peripherieeinheit 250.0 beschrieben, aber die Peripheriegruppen 250.1-250.n können auf gleiche Weise konstruiert werden. Die Peripheriegruppe 250.0 kann eine PPU 251.0, PPU-MMIO-Register 252.0 und 253.0, SMPU-MMIO-Register 254.0, MPU-MMIO-Register 255.0 und Peripherie-MMIO-Register 256.0 umfassen. Die verschiedenen MMIO-Register können verwendet werden, um Sicherheit und Schutz zu implementieren, die über die System-Bus-Architektur 210 und Bus-Architektur 140 von 1 realisiert werden.
Das Schutzsystem 200 kann jedem Bus-Master erlauben, auf das Peripherie-Teilsystem über exakt eine Master/Slave-Schnittstelle (MS0-MS3) zuzugreifen. Die vier Master/Slave-Schnittstellen können bis zu vier gleichzeitige Zugriffe auf die Peripherien aktivieren, solange Zugriffe über unterschiedliche Master-Schnittstellen erfolgen und auf unterschiedliche Peripheriegruppen des Peripherie-Teilsystems gerichtet sind.
Jede Master/Slave-Schnittstelle kann feste PPU-Strukturen entsprechend jeder Peripheriegruppe sowie programmierbare PPU-Strukturen umfassen. In jeder der Peripheriegruppen können feste PPU-Strukturen für Peripherie-Teilregionen (z. B. 252 und 253) sowie feste PPU-Strukturen für jede Peripherie (z. B. 251) existieren. Feste PPU-Strukturen für die Peripheriegruppen können den Zugriff auf eine gesamte Peripheriegruppe für gewisse Schutzkontexte verweigern oder begrenzen. In einer solchen Ausführungsform können Ausnahmen für gewisse Teiladressbereiche innerhalb der Peripheriegruppe nicht gestattet sein. Feste PPU-Strukturen für die Peripheriegruppen können die höchste Priorität erhalten und sie können in der Master/Slave-Schnittstelle (als Teil der PPU 233) liegen. Mit dieser Ausführungsform wird, wenn ein Zugriff verweigert wird, der Zugriff nicht die angezielte Peripheriegruppe erreichen; auf die Peripheriegruppe kann gleichzeitig von einer anderen Master-Schnittstelle zugegriffen werden.
Feste PPU-Strukturen für Peripherie-Teilregionen sowie für ganze Peripherien können Adressbereiche umfassen, die kleiner als eine Peripheriegruppe sind. Demzufolge können sie in der Peripheriegruppe selbst liegen. Da feste PPU-Strukturen für die Peripherie-Teilregionen Ausnahmen von den Schutzattributen der ganzen Peripherie erzeugen, können sie eine höhere Priorität als die festen PPU-Strukturen aufweisen, die für die gesamte Peripherie definiert sind.
Programmierbare PPU-Strukturen können den kombinierten Adressbereich von allen Peripheriegruppen abdecken. Programmierbare PPU-Strukturen können daher in den Master/Slave-Schnittstellen liegen. In anderen Ausführungsformen können programmierbare PPU-Strukturen innerhalb der Peripheriegruppen liegen. In einer ersten Ausführungsform kann es duplizierte programmierbare PPU-Strukturen in jeder Peripheriegruppe geben. In einer zweiten Ausführungsform können die programmierbaren PPU-Strukturen unter den Peripheriegruppen verteilt sein.
3 illustriert ein Verfahren 300, um sicherzustellen, dass programmierbare PPU-Strukturen nach festen PPU-Strukturen in den Peripheriegruppen bewertet werden. Programmierbare PPU-Strukturen werden in Schritt 310 bewertet. Falls in Entscheidungsschritt 315 eine Verletzung detektiert wird, können Informationen mit der Verletzung markiert werden. Feste PPU-Strukturen können in Schritt 320 bewertet werden. In einer einzelnen Ausführungsform kann Schritt 320 zeitgleich mit oder getrennt von Schritt 310 stattfinden. Falls in Entscheidungsschritt 325 eine Verletzung nicht detektiert wird, können die markierten Informationen von Schritt 330 in Schritt 340 bewertet werden. Falls in Entscheidungsschritt 345 keine Verletzung detektiert wird, kann in Schritt 350 Zugriff gewährt werden. Falls in Entscheidungsschritt 315 keine Verletzung detektiert wurde, kann in Schritt 350 ebenfalls Zugriff gewährt werden. Falls entweder in Entscheidungsschritt 325 oder Entscheidungsschritt 345 eine Versetzung detektiert wird, kann in Schritt 360 Zugriff verweigert werden.
Das Schutzsystem 200 von 2 kann ein kontextbasiertes Schutzschema mit den MPUs, SMPUs und PPUs bereitstellen, das erlaubt, mehrere Schutzstrukturen zu unterstützen, wobei jede Struktur einen Adressbereich in einer einheitlichen Speicherarchitektur und Zugriffsattribute, die regeln, wie Zugriff auf einen gegebenen Adressbereich gestattet wird, spezifizieren. Eine Verletzung, die von dem Schutzsystem detektiert oder verboten wird, kann durch eine Nichtzusammenpassung zwischen der Adressregion und Zugriffsattributen eines Bustransfers und den Adressbereichen und Zugriffsattributen der Schutzstrukturen verursacht werden. Wenn eine Verletzung detektiert wird, kann die Verletzung in einer Fehlerberichtsstruktur, wie etwa Fehler-MMIO 180 von 1, erfasst werden, die eine künftige Analyse erlaubt. Es kann nützlich sein, die Ursache von Fehlern zu verstehen. Ein Fehler in der Operation kann auf Bugs in der Programmierung oder Systemdefinition zurückzuführen sein. Fehler können auf nicht autorisierte Zugriffs- oder Steuerungsversuche zurückzuführen sein. Fehlerberichtstrukturen können eine Unterbrechung generieren, um auf das Stattfinden eines Fehlers hinzuweisen. In einer einzelnen Ausführungsform kann die Unterbrechung verwendet werden, um eine Verarbeitungsvorrichtung außerhalb des Systems darauf hinzuweisen, dass ein Fehler stattgefunden hat und dass eine Analyse notwendig ist. Dies kann besonders nützlich sein, wenn ein Bus-Master den Bus-Fehler nicht selbst lösen kann, aber einen anderen Bus-Master erfordert, um den Bus-Fehler an seiner Stelle zu lösen.
Eine Verletzung des Schutzsystems, die in einem Bus-Fehler resultiert, verbietet, dass der Bus-Transfer sein Ziel erreicht. Beispielsweise eine MPU- oder SMPU-Verletzung, die eine Peripherieeinheit anzielt, wird nicht die PPU der Peripherie erreichen.
Schutzkontexte
Jeder Bus-Master kann ein MPU-Schutzkontextfeld, PC[], aufweisen. Der Schutzkontext kann als Schutzkontextattribut für alle Bus-Transfers verwendet werden, die von dem Bus-Master initiiert werden. SMPUs und PPUs können Bus-Transfers zu Speicher- und Peripherieorten, die von dem Bus-Master initiiert werden, basierend auf dem Schutzkontext, der den Bus-Transfers zugeteilt ist, erlauben oder verbieten (beschränken).
In einer einzelnen Ausführungsform können sich mehrere Bus-Masters einen Schutzkontext teilen. Beispielsweise eine CPU und ein USB-Controller, der unter der Kontrolle dieser CPU steht, können sich den gleichen Schutzkontext teilen. In diesem Beispiel können die CPU und der USB-Controller die gleichen SMPU- und PPU-Zugriffsbeschränkungen aufweisen und Bus-Transfers können jeweils (von der CPU und dem USB-Controller) unter den gleichen Bedingungen und zu den gleichen Speicher- oder Peripherieorten erlaubt oder verboten sein.
Ein Schutzkontext eines Bus-Masters kann durch Reprogrammieren des PC[]-Feldes (PC[]) geändert werden. Da die Funktion des Schutzkontexts jedoch darin besteht, Bus-Transfers zu erlauben oder zu verbieten, müssen Änderungen des PC[]-Feldes kontrolliert werden. Das heißt, Änderungen des PC[]-Feldes müssen die Sicherheit des Systems aufrechterhalten. Falls versäumt wird, für Aktualisierungen des PC[]-Feldes das gleiche Sicherheitsniveau aufrechtzuerhalten, können Änderungen an der Sicherheit des Systems erlaubt werden, die nicht beabsichtigt waren oder die den Schutzkontext umgehen können. Des Weiteren sollten Änderungen des Schutzkontexts nur einen minimalen CPU-Overhead mit sich ziehen, sodass Schutzkontexte regelmäßig gehindert werden können, ohne die Bus-Latenz und Leistung negativ zu beeinträchtigen. Um regelmäßige und sichere Änderungen der Schutzkontexte zu realisieren, kann jeder Bus-Master ein SMPU-Schutzkontext-Maskenfeld aufweisen, das die verfügbaren Schutzkontexte identifiziert, die in dem Bus-Master-PC[]-Feld programmiert werden können. Die folgenden Felder können die erforderliche Sicherheit für die Bus-Master-Schutzkontext-Kontrolle bereitstellen:

• MPU-Schutzkontext - unter der Kontrolle des Bus-Masters; weist die gleichen Zugriffsbeschränkungen wie die MPU-MMIO-Register des Bus-Masters auf.
• Schutzkontext Maske - unter der Kontrolle der Sicheren CPU; weist die gleichen Zugangsbeschränkungen wie die SMPU-MMIO-Register auf.

SMPUs und PPUs erlauben und beschränken Bus-Transfers basierend auf dem Schutzkontext Attribut, das den Bus-Transfers zugeteilt ist. Der Schutzkontext stellt daher einen Schritt des Schutzes zwischen dem Bus-Master und dem SMPU- und dem PPU-Schutz bereit. Diese Ausführungsform erlaubt einem einzelnen Bus-Master, mit mehreren Schutzrollen durch Reprogrammieren des PC[]-Feldes zu identifizieren. Eine Änderung der Schutzkontexte weist einen begrenzten CPU-Overhead auf, da die SMPUs und PPUs nicht reprogrammiert werden müssen.
Zweckgebundene Funktionalität
Es kann wünschenswert sein, einen Schutzkontext mit zweckgebundener Funktionalität zu haben. In einer einzelnen Ausführungsform kann die zweckgebundene Funktionalität dem Schutzkontext 0 zugeteilt sein. Schutzkontext 0 kann vollständigen Zugriff auf alle Systemkomponenten aufweisen. Es ist wichtig, einen „Vertrauensanker“ zu etablieren. Bus-Master 0 kann verwendet werden oder es kann ihm gestattet werden, als „sichere CPU“ zu fungieren, sodass die sichere CPU sowohl Hersteller-Code als auch Kunden-Code ausführen kann. Hersteller-Code für die CPU kann in einem Festwertspeicher (Read-Only Memory, ROM) oder Flash, wie etwa ROM 164 und Flash 162, gespeichert werden. Hersteller-ROM kann als vertrauenswürdig (ein Vertrauensanker) betrachtet werden und verwendet werden, um Hersteller-Flash zu authentifizieren. In verschiedenen Ausführungsformen kann der Hersteller-Code verwendet werden, um Flash-Programmierung, eFUSE-Programmierung oder eine andere herstellereigene Funktionalität bereitzustellen.
Kunden-Code für die Ausführung der sicheren CPU können im Flash programmiert werden. Der Hersteller hat möglicherweise keine Kontrolle über diesen Code. Kunden-Code kann daher nicht als vertrauenswürdig angenommen werden. Kunden-Code-Ausführung sollte die vertrauenswürdige Qualität des Hersteller-Codes beinhalten.
Da vertrauenswürdiger Hersteller-Code und nicht vertrauenswürdige Kunden-Code von der gleichen CPU ausgeführt werden können, kann es notwendig sein, ein Schutzschema bereitzustellen, das auf mehr als masterspezifischen Schutzkontexten basiert. Eine dem Schutzkontext 0 verliehene spezielle Bedeutung kann Hardwareunterstützung und Kontrolle für sicheren CPU-Schutzkontext bereitstellen. Schutzkontext 0 kann unbegrenzten (nicht geschützten) Zugriff auf alle Speicher- und Peripherieorte bereitstellen. Schutzkontext 0 kann unter zwei Bedingungen geändert (oder eingegeben) werden; die Verwendung des Schutzkontext 0 kann daher beschränkt sein.
Bei der ersten Bedingung kann die sichere CPU durch die Ausführung eines Rücksetzungsausnahmebehandlers zurückgesetzt werden. Bei dieser Bedingung kann eine Vektoradresse von einer spezifischen ROM-Adresse bereitgestellt werden. Da ROM-Adressen von dem Hersteller bereitgestellt werden, ist die Vektoradresse vertrauenswürdig, und da die Vektoradresse vom ROM bereitgestellt wird. Der Eingabepunkt des Behandlers ist daher vertrauenswürdig. Nach Rückstellung einer sicheren CPU können alle Unterbrechungen deaktiviert werden und die CPU-Ausführung kann deterministisch sein (d. h. vollständig bestimmt von dem Rücksetzungsausnahmebehandler).
Bei der zweiten Bedingung kann ein Ausnahme- oder Unterbrechungsbehandler einer sicheren CPU empfangen werden. Bei dieser Bedingung kann die Behandler-Vektoradresse von einer Vektortabelle mit einer konfigurierbaren Basisadresse bereitgestellt werden. Wenn die sichere CPU zurückgestellt ist, kann die Basisadresse auf einen Standardwert eingestellt werden und kann die Behandler-Vektoradresse geschrieben werden. Da die Behandler-Vektoradresse eine ROM-Adresse ist, ist sie vertrauenswürdig. Die CPU kann jedoch von der Vektortabelle-Basisadresse auf eine SRAM-Adresse verlegt werden und die Behandler-Vektoradresse kann auf jeden beliebigen Wert programmiert werden. Der programmierte Wert kann in einem vom Kunden bereitgestellten Behandler-Code resultieren. In diesem Fall ist der Eingabepunkt des Behandlers nicht vertrauenswürdig. Der Schutzkontext kann jedoch nur auf 0 gehindert werden, falls die Vektor-Behandler-Adresse der sicheren CPU die gleiche wie die spezifische Vektoradresse ist. Es ist für Kunden-Code möglich, die Vektortabelle zu verlegen, aber eine Änderung auf den Schutzkontext 0 würde erfordern, dass die Vektoradresse nicht modifiziert wird. Wenn das System detektiert, dass die Vektoradresse der sicheren CPU nicht die gleiche wie der Behandler ist, wird der Schutzkontext nicht auf 0 geändert. Falls er bereits 0 ist, kann er zurück auf den Wert geändert werden, den er hatte, bevor er auf 0 geändert wurde.
Die Sicherheit für den Schutzkontext 0 ist entscheidend, da der Schutzkontext 0 vertrauenswürdigen Hersteller-Code identifiziert und unbegrenzten Zugriff (von SMPUs und PPUs) bereitstellt.
Schutzstrukturen
Das Schutzsystem der vorliegenden Erfindung ist dafür beabsichtigt, Bus-Transfers auf einer Bus-Infrastruktur (hierin auch System-Bus-Architektur genannt) zu erlauben oder zu beschränken. Ein Bus-Transfer des Schutzsystems spezifiziert eine Reihe von Attributen, die Folgendes umfassen:

• einen Adressbereich, auf dem durch den Bus-Transfer zugegriffen wird;
• ein Lese-/Schreibattribut;
• ein Ausführungsattribut;
• ein Benutzerattribut/privilegiertes Attribut;
• ein sicheres/nicht sicheres Attribut; und
• ein Schutzkontextattribut.

Ein Bus-Transfer-Adressbereich spezifiziert entweder Speicherorte oder Peripherie-MMIO-Register, für die der Bus-Transfer beabsichtigt ist. Strukturell gibt es kaum einen Unterschied zwischen Speicherschutz und Peripherieschutz. Für die Implementierung von Sicherheitsmaßnahmen in einem System ist jedoch die Trennung von Speicherschutz und Peripherieschutz vorteilhaft. In einigen Ausführungsformen wird diese Trennung durch Bereitstellen von Speicherschutz in einem CPU-Teilsystem und Bereitstellen von Peripherieschutz in einem Peripherie-Teilsystem erreicht.
Das Lese-/Schreibattribut kann Schutz für einen Speicher oder eine Peripherie vor der Fähigkeit bieten, von einem spezifischen Master gelesen oder auf diesen geschrieben zu werden. Das Ausführungsattribut kann verwendet werden, um den Zugriff auf Code oder auf Daten eines spezifischen Speichers oder einer spezifischen Peripherie einzustellen. Das heißt, ein Bus-Transfer kann in einer einzelnen Ausführungsform versuchen, Zugriff auf den Code eines spezifischen Befehls oder einer spezifischen Peripherie zu erhalten. Während in einer anderen ein Bus-Transfer versuchen kann, Zugriff auf den Ausgang des Codes oder Befehls, nach der Ausführung, zu erhalten. Das Benutzerattribut/privilegierte Attribut kann verwendet werden, um zwischen OS- oder Kernel-Zugriff und Aufgaben- oder Thread-Zugriff zu unterscheiden. Das sichere/nicht sichere Attribut kann verwendet werden, um zwischen sicherem und nicht sicherem Zugriff zu unterscheiden. Das Schutzkontextattribut kann schließlich verwendet werden um gewisse Peripherien, Peripheriegruppen oder Masters abzugrenzen.
Wie in Bezug auf 1 beschrieben, kann es mehrere Niveaus von Schutzstrukturen geben, einschließlich Speicherschutzeinheiten (MPUs), geteilte Speicherschutzeinheiten (SMPUs) und Peripherie-Schutzeinheiten (PPUs). Eine MPU kann mit einem einzelnen Master assoziiert sein und kann Benutzerzugriff und privilegierten Zugriff von dem einzelnen assoziierten Master unterscheiden. Eine MPU kann auch eine Zugriffssteuerung an dem sicheren/nicht sicheren Attribut durchführen. Einige Masters können eine eingebaute MPU aufweisen, wie Bus-Masters 101.0 und 101.3 von 1. Für andere Bus-Masters kann die MPU als Teil der Bus-Infrastrukturen implementiert werden, wie etwa MPUs 103.1, 103.2 und 103.n von 1.
Eine SMPU kann von allen Bus-Masters geteilt werden. In einer einzelnen Ausführungsform kann eine SMPU von einem Teilsatz von Bus-Masters, aber nicht allen Bus-Masters des Systems, geteilt werden. Eine SMPU kann zwischen unterschiedlichen Schutzkontexten und zwischen sicheren und nicht sicheren Zugriffen unterscheiden. Eine SMPU kann auch Zugriffsteuerung basierend auf dem Benutzerattribut/privilegierten Modusattribut durchführen. Da SMPUs geteilt werden, werden diese nicht als Teil von spezifischen oder einzelnen Bus-Masters implementiert. Stattdessen können SMPUs als Teil der System-Bus-Architektur implementiert werden, sodass so viele Bus-Masters wie erforderlich auf sie zugreifen können.
PPUs können als Teil einer Master/Slave-Schnittstelle sowie als Teil einer Schnittstelle, die eine PPU umfasst, wie etwa MS-Schnittstellen 233 von 2, implementiert werden. Auf die Peripheriegruppe kann von mehreren Masters über mehrere Master-Schnittstellen über eine PPU zugegriffen werden, die für die Peripheriegruppe zweckgebunden ist, wie etwa Peripheriegruppen 251 von 2. Eine Peripheriegruppe kann aus mehreren Peripherieeinheiten mit einer geteilten AHB-Lite-Bus-Infrastruktur bestehen. PPUs können zwischen unterschiedlichen Schutzkontexten, zwischen sicheren und nicht sicheren Zugriffen und zwischen Benutzermoduszugriff und privilegiertem Moduszugriff unterscheiden.
Jede der Schutzstrukturen des Schutzsystems kann durch eine Adressregion und mindestens ein Zugriffssteuerungsattribut definiert sein. Die Schutzstruktur kann auf einen gegebenen Ort eines Speicherplatzes ausgerichtet sein. Zwei Register, die der Schutzstrukturadresse bzw. dem Attribut zugeteilt sind, können einen Schutz für die Schutzstrukturen erlauben.
Die folgenden Ressourcen erfordern möglicherweise Schutz, der mit dem beschriebenen Schutzsystem erreicht wird: Peripherien innerhalb einer Peripheriegruppe; und MMIO-Register innerhalb einer Peripherie, wie etwa individuelle IPC-Strukturen, Datenleitung oder Direktspeicherzugriff(DMA)-Controller-Kanal-Strukturen, SMPU-Schutzregion-Strukturen und PPU-Schutzregion-Strukturen. Die obigen Ressourcen können feste Adressbereiche oder Adressbereiche, die zum Zeitpunkt der Konzeption bekannt sind, einschließen.
Eine Schutzeinheit, wie etwa eine MPU und SMPU oder eine PPU, kann mehrere Schutzstrukturen beinhalten und kann diese mehreren Schutzstrukturen in absteigender Reihenfolge bewerten. Höher indizierte Strukturen können gegenüber niedriger indizierten Strukturen Vorrang haben. Für eine adäquate Sicherheit sollte es für einen nicht sicheren Schutzkontext nicht möglich sein, Schutzstrukturen hinzuzufügen, die einen höheren Index aufweisen als die Schutzstrukturen, die sicheren Zugriff bereitstellen. In einem solchen Fall kann es für eine Schutzstruktur mit einem höheren Index möglich sein, programmiert zu werden, um nicht sicheren Zugriff zu erlauben. In einem sicheren System sind höhere programmierbare Schutzstrukturen geschützt, um nur beschränkte Zugriffe zu erlauben.
Verglichen mit MPUs und SMPUs können PPUs eine relativ große Zahl von Schutzregionen aufweisen. Ressourcen, die möglicherweise einen von einer PPU bereitgestellten Schutz erfordern, können alle Peripherien innerhalb einer Peripheriegruppe oder einen Satz von MMIO-Registern innerhalb einer Peripherie umfassen. MMIO-Register innerhalb einer Peripherie können individuelle IPC-Strukturen, DMA-Controller-Kanal-Strukturen, SMPU-Schutzregion-Strukturen und PPU-Schutzregion-Strukturen umfassen.
PPU-Schutzstrukturen können Ressourcen mit einem bekannten Adressbereich umfassen, wofür Konzeptionszeitpunkt-Konfiguration des Schutzes erfordert, dass der Adressbereich implementiert werden kann. Für Ressourcen, die einen unbekannten Adressbereich aufweisen, wie jene, die durch Vorrichtungsbenutzung identifiziert werden, kann eine vollständige Programmierbarkeit des Adressbereichs der Schutzregion verwendet werden.
Zugriffssteuerungsattribute
Wie oben erwähnt, können Zugriffsattribute die Zugriffssteuerung für eine Region spezifizieren. Eine Region, oder Adressregion, kann durch eine Basisadresse, eine Größe der Region und Teilregionen innerhalb der Region, die aktiviert oder deaktiviert werden können, definiert sein. In einer einzelnen Ausführungsform kann es acht Teilregionen geben. Es können jedoch mehr oder weniger Teilregionen implementiert werden.
Zugriffssteuerung für eine Region kann an allen Teilregionen innerhalb der Region angewandt werden. Zugriffssteuerung wird durch Bewerten der Zugriffsattribute eines Transfers durchgeführt. In verschiedenen Ausführungsformen können die folgenden Zugriffssteuerungsfelder implementiert sein:

• Steuerung für Lesezugriffe im Benutzermodus;
• Steuerung für Schreibzugriffe im Benutzermodus;
• Steuerung für Ausführungszugriffe im Benutzermodus;
• Steuerung für Lesezugriffe im privilegierten Modus;
• Steuerung für Schreibzugriffe im privilegierten Modus;
• Steuerung für Ausführungszugriffe im privilegierten Modus;
• Steuerung für sicheren Zugriff;
• Steuerung für individuelle Schutzkontexte, kann nur in SMPUs und PPUs vorliegen; und
• Steuerung von „Zusammenpassung“ und „Zugriffsbewertungsprozessen“, die nur in SMPUs und PPUs vorliegen können.

Beispielsweise, unter Verwendung der obigen Zugriffssteuerungsfelder, kann Schutzkontext 2 für nicht sicheren Zugriff für Lese- und Schreibvorgänge in privilegiertem Modus mit den folgenden Einstellungen definiert werden:

Modus	Einstellung	Ergebnis
Lesezugriff im Benutzermodus	0	Lesezugriff im Benutzermodus nicht gestattet
Schreibzugriff im Benutzermodus	0	Schreibzugriff im Benutzermodus nicht gestattet
Ausführungszugriff im Benutzermodus	0	Ausführungszugriff im Benutzermodus nicht gestattet
Lesezugriff im privilegierten Modus	1	Lesezugriff im privilegierten Modus nicht gestattet
Schreibzugriff im privilegierten Modus	1	Schreibzugriff im privilegierten Modus nicht gestattet
Ausführungszugriff im privilegierten Modus	0	Ausführungszugriff im privilegierten Modus nicht gestattet
Sicherer Zugriff	0	Sicherer Zugriff nicht gestattet
Schutzkontext	0 × 0005	Zugriffe für Schutzkontexte 0 und 2 aktiviert
Zugriffsbewertung	0	Für Zugriffsbewertung verwendetes Maskenfeld

Es können drei getrennte Zugriffsbewertungs-Teilprozesse unterschieden werden. Ein erster Teilprozess kann den Zugriff basierend auf Lese/Schreib-, Ausführungs- und Benutzer-/privilegierten Zugriffsattributen bewerten. Ein zweiter Teilprozess kann den Zugriff basierend auf dem sicheren/nicht sicheren Attribut bewerten. Ein dritter Teilprozess kann den Zugriff basierend auf dem Schutzkontextattribut (verwendet von der SMPU und PPU) bewerten.
Falls alle Zugriffsbewertungen erfolgreich sind, kann der Zugriff gestattet werden. Falls eine der Zugriffsbewertungen nicht erfolgreich ist, kann der Zugriff verboten werden. Eine Verweigerung des Zugriffs kann in den Fehler-MMIO-Registern, wie etwa Fehler-MMIO-Register 180 von 1, gespeichert werden.
Zusammenpassung
Die Zusammenpassung der Bus-Transfer-Adresse und Zugriffsbewertung des Bus-Transfers kann in zwei unabhängigen Prozessen implementiert werden. Für die Zusammenpassung kann ein erster Prozess eine innerhalb eines Adressbereichs enthaltene Transfer-Adresse für jede Schutzstruktur identifizieren. Der erste Prozess kann dann bestimmen, ob ein geeignetes Bit, das einem gegebenen Schutzkontext entspricht, „1“ ist. Dies identifiziert die zusammenpassenden Regionen. Für die Zugriffsbewertung kann ein zweiter Prozess die Bus-Transfer-Attribute gegenüber den Zugriffssteuerungsattributen bewerten.
Es kann in einer Schutzeinheit mehrere Schutzstrukturen geben. In einer einzelnen Ausführungsform kann die Schutzeinheit Schutzstrukturen in absteigender Reihenfolge bewerten. Höher indizierte Strukturen können gegenüber niedriger indizierten Strukturen Vorrang haben. Höher indizierte Strukturen können mehr Kontrolle oder Zugriff als niedriger indizierte Strukturen aufweisen, sodass Zugriff auf höher indizierte Strukturen zuerst bewertet werden kann, um zu verhindern, dass niedriger indizierten Strukturen Zugriff erlaubt wird, wenn dieser erlaubt werden sollte. Falls versäumt wird, diesem Paradigma zu folgen, kann einem nicht sicheren Schutzkontext erlaubt werden, Schutzstrukturen hinzuzufügen, die einen höheren Index aufweisen als die Schutzstrukturen, die sicheren Zugriff bereitstellen. Mit anderen Worten, die Schutzstruktur mit dem höheren Index kann nicht ordnungsgemäß programmiert werden, um nicht sicheren Zugriff zu erlauben.
Schutz von Schutzstrukturen
Schutzstrukturen können einmal während des Boot-Zeitpunkts eingestellt werden oder sie können während der Vorrichtungsausführung dynamisch geändert werden. In einer einzelnen Ausführungsform kann ein CPU-RTOS die MPU-MMIO-Einstellungen der CPU ändern. Wie oben erwähnt, kann eine sichere CPU die SMPU- und PPU-MMIO-Einstellungen ändern. Da MPU-, SMPU- und PPU-MMIO-Register MMIO-Register sind, die anderen Peripherie-MMIO-Registern ähnlich sind, können sie ähnlich geändert werden. Darüber hinaus kann ein Adressbereich einer Schutzstruktur die Schutzstruktur selbst umfassen. Unter Verwendung dieser Tautologie kann es möglich sein, das Schutzsystem zu verwenden, um die Schutzstrukturen selbst zu schützen; das Schutzsystem ist daher schwieriger zu umgehen.
4 illustriert ein Schema 400, das verwendet wird, um eine Peripherie (A) 410 zu schützen, gemäß einer einzelnen Ausführungsform. Peripherie A kann von zwei Schutzkontexten, PC[1] 401 und PC[2] 402, geteilt werden. Peripherie A 410 kann eine Adressregion 415 aufweisen. Eine 42-Byte-PPU-Schutzstruktur 422 an Adresse 0x4000:0000 (bis zu ox4000:001f) kann verwendet werden, um Peripherie A 410 zu schützen. Die Schutzstruktur 422 kann eine von mehreren Schutzstrukturen sein, die mit PC[1] 401 und PC[2] 402 assoziiert sind. Die Schutzstrukturen können für PC[1] 401 und PC[2] 402 zusammen in PPU-Schutzstrukturen 420.1 und 420.2 gruppiert werden. Der Besitz der Peripherie A 410 kann von PC[1] 401 auf PC[2] übertragen werden, indem PC[1] 401 Schutzsteuerungsattribute der Schutzstruktur reprogrammiert, um sie auf PC[2] 402 auszurichten. Dies wird in 4 illustriert, wo PC[1] 401 die PPU-Schutzstruktur 422 reprogrammiert, sodass PC[2] auf Peripherie A 410 zugreifen kann. In ähnlicher Weise kann PC[2] 402, wenn es die Peripherie A 410 „besitzt“, die Peripherie A 410 PC[1] 401 zuteilen.
5 illustriert ein Schema 500, um eine Peripherie (B) 510 zu schützen, das verhindern kann, dass ein Schutzkontext, der die Peripherie B 510 nicht besitzt, den Besitz durch Reprogrammieren der Schutzkontext-Steuerungsattribute sich selbst zuteilt. Zwei 32-Byte-PPU-Schutzstrukturen 515 und 517 an Adressen 0x4000:0000 (bis zu ox4000:001f) und 0x4000:0020 (bis zu 0x4000:003f) können verwendet werden. Die Schutzstruktur 517 kann verwendet werden, um die Schutzstruktur 515 sowie sich selbst zu schützen. Die Schutzstruktur 515 kann eine Slave-Schutzstruktur sein und die Schutzstruktur 517 kann eine Master-Schutzstruktur sein. Master- und Slave-Schutzstrukturen können ein Schutzpaar 513 sein.
In der PPU können die Schutzstrukturen 520 den Schutzstrukturen 515 und 517 der Peripherie B 510 entsprechen. Die Slave-Schutzstruktur 522 kann auf die Schutzstruktur 515 ausgerichtet sein. Die Master-Schutzstruktur 524 kann auf die Schutzstruktur 517 ausgerichtet sein. Anfangs können die PPU-Schutzstrukturen 520.0 die Slave-Schutzstruktur 522 aufweisen, bei der der Besitz der Peripherie B PC[1] 501 zugeteilt ist und die Master-Schutzstruktur 524 PC[1] zugeteilt ist. In einem ersten Schritt kann PC[1] 501 den Besitz der Peripherie B 510 auf PC[2] 502 ändern, sodass die PPU-Schutzstrukturen 520.1 die Slave-Schutzstruktur 522 aufweisen, bei der der Besitz der Peripherie B PC[2] 502 zugeteilt ist und die Master-Schutzstruktur 524 PC[1] 501 zugeteilt ist. In einem zweiten Schritt kann PC[1] 501 den Master/Slave-Besitz der Peripherie B 510 auf PC[2] 502 ändern, sodass die PPU-Schutzstrukturen 520.2 die Slave-Schutzstruktur 522 aufweisen, bei der der Besitz der Peripherie B 510 PC[2] 502 zugeteilt ist und die Master-Schutzstruktur 524 PC[2] 502 zugeteilt ist.
Das Ändern des Besitzes von PC[2] 502 auf PC[1] 501 kann einem ähnlichen Muster folgen. In einem ersten Schritt kann PC[2] 502 den Besitz der Peripherie B 510 auf PC[1] 501 ändern, sodass die PPU-Schutzstrukturen 520.3 die Slave-Schutzstruktur 522 aufweisen, bei der der Besitz der Peripherie B PC[1] 501 zugeteilt ist und die Master-Schutzstruktur 524 PC[2] 502 zugeteilt ist. In einem zweiten Schritt kann PC[2] 502 den Master/Slave-Besitz der Peripherie B 510 auf PC[1] 501 ändern, sodass die PPU-Schutzstrukturen 520.1 die Slave-Schutzstruktur 522 aufweisen, bei der der Besitz der Peripherie B 510 PC[1] 501 zugeteilt ist und die Master-Schutzstruktur 524 PC[2] 502 zugeteilt ist.
Mit anderen Worten, ein erster Schritt ändert den Peripheriebesitz auf den anderen Schutzkontext und der zweite Schritt ändert die Fähigkeit, den Master/Slave-Besitz auf den anderen Schutzkontext zu ändern. Dieses Schema kann verhindern, dass ein Schutzkontext, der die Peripherie nicht besitzt, den Besitz durch Reprogrammieren der Schutzkontext-Steuerungsattribute sich selbst zuteilt.
Für das in 5 illustrierte Schema kann es bevorzugt sein, dass die Schutzstrukturen benachbart sind. Beispielsweise können die PPU- und SMPU-Schutzstrukturen in Paaren ausgerichtet sein. Eine erste Schulstruktur kann die Ressource (d. h. die Peripherie) schützen und die zweite Schutzstruktur kann den Schutz schützen. In verschiedenen anderen Ausführungsformen des in 5 illustrierten Schemas kann der Peripheriebesitz von mehr als zwei Schutzkontexten geteilt werden, während die Fähigkeit, den Besitz der Peripherie zu ändern, auf einen einzelnen Schutzkontext begrenzt sein kann.
In der obigen Beschreibung werden zahlreiche Details dargelegt. Es wird einem Durchschnittsfachmann auf dem Gebiet mit dem Nutzen dieser Offenbarung jedoch klar sein, dass Ausführungsformen der vorliegenden Erfindung ohne diese spezifischen Details ausgeübt werden können. In einigen Fällen werden bekannte Strukturen und Vorrichtungen in Blockdarstellungsform, anstatt im Detail, gezeigt, um ein Unverständlichmachen der Beschreibung zu vermeiden.
Einige Teile der Beschreibung werden im Hinblick auf Algorithmen und symbolische Repräsentation von Operationen an Datenbits innerhalb eines Computerspeichers präsentiert. Diese algorithmischen Beschreibungen und Repräsentationen sind die von Fachleuten auf dem Gebiet der Datenverarbeitung verwendeten Mittel, um den Inhalt ihrer Arbeit anderen Fachleuten auf dem Gebiet am effektivsten zu vermitteln. Ein Algorithmus wird hier und generell als eine in sich konsistente Sequenz von Schritten, die zu einem gewünschten Ergebnis führen, verstanden. Die Schritte sind jene, die physische Manipulationen von physischen Größen erfordern. Gewöhnlich, aber nicht notwendigerweise, bestehen diese Größen in Form von elektrischen oder magnetischen Signalen, die gespeichert, übertragen, kombiniert, verglichen und anderweitig manipuliert werden können. Es hat sich manchmal als praktisch erwiesen, prinzipiell aus Gründen gemeinsamer Nutzung, diese Signale als Bits, Werte, Elemente, Symbole, Zeichen, Ausdrücke, Nummern oder dergleichen zu bezeichnen.
Es sollte jedoch beachtet werden, dass alle diese und ähnliche Ausdrücke den entsprechenden physischen Größen zugehörig sein sollen und lediglich praktische Bezeichnungen für diese Größen sind. Sofern nicht spezifisch anders angegeben, wie aus der obigen Erörterung erkennbar, ist anzumerken, dass sich in der gesamten Beschreibung Erörterungen, die Ausdrücke wie „Verschlüsseln“, „Entschlüsseln“, „Speichern“, „Bereitstellen“, „Ableiten“, „Erhalten“, „Empfangen“ „Authentifizieren“, „Löschen“, „Ausführen“, „Anfordern“, „Kommunizieren“ oder dergleichen verwenden, auf die Vorgänge und Prozesse eines Computersystems oder einer ähnlichen elektronischen Computervorrichtung beziehen, das/die als physische (z. B. elektronische) Größen innerhalb der Register und Speicher des Computersystems repräsentierte Daten manipuliert und in andere, gleichermaßen als physische Größen innerhalb der Computersystemspeicher oder -register oder anderer Informationsspeicher-, Übertragungs- oder Anzeigevorrichtungen repräsentierte Daten transformiert.
Die Wörter „Beispiel“ oder „beispielhaft“ werden hierin verwendet, um als Beispiel, Fall oder Illustration dienend zu bedeuten. Jeder bzw. jede hierin als „Beispiel“ oder „beispielhaft“ beschriebene Aspekt bzw. Konstruktion ist nicht notwendigerweise als bevorzugt oder vorteilhaft gegenüber anderen Aspekten oder Konstruktionen zu verstehen. Vielmehr wird durch die Verwendung der Wörter „Beispiel“ oder „beispielhaft“ beabsichtigt, Konzepte auf eine konkrete Weise zu präsentieren. Wie in dieser Anmeldung verwendet, wird mit dem Ausdruck „oder“ ein inklusives „oder“ statt ein exklusives „oder“ bezeichnet. Das heißt, sofern nicht anders angegeben oder aus dem Kontext ersichtlich, bedeutet „X umfasst A oder B“ jede der natürlichen inklusiven Permutationen. Das heißt, falls X A umfasst, X B umfasst oder X sowohl A als auch B umfasst, dann wird „X umfasst A oder B“ unter jedem der vorstehenden Fälle erfüllt. Darüber hinaus sollen die Artikel „ein“ und „eine“, wie in dieser Anmeldung und den angehängten Ansprüchen verwendet, generell als „ein(e) oder mehrere“ verstanden werden, sofern nicht anders angegeben oder aus dem Kontext ersichtlich auf eine Singularform bezogen. Außerdem ist durchgehend der Ausdruck „eine Ausführungsform“ oder „eine einzelne Ausführungsform“ oder „eine Implementierung“ oder „eine einzelne Implementierung“ nicht als gleiche Ausführungsform oder Implementierung zu verstehen, sofern dies nicht so beschrieben wird.
Spezifische, in Bezug auf das oben beschriebene Protokoll referenzierte Befehle oder Meldungen sind nur als illustrativ gedacht. Ein durchschnittlicher Fachmann auf dem Gebiet würde verstehen, dass Befehle mit unterschiedlicher spezifischer Formulierung, aber ähnlicher Funktion, verwendet werden können und noch im Geltungsbereich der obigen Beschreibung liegen können.
Die hierin beschriebenen Ausführungsformen können sich auch auf eine Vorrichtung zum Durchführen der hierin detaillierten Operationen beziehen. Diese Vorrichtung kann speziell für die erforderlichen Zwecke gebaut sein oder kann einen Allzweckcomputer beinhalten, der durch ein im Computer gespeichertes Computerprogramm selektiv aktiviert oder rekonfiguriert wird. Ein solches Computerprogramm kann in einem nicht transitorischen computerlesbaren Speichermedium, wie etwa, aber nicht beschränkt auf jede Art von Diskette, einschließlich Floppydisks, optischer Platten, CD-ROMs und magnetisch-optischer Platten, Festwertspeicher (ROMs), Arbeitsspeicher (RAMs), EPROMs, EEPROMs, magnetischer oder optischer Karten, Flashspeicher oder jeder Art von Medium, das für das Speichern von elektronischen Anweisungen geeignet ist, gespeichert werden. Der Ausdruck „computerlesbares Speichermedium“ sollte so verstanden werden, dass er ein einzelnes Medium oder mehrere Medien (z. B. eine zentralisierte oder verteilte Datenbank und/oder zugehörige Caches und Server) umfasst, die einen oder mehrere Sätze Anweisungen speichern. Der Ausdruck „computerlesbares Medium“ sollte auch so verstanden werden, dass er ein beliebiges Medium umfasst, das einen Satz Anweisungen zur Ausführung durch die Maschine speichern, codieren oder führen kann und das bewirkt, dass die Maschine eine oder mehrere der Methodologien der vorliegenden Ausführungsformen durchführt. Der Ausdruck „computerlesbares Speichermedium“ sollte demgemäß so verstanden werden, dass er, allerdings ohne Beschränkung auf Festkörperspeicher, optische Medien, magnetische Medien, ein beliebiges Medium umfasst, das einen Satz Anweisungen zur Ausführung durch die Maschine speichern kann und das bewirkt, dass die Maschine eine oder mehrere der Methodologien der vorliegenden Ausführungsformen durchführt.
Die hierin präsentierten oder referenzierten Algorithmen und Anzeigen beziehen sich nicht inhärent auf einen bestimmten Computer oder eine bestimmte andere Vorrichtung. Verschiedene Allzwecksysteme können mit Programmen in Übereinstimmung mit den Lehren hierin verwendet werden, oder es kann sich als praktisch erweisen, eine spezialisierte Vorrichtung zu bauen, um die erforderlichen Verfahrensschritte durchzuführen. Die erforderliche Struktur für eine Reihe dieser Systeme wird aus der nachstehenden Beschreibung ersichtlich sein. Darüber hinaus werden die vorliegenden Ausführungsformen nicht mit Bezug auf eine bestimmte Programmiersprache beschrieben. Es ist zu bemerken, dass eine Reihe von Programmiersprachen verwendet werden kann, um die Lehren der Ausführungsformen, wie hierin beschrieben, zu implementieren.
Die obige Beschreibung legt zahlreiche spezifische Details dar, wie etwa Beispiele für spezifische Systeme, Komponenten, Verfahren und so weiter, um ein gutes Verständnis von mehreren Ausführungsformen der vorliegenden Erfindung bereitzustellen. Es wird einem Fachmann auf dem Gebiet jedoch klar sein, dass mindestens einige Ausführungsformen der vorliegenden Erfindung ohne diese spezifischen Details ausgeübt werden können. In anderen Fällen werden gut bekannte Komponenten oder Verfahren nicht im Detail beschrieben oder werden in einem einfachen Blockdiagrammformat präsentiert, um das Verständnis der vorliegenden Erfindung nicht unnötig zu erschweren. Die oben dargelegten spezifischen Details sind daher lediglich beispielhaft. Besondere Ausführungsformen können von diesen beispielhaften Details abweichen und trotzdem im Umfang der vorliegenden Erfindung vorgesehen sein.
Es versteht sich, dass die obige Beschreibung illustrativ und nicht beschränkend ist. Viele andere Ausführungsformen werden Fachleuten auf dem Gebiet nach der Lektüre und nach dem Verstehen der obigen Beschreibung klar sein. Der Umfang der Erfindung sollte daher mit Bezug auf die anhängenden Ansprüche zusammen mit dem vollen Umfang von Entsprechungen, für die solche Ansprüche berechtigt sind, bestimmt werden.
ZITATE ENTHALTEN IN DER BESCHREIBUNG
Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
Zitierte Patentliteratur

US 15653203 [0001]
US 62364652 [0001]
US 62364246 [0001]

Claims

Ein System, das Folgendes beinhaltet: eine erste zentrale Verarbeitungseinheit (CPU), die konfigurierbar ist, um in einer Vielzahl von Schutzkontexten zu arbeiten; und mindestens ein Peripheriemodul, wobei das Peripheriemodul durch die erste CPU zugreifbar ist, wenn die erste CPU in einem ersten Schutzkontext der Vielzahl von Schutzkontexten konfiguriert ist, und durch die erste CPU nicht zugreifbar ist, wenn die erste CPU in einem zweiten Schutzkontext der Vielzahl von Schutzkontexten konfiguriert ist.
System gemäß Anspruch 1, das ferner ein CPU-Teilsystem beinhaltet, wobei das CPU-Teilsystem Folgendes beinhaltet: die erste CPU; mindestens eine Speicherschutzeinheit; mindestens eine geteilte Speicherschutzeinheit.
System gemäß Anspruch 2, wobei die mindestens Speicherschutzeinheit zwischen Benutzerzugriffen und privilegierten Zugriffen von einem einzelnen Bus-Master differenziert.
System gemäß Anspruch 2, wobei die mindestens eine geteilte Speicherschutzeinheit zwischen dem ersten und zweiten Schutzkontext der Vielzahl von Schutzkontexten differenziert und zwischen sicheren und nicht sicheren Zugriffen der ersten CPU differenziert.
System gemäß Anspruch 1, das ferner ein Peripherie-Teilsystem beinhaltet, das Folgendes beinhaltet: das mindestens eine Peripheriemodul; und mindestens eine Peripherie-Schutzeinheit, wobei die mindestens eine Peripherie-Schutzeinheit zwischen Folgendem differenziert: dem ersten und zweiten Schutzkontext der Vielzahl von Schutzkontexten, sicheren und nicht sicheren Zugriffen und Benutzermoduszugriffen von privilegierten Moduszugriffen.
System gemäß Anspruch 1, wobei der Zugriff auf das Peripheriemodul durch Werte von Vektorpaaren gesteuert wird, den ersten Vektor des Vektorpaars zum Steuern von Lesezugriff auf das Peripheriemodul und den zweiten Vektor des Vektorpaars zum Steuern von Schreibzugriff auf den ersten Vektor des Vektorpaars.
System gemäß Anspruch 1, wobei die erste CPU-Operation in dem zweiten Schutzkontext von dem ersten Schutzkontext durch einen mit dem zweiten Schutzkontext assoziierten Unterbrechungsfaktor gegatet ist.
System gemäß Anspruch 1, wobei das Peripheriemodul ein Speicher ist.
System gemäß Anspruch 1, das ferner eine zweite CPU beinhaltet, die konfigurierbar ist, um in mindestens einem der Vielzahl von Schutzkontexten zu arbeiten.
Eine Businfrastruktur, die eine Vielzahl von Schutzstrukturen beinhaltet, wobei die Vielzahl von Schutzstrukturen Folgendes beinhaltet: eine Speicherschutzeinheit (MPU), die einem einzelnen Bus-Master zugeteilt ist, wobei die MPU Benutzerzugriff und privilegierten Zugriff von dem Bus-Master differenziert; eine geteilte Speicherschutzeinheit (SMPU), die einer Vielzahl von Bus-Bus-Masters zugeteilt ist, wobei die SMPU zwischen unterschiedlichen Schutzkontexten differenziert und zwischen sicherem und nicht sicherem Zugriff auf einen Speicher differenziert; und eine Peripherie-Schutzeinheit (PPU), die einer Peripheriegruppe zugeteilt ist, wobei die PPU sichere und nicht sichere Zugriffe auf die Peripheriegruppe differenziert.
Businfrastruktur gemäß Anspruch 10, wobei die PPU zwischen sicheren und nicht sicheren Zugriffen auf die Peripheriegruppe durch Bestätigen eines Benutzermodus und eines privilegierten Modus differenziert, wobei sich der Zugriff, der in einem Benutzermodus gestattet ist, von einem Zugriff, der in einem privilegierten Modus gestattet ist, unterscheidet.
Businfrastruktur gemäß Anspruch 10, wobei jede der Vielzahl von Schutzstrukturen durch Folgendes definiert ist: eine Adressregion; und Zugriffssteuerungsattribute, wobei die Zugriffssteuerungsattribute Zugriffssteuerung zum Speicherort spezifizieren.
Businfrastruktur gemäß Anspruch 10, wobei die PPU eine Vielzahl von Schutzregionen beinhaltet, die mindestens eines von Folgendem umfassen: alle Peripherien in der Peripheriegruppe; und einen Teilsatz von Peripherien der Peripheriegruppe, einschließlich individueller Interprozessor-Kommunikations(IPC)-Strukturen, DMA-Controller-Kanal-Strukturen, SMPU-Schutz erforderlicher Strukturen oder PPU-Schutzregion-Strukturen.
Businfrastruktur gemäß Anspruch 10, wobei der Bus-Master eine zentrale Verarbeitungseinheit (CPU) ist, die in einem ersten Schutzkontext und einem zweiten Schutzkontext arbeitet.
Businfrastruktur gemäß Anspruch 10, wobei der Bus-Master auf die erste Peripheriegruppe zugreift, wenn die CPU in dem ersten Schutzkontext arbeitet, und es ihm verboten ist, auf die Peripheriegruppe zuzugreifen, wenn die CPU in dem zweiten Schutzkontext arbeitet.
Businfrastruktur gemäß Anspruch 10, wobei der Zugriff auf die Peripheriegruppe durch Werte von Vektorpaaren der PPU gesteuert wird, den ersten Vektor des Vektorpaars zum Steuern von Lesezugriff auf die Peripheriegruppe und den zweiten Vektor des Vektorpaars zum Steuern von Schreibzugriff auf den ersten Vektor des Vektorpaars.
Ein Verfahren zum Steuern des Zugriffs auf Peripheriemodule, wobei das Verfahren Folgendes beinhaltet: Vergleichen eines ersten Schutzkontextes einer Vielzahl von Schutzkontexten einer zentralen Verarbeitungseinheit (CPU) mit einem erlaubten Schutzkontext eines ersten Peripheriemoduls; Gestatten des Zugriffs auf das erste Peripheriemodul durch die CPU, falls der erste Schutzkontext der CPU mit dem erlaubten Schutzkontext des ersten Peripheriemoduls zusammenpasst; Verändern des Schutzkontextes der CPU von dem ersten Schutzkontext auf einen zweiten Schutzkontext; Verbieten des Zugriffs auf das erste Peripheriemodul durch die CPU, falls der zweite Schutzkontext mit dem erlaubten Schutzkontext des ersten Peripheriemoduls nicht zusammenpasst; und Gestatten des Zugriffs auf ein zweites Peripheriemodul durch die CPU, falls der zweite Schutzkontext der CPU mit dem erlaubten Schutzkontext des zweiten Peripheriemoduls zusammenpasst, wobei sich der erste Schutzkontext von dem zweiten Schutzkontext unterscheidet.
Verfahren für kontextbasierten Schutz von Peripheriemodulen gemäß Anspruch 17, wobei der Zugriff auf die Peripheriemodule durch ein Vektorpaar für jedes Peripheriemodul definiert ist und wobei das Vektorpaar einen ersten Vektor des Vektorpaars zum Steuern von Lesezugriff auf das Peripheriemodul und einen zweiten Vektor des Vektorpaars zum Steuern des Schreibzugriffs auf den ersten Vektor des Vektorpaars beinhaltet.