-
Die Erfindung betrifft ein System-on-Chip (SoC) und ein Verfahren zum Betreiben eines System-on-Chip.
-
Im Zusammenhant mit Virtualisierung kann ein System (z.B. ein Microcontroller) mit mehreren Prozessorkernen in mehrere virtuelle Maschinen (VM) partitioniert sein, von denen jede einen oder mehr der Prozessorkerne aufweisen kann. Außerdem ist es möglich, dass ein einzelner Prozessorkern mehrere VMs aufweist, so dass dieser einzelne Prozessorkern entsprechend mehrere isolierte Softwareanwendungen ausführen kann.
-
Ein solches System, auch als „System-on-Chip“ bezeichnet, kann es ermöglichen, komplexe (betriebs-)sicherheitskritische (Echtzeit-)Hardwaresysteme zu steuern oder zu regeln.
-
Das Ausführen von Software (SW) in verschiedenen unabhängigen VMs kann ein Isolieren der Software vereinfachen, was aus Sicherheitsgründen attraktiv ist.
-
Der deutsche Begriff „Sicherheit“ und damit zusammenhängende Begriffe (z.B. „sicherheitskritisch“) wird allgemein in zwei verschiedenen Zusammenhängen gebraucht, welche im Englischen mittels der Begriffe „safety“ bzw. „security“ unterschieden werden. Hierbei bezeichnet „safety“ eine Betriebssicherheit, also dass ein System in einem Zustand betrieben wird, in welchem seine Nutzung weder Schäden am System selbst noch an seiner Umgebung (z.B. einem Nutzer oder einem anderen System) verursacht, also eine schädliche Wechselwirkung vermieden wird. „Security“ hingegen bezieht sich auf eine Datensicherheit. Also darauf, dass ein Zugriff auf Daten und/oder Funktionen, welche von einem System bereitstellbar bzw. ausführbar sind, nur Zugriffsberechtigten ermöglicht sind, also beispielsweise ein Angriff verhindert wird.
-
Das Konzept der Virtualisierung, bei welcher typischerweise ein so genannter Hypervisor (HV) die VMs verwaltet, wird, wie oben bereits angedeutet, auch zunehmend so umgesetzt, dass die VMs und der HV auf derselben Hardware (HW), z.B. innerhalb eines einzelnen Chips, integriert werden.
-
Das ist zwar kostensparend, verkompliziert allerdings sowohl die Betriebs- als auch die Datensicherheit.
-
Häufig liegen, wie beispielsweise in 1 dargestellt ist, in einem System eine erste virtuelle Maschine VM1, eine zweite virtuelle Maschine VM2 und ein Hypervisor HV vor. VM1 soll dabei die Anwendung A ausführen, VM2 die Anwendung B, und der Hypervisor HV soll beide verwalten/steuern.
-
Häufig kann es jedoch inakzeptabel sein, dass jeder Softwareentwickler, z.B. der Anwendung A, die volle Information und Analysemöglichkeiten für die Anwendung B erhält. Beispielsweise kann es sich bei der Anwendung B um eine Anwendung aus dem Cybersecurity-Bereich (CS-Anwendung, wie z.B. eine Secure Hardware Extension (SHE+)-Emulation) oder um eine Software von einem direkten Mitbewerber handeln, so dass zum Aufrechterhalten der Datensicherheit und/oder zum Schutz geistigen Eigentums ausgeschlossen werden muss, dass eine Person, die die Anwendung A entwickelt oder debuggt, Zugriff auf die Anwendung B erhält (und natürlich ggf. auch umgekehrt).
-
Häufig werden in ein System (z.B. ein von Autoherstellern genutztes SoC) Software-Anwendungen von verschiedenen Zulieferern in unterschiedliche VMs integriert, und direkt nach der Installation versagt das Gesamtsystem, obwohl beide Anwendungen während der Entwicklung (in 2 für eine beispielhaft in der VM2 integrierte Anwendung B dargestellt) funktioniert haben, als sie allein auf dem Chip bereitgestellt waren. Selbstverständlich möchte in einer solchen Situation der Entwickler der Anwendung B dem Entwickler der Anwendung A keinen Zugriff auf seine Software gestatten.
-
Der Hersteller kann möglicherweise Zugriff auf beide VMs/beide Anwendungen haben, aber ihm kann möglicherweise das Know-How fehlen, um eine der Anwendungen (oder beide) zu debuggen.
-
Häufig wird Virtualisierung für große Anwendungskern-basierte Systeme genutzt (z.B. von Intel, AMD x86 oder ARM A-Serie), welche die verschiedenen VMs auch hinsichtlich der Hardware weitgehend trennen.
-
Das Debuggen wird in solchen Fällen typischerweise monitorbasiert vorgenommen. Der Debug-Monitor ist dann eine Software, welche innerhalb desselben VM-Kontexts läuft und deshalb kein zusätzliches Risiko hinsichtlich der Datensicherheit bildet.
-
Eingebettete System mit höheren Echtzeit-Ansprüchen könnten zwar im Prinzip eine ähnliche Herangehensweise nutzten, allerdings gibt es dabei verschiedene Hinderungsgründe.
-
Beispielsweise kann ein Debuggen von Echtzeitsystemen sehr komplex sein, wenn das Debuggen das Zeitmanagement verändert/beeinflusst. Während in frühen Entwicklungsphasen ein Debuggen der Ausführungssteuerung mit Haltepunkten (Breakpoints) und Einzelschrittverfolgung akzeptabel sein kann, ist dies in späteren Phasen der Entwicklung eines so genannten „harten“ Echtzeitsystems nicht angemessen.
-
Ferner sind die Ressourcen eines eingebetteten Systems typischerweise limitiert, so dass ein großer Debug-Monitor nicht bzw. schwer umsetzbar ist.
-
Weiterhin weist ein solches System typischerweise ein Speicher-Schutzsystem (Memory Protection System (MPU)) auf, anstelle der sonst üblichen Speicher-Verwaltungssystems (Memory Management Unit (MMU)). Ein MPU-basiertes System stellt eine wesentlich größere Herausforderung dar, wenn es darum geht, einen robusten und allgemein anwendbaren Debug-Monitor bereitzustellen.
-
Außerdem gibt es viele verschiedene Betriebssysteme, und ein solcher Debug-Monitor ist jeweils betriebssystemspezifisch.
-
Und schließlich ist es typischerweise erforderlich, dass der Debug-Monitor mit dem Hypervisor zusammenarbeitet oder ein Teil des HV ist, so dass der Debug-Monitor sogar noch spezieller angepasst sein muss, nämlich an das Betriebssystem in der Kombination mit dem Hypervisor. Anbieter von Debugger, Betriebssystem und Hypervisor sind typischerweise drei unterschiedliche Firmen, was es technisch und ökonomisch schwierig macht, eine gute Lösung zu finden.
-
In verschiedenen Ausführungsbeispielen wird ein System-on-Chip bereitgestellt, welches es ermöglicht, einem Debugger Zugriff auf eine virtuelle Maschine des System-on-Chip zu ermöglichen, und den Zugriff auf mindestens eine zusätzliche im System-on-Chip integrierte virtuelle Maschine zu verhindern.
-
In verschiedenen Ausführungsbeispielen kann ein privilegierter Nutzer (auch als System-Integrator bezeichnet) berechtigt sein, das System-on-Chip vorzubereiten, indem er Schutzmechanismen aktiviert. Dadurch können Restriktionen festgelegt werden, die durch ein on-Chip-Securitysystem umgesetzt werden.
-
Das SoC kann eingerichtet sein, einem „normalen“ Nutzer, z.B. einem Debugger-Benutzer, erst dann Zugriff zu ermöglichen, wenn die Schutzmechanismen aktiviert sind.
-
Damit kann in verschiedenen Auführungsbeispielen ermöglicht werden, dass der Systemintegrator eine Lese- und Schreibberechtigungen für die virtuellen Maschinen steuert, und ein Entwickler von auf einer der virtuellen Maschinen ausgeführten Software die Möglichkeit hat, Debug-Informationen zu erhalten.
-
In verschiedenen Ausführungsbeispielen kann das SoC so eingerichtet sein, dass eine Anpassung des Debuggers an ein spezifisches Betriebssystem und/oder Hypervisor überflüssig ist.
-
Das SoC kann in verschiedenen Ausführungsbeispielen für ein Trace-basiertes Debugging eingerichtet sein, so dass Debug-Artefakte infolge abweichenden zeitbezogenen Verhaltens beim Debuggen der Ausführungssteuerung vermieden werden kann.
-
Das System-on-Chip kann in verschiedenen Ausführungsbeispielen eingerichtet sein, in einem Debug-Modus betrieben zu werden. Dabei kann einer der Prozessorkerne eingerichtet sein, im Debug-Modus nach einem Betriebsstart des System-on-Chip zunächst nur eine Debug-Konfigurations-Software zu starten. Die Debug-Konfigurations-Software kann eingerichtet sein, eine Debug-Einstellung vorzunehmen, die nach einem Beenden der Debug-Konfigurations-Software einen Zugriff durch eine Debugger-Software auf mindestens eine der virtuellen Maschinen verhindert und einen Zugriff durch die Debugger-Software auf mindestens eine weitere der virtuellen Maschinen ermöglicht.
-
In verschiedenen Ausführungsbeispielen kann zumindest ein Teil des Debuggers (z.B. einer Debugger-Software) als Teil des System-on-Chip bereitgestellt werden oder sein.
-
Der im SoC integrierte Teil des Debuggers kann in verschiedenen Ausführungsbeispielen eine fein granulierte, hinsichtlich Datensicherheit geschützte Zugriffssteuerung zu Registern und Speichern des SoC ermöglichen.
-
Das System-on-Chip kann in verschiedenen Ausführungsbeispielen ferner ein Trace-System (z.B. eine Tracing-Software) aufweisen, welches die genannte Zugriffssteuerung unterstützt, z.B. auf einer VM-Ebene.
-
In verschiedenen Ausführungsbeispielen kann ein Teil des Trace-Systems mittels der im SoC integrierten gesicherten Zugriffssteuerung konfigurierbar sein, und ein weiterer Teil mittels eines externen Teils der Debug-Software.
-
In verschiedenen Ausführungsbeispielen kann in einer Integrationsphase des System-on-Chip der privilegierte System-Integrator eine Schutz-und-Debug-Systemkonfiguration mit beschränkten Zugriffsrechten und Tracefähigkeiten vorbereiten. Das SoC kann eingerichtet sein, die Beschränkungen mittels eines on-Chip-CyberSecurity-Systems (CSRM) zu erzwingen.
-
Anwendungsentwicklern kann damit ermöglicht werden, mittels eines herkömmlichen (z.B. Debug-Schnittstellen (z.B. DAP/JTAG-) basierten) Debuggers, der lediglich auf Speicher und Peripheriegeräte bzw. -schaltkreise, die vom System-Integrator freigegeben sind, Zugriff hat, eine Softwareanwendung auf einer der virtuellen Maschinen zu debuggen.
-
In verschiedenen Ausführungsbeispielen kann der System-Integrator beispielsweise ein unbeschränktes Multi-Core-Debugsystem-Tracing der zu debuggenden virtuellen Maschine an den CPUs und Zustands- und Signaltraces relevanter Peripheriemodule bzw. -schaltkreise ermöglichen, beispielsweise mittels Definierens eines (Lese- )Zugriffsbereichs an Slave-Interfaces lokaler Speicher der CPU.
-
Ausführungsbeispiele der Erfindung sind in den Figuren dargestellt und werden im Folgenden näher erläutert.
-
Es zeigen
- 1 eine schematische Veranschaulichung eines System-on-Chip und eines Debuggers während einer Integration durch einen privilegierten Nutzer;
- 2 eine schematische Veranschaulichung eines System-on-Chip und eines Debuggers während einer Entwicklung einer Anwendung auf einer virtuellen Maschine;
- 3 eine schematische Veranschaulichung eines System-on-Chip gemäß verschiedenen Ausführungsbeispielen und eines Debuggers während eines Debug-Vorgangs;
- 4 ein Ablaufdiagramm eines Debug-Vorgangs bei einem System-on-Chip gemäß verschiedenen Ausführungsbeispielen;
- 5 Register eines System-on-Chip gemäß verschiedenen Ausführungsbeispielen; und
- 6 ein Flussdiagramm eines Verfahrens zum Betreiben eines System-on-Chip gemäß verschiedenen Ausführungsbeispielen.
-
In der folgenden ausführlichen Beschreibung wird auf die beigefügten Zeichnungen Bezug genommen, die Teil dieser bilden und in denen zur Veranschaulichung spezifische Ausführungsformen gezeigt sind, in denen die Erfindung ausgeübt werden kann. In dieser Hinsicht wird Richtungsterminologie wie etwa „oben“, „unten“, „vorne“, „hinten“, „vorderes“, „hinteres“, usw. mit Bezug auf die Orientierung der beschriebenen Figur(en) verwendet. Da Komponenten von Ausführungsformen in einer Anzahl verschiedener Orientierungen positioniert werden können, dient die Richtungsterminologie zur Veranschaulichung und ist auf keinerlei Weise einschränkend. Es versteht sich, dass andere Ausführungsformen benutzt und strukturelle oder logische Änderungen vorgenommen werden können, ohne von dem Schutzumfang der vorliegenden Erfindung abzuweichen. Es versteht sich, dass die Merkmale der hierin beschriebenen verschiedenen beispielhaften Ausführungsformen miteinander kombiniert werden können, sofern nicht spezifisch anders angegeben. Die folgende ausführliche Beschreibung ist deshalb nicht in einschränkendem Sinne aufzufassen, und der Schutzumfang der vorliegenden Erfindung wird durch die angefügten Ansprüche definiert.
-
Im Rahmen dieser Beschreibung werden die Begriffe „verbunden“, „angeschlossen“ sowie „gekoppelt“ verwendet zum Beschreiben sowohl einer direkten als auch einer indirekten Verbindung, eines direkten oder indirekten Anschlusses sowie einer direkten oder indirekten Kopplung. In den Figuren werden identische oder ähnliche Elemente mit identischen Bezugszeichen versehen, soweit dies zweckmäßig ist.
-
In verschiedenen Ausführungsbeispielen wird während einer Integrationsphase mehrerer virtueller Maschinen, die von einem privilegierten Nutzer (auch als System-Integrator bezeichnet) in einem System-on-Chip integriert werden, ermöglicht, eine Einstellung eines Schutz- und Debugsystems vorzunehmen, so dass es beschränkte Zugriffsrechte und TraceFähigkeiten aufweist. Dabei können zugehörige Beschränkungen mittels eines im Chip integrierten Sicherheitssystems (on-Chip CyberSecurity-System CSRM) erzwungen werden.
-
Anders ausgedrückt kann eine privilegierte Software, die als erstes nach einem Reset eines SoC läuft, eingerichtet sein, gewisse Einstellungen in einem Trace-System festzulegen, die später (bis zum nächsten Reset) nicht mehr änderbar sind, wobei der Rest des Trace-Systems frei programmierbar sein kann.
-
Anwendungsentwickler können daraufhin herkömmliche Debug-Schnittstellen-basierte (z.B. DAP/JTAG-basierte) Debug-Anwendungen verwenden, wobei sie lediglich Zugriff auf Speicher und Peripheriegeräte bzw. -schaltkreise haben, die der System-Integrator freigegeben hat.
-
Sofern lediglich eine der virtuellen Maschinen vor einem Zugriff geschützt zu werden braucht, kann einem Entwickler der dort installierten Software die Funktion des System-Integrators gewährt werden. Ein Verantwortungsbereich des System-Integrators betrifft ein Bereitstellen einer Debug-Umgebung für Anwendungsentwickler, welche bei Bedarf eine datensichere Umgebung für Anwendungen, welche gerade nicht debuggt werden, bereitstellt.
-
3 zeigt eine schematische Veranschaulichung eines System-on-Chip 300 gemäß verschiedenen Ausführungsbeispielen und eines Debuggers 102 während eines Debug-Vorgangs. 4 zeigt ein Ablaufdiagramm eines Debug-Vorgangs bei einem System-on-Chip 300 gemäß verschiedenen Ausführungsbeispielen
-
Das System-on-Chip 300 kann eingerichtet sein, in einem Debug-Modus betrieben zu werden.
-
Der Debug-Modus ist auch in 4 veranschaulicht, welche ein Ablaufdiagramm eines Debug-Vorgangs bei einem System-on-Chip 300 gemäß verschiedenen Ausführungsbeispielen zeigt.
-
Das System-on-Chip 300 kann eine Mehrzahl von Prozessorkernen 332 aufweisen, die eine Mehrzahl virtueller Maschinen (hier beispielhaft zwei virtuelle Maschinen, nämlich die erste virtuelle Maschine VM1 und die zweite virtuelle Maschine VM2) aufweisen.
-
Das System-on-Chip 300 kann ferner einen weiteren Prozessorkern 334 aufweisen, der eingerichtet sein kann, im Debug-Modus nach einem Betriebsstart des System-on-Chip (auch als Power-on-Reset oder Energie-an-Reset bezeichnet) zunächst nur eine Debug-Konfigurations-Software zu starten.
-
Der weitere Prozessorkern 334 kann beispielsweise ein Hardware-Sicherheitsmodul (HSM) sein (in 4 als Security Prozessor und oben als CSRM bezeichnet). Der weitere Prozessorkern 334 kann eingerichtet sein, eine Start-Software zu laden (bei 456 veranschaulicht), beispielsweise aus einem Speicher, z.B. einem ROM. Die Debug-Konfigurations-Software kann Teil der Start-Software sein oder eingerichtet sein, von der Start-Software gestartet zu werden.
-
Die Debug-Konfigurations-Software kann in verschiedenen Ausführungsbeispielen eingerichtet sein, eine Debug-Einstellung vorzunehmen, die nach einem Beenden der Debug-Konfigurations-Software einen Zugriff durch eine Debugger-Software (des Debuggers 102) auf mindestens eine der virtuellen Maschinen VM1 oder VM2 verhindert und einen Zugriff durch die Debugger-Software 102 auf mindestens eine weitere der virtuellen Maschinen (die andere von VM1 bzw. VM2) ermöglicht.
-
In 4 ist (bei 458) veranschaulicht, dass der weitere Prozessorkern 334 eingerichtet sein kann, unmittelbar nach dem Hochfahren des System-on-Chip 300 („Energie-an-Reset“ (auch als Power-on-Reset bezeichnet)) einem im System-on-Chip 300 integrierten Teil des Debug-Systems, z.B. dem so genannten Multicore Debug System (Mehrkern-Debug-System MCDS) 444 und dem Debug-Interface 446 (das Multicore Debug System 444 und das Debug-Interface 446 sind gemeinsam in 3 als „Debug-Anteil“ 330 bezeichnet), zu ermöglichen, Zugriffsberechtigungen zu der Mehrzahl von Prozessorkernen („Anwendungs-CPUs“) 332 festzulegen. Ferner kann der weitere Prozessorkern 334 eingerichtet sein, mittels des MCDS 444 Tracequellen zur Nutzung freizugeben (eine Leseberechtigung erteilen) oder zu verweigern (siehe 462 und 5, Tabellen d), e) f)). Anschließend kann die eingestellte Tracequellen-Konfiguration vom weiteren Prozessorkern 334 mittels des MCDS 444 verriegelt werden („lock“, siehe 464 und 5, Tabelle g)), d.h. vor einer Veränderung vor einem erneuten Reset des System-on-Chip 300 geschützt werden.
-
Das Festlegen und das Verriegeln der Berechtigungen kann mittels Schreiben in Register, die beispielhaft in 5 beschrieben sind, erfolgen.
-
Das mindestens eine Register kann beispielsweise mindestens ein Sperrbit aufweisen, welches beim Reset in einen Grundzustand setzbar ist und mittels der Debug-Konfigurations-Software einmalig in einen vorbestimmten Zustand änderbar ist. Die Debug-Einstellung kann unveränderbar sein, wenn das Sperrbit im vorbestimmten Zustand ist.
-
In verschiedenen anderen Ausführungsbeispielen kann die Debug-Einstellung nach dem Beenden der Debug-Konfigurations-Software nur durch einen vertrauenswürdigen Master veränderbar sein. Der vertrauenswürdige Master kann beispielsweise ein Hardware Bus Master des Hardware-Sicherheitsmoduls sein.
-
Zum Verwalten der Zugriffsberechtigungen kann das System-on-Chip 300 in verschiedenen Ausführungsbeispielen mit mindestens einer so genannten Access Protection Unit (APU, auf Deutsch: Zugriffsschutzvorrichtung) ausgestattet sein, welche beispielsweise in den oben genannten Registern die Zugriffsrechte (lesen/schreiben) für jeden Master und/oder Slave innerhalb des System-on-Chip 300 und (z.B. über von außen zugängliche Schnittstellen) außerhalb des System-on-Chip 300 einräumen bzw. verweigern kann. Beispielsweise können alle Busverbindungs-Slave-Interfaces über Access Protection Units verfügen, welche es ermöglichen, Zugriffsberechtigungen für einen Lese- bzw. Schreibzugriff zuzuweisen. Eine Granularität der Zugriffsberechtigungen kann beispielsweise auf VM-Basis vorliegen und mittels Hardware geschützt sein.
-
Der Debugger 102 kann ein Master sein, dem Lesezugriff auf Tracequellen und ggf. Schreibzugriff für Tracekonfigurationen, z.B. auf Filtereinstellungen, Triggerpunkte usw., ermöglicht wird.
-
In dem in 3 veranschaulichten Beispiel kann das System-on-Chip 300 so eingerichtet sein, dass die zweite virtuelle Maschine VM2 (bzw. die dort installierte Software) debuggt wird, und die erste virtuelle Maschine VM1 währenddessen vor einem Zugriff durch den Debugger 102 geschützt ist.
-
Das bedeutet unter anderem, dass Software, die auf der ersten virtuellen Maschine VM1 bzw. auf der zweiten virtuellen Maschine VM2 installiert ist, erst nach der Debug-Konfigurations-Software gestartet wird, und erst danach die Debug-Software gestartet wird, allerdings frühestens dann, wenn die erste User-Code-Instruktion ausgeführt wird, welche verzögert wird, bis die Schutzmechanismen mit Hilfe der Debug-Konfigurations-Software installiert sind. Erst dann wird die Debug-Software des Debuggers 102 tatsächlich ausgeführt.
-
In verschiedenen Ausführungsbeispielen kann ein Datenmissbrauch-Schutzsystem („Protection System“) zum Schutz von Speichern und Peripheriemodulen bzw. -schaltkreisen der zu schützenden virtuellen Maschine (im Beispiel ist das die VM1) konfigurierbar sein, beispielsweise eine Eigenschaft, ob ein Zugriff durch den Debugger 102 erlaubt ist oder nicht.
-
Im Beispiel aus 3 kann dem Debugger 102 beispielsweise nur den Zugriff auf Peripheriegeräte, Peripherieschaltkreise und Speicher ermöglicht werden, die zur zweiten virtuellen Maschine VM2 gehören.
-
Der erlaubte Zugriff kann beispielsweise ein Lesezugriff sein. Das kann bedeuten, dass während eines Ausführens der Software der zweiten virtuellen Maschine VM2 ein Tracing ausgeführt werden kann. Das kann zwar bedeuten, dass die Debug-Möglichkeiten eingeschränkt sind, weil beispielsweise ein Single-Stepping usw. nicht zugänglich ist, sondern nur Informationen gewonnen werden können, die mittels Lesezugriff auf VM2-Ressourcen und tracebare Aktivitäten der VM2 erhaltbar sind. Allerdings kann mit dieser Beschränkung (auch auf die zu debuggende zweite virtuelle Maschine VM2 wird kein Schreibzugriff gestattet) kann die Datensicherheit für die erste virtuelle Maschine VM1 (bzw. allgemeiner: für die zu schützende(n) virtuelle(n) Maschine(n)) ermöglicht werden.
-
Anders ausgedrückt wird sichergestellt, dass mit dem Debugger 102 kein Code in die zu debuggende virtuelle Maschine (hier VM2) eingebracht werden kann (in die zu schützende(n) virtuelle(n) Maschine(n), hier VM1, selbstverständlich auch nicht), sondern dass die zu debuggende virtuelle Maschine (hier VM2) beim Debuggen lediglich (z.B. mittels Tracing) beobachtet wird.
-
Das bedeutet, dass auch ein bösartiger Angreifer nicht die Möglichkeit hat, Code in die geschützten virtuellen Maschinen (hier: VM1) oder in die zu debuggende virtuelle Maschine (hier: VM2) einzubringen.
-
In verschiedenen Ausführungsbeispielen kann nach dem Festlegen von Berechtigungen ein Konfigurieren der Tracefunktionen erfolgen (bei 468). Diese Berechtigung kann dem Debugger 102 eingeräumt sein. Die Tracefunktionen können beispielsweise eine Filtergestaltung, Triggerpunkte oder ähnliches betreffen und auf diejenigen Traces beschränkt sein, für die eine Leseberechtigung vorliegt, im beispielhaften Fall aus 3 also z.B. die Traces, welche die zweite virtuelle Maschine VM2 betreffen.
-
Anders ausgedrückt kann das System-on-Chip 300 gemäß verschiedenen Ausführungsbeispielen so gestaltet sein, dass feingranular einstellbar ist, auf welche Register, Peripheriemodule und Speicher das Debug-System 102 Zugriff hat.
-
Sollte der Debug-Vorgang ergeben, dass eine Änderung an der Software der zu debuggenden virtuellen Maschine (der VM2) nötig ist, kann diese beispielsweise offline erfolgen und die geänderte Software mittels des privilegierten Nutzers zu einem späteren Zeitpunkt ins System-on-Chip 300 (hier in die zweite virtuelle Maschine VM2) eingespeist werden.
-
In verschiedenen Ausführungsbeispielen kann der weitere Prozessorkern 334 so eingerichtet sein, dass die zu erteilenden (bzw. zu verweigernden) Zugriffsberechtigungen in der Software hartcodiert sind und nicht beeinflusst werden können.
-
Beispielsweise kann die privilegierte Software zuerst laufen, die Multiplexer-Register einstellen (also z.B., welche Quellen von welchen der virtuellen Maschinen VM tracebar sein sollen), Bits zum Einfrieren der Einstellung setzen (auch die privilegierte Software kann sie anschließend nicht mehr ändern), und dann die Software der zu debuggenden virtuellen Maschine VM und die Debug-Software des Debuggers 102 starten, die alles, was zugänglich ist, ändern kann (was insbesondere Tracing-Funktionalitäten wie Filter, Triggerpunkte usw. betrifft), aber insbesondere nicht mehr die von der privilegierten Software eingestellten Registereinträge/Bits, und auch keinen Code in den virtuellen Maschinen VM.
-
Das heißt, die vorzunehmende Einstellung kann in verschiedenen Ausführungsbeispielen als Teil der Debug-Konfigurations-Software bereitgestellt sein, z.B. als Teil des Codes oder als gespeicherte Daten.
-
In weiteren Ausführungsbeispielen kann die privilegierte Software (die Debug-Konfigurations-Software) zuerst laufen und eingerichtet sein, die vorzunehmende Einstellung als mittels eines authentifizierten Verfahrens erzeugte Daten von einer Quelle außerhalb des System-on-Chip 300 zu erhalten und zu authentizfizieren. Der privilegierte Nutzer kann beispielsweise die vorzunehmende Einstellung bereitstellen.
-
Haupt-Debug-Funktionen während der hierin beschriebenen Integrationsphase betreffen eine Beobachtung (das Tracing) für eine weitergehende Analyse. Diese Funktionen werden, wie oben beschrieben, vom MCDS Trace-System 444 (in Kooperation mit dem Debug-Interface 446 und dem Debugger 102) bereitgestellt, wobei lediglich die virtuelle Maschine VM (hier: VM2), auf welcher die zu debuggende Anwendung installiert ist, für einen Lesezugriff freigegebene Beobachtungspunkte aufweist.
-
Die Register, in welchen die Trace-Konfiguration eingestellt werden kann, sind beispielhaft mit Feldern, Bits, Typen, Beschreibungen usw. in 5 wiedergegeben. Der Übersichtlichkeit halber werden diese Informationen hier nicht wiederholt.
-
Auch Zustands- und Signaltraces können hartcodiert oder flexibel konfigurierbar sein, abhängig von einer Schutzeinstellung des entsprechenden Peripheriemoduls bzw - schaltkreises.
-
In verschiedenen Ausführungsbeispielen kann es ausreichend sein, ausschließlich ein Tracing zum Debuggen zu ermöglichen.
-
In weiteren Ausführungsbeispielen kann es vorteilhaft sein, eine beschränkte Ablaufsteuerungs-Funktionalität bereitzustellen, beispielsweise ein Anhalten der laufenden Prozesse mittels einer Triggerbedingung, die mittels des MCDS 444 setzbar ist. Das kann es ermöglichen, eine weitergehende Analyse von Peripheriemodulen oder -schaltkreisen oder Daten in Speichern im gewählten Zustand zu ermöglichen.
-
Bei einer Gestaltung des System-on-Chip 300 mit der umfassendsten Beschränkung kann die Einstellung so gewählt sein, dass ein Zugriff des Debuggers 102 lediglich auf das MCDS 444 und Speicher, in welchen Traces gespeichert werden, ermöglicht wird.
-
Bei einer Gestaltung des System-on-Chip 300 mit weniger umfassenden Beschränkungen kann die Einstellung so gewählt sein, dass ein Zugriff des Debuggers 102 (welcher beispielsweise als Bus-Master identifizierbar sein kann) dieselben Zugriffs- (z.B. Leserechte) auf Speicher und Peripheriegeräte bzw. -schaltkreise erhält wie die zu debuggende Anwendung, und ggf. zu weiteren Speichern der gewählten virtuellen Maschine (z.B. VM2), z.B. lokalen RAMs o.ä. Das kann beispielsweise mittels Bereitstellens von mindestens einem Bereich der APU für einen speziellen Zugangspfad zum Debuggen ermöglicht werden.
-
Obwohl die Beschreibung sich auf die Verwendung mehrerer virtueller Maschinen VM1, VM2 konzentriert, können Ausführungsbeispiele auch genutzt werden, wenn zwei oder mehr Anwendungen (ohne dass es sich um unterschiedliche virtuelle Maschinen handelt) unterschiedliche Prozessoren nutzen.
-
6 zeigt ein Flussdiagramm eines Verfahrens zum Betreiben eines System-on-Chip, das eine Mehrzahl von Prozessorkernen mit einer Mehrzahl virtueller Maschinen und einen weiteren Prozessorkern aufweist, in einem Debug-Modus gemäß verschiedenen Ausführungsbeispielen.
-
Das Verfahren kann ein Starten des System-on-Chip (bei 610), ein Starten einer Debug-Konfigurations-Software mittels des weiteren Prozessorkerns (bei 620) und ein Vornehmen einer Debug-Einstellung mittels der Debug-Konfigurations-Software, die nach einem Beenden der Debug-Konfigurations-Software einen Zugriff durch eine Debugger-Software auf mindestens eine der virtuellen Maschinen verhindert und einen Zugriff der Debugger-Software auf mindestens eine weitere der virtuellen Maschinen ermöglicht, aufweisen (bei 630).
-
Im Folgenden werden zusammenfassend einige Ausführungsbeispiele angegeben.
-
Ausführungsbeispiel 1 ist ein System-on-Chip. Das System-on-Chip kann eingerichtet sein, in einem Debug-Modus betrieben zu werden, und kann eine Mehrzahl von Prozessorkernen, die eine Mehrzahl virtueller Maschinen aufweisen, einen weiteren Prozessorkern, der eingerichtet ist, im Debug-Modus nach einem Betriebsstart des System-on-Chip zunächst nur eine Debug-Konfigurations-Software zu starten, aufweisen, wobei die Debug-Konfigurations-Software eingerichtet ist, eine Debug-Einstellung vorzunehmen, die nach einem Beenden der Debug-Konfigurations-Software einen Zugriff durch eine Debugger-Software auf mindestens eine der virtuellen Maschinen verhindert und einen Zugriff durch die Debugger-Software auf mindestens eine weitere der virtuellen Maschinen ermöglicht.
-
Ausführungsbeispiel 2 ist ein System-on-Chip gemäß Ausführungsbeispiel 1, wobei der Zugriff als Lesezugriff, beispielsweise auf Tracedaten einer Traceinfrastruktur, erfolgt.
-
Ausführungsbeispiel 3 ist ein System-on-Chip gemäß Ausführungsbeispiel 1 oder 2, wobei die vorzunehmende Einstellung als Teil der Debug-Konfigurations-Software bereitgestellt ist, optional als Teil des Codes oder als gespeicherte Daten.
-
Ausführungsbeispiel 4 ist ein System-on-Chip gemäß Ausführungsbeispiel 1 oder 2, wobei die Debug-Konfigurations-Software eingerichtet ist, die vorzunehmende Einstellung als mittels eines authentifizierten Verfahrens erzeugte Daten von einer Quelle außerhalb des System-on-Chip zu erhalten und zu authentizfizieren.
-
Ausführungsbeispiel 5 ist ein System-on-Chip gemäß einem der Ausführungsbeispiele 2 bis 4, wobei der weitere Prozessorkern ein Hardware-Sicherheitsmodul (HSM) ist.
-
Ausführungsbeispiel 6 ist ein System-on-Chip gemäß einem der Ausführungsbeispiele 1 bis 5, wobei die Debug-Einstellung nach dem Beenden der Debug-Konfigurations-Software unveränderbar ist.
-
Ausführungsbeispiel 7 ist ein System-on-Chip gemäß einem der Ausführungsbeispiele 1 bis 6, wobei die Debug-Einstellung nach dem Beenden der Debug-Konfigurations-Software nur durch einen vertrauenswürdigen Master veränderbar ist.
-
Ausführungsbeispiel 8 ist ein System-on-Chip gemäß Ausführungsbeispiel 7, wobei der vertrauenswürdige Master ein Hardware Bus Master des Hardware-Sicherheitsmoduls ist.
-
Ausführungsbeispiel 9 ist ein System-on-Chip gemäß einem der Ausführungsbeispiele 1 bis 8, welches ferner mindestens ein Register zum Vornehmen der Debug-Einstellung aufweist.
-
Ausführungsbeispiel 10 ist ein System-on-Chip gemäß Ausführungsbeispiel 9 und einem der Ausführungsbeispiele 4 bis 8, wobei nur ein vertrauenswürdiger Master berechtigt ist, mittels der Debug-Konfigurations-Software in das mindestens eine Register zu schreiben.
-
Ausführungsbeispiel 11 ist ein System-on-Chip gemäß Ausführungsbeispiel 9 oder 10, wobei das mindestens eine Register mindestens ein Sperrbit aufweist, welches beim Reset in einen Grundzustand setzbar ist und mittels der Debug-Konfigurations-Software einmalig in einen vorbestimmten Zustand änderbar ist, und wobei die, durch dieses Sperrbit geschützten, Debug-Einstellung unveränderbar ist, wenn das Sperrbit im vorbestimmten Zustand ist.
-
Ausführungsbeispiel 12 ist ein System-on-Chip gemäß einem der Ausführungsbeispiele 9 bis 11, wobei der verhinderte Zugriff auf die mindestens eine virtuelle Maschine im Register als eine Eintragung einer fehlenden Lese- und Schreibberechtigung für einen die mindestens eine virtuelle Maschine betreffenden Adressbereich gestaltet ist.
-
Ausführungsbeispiel 13 ist ein System-on-Chip gemäß einem der Ausführungsbeispiele 9 bis 12, wobei der ermöglichte Zugriff auf die mindestens eine weitere virtuelle Maschine im Register als eine Eintragung Lese- und/oder Schreibberechtigung für einen die mindestens eine weitere virtuelle Maschine betreffenden Adressbereich gestaltet ist.
-
Ausführungsbeispiel 14 ist ein Verfahren zum Betreiben eines System-on-Chip, das eine Mehrzahl von Prozessorkernen mit einer Mehrzahl virtueller Maschinen und einen weiteren Prozessorkern aufweist, in einem Debug-Modus. Das Verfahren kann ein Starten des System-on-Chip, ein Starten einer Debug-Konfigurations-Software mittels des weiteren Prozessorkerns und ein Vornehmen einer Debug-Einstellung mittels der Debug-Konfigurations-Software, die nach einem Beenden der Debug-Konfigurations-Software einen Zugriff durch eine Debugger-Software auf mindestens eine der virtuellen Maschinen verhindert und einen Zugriff der Debugger-Software auf mindestens eine weitere der virtuellen Maschinen ermöglicht, aufweisen.
-
Ausführungsbeispiel 15 ist ein Verfahren gemäß Ausführungsbeispiel 14, wobei der Zugriff als Lesezugriff erfolgt, beispielsweise auf Tracedaten einer Traceinfrastruktur.
-
Ausführungsbeispiel 16 ist ein Verfahren gemäß Ausführungsbeispiel 14 oder 15, wobei die vorzunehmende Einstellung als Teil der Debug-Konfigurations-Software bereitgestellt ist, optional als Teil des Codes oder als gespeicherte Daten.
-
Ausführungsbeispiel 17 ist ein Verfahren gemäß Ausführungsbeispiel 14 oder 15, welches ferner ein Empfangen der vorzunehmenden Einstellung als mittels eines authentifizierten Verfahrens erzeugte Daten von einer Quelle außerhalb des System-on-Chip und ein Authentifizieren der vorzunehmenden Einstellung aufweist.
-
Ausführungsbeispiel 18 ist ein Verfahren gemäß einem der Ausführungsbeispiele 14 bis 17, wobei der weitere Prozessorkern ein Hardware-Sicherheitsmodul (HSM) ist.
-
Ausführungsbeispiel 19 ist ein Verfahren gemäß einem der Ausführungsbeispiele 14 bis 18, wobei die Debug-Einstellung nach dem Beenden der Debug-Konfigurations-Software unveränderbar ist.
-
Ausführungsbeispiel 20 ist ein Verfahren gemäß einem der Ausführungsbeispiele 14 bis 18, wobei die Debug-Einstellung nach dem Beenden der Debug-Konfigurations-Software nur durch einen vertrauenswürdigen Master veränderbar ist.
-
Ausführungsbeispiel 21 ist ein Verfahren gemäß Ausführungsbeispiel 20, wobei der vertrauenswürdige Master ein Hardware Bus Master des Hardware-Sicherheitsmoduls ist.
-
Ausführungsbeispiel 22 ist ein Verfahren gemäß einem der Ausführungsbeispiele 14 bis 21, wobei das System-on-Chip ferner mindestens ein Register zum Vornehmen der Debug-Einstellung aufweist.
-
Ausführungsbeispiel 23 ist ein Verfahren gemäß Ausführungsbeispiel 22 und einem der Ausführungsbeispiele 20 oder 21, wobei nur der vertrauenswürdige Master berechtigt ist, mittels der Debug-Konfigurations-Software in das mindestens eine Register zu schreiben.
-
Ausführungsbeispiel 24 ist ein Verfahren gemäß Ausführungsbeispiel 22 oder 23, wobei das mindestens eine Register mindestens ein Sperrbit aufweist, welches beim Reset in einen Grundzustand setzbar ist und mittels der Debug-Konfigurations-Software einmalig in einen vorbestimmten Zustand änderbar ist, und wobei die, durch dieses Sperrbit geschützten, Debug-Einstellung unveränderbar ist, wenn das Sperrbit im vorbestimmten Zustand ist.
-
Ausführungsbeispiel 25 ist ein Verfahren gemäß einem der Ausführungsbeispiele 22 bis 24, welches ferner ein Eintragen einer fehlenden Lese- und Schreibberechtigung im Register für einen die mindestens eine virtuelle Maschine betreffenden Adressbereich zum Verhindern des Zugriffs auf die mindestens eine virtuelle Maschine aufweist.
-
Ausführungsbeispiel 26 ist ein Verfahren gemäß einem der Ausführungsbeispiele 22 bis 25, welches ferner ein Eintragen einer Lese- und/oder Schreibberechtigung im Register für einen die mindestens eine weitere virtuelle Maschine betreffenden Adressbereich zum Ermöglichen des Zugriffs auf die mindestens eine virtuelle Maschine aufweist.
-
Weitere vorteilhafte Ausgestaltungen der Vorrichtung ergeben sich aus der Beschreibung des Verfahrens und umgekehrt.
