DE102014002181B4

DE102014002181B4 - Chip und Verfahren zum Betreiben eines Chips

Info

Publication number: DE102014002181B4
Application number: DE102014002181.5A
Authority: DE
Inventors: Prakash Balasubramanian
Original assignee: Infineon Technologies AG
Current assignee: Infineon Technologies AG
Priority date: 2013-03-01
Filing date: 2014-02-18
Publication date: 2020-10-01
Anticipated expiration: 2034-02-19
Also published as: CN104021037A; US9536075B2; CN104021037B; DE102014002181A1; US20140250540A1

Abstract

Chip, der Folgendes umfasst:eine Snooping-Komponente, die so ausgelegt ist, dass sie einen Prozessor überwacht und bestimmt, ob eine auf dem Prozessor ausgeführte Anwendung sicheren Zugriff auf eine Ressource anfordert; undeine Ausgabekomponente, die so ausgelegt ist, dass sie ein Signal für einen sicheren Modus ausgibt, das sicheren Zugriff auf sichere Funktionsblöcke von Modulen mit gemeinsam genutzten Ressourcen gewährt, wenn es sich bei der Anwendung um eine sichere Anwendung handelt; undeine Interrupt-Behandlungskomponente, die so ausgelegt ist, dass sie ein Interrupt-Vektorregister mit einer sicheren ISR-Behandlungsroutine (Interrupt-Service-Routine) umprogrammiert, wenn das Signal für den sicheren Modus zugesichert bzw. aktiviert ist.

Description

Verschiedene Ausführungsformen betreffen einen Chip und ein Verfahren zum Betreiben desselben.
In vielen Betriebs- oder IT-Umgebungen geben das Stehlen von geistigem Eigentum und andere Formen von potenziell schädlichen Aktivitäten Anlass zu großer Sorge. Oft bieten zum Beispiel Mikrocontroller aufgrund der Konfiguration der Hardware keine vertrauenswürdigen Ausführungsumgebungen zum Ausführen firmeneigener oder vertraulicher Routinen an. Zum Beispiel kann die Architektur der Hardware eher auf Überlegungen für eine ökonomische Auslegung basieren, insbesondere, wenn die Hardware in einer industriellen Anwendung bereitgestellt werden soll. Dies kann problematisch sein, wenn man die potenziell ungeschützten Umgebungen betrachtet, in denen solche Mikrocontroller möglicherweise betrieben werden. In diesen Situationen können wertvolles geistiges Eigentum wie Firmware, Software, Daten und dergleichen Angriffen ungeschützt ausgeliefert sein.
Vorgeschlagene Lösungen umfassen oft das Duplizieren von Ressourcen, was zusätzliche Hardware-Komponenten oder Systeme umfassen kann. Zum Beispiel kann ein SoC (System-on-Chip, System auf einem Chip) neben ähnlichen Allzweckkomponenten auf dem Chip zusätzliche „sichere“ Komponenten (zum Beispiel zum Zweck der digitalen Rechteverwaltung) aufweisen. Sichere Komponenten zum Beispiel können nur von vertrauenswürdigen Anwendungen in einer sicheren Umgebung verwendet werden. Solche sicheren Komponenten können Taktgeber, Interrupt-Controller, DMA-Module, Speicher und dergleichen umfassen. Im Allgemeinen bringt das Duplizieren von Ressourcen eine Vergrößerung des Chips und höheren Stromverbrauch mit sich.
In weiteren vorgeschlagenen Lösungen kann eine durch die Konstruktion vorgegebene zeitliche Aufteilung verwendet werden, um Module von einem unsicheren Modus in einen sicheren Modus und zurück umzuschalten, um bei Bedarf sichere Anwendungen auszuführen. Sobald jedoch ein Modul vorübergehend einer unsicheren Anwendung oder einer sicheren Anwendung zugewiesen worden ist, ist das gesamte Modul während eines Zeitraums allgemein für die übrige „Welt“ (zum Beispiel sichere Anwendungen/Routinen bzw. unsichere Anwendungen/Routinen) nicht verfügbar, bis es durch die zugewiesene Anwendung freigegeben wird. Dies gilt im Allgemeinen, selbst wenn das Modul mehrere Funktionsblöcke aufweist, die gleichzeitig und unabhängig voneinander verwendet werden können. In einer solchen Situation können sich viele der Funktionsblöcke des Moduls im Leerlauf befinden (die Mehrzahl zum Beispiel), während der Rest der Blöcke des Moduls (einige wenige zum Beispiel) von der zugewiesenen Anwendung verwendet wird. Diese Technik kann den Anwendungsbereich und/oder die Anwendungsfälle für die Konstruktion einschränken und ineffizient sein.
Beispiele vorgeschlagener Lösung sind in DE 60308215 T2 , US 2003/0188173 A1 und US 2007/0226795 A1 gezeigt.
Es ist eine Aufgabe einen Chip und ein Verfahren zum Betreiben desselben bereitzustellen, der eines oder mehrere der zuvor genannten Probleme löst oder reduziert.
Gemäß einem Aspekt der Erfindung wird ein Chip vorgesehen, der Folgendes aufweist: eine Snooping-Komponente, die so ausgelegt ist, dass sie einen Prozessor überwacht und bestimmt, ob eine auf dem Prozessor ausgeführte Anwendung sicheren Zugriff auf eine Ressource anfordert; und
eine Ausgabekomponente, die so ausgelegt ist, dass sie ein Signal für einen sicheren Modus ausgibt, das sicheren Zugriff auf sichere Funktionsblöcke von Modulen mit gemeinsam genutzten Ressourcen gewährt, wenn es sich bei der Anwendung um eine sichere Anwendung handelt; und eine Interrupt-Behandlungskomponente, die so ausgelegt ist, dass sie ein Interrupt-Vektorregister mit einer sicheren ISR-Behandlungsroutine (Interrupt-Service-Routine) umprogrammiert, wenn das Signal für den sicheren Modus zugesichert ist.
Zweckmäßigerweise sind die gemeinsam verwendeten Ressourcen-Module in sichere Funktionsblöcke und unsichere Funktionsblöcke unterteilt, wobei sichere Anwendungen auf die sicheren Funktionsblöcke zugreifen, während gleichzeitig unsichere Anwendungen auf die unsicheren Funktionsblöcke zugreifen.
Zweckmäßigerweise sind die sicheren Funktionsblöcke hinsichtlich der Kommunikation von den unsicheren Funktionsblöcken isoliert.
Zweckmäßigerweise sichert der Chip das Signal für den sicheren Modus zu, wenn eine berechtigte Anwendung eine sichere Transaktion beginnt oder den Zugriff auf eine sichere Ressource einleitet, und der Chip nimmt die Zusicherung des Signals für den sicheren Modus zurück, wenn eine Anwendung eine sichere Transaktion beendet oder den Zugriff auf eine sichere Ressource beendet.
Zweckmäßigerweise ist der Chip so ausgelegt, dass er Anforderungen nach sicheren Interrupts zusammenfasst und die zusammengefassten Anforderungen nach sicheren Interrupts an den Prozessor und/oder einen externen Interrupt-Controller weiterleitet.
Zweckmäßigerweise ist der Chip so ausgelegt, dass er eine Debugging-Infrastruktur deaktiviert, wenn das Signal für den sicheren Modus zugesichert ist, und die Debugging-Infrastruktur aktiviert, wenn die Zusicherung des Signals für den sicheren Modus zurückgenommen wird.
Gemäß einer Erscheinungsform weist der Chip Folgendes auf:

einen Prozessor, der so ausgelegt ist, dass er gleichzeitig eine unsichere Anwendung und eine sichere Anwendung ausführt;
eine Sicherheits-Überwachungseinheit, die so ausgelegt ist, dass er den Prozessor überwacht und
ein Signal für einen sicheren Modus ausgibt, wenn die sichere Anwendung Zugriff auf ein Ressourcen-Modul anfordert;
ein oder mehrere Ressourcen-Module, wobei jedes Ressourcen-Modul eine Vielzahl von Funktionsblöcken aufweist, wobei einer oder mehrere der Vielzahl von Funktionsblöcken der unsicheren Anwendung zugeordnet ist bzw. sind und gleichzeitig einer oder mehrere der Vielzahl von Funktionsblöcken der sicheren Anwendung zugeordnet ist bzw. sind; und
einen oder mehrere Sicherheits-Sockets, die so ausgelegt sind, dass er Zugriffsberechtigungen jedes der zugeordneten Funktionsblöcke des einen oder der mehreren Ressourcen-Module bestimmt, wobei die Zugriffsberechtigungen darauf basieren, ob ein Funktionsblock der unsicheren Anwendung zugeordnet ist oder der sicheren Anwendung zugeordnet ist.

Zweckmäßigerweise weist der Chip ferner ein Zuordnungsmodul auf, das so ausgelegt ist, dass es dynamisch einen oder mehrere von der Vielzahl von Funktionsblöcken des einen oder der mehreren Ressourcen-Module einer anfordernden unsicheren Anwendung zuordnet und/oder dass es dynamisch einen oder mehrere von der Vielzahl von Funktionsblöcken des einen oder der mehreren Ressourcen-Module einer anfordernden sicheren Anwendung zuordnet.
Zweckmäßigerweise weist der Chip ferner eine oder mehrere Speichervorrichtungen auf, einschließlich eines sicheren Speicherteils und eines unsicheren Speicherteils.
Zweckmäßigerweise wird der sicheren Anwendung der Zugriff auf den sicheren Speicher gewährt, wenn die Sicherheits-Überwachungseinheit das Signal für den sicheren Modus zusichert, und wobei der Zugriff auf den sicheren Speicher verweigert wird, wenn die Sicherheits-Überwachungseinheit die Zusicherung des Signals für den sicheren Modus zurücknimmt.
Zweckmäßigerweise weist der Chip ferner Interconnect-Register auf, die so ausgelegt sind, dass er weitere Zugriffsberechtigungen des einen oder der mehreren Ressourcen-Module bestimmen.
Zweckmäßigerweise weisen das eine oder die mehreren Ressourcen-Module eines der Elemente Echtzeit-Taktgeber, Interrupt-Controller, Tastatur-Controller und DMA-Modul (Direct Memory Access, direkter Speicherzugriff) auf.
Zweckmäßigerweise ist es sicheren ausführbaren Anweisungen erlaubt, den Sicherheits-Socket mit Konfigurationsinformationen zu programmieren, und unsicheren ausführbaren Anweisungen ist es nicht erlaubt, den Sicherheits-Socket zu programmieren.
Zweckmäßigerweise ist der Chip ein Mikrocontroller oder weist einen solchen auf.
Gemäß einer Erscheinungsform umfasst ein Verfahren zum Betreiben eines vorgenannten Chips Folgendes:

Empfangen einer ersten Anforderung nach einer Ressource eines Moduls von einer ersten Anwendung, wobei es sich bei der ersten Anwendung um eine von einer sicheren Anwendung oder einer unsicheren Anwendung handelt;
Zuordnen eines ersten Funktionsblocks des Moduls zu der ersten Anwendung, wobei das Modul eine Vielzahl von Funktionsblöcken aufweist;
Empfangen einer zweiten Anforderung nach einer Ressource des Moduls von einer zweiten Anwendung, wobei es sich bei der zweiten Anwendung um die andere von der sicheren Anwendung oder der unsicheren Anwendung handelt; und
Zuordnen eines zweiten Funktionsblocks des Moduls zu der zweiten Anwendung, wobei das Zugreifen der zweiten Anwendung auf das Modul gleichzeitig mit dem Zugreifen der ersten Anwendung auf das Modul erfolgt und der erste Funktionsblock hinsichtlich der Kommunikation von dem zweiten Funktionsblock isoliert ist.

Zweckmäßigerweise umfasst das Verfahren ferner das Aufteilen des Moduls in die Vielzahl von Funktionsblöcken, sodass die Funktionsblöcke des Moduls ähnlich oder identisch sind.
Zweckmäßigerweise umfasst das Verfahren ferner das Verbinden eines Wrapper mit dem Modul, wobei der Wrapper so ausgelegt ist, dass er Zugriffsberechtigungen von zugeordneten Funktionsblöcken des Moduls bestimmt, wobei die Zugriffsberechtigungen darauf basieren, ob ein Funktionsblock einer sicheren Anwendung oder einer unsicheren Anwendung zugeordnet ist.
Zweckmäßigerweise umfasst das Verfahren ferner das Erlauben oder Verweigern eines Buszugriffs auf einen Funktionsblock, basierend auf von dem Wrapper des Moduls bestimmten Zugri ffsberechtigungen.
Zweckmäßigerweise ist der Wrapper mittels sicherer ausführbarer Anweisungen programmierbar und mittels unsicherer ausführbarer Anweisungen nicht programmierbar.
Zweckmäßigerweise umfasst das Verfahren ferner das Zuweisen eines Funktionsblocks des Moduls zu einem der folgenden Elemente: eine sichere Welt, eine unsichere Welt oder weder die sichere Welt noch die unsichere Welt, basierend auf den von dem Wrapper des Moduls bestimmten Zugriffsberechtigungen.
Zweckmäßigerweise umfasst das Verfahren ferner das Erlauben des Zugriffs einer Anwendung auf einen der sicheren Welt zugewiesenen Funktionsblock, während ein sicherer Modus aktiv ist, und das Verweigern des Zugriffs der Anwendung auf einen der sicheren Welt zugewiesenen Funktionsblock, während der sichere Modus inaktiv ist.
Zweckmäßigerweise umfasst das Verfahren ferner das Erlauben oder Blockieren einer Transaktion mit dem Modul über Interconnect-Fabric, basierend auf vorbestimmten Berechtigungen des Moduls.
Zweckmäßigerweise umfasst das Verfahren ferner das Zuordnen eines nächsten verfügbaren Funktionsblocks des Moduls zu einer nächsten anfordernden Anwendung ohne Rücksicht darauf, ob es sich bei der nächsten anfordernden Anwendung um eine sichere Anwendung oder um eine unsichere Anwendung handelt.
Zweckmäßigerweise ist der nächste Funktionsblock hinsichtlich der Kommunikation von wenigstens einem von dem ersten Funktionsblock und dem zweiten Funktionsblock isoliert.
Gemäß einer Erscheinungsform ist eine Controller-Vorrichtung vorgesehen, die einen Prozessor und eine oder mehrere Speichervorrichtungen mit darin gespeicherten, durch den Prozessor ausführbaren Anweisungen aufweist, die, wenn er durch den Prozessor ausgeführt werden, den Prozessor anweisen, Operationen durchzuführen, einschließlich:

Figurenliste
Die ausführliche Beschreibung erfolgt unter Bezugnahme auf die beigefügten Figuren. In den Figuren identifiziert bzw. identifizieren die ganz links befindliche(n) Ziffer(n) eines Bezugszeichens die Figur, in der das Bezugszeichen zum ersten Mal vorkommt. Die Verwendung derselben Bezugszeichen in unterschiedlichen Figuren gibt ähnliche oder identische Elemente an.
Bei dieser Erörterung sind die in den Figuren veranschaulichten Vorrichtungen und Systeme so gezeigt, dass sie eine Vielzahl von Komponenten aufweisen. Verschiedene Implementierungen von Vorrichtungen und/oder Systemen, wie diese in dem vorliegenden Dokument beschrieben sind, können weniger Komponenten enthalten und innerhalb des Schutzumfangs der Offenbarung bleiben. Alternativ können weitere Implementierungen von Vorrichtungen und/oder Systemen zusätzliche Komponenten oder verschiedene Kombinationen der beschriebenen Komponenten enthalten und innerhalb des Schutzumfangs der Offenbarung bleiben.

1 ist ein Blockdiagramm eines Teils einer beispielhaften Topologie eines Mikrocontrollers, wobei die in dem vorliegenden Dokument offenbarten Techniken und Vorrichtungen gemäß einer Implementierung angewendet werden können.
2 ist ein Blockdiagramm eines beispielhaften Moduls gemäß einer Implementierung, das aus einer Menge von Funktionsblöcken besteht. Das Modul ist mit seinem verbundenen Sicherheits-Socket-Wrapper und verschiedenen Interconnect-Pfaden gezeigt.
3 ist ein Blockdiagramm eines beispielhaften Interrupt-Liefermechanismus gemäß einer Implementierung, der auf der Ebene eines Funktionsblocks dargestellt ist.
4A ist ein Blockdiagramm eines beispielhaften Interrupt-Behandlungsschemas, das eine dedizierte Interrupt-Behandlung umfasst.
4B ist ein Blockdiagramm eines beispielhaften Interrupt-Behandlungsschemas, das gemäß einer Implementierung einen gemeinsamen Interrupt für Zwecke einer sicheren und allgemeinen Verwendung verwendet.
5A ist ein Blockdiagramm einer beispielhaften Sicherheits-Überwachungseinheit gemäß einer Implementierung.
5B ist ein Zustandsdiagramm, welches das beispielhafte Umschalten zwischen der unsicheren Welt und der sicheren Welt gemäß einer Implementierung zeigt.
6 ist ein Verlaufsdiagramm, das beispielhafte Phasen des Umschaltens zwischen der unsicheren Welt und der sicheren Welt gemäß einer Implementierung zeigt.
7 ist ein Verlaufsdiagramm, das eine Technik für gesteuerte Übergänge zwischen der unsicheren Welt und der sicheren Welt gemäß einer Implementierung zeigt, wobei die beteiligten Interrupts im Detail gezeigt sind.
8 ist ein Verlaufsdiagramm, das beispielhafte Phasen des Zuweisens von Funktionsblöcken zu unsicheren Anwendungen gemäß einer Implementierung zeigt.
9 ist ein Verlaufsdiagramm, das beispielhafte Phasen des Zuweisens von Funktionsblöcken zu sicheren Anwendungen gemäß einer Implementierung zeigt.
10 ist ein Ablaufdiagramm, das einen beispielhaften Prozess zum Bereitstellen einer dynamischen gemeinsamen Nutzung von Ressourcen zwischen unsicheren und sicheren Anwendungen gemäß einer Implementierung zeigt.

AUSFÜHRLICHE BESCHREIBUNG
Übersicht
Repräsentative Implementierungen von Vorrichtungen und Techniken sehen eine dynamische sichere gemeinsame Nutzung von Ressourcen durch unsichere und sichere Anwendungen vor, ohne den Bedarf an duplizierter Hardware und die damit einhergehende Vergrößerung des Chips und ohne einen höheren Stromverbrauch. Bei einem Beispiel kann ein Ressourcen-Modul in eine Vielzahl von Funktionsblöcken aufgeteilt werden, die unsicheren und sicheren Anwendungen zugeordnet werden können. Bei einer Implementierung können einige Funktionsblöcke aus einem Ressourcen-Modul unsicheren Anwendungen zugeordnet werden, und weitere Funktionsblöcke aus dem Ressourcen-Modul können gleichzeitig sicheren Anwendungen zugeordnet werden, ohne dass es zu Datenlecks oder Beeinträchtigungen der Sicherheit der sicheren Anwendung(en) kommt.
Bei einer Implementierung kann eine Sicherheits-Überwachungseinheit auf der Grundlage von Anforderungen nach sicheren Ressourcen durch auf dem Prozessor ausgeführte Anwendungen die Aktivität des Prozessors überwachen und bestimmen, wann auf sichere Ressourcen zugegriffen werden kann. Zum Beispiel kann die Sicherheits-Überwachungseinheit ein Signal für einen sicheren Modus ausgeben, wenn eine sichere Anwendung Zugriff auf ein Ressourcen-Modul anfordert. Die Sicherheits-Überwachungseinheit kann dann die Zusicherung des Signals für den sicheren Modus zurücknehmen, wenn der Zugriff auf sichere Ressourcen beendet ist.
Bei verschiedenen Implementierungen sind die Ressourcen-Module mit einem Sicherheits-Socket verbunden, der so ausgelegt ist, dass er Zugriffsberechtigungen jedes der zugeordneten Funktionsblöcke der Ressourcen-Module bestimmt. Zum Beispiel können die Zugriffsberechtigungen darauf basieren, ob ein Funktionsblock einer unsicheren Anwendung zugeordnet ist oder einer sicheren Anwendung zugeordnet ist.
In der vorliegenden Offenbarung werden verschiedene Implementierungen und Techniken für die sichere gemeinsame Nutzung von Ressourcen erörtert. Techniken und Vorrichtungen werden unter Bezugnahme auf in den Figuren veranschaulichte beispielhafte Mikrocontroller-Vorrichtungen und -Systeme erörtert. Dies soll jedoch nicht einschränkend sein, sondern erfolgt zur Erleichterung der Erörterung und zur komfortableren Veranschaulichung. Die erörterten Techniken und Vorrichtungen können auf viele von verschiedenen Konstruktionen von Prozessoren und Controller-Vorrichtungen, eingebettete Vorrichtungen und Systeme, Strukturen und dergleichen angewendet werden und bleiben immer noch innerhalb des Schutzumfangs der Offenbarung. Die Verwendung des Begriffs „Mikrocontroller“ oder „Controller“ in der vorliegenden Offenbarung soll jegliche und alle solchen Prozessor-Vorrichtungen, Systeme, Strukturen und so weiter einschließen.
Weiter unten sind die Implementierungen ausführlicher unter Verwendung einer Vielzahl von Beispielen erläutert. Obwohl verschiedene Implementierungen und Beispiele hier und weiter unten erörtert werden, können weitere Implementierungen und Beispiele möglich sein, indem die Merkmale und Elemente von einzelnen Implementierungen und Beispielen miteinander kombiniert werden.
Beispielhafte Controller-Topologie
1 ist ein Blockdiagramm eines Teils einer beispielhaften Topologie 100 eines Controllers (zum Beispiel Mikrocontrollers), wobei die in dem vorliegenden Dokument offenbarten Techniken und Vorrichtungen gemäß einer Implementierung angewendet werden können. Die beispielhafte Topologie 100 ist mit wenigstens zwei Interconnect-Bussen (L1 und L2) gezeigt, mit einer Menge „n“ von Ressourcen-Modulen (zum Beispiel Slave-Modulen) 102 („Module“) auf dem Interconnect-Bus L1 und einer weiteren Menge „m“ von Modulen 102 auf dem Interconnect-Bus L2. Bei verschiedenen Implementierungen kann eine Topologie 100 eine beliebige Menge von Bussen, Interconnect-Bussen und Modulen 102 sowie zusätzliche Komponenten aufweisen.
Zum Beispiel ist in der beispielhaften Topologie 100 von 1 jedes Modul 102 mit einem Sicherheits-Socket 104 verbunden, der so ausgelegt ist, dass er, wie weiter unten beschrieben, Zugriffsberechtigungen für das Modul 102 bestimmt. Außerdem umfasst die Veranschaulichung von 1 eine zentrale Verarbeitungseinheit (CPU) 106, eine Sicherheits-Überwachungseinheit 108, einen Speicher-Controller 110, sicheren Speicher 112, Allzweck-Speicher 114, eine Brückenkomponente 116 und eine Bus-Master-Komponente 118. Bei verschiedenen Implementierungen kann die Topologie 100 weniger, zusätzliche oder alternative Komponenten aufweisen und innerhalb des Schutzumfangs der Offenbarung bleiben.
Bei einer Implementierung stellen die Ressourcen-Module („Module“) 102 Ressourcen dar, die von auf der CPU 106 ausgeführten Anwendungen verwendet werden können, um Operationen oder Aufgaben durchzuführen. Zum Beispiel können die Module 102 Referenzkomponenten wie Echtzeit-Taktgeber; Aufgabenverwaltungskomponenten wie beispielsweise einen Interrupt-Controller; Eingabe/Ausgabe-Verwaltungskomponenten wie beispielsweise einen Tastatur-Controller; Speicherverwaltungskomponenten wie beispielsweise ein DMA-Modul (Direct Memory Access, direkter Speicherzugriff) und so weiter umfassen. Es versteht sich, dass diese Beispiele lediglich einige wenige Beispiele der vielen verschiedenen Typen von Modulen 102 sind. Im Allgemeinen kann es sich bei jeglichen beliebigen und allen Ressourcen, die von einer auf der CPU 106 ausgeführten Anwendung angefordert und/oder genutzt werden, um ein Modul 102 handeln.
Bei verschiedenen Implementierungen ist die CPU 106 so ausgelegt, dass sie gleichzeitig eine oder mehrere unsichere Anwendungen und eine oder mehrere sichere Anwendungen ausführen kann. Die CPU 106 kann mit einem einzelnen oder mehreren Prozessoren ausgestattete Computer-, Prozessor- oder Controller-Systeme, Mini-Computer-Geräte, Mainframe-Geräte sowie PCs, Handheld-Geräte oder mobile Computergeräte (zum Beispiel Tablet-Computer, Smartphones, usw.), auf Mikroprozessoren basierende oder programmierbare Elektronik für Endverbraucher oder Industrie-Elektronik und dergleichen umfassen. Die veranschaulichten Erscheinungsformen können auch in verteilten Computerumgebungen praktisch ausgeführt werden, wo Aufgaben von fernen Verarbeitungsvorrichtungen durchgeführt werden, die über ein Kommunikationsnetzwerk verbunden sind. Jedoch können einige, wenn nicht alle Erscheinungsformen der Offenbarung auf eigenständigen Computervorrichtungen praktisch ausgeführt werden. In einer verteilten Computerumgebung können Programmkomponenten sich sowohl in lokalen als auch in fernen Speichervorrichtungen (wie beispielsweise den Speichervorrichtungen 112, 114) befinden.
Bei einer Implementierung ist die Sicherheits-Überwachungseinheit 108 so ausgelegt, dass sie den Prozessor (das heißt die CPU 106) auf Eintritts- und Austrittssequenzen für den sicheren Modus durch auf dem Prozessor 106 ausgeführte Anwendungen überwacht. Zum Beispiel ist die Sicherheits-Überwachungseinheit 108 so ausgelegt, dass sie das Signal für den sicheren Modus zusichert, wenn eine berechtigte Anwendung eine sichere Transaktion beginnt oder den Zugriff auf eine sichere Ressource einleitet. Ferner nimmt die Sicherheits-Überwachungseinheit 108 die Zusicherung des Signals für den sicheren Modus zurück, wenn eine Anwendung eine sichere Transaktion beendet oder den Zugriff auf eine sichere Ressource beendet.
Bei einer Implementierung weist die Sicherheits-Überwachungseinheit 108, wie in 4 gezeigt, eine Snooping-Komponente 402 auf, die so ausgelegt ist, dass sie den Prozessor 106 überwacht und bestimmt, ob eine auf dem Prozessor 106 ausgeführte Anwendung sicheren Zugriff auf eine Ressource, wie beispielsweise ein Modul 102, einen Speicher 114 oder dergleichen, anfordert.
Bei verschiedenen Implementierungen gibt die Sicherheits-Überwachungseinheit 108 ein Signal für den sicheren Modus aus, wenn die Bedingungen für den Eintritt in den sicheren Modus erfüllt sind. Wenn zum Beispiel eine unsichere Anwendung für einen Funktionsblock 202 eines Ressourcen-Moduls 102 anfordert, dass er durch einen vordefinierten Vertrag (zum Beispiel über bootROM) oder dergleichen der unsicheren Anwendung zugewiesen wird, kann der bootROM-Code (oder ein ähnlicher Mechanismus) eine Sequenz ausführen, um die Sicherheits-Überwachungseinheit 108 davon zu überzeugen, dass der Anforderung vertraut werden kann. Bei einem solchen Beispiel gibt die Sicherheits-Überwachungseinheit 108 das Signal für den sicheren Modus aus, wodurch der sichere Modus zugesichert wird. Bei den Implementierungen kann die Sicherheits-Überwachungseinheit 108 eine Ausgabekomponente (nicht gezeigt) aufweisen, die zum Beispiel so ausgelegt ist, dass sie das Signal für den sicheren Modus ausgibt, das sicheren Zugriff auf sichere Funktionsblöcke von Modulen mit gemeinsam genutzten Ressourcen gewährt, wenn es sich bei der anfordernden Anwendung um eine sichere Anwendung handelt oder die anfordernde Anwendung die Berechtigung besitzt, auf sichere Ressourcen zuzugreifen.
Bei einer zusätzlichen Implementierung ist die Sicherheits-Überwachungseinheit 108 so ausgelegt, dass sie sichere Interrupt-Anforderungen handhaben oder verwalten kann. Auf diese Weise werden die Interrupts auf sichere Weise gehandhabt und von unsicheren Systemen oder Anwendungen isoliert. Zum Beispiel kann die Sicherheits-Überwachungseinheit 108 Anforderungen nach sicheren Interrupts zusammenfassen und die zusammengefassten Anforderungen nach sicheren Interrupts zur Verarbeitung der Interrupts an den Prozessor 106 und/oder einen Interrupt-Controller weiterleiten.
Bei einer beispielhaften Implementierung weist die Sicherheits-Überwachungseinheit 108 eine Interrupt-Behandlungskomponente (nicht gezeigt) auf, die so ausgelegt ist, dass sie ein Interrupt-Vektorregister mit einer sicheren ISR-Behandlungsroutine (Interrupt-Service-Routine) umprogrammiert, wenn das Signal für den sicheren Modus zugesichert ist. Zum Beispiel kann die Sicherheits-Überwachungseinheit 108 so ausgelegt sein, dass sie einen Eintrag für einen dedizierten Interrupt-Vektor in dem sicheren Modus mit der Adresse des ISR für den sicheren Modus (zum Beispiel in dem sicheren ROM definiert) programmiert und den Interrupt zur Verarbeitung der Interrupts an die CPU 106 und/oder einen Interrupt-Controller weiterleitet. Bei anderen Implementierungen können andere Techniken verwendet werden, um sichere Interrupts mit der Sicherheits-Überwachungseinheit 108 zu behandeln.
Daher wird jeder beliebige Interrupt, der von einem der sicheren Welt zugewiesenen Funktionsblock 202 zugesichert wird, auf sichere Weise behandelt, ohne dass er von einer böswilligen Anwendung oder dergleichen abgefangen wird.
Bei einer weiteren Implementierung ist die Sicherheits-Überwachungseinheit 108 so ausgelegt, dass sie eine Debugging-Infrastruktur des Controllers 100 deaktiviert, wenn das Signal für den sicheren Modus zugesichert ist, und die Debugging-Infrastruktur aktiviert, wenn die Zusicherung des Signals für den sicheren Modus zurückgenommen wird. Auf diese Weise werden sichere Operationen und Transaktionen auch von der Debugging-Infrastruktur isoliert gehalten, wodurch eine zusätzliche Sicherheitsstufe vorgesehen wird. Bei verschiedenen Implementierungen können alternative oder zusätzliche Schutzmechanismen verwendet werden, um ein unberechtigtes Debugging in dem sicheren Modus zu verhindern.
Wenn er eingeschlossen ist, dann kann der Speicher-Controller 110 so ausgelegt sein, dass er den Zugriff auf die Speichervorrichtungen, wie beispielsweise den sicheren Speicher 112 und den Allzweck-Speicher 114, durch Anwendungen und/oder Routinen steuert, die auf dem von der Sicherheits-Überwachungseinheit 108 ausgegebenen Signal für den sicheren Modus basieren. Zum Beispiel kann einer sicheren Anwendung der Zugriff auf den sicheren Speicher 112 gewährt werden, wenn die Sicherheits-Überwachungseinheit 108 das Signal für den sicheren Modus zusichert. Hingegen kann der Zugriff auf den sicheren Speicher 112 verweigert werden, wenn die Sicherheits-Überwachungseinheit 108 die Zusicherung des Signals für den sicheren Modus zurücknimmt.
Bei verschiedenen Implementierungen können die Speichervorrichtungen 112 und 114 unter Verwendung jeder beliebigen Form von computerlesbaren Medien implementiert sein, auf die der Prozessor (das heißt die CPU 106) zugreifen kann. Computerlesbare Medien können zum Beispiel Computerspeichermedien und Kommunikationsmedien sein.
Computerlesbare Speichermedien umfassen flüchtige und nichtflüchtige, wechselbare und nicht wechselbare Medien, die in jedem beliebigen Verfahren oder in jeder beliebigen Technologie zum Speichern von Informationen, wie beispielsweise computerlesbaren Anweisungen, Datenstrukturen, Programmmodulen oder anderen Daten implementiert sind. Der Speicher 112, 114 ist ein Beispiel für ein computerlesbares Speichermedium. Zusätzliche Typen von computerlesbaren Speichermedien, die vorhanden sein können, umfassen RAM, ROM, EEPROM, Flash-Speicher oder andere Speichertechnologien, CD-ROM, DVDs (Digital Versatile Disks) oder andere optische Speicher, Magnetkassetten, Magnetband, magnetischen Plattenspeicher oder andere magnetische Speichervorrichtungen oder jegliches beliebige andere Medium, das zum Speichern der gewünschten Informationen verwendet werden kann und auf das der Prozessor
Hingegen verkörpern Kommunikationsmedien typischerweise computerlesbare Anweisungen, Datenstrukturen, Programmmodule oder andere Daten in einem modulierten Datensignal, wie beispielsweise einer Trägerwelle oder einem anderen Transportmechanismus.
Wenn eingeschlossen, sieht die Brücke 116 einen Signalweg zwischen Bussen, Interconnect-Bussen (wie beispielsweise L1, L2) und dergleichen vor. Bei verschiedenen Implementierungen kann die Brücke 116 einen oder mehrere Ports aufweisen, um die Interconnect-Busse, usw. zu berücksichtigen.
Bei einer weiteren Implementierung kann die Topologie 100 einen Bus-Master 118 aufweisen. Bei der Implementierung ist der Bus-Master 118 so ausgelegt, dass er den Datenverkehr auf den Bussen, Interconnect-Bussen und so weiterleitet. Zum Beispiel kann der Bus-Master 118 Daten oder Pakete von den und zu den Eingabe/Ausgabekomponenten (wie beispielsweise einem oder mehreren Modulen 102) oder dergleichen leiten. Bei verschiedenen Implementierungen steuert der Bus-Master 118 (entweder dynamisch oder anfänglich) die Signalwege für Daten, Adressen und so weiter, im Allgemeinen im Hinblick auf Eingabe/Ausgabevorrichtungen und/oder -module 102. Bei einer weiteren Implementierung kann es sich bei dem Bus-Master 118 um einen zweiten oder nachfolgenden Bus-Master handelt, basierend auf einer weiteren (zum Beispiel prioritären, zusätzlichen, usw.) Busverkehrs-Steuerung, die sich an anderer Stelle befindet, beispielsweise die CPU 106 oder so weiter.
Bei alternativen Implementierungen kann eine Controller-Topologie 100 weniger Komponenten, zusätzliche Komponenten oder alternative Komponenten aufweisen, um die erörterten Funktionen oder eine weitere gewünschte Funktionalität auszuführen.
Beispielhaftes Ressourcen-Modul
2 ist ein Blockdiagramm eines Bereichs der Controller-Topologie 100, das Einzelheiten eines beispielhaften Moduls 102 und verbundener Komponenten zeigt. Bei einer Implementierung bestehen die Module 102 aus einer Menge von Funktionsblöcken 202. In der Veranschaulichung von 2 ist das Modul 102 mit dem verbundenen Sicherheits-Socket (auch als Wrapper bezeichnet) 104 und einer verbundenen Zuordnungseinheit 204 gezeigt. Es versteht sich, dass die Zuordnungseinheit 204 mit dem Modul 102 wie gezeigt verbunden ist oder mit einem weiteren Modul verbunden sein kann, oder es kann sich um ein separates Element handeln.
Wie in 2 gezeigt, sind bei einer Implementierung die gemeinsam genutzten Ressourcen-Module 102 in eine Menge von Funktionsblöcken 202 aufgeteilt, die so zugewiesen sein können, dass sie sichere Funktionsblöcke oder unsichere Funktionsblöcke sind. Bei einer Implementierung sind die Funktionsblöcke 202 entweder als sichere oder als unsichere Funktionsblöcke 202 zugeordnet, basierend auf der Reihenfolge, in der sie von einer Anwendung oder Routine angefordert werden, und gemäß der sicheren Natur oder Berechtigung der anfordernden Anwendung.
Dies wird zum Beispiel durch die Zuweisung eines Funktionsblocks 202 zu einer bestimmten „Welt“ dargestellt. Für eine Zeitdauer kann jeder Funktionsblock 202 einer Allzweckwelt 402 (das heißt „unsichere Welt“, „normale Welt“, usw.) oder einer „sicheren Welt“ 404 (wie in 4B gezeigt) zugewiesen sein. Die Zuweisung zu einer sicheren Welt 404 bedeutet, dass berechtigte Anwendungen, Routinen, usw. auf den Funktionsblock 202 zugreifen können, während die Sicherheits-Überwachungseinheit 108 das Signal für den sicheren Modus zusichert (das heißt ausgibt). Mit anderen Worten wird der Funktionsblock 202 zu einer dedizierten Ressource, auf die (für eine Zeitdauer) in einem privilegierten Betriebsmodus - dem sicheren Betriebsmodus - zugegriffen werden kann. Auf den Funktionsblock 202 können keinerlei Anwendungen, Routinen, usw. zugreifen, während die Sicherheits-Überwachungseinheit 108 die Zusicherung des Signals für den sicheren Modus zurücknimmt (das heißt das Signal beendet). Zum Beispiel wird bei Versuchen, auf den Funktionsblock 202 zuzugreifen, während der sichere Modus inaktiv ist, ein Busy-Signal (Ausgelastet) oder dergleichen zurückgegeben.
Die Zuweisung zu der Allzweckwelt (GP) 402 bedeutet, dass alle beliebigen Anwendungen, Routinen, usw. auf den Funktionsblock 202 zugreifen können, unabhängig davon, ob die Sicherheits-Überwachungseinheit 108 das Signal für den sicheren Modus zusichert oder nicht. Anwendungen, die auf einen der Allzweckwelt zugewiesenen Funktionsblock 202 zugreifen, können nicht erwarten, dass ihre Operationen sicher oder isoliert von anderen Operationen, Routinen, usw. sind.
Zusätzlich kann ein Funktionsblock 202 für eine Zeitdauer weder der Allzweckwelt 402 noch der sicheren Welt 404 zugewiesen sein. Dies bedeutet, dass der Funktionsblock 202 für die Zeitdauer frei und verfügbar ist, in der Zukunft einer anfordernden Anwendung (entweder einer unsicheren oder einer sicheren Anwendung) zugewiesen zu werden.
Zum Beispiel kann bei einer Implementierung die Controller-Topologie 100 eine Zuordnungseinheit 204 aufweisen, die so ausgelegt ist, dass sie dynamisch einen oder mehrere von der Vielzahl von Funktionsblöcken 202 des einen oder der mehreren Ressourcen-Module 102 einer anfordernden unsicheren Anwendung zuordnet und/oder dass sie dynamisch einen oder mehrere von der Vielzahl von Funktionsblöcken 202 des einen oder der mehreren Ressourcen-Module 102 einer anfordernden sicheren Anwendung zuordnet. Bei verschiedenen Implementierungen kann dies eine Abfolge von aufeinander folgenden Anforderungen von einer oder mehreren unsicheren Anwendungen und/oder eine Abfolge von aufeinander folgenden Anforderungen von einer oder mehreren sicheren Anwendungen umfassen. Nach diesen Anforderungen ist die Zuordnungseinheit 204 so ausgelegt, dass sie Funktionsblöcke 202 von dem angeforderten Modul 102 den anfordernden Anwendungen in der Reihenfolge der Anforderungen zuordnet.
Bei einer Implementierung werden die Anforderungen für ein Modul 102 jedoch von einer unsicheren Anwendung und von einer sicheren Anwendung unmittelbar aufeinanderfolgend empfangen. Zum Beispiel kann bei der Implementierung die Zuordnungseinheit 204 eine erste Anforderung nach einer Ressource eines Moduls 102 von einer ersten Anwendung empfangen, wobei es sich bei der ersten Anwendung um eine sichere Anwendung oder um eine unsichere Anwendung handelt. Die Zuordnungseinheit 204 ordnet einen ersten Funktionsblock 202 der Vielzahl von Funktionsblöcken 202 des Moduls 102 der ersten Anwendung zu. Anschließend empfängt die Zuordnungseinheit 204 eine zweite Anforderung nach einer Ressource desselben Moduls 102 von einer zweiten Anwendung, wobei es sich bei der zweiten Anwendung um das Gegenteil der ersten Anwendung handelt, zum Beispiel um eine unsichere Anwendung bzw. eine sichere Anwendung. Demgemäß ordnet die Zuordnungseinheit 204 einen zweiten Funktionsblock 202 desselben Moduls 102 der zweiten Anwendung zu. Bei der Implementierung greift die zweite Anwendung zu dem gleichen Zeitpunkt auf das Modul 102 zu, wie die erste Anwendung auf das Modul 102 zugreift, jedoch ist der erste Funktionsblock 202 kommunikativ von dem zweiten Funktionsblock 202 isoliert, sodass kein Datenleck oder keine Beeinträchtigung der Sicherheit der sicheren Anwendung oder des ihr zugeordneten Funktionsblocks bzw. der ihr zugeordneten Funktionsblöcke 202 auftritt.
Somit können bei verschiedenen Implementierungen sichere Anwendungen auf einen oder mehrere sichere Funktionsblöcke 202 eines Moduls 102 zugreifen, während gleichzeitig unsichere Anwendungen auf einen oder mehrere unsichere Funktionsblöcke 202 des Moduls 102 zugreifen. Dies kann ohne Duplizieren der Hardware erfolgen, da die sicheren Funktionsblöcke 202 hinsichtlich der Kommunikation von den unsicheren Funktionsblöcken 202 isoliert sind.
Ferner können zusätzliche Funktionsblöcke 202 (während sie verfügbar sind) desselben Moduls 102 der ersten oder der zweiten Anwendung oder zusätzlichen Anwendungen auf der Basis der zuerst empfangenen Anforderung zugeordnet werden, unabhängig davon, ob diese sicher oder unsicher sind. Bei alternativen Implementierungen kann die Zuordnung von Funktionsblöcken 202 eines Moduls 102 auf der Grundlage eines vordefinierten Prioritätssystems oder anderer etablierter Regeln erfolgen (zum Beispiel durch Berücksichtigen von Regeln des Betriebssystems, und so weiter).
Bei verschiedenen Implementierungen kann die Zuordnungseinheit 204 ein Modul, eine Komponente, eine Routine oder dergleichen oder Kombinationen aus diesen aufweisen. Teile der Zuordnungseinheit 204 können in Hardware, Firmware und/oder in Software implementiert sein. Zusätzlich kann bei einigen Implementierungen eine Zuordnungseinheit 204 lokal für ein spezifisches Modul 102 vorhanden sein (zum Beispiel kann die Zuordnungseinheit wenigstens teilweise innerhalb des Moduls 102 angeordnet oder gespeichert sein), und sie kann einstückig mit dem spezifischen Modul 102 verbunden sein, wobei sie Funktionsblöcke dieses Moduls 102 zuordnet. Bei einer alternativen Implementierung kann eine Zuordnungseinheit 204 allgemeiner verbunden sein (zum Beispiel mit einer Gruppe von Modulen 102 verbunden, mit einem Interconnect-Bus (L1, L2) verbunden, usw.), und sie kann so ausgelegt sein, dass sie Funktionsblöcke 202 mehrerer Module 102 zuordnet. Bei solchen alternativen Implementierungen können Teile der Zuordnungseinheit 204 fern von einem oder mehreren der mehreren Module 102 angeordnet oder gespeichert sein, die mit der Zuordnungseinheit 204 verbunden sind.
Die Veranschaulichung von 2 zeigt den Slave (das Slave-Modul) 102, aufgeteilt in „n“ Funktionsblöcke 202. Bei verschiedenen Implementierungen können die Funktionsblöcke 202 identisch oder nahezu identisch mit den Funktionen des Moduls 102 sein. Bei weiteren Implementierungen können die Funktionsblöcke 202 auf der Grundlage des Ressourcenbedarfs der anfordernden Anwendungen oder anderer Bedingungen aufgeteilt sein.
Bei einer Implementierung ist, wie in 2 gezeigt, ein Sicherheits-Socket 104 (auch als Wrapper bezeichnet) mit einem spezifischen Modul 102 verbunden. Bei einer alternativen Implementierung ist der Sicherheits-Socket 104 mit mehr als einem Modul 102 verbunden. Bei verschiedenen Implementierungen ist der Sicherheits-Socket 104 mit Konfigurationsinformationen der von ihm bedienten Funktionsblöcke 202 programmiert (zum Beispiel Startadresse, Größe, sichere Zugriffsberechtigungen, usw.). Bei einer Implementierung ist der Sicherheits-Socket 104 so ausgelegt, dass er Zugriffsberechtigungen von jedem der zugeordneten Funktionsblöcke 202 des einen oder der mehreren mit ihm verbundenen Ressourcen-Module 102 bestimmt. Zum Beispiel basieren die Zugriffsberechtigungen darauf, ob ein Funktionsblock 202 einer unsicheren Anwendung zugeordnet ist oder einer sicheren Anwendung zugeordnet ist.
Dies ist in der Veranschaulichung von 2 durch die Liste der Funktionsblöcke 202 (FB ID 1 bis FB ID N) und die jeweils verbundene zugewiesene Welt für jeden der Funktionsblöcke 202 („zugewiesene Welt“) innerhalb des Diagramms für den Sicherheits-Socket 104 dargestellt. Wie bereits erwähnt, kann die zugewiesene Welt für jeden Funktionsblock 202 die Allzweckwelt (GP) 402, die sichere Welt 404 oder keine davon (zum Beispiel verfügbar für die Zuweisung zu einer Welt) umfassen.
Bei einer Implementierung dürfen sichere ausführbare Anweisungen den Sicherheits-Socket 104 mit Konfigurationsinformationen programmieren. Wie in dem vorliegenden Dokument verwendet, umfasst der Begriff „sichere ausführbare Anweisungen“ Anweisungen von sicherer (zum Beispiel autorisierter, vertrauenswürdiger, usw.) Software oder sicherem (zum Beispiel autorisiertem, vertrauenswürdigem, usw.) Code. Unsichere ausführbare Anweisungen, das heißt Anweisungen aus unsicherer (zum Beispiel nicht autorisierter, nicht vertrauenswürdiger, nicht geprüfter, usw.) Software oder aus unsicherem (zum Beispiel nicht autorisiertem, nicht vertrauenswürdigem, nicht geprüftem, usw.) Code dürfen den Sicherheits-Socket 104 jedoch nicht programmieren. Bei einer Implementierung umfassen die sicheren und die unsicheren ausführbaren Anweisungen Firmware, wie beispielsweise Firmware, die mit mit dem Controller 100 gekoppelten Hardware-Komponenten verbunden ist, in nichtflüchtigen Speichervorrichtungen des Controllers 100 gespeicherte Firmware und dergleichen.
Bei verschiedenen alternativen Implementierungen umfassen die sicheren und unsicheren ausführbaren Anweisungen jegliche von einem Computer oder einem Prozessor ausführbaren Anweisungen, gleichgültig, wo sie gespeichert sind oder was ihr Ursprung ist (zum Beispiel Speichervorrichtungen, eingebettete Systeme, Peripherievorrichtungen, Netzwerke, das Internet, Cloud-Speicher, tragbare/wechselbare Speichervorrichtungen oder -medien und dergleichen). Zum Beispiel dürfen nur sichere ausführbare Anweisungen, unabhängig von ihrem Ursprung, den Sicherheits-Socket 104 programmieren. Da der Sicherheits-Socket 104 Berechtigungen bestimmt, verhindert dies, dass eine unsichere Quelle mit den Funktionsblöcken 202 oder den Modulen 102 verbundene Berechtigungen verändert.
Bei einer Implementierung kann die Topologie 100 ferner Interconnect-Register aufweisen, die so ausgelegt sind, dass sie weitere Zugriffsberechtigungen des einen oder der mehreren Ressourcen-Module 102 bestimmen. Zum Beispiel kann ein Modul 102 auf der Grundlage der beabsichtigten Verwendung, der Installation, des Ressourcen-Typs, und so weiter des Moduls 102 bestimmte Berechtigungen aufweisen (zum Beispiel kann das Modul 102 für den Nur-Lese-Zugriff fest verdrahtet sein, usw.). In einem solchen Fall wird jede beliebige Anwendung, die versucht, eine im Widerspruch zu den Berechtigungen des Moduls stehende Operation durchzuführen (zum Beispiel eine Schreiboperation in ein Nur-Lese-Ressourcen-Modul 102), basierend auf den Interconnect-Informationen bezüglich des Moduls 102 bei der Durchführung der Operation scheitern.
Beispielhafte Implementierungen
Wie oben bereits erörtert, kann eine Sicherheits-Überwachungseinheit 108 die Behandlung von sicheren Interrupts und dergleichen steuern. 3 ist ein Blockdiagramm eines beispielhaften Interrupt-Liefermechanismus 300 gemäß einer Implementierung, der auf der Ebene eines Funktionsblocks gezeigt ist.
Bei der Implementierung ist, wie in 3 gezeigt, ein Modul 102, wie beispielsweise Modul N, in eine Menge von „n“ Funktionsblöcken 202 aufgeteilt. Jeder von den Funktionsblöcken 202 kann auf der Grundlage von Ereignissen, die bei dem Funktionsblock 202 stattfinden, Interrupts erzeugen. Bei einer Implementierung sind die Interrupts in allgemeine Interrupts und sichere Interrupts aufgeteilt. Zum Beispiel können von allgemeinen Routinen verwendete Funktionsblöcke 202 allgemeine Interrupts erzeugen, und von sicheren Routinen verwendete Funktionsblöcke 202 können sichere Interrupts erzeugen.
Bei der Implementierung werden, wie in 3 gezeigt, allgemeine Interrupts zu einer regulären Interrupt-Verteilung 302 geleitet, wie in jedem allgemeinen Controller-Schema, oder gemäß der allgemeinen Interrupt-Handhabung des bestimmten Prozessors (zum Beispiel der CPU 106). Zum Beispiel können die Interrupts zur Verarbeitung zu der CPU 106 geleitet werden.
Bei der Implementierung werden, wie in 3 gezeigt, die sicheren Interrupts zu einem Interrupt-Sammler für den sicheren Modus 304 oder dergleichen zusammengefasst. Die zusammengefassten Interrupts werden getrennt von den allgemeinen Interrupts behandelt, um die Sicherheit der sicheren Anwendungen, Routinen, Ressourcen und dergleichen beizubehalten. Zum Beispiel können die gesammelten sicheren Interrupts, wie in 3 gezeigt, zu der Sicherheits-Überwachungseinheit 106 weitergeleitet werden. Wie oben bereits erörtert, kann die Sicherheits-Überwachungseinheit 108 die zusammengefassten sicheren Interrupt-Anforderungen zur Verarbeitung der Interrupts an die CPU 106 und/oder einen Interrupt-Controller weiterleiten.
Wie gezeigt, kann bei einer Implementierung jeder Funktionsblock 202 eines Moduls 102 allgemeine Interrupt-Pfade und sichere Interrupt-Pfade aufweisen, um die Zuordnung als unsicherer Funktionsblock 202 oder als sicherer Funktionsblock 202 zu berücksichtigen. Demgemäß kann jeder Funktionsblock 202 abhängig von der bzw. den Anwendung(en), die auf der CPU 106 ausgeführt werden, in unterschiedlichen Szenarien auf unterschiedliche Weise zugeordnet werden (unsicher oder sicher).
4A ist ein Blockdiagramm eines beispielhaften Interrupt-Behandlungsschemas, welches das Behandeln von Interrupts der Allzweck-Welt (GP) 402 mit einem dedizierten Allzweck-Interrupt-Controller (GP intC) 406 und das Behandeln von Interrupts der sicheren Welt 404 mit einem dedizierten sicheren Interrupt-Controller (SEC intC) 408 umfasst. Bei diesem Schema und ähnlichen Schemata wird das Duplizieren von Ressourcen im Allgemeinen verwendet, um sicherzustellen, dass sichere Interrupts isoliert behandelt werden.
Hingegen zeigt 4B ein beispielhaftes Schema, wie oben unter Bezugnahme auf 3 umrissen. Zum Beispiel können Interrupts der sicheren Welt 404 über die Sicherheits-Überwachungseinheit 108 behandelt werden, einschließlich des Zusammenfassens der sicheren Interrupts und des Weiterleitens des zusammengefassten Interrupt-Signals an die CPU 106 oder dergleichen zur Verarbeitung. Dieses zusammengefasste Interrupt-Signal kann ferner zu Allzweck-Interrupts (beispielsweise aus Allzweck-Anwendungen) zusammengefasst werden, sowie es von der CPU 106 empfangen wird. Auf diese Weise ist der CPU 106 sowie dem Controller 100 und seinen Allzweck-Komponenten die Quelle des empfangenen Interrupt nicht bekannt. Demgemäß wird die sichere Natur der sicheren Interrupts und ihrer sicheren Anwendung(en) beibehalten.
5A ist ein Blockdiagramm einer beispielhaften Sicherheits-Überwachungseinheit 108 gemäß einer Implementierung. Wie in 5A gezeigt, kann eine beispielhafte Sicherheits-Überwachungseinheit 108 eine Snooping-Komponente 502 aufweisen, die so ausgelegt ist, dass sie die CPU 106 auf Eintritts- und Austrittssequenzen für den sicheren Modus (wie in 5B und 6 bis 9 gezeigt) durch auf der CPU 106 ausgeführte Anwendungen überwacht. Bei zusätzlichen oder alternativen Implementierungen kann die Sicherheits-Überwachungseinheit 108 so ausgelegt sein, dass sie über einen CPU-Bus eine Schnittstelle mit der CPU 106 bildet und/oder über einen Interconnect-Bus (wie beispielsweise LI, L2) mittels einer BIU (Bus Interface Unit, Bus-Interface-Einheit) 504 oder dergleichen eine Schnittstelle mit dem Controller 100 bildet.
Wie oben bereits erörtert, kann bei weiteren Implementierungen die Sicherheits-Überwachungseinheit 108 so ausgelegt sein, dass sie ein oder mehrere sichere Interrupts empfängt und einen zusammengefassten Interrupt in dem sicheren Modus ausgibt.
5B ist ein Zustandsdiagramm, welches das beispielhafte Umschalten zwischen einer unsicheren Allzweckwelt 402 und einer sicheren Welt 404 gemäß einer Implementierung zeigt. Es werden verschiedene Trigger und Ergebnisse gezeigt; wobei das Umschalten von einer der „Welten“ zu der anderen der „Welten“ mittels der Sicherheits-Überwachungseinheit 108 ermöglicht wird, welche wie erörtert das Signal für den sicheren Modus zusichert bzw. die Zusicherung des Signals für den sicheren Modus zurücknimmt.
Die Veranschaulichung von 5B zeigt, dass ein sicherer Interrupt von einer Anwendung oder Routine in der sicheren Welt 404 ein Umschalten in den sicheren Modus zum Behandeln des sicheren Interrupt einleitet. Zum Beispiel kann eine Anwendung in der sicheren Welt 404 einen Interrupt auslösen, während die Allzweckwelt 402 aktiv ist, was zur sicheren Behandlung des sicheren Interrupt ein Umschalten in die sichere Welt 404 erforderlich macht. Dies veranlasst die Sicherheits-Überwachungseinheit 108, das Signal für den sicheren Modus zuzusichern. Der sichere Interrupt wird behandelt, während die sichere Welt aktiv ist (zum Beispiel sind sichere Ressourcen, Module 102, sicherer Speicher 112 und dergleichen für berechtigte Anwendungen und/oder Routinen zugreifbar). Das Abschließen der sicheren Interrupt-Behandlung leitet ein Zurückschalten zu der Allzweckwelt 402 ein (einschließlich einer Rückkehr von dem sicheren Interrupt).
Wie in 5B gezeigt, wird ein Allzweck-Interrupt innerhalb der Allzweckwelt 402 behandelt, und ein sicherer Interrupt wird, wie oben bereits erörtert, innerhalb der sicheren Welt 404 behandelt.
Die Veranschaulichung von 5B zeigt auch, dass ein kontrolliertes Aufrufen eines sicheren Dienstes von einer Anwendung oder Routine in der Allzweckwelt 402 ein Umschalten in die sichere Welt 404 zum Verarbeiten der Anforderung einleitet. Zum Beispiel würde dies auch die Sicherheits-Überwachungseinheit 108 veranlassen, das Signal für den sicheren Modus zuzusichern. Ein kontrolliertes Aufrufen eines sicheren Dienstes kann eine Anforderung nach Ressourcen von einem Modul 102 aus und dergleichen umfassen. Die Anforderung wird innerhalb der sicheren Welt 404 behandelt, einschließlich des Bereitstellens des bzw. der angeforderten Dienste, wie beispielsweise Ressourcen des Moduls 102 von einem oder mehreren Funktionsblöcken 202 aus, wie oben bereits erörtert. Das Beenden des sicheren Dienstes leitet ein Zurückschalten zu der Allzweckwelt 402 ein (einschließlich einer Rückkehr von dem kontrollierten Aufruf).
6 ist ein Verlaufsdiagramm, das beispielhafte Phasen des Umschaltens zwischen der unsicheren Welt 402 und der sicheren Welt 404 gemäß einer Implementierung zeigt. Zum Beispiel kann eine Eintrittssequenz in den sicheren Modus 600 eingeleitet werden, wenn eine Anwendung der Allzweckwelt 602 sichere Dienste über eine BootROM-Schnittstelle 604 anfordert. Bei einer Implementierung wird der BootROM-Dispatcher (BROM_DISPATCHER(DIENST, PARAMETER) mit den notwendigen Details der Dienstanforderung aufgerufen. Das Aufrufen des Dispatcher und die nachfolgende Ausführung der Eintrittssequenz 600 wird von der Sicherheits-Überwachungseinheit 108 überwacht, die am Ende der Eintrittssequenz 600 das Signal für den sicheren Modus zusichert.
Vor dem Zusichern des Signals für den sicheren Modus kann die Sicherheits-Überwachungseinheit 108 die Debugging-Infrastruktur, wie oben bereits erwähnt, vorübergehend deaktivieren. Mit der Zusicherung des Signals für den sicheren Modus ist die sichere Welt 404 aktiv, und berechtigte Anwendungen, Routinen und dergleichen können auf sichere Ressourcen (wie zum Beispiel sichere Funktionsblöcke 202 eines Moduls 102) zugreifen. BootROM kann die Dienstanforderung an das sichere ROM 606 übergeben (zum Beispiel mit der als SROM_LOAD(START, LANGE) gezeigten Funktion), wodurch entweder die gewünschte Anforderung ausgeführt wird oder die Anforderung an eine sichere Anwendung in dem sicheren RAM 610 übergeben wird.
In dem in 6 gezeigten Beispiel umfasst der Dienst einen Entschlüsselungs-Dienst 612 in dem sicheren ROM 606, einschließlich des Lesens von verschlüsseltem Inhalt (zum Beispiel in dem NVROM/FLASH 608), des Entschlüsselns des Inhalts und des Schreibens des entschlüsselten Inhalts in das sichere RAM, zum Beispiel zur E/A-Verarbeitung. Nachdem der Dienst beendet wurde, kehrt die Funktion SROM_LOAD() zu dem Boot-ROM 604 zurück, und die Austrittssequenz für den sicheren Modus 614 wird eingeleitet. Dies umfasst das Zurücknehmen der Zusicherung des Signals für den sicheren Modus und das Aktivieren der Debugging-Infrastruktur durch die Sicherheits-Überwachungseinheit 108. Schließlich gibt der BootROM-Dispatcher die Steuerung an die Allzweck-Software 602 zurück, welche die Routine aufgerufen hat.
Bei der beispielhaften Implementierung können die Allzweck-Software, die Boot-ROM-Software 604 und der NVROM/FLASH-Speicher 608 in den Allzweckspeicher 114 geladen werden, und die sichere ROM-Software 606 und das sichere RAM 610 können zum Beispiel in den sicheren Speicher 112 geladen werden.
7 ist ein Verlaufsdiagramm, das eine Technik für gesteuerte Übergänge zwischen der unsicheren Welt 402 und der sicheren Welt 404 gemäß einer Implementierung zeigt, wobei die beteiligten Interrupts im Detail gezeigt sind. Zum Beispiel kann eine Eintrittssequenz in den sicheren Modus 700 eingeleitet werden, wenn ein Interrupt für den sicheren Modus von der Sicherheits-Überwachungseinheit 108 erkannt wird. In dem beispielhaften Szenario von 7 wird ein sicheres Interrupt-Ereignis von einem der sicheren Welt 404 zugewiesenen Funktionsblock 202 signalisiert. Das sichere Interrupt-Ereignis wird von der Sicherheits-Überwachungseinheit 108 empfangen, was zum Beispiel den Eintrag für den sicheren Interrupt-Vektor in dem Vektorregister der Anwendung 702 mit dem in dem Boot-ROM 604 definierten Vektor aktualisiert.
Sobald der sichere Vektoreintrag installiert worden ist, wird das ursprüngliche Ereignis an den regulären Interrupt-Controller 704 übergeben, der darin die CPU 106 unterbricht und bewirkt, dass die neu installierte Behandlungsroutine ausgeführt wird.
Nachdem der sichere Interrupt behandelt worden ist, gibt die sichere Anwendung in dem sicheren ROM 606 die Steuerung an das Boot-ROM 604 zurück, was dann die Austrittssequenz für den sicheren Modus 706 ausführt. Dies stellt den Kontext der unterbrochenen Allzweck-Anwendung (einschließlich der ursprünglichen Vektortabelle) wieder her.
8 ist ein Verlaufsdiagramm, das beispielhafte Phasen des Zuweisens von Funktionsblöcken 202 zu unsicheren Allzweck-Anwendungen 602 gemäß einer Implementierung zeigt. Zum Beispiel kann eine Eintrittssequenz in den sicheren Modus 800 eingeleitet werden, wenn die Allzweck-Anwendung 602 über den Boot-ROM-Dispatcher unter Verwendung der Boot-ROM-Software 604 eine Anforderung nach Ressourcen vornimmt. Es wird ein dedizierter sicherer Dienst für das ROM 606 aufgerufen.
Bei der beispielhaften Implementierung liest der sichere Dienst für das ROM 606 den mit dem angeforderten Ressourcen-Modul 202 verbundenen sicheren Socket 104 und identifiziert den ersten verfügbaren Funktionsblock 202. Der Funktionsblock 202 wird zugeordnet und der Allzweckwelt 402 zugewiesen. Die Austrittssequenz für den sicheren Modus 802 wird eingeleitet, einschließlich des Zurückgebens der ID des Funktionsblocks an die Allzweck-Anwendung 602.
9 ist ein Verlaufsdiagramm, das beispielhafte Phasen des Zuweisens eines Funktionsblocks 202 zu einer sicheren Anwendung 610 gemäß einer Implementierung zeigt. Zum Beispiel kann eine Eintrittssequenz in den sicheren Modus 900 eingeleitet werden, wenn eine Allzweck-Anwendung 602 über den Boot-ROM-Dispatcher unter Verwendung der Boot-ROM-Software 604 einen sicheren Dienst anfordert. Ein dedizierter sicherer Dienst für das ROM 606 wird aufgerufen, der die Steuerung (SECURE SERVICE) an eine sichere Anwendung 610 übergibt, welche in der Lage ist, den angeforderten Dienst zu erfüllen. Die sichere Anwendung 610 kann zum Beispiel eine Hardware-Ressource verwenden, um die Dienstanforderung der Allzweck-Anwendung 602 zu leisten.
Bei der beispielhaften Implementierung kann die sichere Anwendung 610 direkt über einen vordefinierten sicheren Dienst für das ROM 606 (SECURE SERVICE) sichere Dienste für eine Instanz eines Funktionsblocks 202 anfordern, um die Dienstanforderung zu erfüllen. Ein solcher Dienst weist vorübergehend (ASSIGN_SEC_FB()) den zugeordneten Funktionsblock 202 der sicheren Welt 404 zu, wie oben bereits erörtert. Nach einer Abfrage und einer Aktualisierung des Sicherheits-Socket 104, der mit dem Modul 102 des zugeordneten Funktionsblocks 202 verbunden ist, gibt der sichere Dienst für das ROM 606 die ID des zugeordneten Funktionsblocks an die sichere Anwendung 610 zurück.
Bei verschiedenen Implementierungen können, wie in 6 bis 9 gezeigt, die Dienste in Verbindung mit der Zuweisung von Funktionsblöcken 202 für die Allzweckwelt 402 und für die sichere Welt 404 unterschiedlich sein. Demgemäß kann ein allgemeiner Zuweisungsdienst es schwierig finden festzustellen, woher eine Dienstanforderung gekommen ist.
Wie oben bereits erörtert, sind die in dem vorliegenden Dokument unter Bezugnahme auf die Implementierungen beschriebenen Techniken, Komponenten und Vorrichtungen nicht auf die Veranschaulichungen von 1 bis 9 beschränkt und können auf andere Controller-Topologien, Vorrichtungen und Konstruktionen angewendet werden, ohne von dem Schutzumfang der Offenbarung abzuweichen. In einigen Fällen können zusätzliche oder alternative Komponenten, Techniken, Sequenzen oder Prozesse verwendet werden, um die in dem vorliegenden Dokument beschriebenen Techniken zu implementieren. Ferner können die Komponenten und/oder Techniken in verschiedenen Kombinationen angeordnet und/oder kombiniert werden, während dies zu ähnlichen oder annähernd identischen Ergebnissen führt. Es versteht sich, dass ein Controller 100 als Einzelvorrichtung oder als Teil eines anderen Systems implementiert werden kann (zum Beispiel integriert in andere Komponenten, Systeme, usw.). Bei verschiedenen Implementierungen können zusätzliche oder alternative Komponenten verwendet werden, um die offenbarten Techniken und Anordnungen zu realisieren.
Repräsentativer Prozess
10 ist ein Ablaufdiagramm, das einen beispielhaften Prozess 1000 zum Bereitstellen einer dynamischen gemeinsamen Nutzung von Ressourcen gemäß einer Implementierung zeigt. Der Prozess 1000 beschreibt das Verwenden einer Sicherheits-Überwachungseinheit (wie zum Beispiel der Sicherheits-Überwachungseinheit 108) zum Überwachen von Anwendungen, die auf einem Controller (wie zum Beispiel dem Controller 100) ausgeführt werden. Funktionsblöcke (wie zum Beispiel die Funktionsblöcke 202) von Ressourcen-Modulen (wie zum Beispiel den Modulen 102) können gleichzeitig unsicheren und sicheren Anwendungen zugeordnet werden, ohne dass dies die Sicherheit der sicheren Anwendungen und der ihnen zugewiesenen Ressourcen beeinträchtigt, und ohne Duplizieren von Hardware. Der Prozess 1000 wird unter Bezugnahme auf 1 bis 9 beschrieben.
Die Reihenfolge, in welcher der Prozess beschrieben ist, soll nicht als Einschränkung ausgelegt werden, und jede beliebige Anzahl der beschriebenen Prozessblöcke kann in jeder beliebigen Reihenfolge kombiniert werden, um den Prozess bzw. einen alternativen Prozess zu implementieren. Zudem können einzelne Blöcke aus dem Prozess entfernt werden, ohne dass dadurch von dem Wesen und Schutzumfang des in dem vorliegenden Dokument beschriebenen Gegenstands abgewichen wird. Ferner kann der Prozess in allen beliebigen geeigneten Materialien oder Kombinationen daraus implementiert werden, ohne dass dadurch von dem Schutzumfang des in dem vorliegenden Dokument beschriebenen Gegenstands abgewichen wird.
Bei Block 1002 umfasst der Prozess 1000 das Empfangen einer ersten Anforderung nach einer Ressource eines Moduls (wie zum Beispiel des Moduls 102) von einer ersten Anwendung gemäß einer Implementierung. Bei der Implementierung umfasst die erste Anwendung eine von einer sicheren Anwendung oder einer unsicheren Anwendung.
Bei Block 1004 umfasst der Prozess das Zuordnen eines ersten Funktionsblocks (wie zum Beispiel des Funktionsblocks 202) des Moduls zu der ersten Anwendung. Bei einer Implementierung handelt es sich bei dem ersten Funktionsblock um den ersten verfügbaren Funktionsblock des Moduls. Zum Beispiel umfasst bei der Implementierung das Modul eine Vielzahl von Funktionsblöcken. Bei einer Implementierung umfasst der Prozess das Aufteilen des Moduls in die Vielzahl von Funktionsblöcken, sodass die Funktionsblöcke des Moduls ähnlich oder identisch sind. Bei einer alternativen Implementierung sind die Funktionsblöcke auf der Grundlage anderer erwünschter Merkmale (zum Beispiel Priorität, Leistung, usw.) unterteilt.
Bei Block 1006 umfasst der Prozess das Empfangen einer zweiten Anforderung nach einer Ressource des Moduls von einer zweiten Anwendung. Bei einer Implementierung umfasst die zweite Anwendung die andere von der sicheren Anwendung oder der unsicheren Anwendung. Wenn es sich zum Beispiel bei der ersten Anwendung um eine unsichere Anwendung handelt, dann handelt es sich bei der zweiten Anwendung um eine sichere Anwendung und umgekehrt. Bei einer alternativen Implementierung ist die zweite Anwendung die erste Anwendung. Bei einer weiteren Implementierung weist die zweite Anwendung dieselbe Sicherheit (unsicher oder sicher) auf wie die erste Anwendung.
Bei Block 1008 umfasst der Prozess das Zuordnen eines zweiten Funktionsblocks des Moduls zu der zweiten Anwendung. Bei einem Beispiel handelt es sich bei dem zweiten Funktionsblock um den nächsten verfügbaren Funktionsblock des Moduls.
Bei einer Implementierung greift die zweite Anwendung zu dem gleichen Zeitpunkt auf das Modul zu, wie die erste Anwendung auf das Modul zugreift. Bei der Implementierung ist der erste Funktionsblock hinsichtlich der Kommunikation von dem zweiten Funktionsblock isoliert.
Bei einer Implementierung umfasst der Prozess das Verbinden eines Wrapper mit dem Modul, wobei der Wrapper so ausgelegt ist, dass er Zugriffsberechtigungen von zugeordneten Funktionsblöcken des Moduls bestimmt. Zum Beispiel basieren die Zugriffsberechtigungen darauf, ob ein Funktionsblock einer sicheren Anwendung oder einer unsicheren Anwendung zugeordnet ist. Bei einer weiteren Implementierung umfasst der Prozess das Erlauben oder Verweigern eines Buszugriffs auf einen Funktionsblock, basierend auf von dem Wrapper des Moduls bestimmten Zugriffsberechtigungen.
Bei einer Implementierung ist der Wrapper mittels sicherer ausführbarer Anweisungen programmierbar und mittels unsicherer ausführbarer Anweisungen nicht programmierbar. Zum Beispiel kann mit einer Ressource einer Hardware-Vorrichtung oder dergleichen verbundene Firmware den Wrapper programmieren, wenn die Firmware sicher ist. Bei alternativen Implementierungen können sichere ausführbare Anweisungen andere Formen von Code, Software, Maschinenanweisungen und dergleichen umfassen.
Bei einer Implementierung umfasst der Prozess das Zuweisen eines Funktionsblocks des Moduls zu einem der folgenden Elemente: eine sichere Welt, eine unsichere Welt oder weder die sichere Welt noch die unsichere Welt, basierend auf den von dem Wrapper des Moduls bestimmten Zugriffsberechtigungen. Bei einer weiteren Implementierung umfasst der Prozess das Erlauben, dass eine Anwendung auf einen der sicheren Welt zugewiesenen Funktionsblock zugreift, während ein sicherer Modus aktiv ist. Bei einer weiteren Implementierung umfasst der Prozess das Verweigern, dass eine Anwendung auf den der sicheren Welt zugewiesenen Funktionsblock zugreift, während der sichere Modus inaktiv ist.
Bei einer Implementierung umfasst der Prozess das Erlauben oder Blockieren einer Transaktion mit dem Modul über Interconnect-Fabric, basierend auf vorbestimmten Berechtigungen des Moduls. Zum Beispiel können die vorbestimmten Berechtigungen (wie zum Beispiel Nur-Lese-Zugriff oder dergleichen) fest verdrahtet sein oder feste Bedingungen des Moduls sein.
Bei einer Implementierung umfasst der Prozess das Zuordnen eines nächsten verfügbaren Funktionsblocks des Moduls zu einer nächsten anfordernden Anwendung ohne Rücksicht darauf, ob es sich bei der nächsten anfordernden Anwendung um eine sichere Anwendung oder um eine unsichere Anwendung handelt. Bei einer weiteren Implementierung ist der nächste Funktionsblock hinsichtlich der Kommunikation von wenigstens einem von dem ersten Funktionsblock und dem zweiten Funktionsblock isoliert, wodurch Sicherheit zwischen den Funktionsblöcken vorgesehen wird.
Bei alternativen Implementierungen können andere Techniken in dem Prozess 1000 in verschiedenen Kombinationen enthalten sein und innerhalb des Schutzumfangs der Offenbarung bleiben.
Schlussfolgerung
Obwohl die Ausführungsbeispiele der Offenbarung in einer für strukturelle Merkmale und/oder methodische Handlungen spezifischen Sprache beschrieben wurden, versteht es sich, dass die Implementierungen nicht notwendigerweise auf die spezifischen beschriebenen Merkmale oder Handlungen beschränkt sind. Die spezifischen Merkmale und Handlungen sind vielmehr als repräsentative Ausbildungen der Implementierung von beispielhaften Vorrichtungen und Techniken offenbart.

Claims

Chip, der Folgendes umfasst: eine Snooping-Komponente, die so ausgelegt ist, dass sie einen Prozessor überwacht und bestimmt, ob eine auf dem Prozessor ausgeführte Anwendung sicheren Zugriff auf eine Ressource anfordert; und eine Ausgabekomponente, die so ausgelegt ist, dass sie ein Signal für einen sicheren Modus ausgibt, das sicheren Zugriff auf sichere Funktionsblöcke von Modulen mit gemeinsam genutzten Ressourcen gewährt, wenn es sich bei der Anwendung um eine sichere Anwendung handelt; und eine Interrupt-Behandlungskomponente, die so ausgelegt ist, dass sie ein Interrupt-Vektorregister mit einer sicheren ISR-Behandlungsroutine (Interrupt-Service-Routine) umprogrammiert, wenn das Signal für den sicheren Modus zugesichert bzw. aktiviert ist.
Chip nach Anspruch 1, wobei die gemeinsam verwendeten Ressourcen-Module in sichere Funktionsblöcke und unsichere Funktionsblöcke unterteilt sind, wobei sichere Anwendungen auf die sicheren Funktionsblöcke zugreifen, während gleichzeitig unsichere Anwendungen auf die unsicheren Funktionsblöcke zugreifen.
Chip nach Anspruch 3, wobei die sicheren Funktionsblöcke hinsichtlich der Kommunikation von den unsicheren Funktionsblöcken isoliert sind.
Chip nach Anspruch 1, wobei der Chip das Signal für den sicheren Modus zusichert bzw. aktiviert, wenn eine berechtigte Anwendung eine sichere Transaktion beginnt oder den Zugriff auf eine sichere Ressource einleitet, und der Chip die Zusicherung bzw. Aktivierung des Signals für den sicheren Modus zurücknimmt, wenn eine Anwendung eine sichere Transaktion beendet oder den Zugriff auf eine sichere Ressource beendet.
Chip nach Anspruch 1, wobei der Chip so ausgelegt ist, dass er Anforderungen nach sicheren Interrupts zusammenfasst und die zusammengefassten Anforderungen nach sicheren Interrupts an den Prozessor und/oder einen externen Interrupt-Controller weiterleitet.
Chip nach Anspruch 1, wobei der Chip so ausgelegt ist, dass er eine Debugging-Infrastruktur deaktiviert, wenn das Signal für den sicheren Modus zugesichert ist, und die Debugging-Infrastruktur aktiviert, wenn die Zusicherung des Signals für den sicheren Modus zurückgenommen wird.
Chip nach Anspruch 1, der ferner Folgendes aufweist: einen Prozessor, der so ausgelegt ist, dass er gleichzeitig eine unsichere Anwendung und eine sichere Anwendung ausführt; eine Sicherheits-Überwachungseinheit, die so ausgelegt ist, dass sie den Prozessor überwacht und ein Signal für einen sicheren Modus ausgibt, wenn die sichere Anwendung Zugriff auf ein Ressourcen-Modul anfordert; ein oder mehrere Ressourcen-Module, wobei jedes Ressourcen-Modul eine Vielzahl von Funktionsblöcken aufweist, wobei einer oder mehrere der Vielzahl von Funktionsblöcken der unsicheren Anwendung zugeordnet ist bzw. sind und gleichzeitig einer oder mehrere der Vielzahl von Funktionsblöcken der sicheren Anwendung zugeordnet ist bzw. sind; und einen oder mehrere Sicherheits-Sockets, die so ausgelegt sind, dass sie Zugriffsberechtigungen jedes der zugeordneten Funktionsblöcke des einen oder der mehreren Ressourcen-Module bestimmt, wobei die Zugriffsberechtigungen darauf basieren, ob ein Funktionsblock der unsicheren Anwendung zugeordnet ist oder der sicheren Anwendung zugeordnet ist.
Chip nach einem der Ansprüche 1 bis 7, wobei der Chip ein Mikrocontroller ist oder aufweist.
Verfahren zum Betreiben eines Chips gemäß einem der Ansprüche 1 bis 8, wobei das Verfahren Folgendes umfasst: Empfangen einer ersten Anforderung nach einer Ressource eines Moduls von einer ersten Anwendung, wobei es sich bei der ersten Anwendung um eine von einer sicheren Anwendung oder einer unsicheren Anwendung handelt; Zuordnen eines ersten Funktionsblocks des Moduls zu der ersten Anwendung, wobei das Modul eine Vielzahl von Funktionsblöcken aufweist; Empfangen einer zweiten Anforderung nach einer Ressource des Moduls von einer zweiten Anwendung, wobei es sich bei der zweiten Anwendung um die andere von der sicheren Anwendung oder der unsicheren Anwendung handelt; und Zuordnen eines zweiten Funktionsblocks des Moduls zu der zweiten Anwendung, wobei das Zugreifen der zweiten Anwendung auf das Modul gleichzeitig mit dem Zugreifen der ersten Anwendung auf das Modul erfolgt und der erste Funktionsblock hinsichtlich der Kommunikation von dem zweiten Funktionsblock isoliert ist.