-
Die Offenbarung betrifft ein computerimplementiertes Verfahren zum Ausführen eines nachladbaren Programms auf einem eingebetteten System eines Fahrzeugs und ein Softwareprogramm, das eingerichtet ist, das computerimplementierte Verfahren auszuführen, wenn es auf einem Computer ausgeführt wird. Die Offenbarung betrifft zudem eine Anordnung zum Ausführen des nachladbaren Programms auf dem eingebetteten System des Fahrzeugs.
-
Mit zunehmender Vernetzung der Mobilität durchleben datenbasierte Dienste einen steilen Anstieg bezüglich ihrer Komplexität und Nutzerzahlen. Kernmerkmal solcher Dienste im Mobilitätskontext ist es, dem Nutzer auf Basis von Fahrzeugdaten relevante Funktionalität außerhalb und innerhalb des Fahrzeugs zur Verfügung zu stellen. Die durch die schnelllebige Welt der Consumer Electronics geprägte Erwartungshaltung der Nutzer fordert hierbei eine schnelle Erweiterung von Funktionalitäten in kurzen Update-Zyklen. Der Infrastruktur, welche Fahrzeugdaten für solche Dienste bereitstellt, wird dementsprechend eine sehr hohe Flexibilität abverlangt, um kurzfristig auf neue oder geänderte Anforderungen während der Laufzeit des Fahrzeugs reagieren zu können.
-
Hierdurch ergibt sich die Anforderung, dynamische Programmkomponenten auf sichere Weise auf automobilen Steuergeräten auszuführen. Diese dürfen die sonstigen funktionellen Eigenschaften des Steuergeräts (Systemfunktionen), die in vielen Fällen auch funktionale Sicherheit garantieren, unter keinen Umständen auf unvorhersehbare Weise beeinflussen - und zwar auch, wenn potentiell fehlerhafte oder schadhafte Programmkomponenten auf das Steuergerät nachgeladen werden. Abhängig vom angewendeten Sicherheitsmodell des Steuergeräts sind hier schadhafte Interaktionen auf oder mit dem Rest des Systems nicht akzeptabel.
-
Darüber hinaus darf der Ressourcenbedarf dieser Laufzeitumgebung für die Ausführung dieser flexiblen Softwarekomponenten die zur Verfügung stehenden Ressourcen auf Kleinststeuergeräten nur in dem Maß ausschöpfen, das nicht für andere funktionelle Eigenschaften benötigt wird. Man hat hier zusätzlich mit sehr RAM-, Flash- und CPUrestriktiven Umgebungen zu tun in einer Größenordnung: 10-100 kB RAM und 100-1000 kB Flash, die zur Verfügung gestellt werden können, und 16-100/400MHz. Aufgrund der Tatsache, dass Mikrocontroller, die auf automobilen Steuergeräten zum Einsatz kommen, oft keine Hardwareunterstützung für Virtualisierung mitbringen, stellt dies die Softwarearchitektur vor komplexe Anforderungen. Des Weiteren soll die Sicherheitsrelevanz der Entwicklungstoolkette und die der Ausführungsumgebung voneinander getrennt werden. Dies bedeutet, dass ein onboard-Anteil des Systems, also der Anteil des Systems im Fahrzeug, unabhängig von der möglichen Schadhaftigkeit der nachgeladenen Software die Integrität und Sicherheit der Ausführung garantieren muss.
-
Konkret kann die Möglichkeit von dynamisch ausführbaren isolierten Softwarebausteinen beispielsweise zum Sammeln von Daten, also Datenbereitstellung, Edge-Computing, also offline-Berechnungen und Datensammlung im Gegensatz zu Cloud-Computing, und zur kurzfristigen Realisierung von allgemeiner on-board-Funktionalität, beispielsweise Kundenfunktionen, Bugfixes etc. verwendet werden. Dieses Konzept könnte in der Folge zur „Containerisierung“ der Softwarearchitektur für elektronische Kontrolleinheiten (Electronic Control Units, ECUs), auch Steuergeräte genannt, führen.
-
Im Kontext von automobilen Steuergeräten wird die flexible und isolierte Ausführung von nachladbarer Logik über verschiedene Mechanismen realisiert. Einerseits kommen Virtuelle Maschinen basierend auf Interpreter-Technologie wie die Lua VM, auch Lua Laufzeitumgebung genannt, und auf größeren Steuergeräten JIT-kompilierende (JIT: Just In Time, gerade rechtzeitig) Laufzeitumgebungen wie node.js zum Einsatz. Andererseits werden sogenannte „embedded hypervisors“ eingesetzt. Diese sind typischerweise hardwarespezifisch und stellen konkrete Anforderungen an die jeweilige Hardware- und Softwarearchitektur oder sogar an das verwendete Betriebssystem und sind, auch aus diesen Gründen, sehr aufwendig in ein System zu integrieren. Hierfür werden die Programme meist offline kompiliert und auf das Steuergerät übertragen, wo sie ausgeführt werden. Dies bedeutet jedoch auch, dass die nachladbaren Programme an bestimmte Bibliotheken oder sogar Hardwarearchitekturen gebunden sind. Hier fehlt eine portable, plattformagnostische, also plattformübergreifende oder plattformunabhängige, ressourceneffiziente Lösung, die eine erforderliche Sicherheit im automobilen Kontext garantiert. Zusätzlich benötigen Interpreter-basierte Laufzeitumgebungen und JIT-Compiler in Hinblick auf CPU-Auslastung und RAM-Verbrauch eine große Menge an bereitgestellten Ressourcen, was die Herstellkosten für Steuergeräte und den Energieverbrauch erhöht. Neben der Betrachtung der während der Laufzeit benötigten Ressourcen benötigen diese Lösungen für den Aufstart/Launch/Inbetriebnahme oft mehr Ressourcen als auf den meisten automobilen Steuergeräten überhaupt verfügbar sind. Zusätzlich sind diese Laufzeitumgebungen für eine konkrete Programmiersprache entwickelt worden, beispielsweise Lua im Fall der Lua VM und JavaScript bei node.js.
-
Ein anderer verwendeter Lösungsansatz für das grundsätzliche Problem der dynamischen Ausführung von Logik besteht darin, dass eine vordefinierte Menge Berechnungs- und Datensammelvorschriften monolithisch bei der Programmierung des Steuergeräts („flashing“) auf dem Steuergerät hinterlegt wird und durch entsprechende Konfigurationsdateien over-the-air im Nachhinein aufgerufen werden kann. Dies bedeutet jedoch, dass jegliche Berechnung, die sich nicht in dieser vordefinierten Menge an Vorschriften befindet, nur durch Neuprogrammierung des Steuergeräts ausgeführt werden kann. Sehr ressourcenbeschränkte Steuergeräte für den mobilen Einsatz sind demnach grundsätzlich auf eben diese Implementierung beschränkt: Eine native Implementierung einer Menge an Funktionen, die over-the-air konfiguriert werden kann, mit entsprechend geringen Ressourcenanforderungen und gleichzeitig hoher Performanz, jedoch aufgrund der statischen Programmierung der Funktionen sehr eingeschränkter Flexibilität durch die Tatsache, dass das Erweitern dieser Funktionalität im Nachhinein nur mit hohem Aufwand möglich ist. Aufgrund der begleitenden, hier potentiell notwendigen, zeitintensiven und teuren Test-, Zertifizierungs- und Absicherungsprozesse bringt diese Lösung eine lange Zeit bis zur Marktreife mit sich, die für die beschriebenen Einsatzgebiete inakzeptabel ist.
-
Andererseits ist eine Codebasis von Virtuellen Maschinen und JIT-Compilern so komplex, beispielsweise benötigt node.js basierend auf Google's V8 Engine mehrere Millionen Zeilen Code, dass der Code nicht mehr effizient überprüft (reviewed) werden kann. Das bedeutet, dass für eine Integration solch einer Lösung in ein Steuergerät erst recht wieder entweder ein eigener physischer dedizierter Prozessorkern, der eine entsprechende Isolation und Querwirkungsfreiheit garantiert, oder eben andere Hardwarevirtualisierungsmerkmale (features), die durch den Mikrocontroller oder die Peripherie zur Verfügung gestellt werden, benötigt werden. Beides soll aus Kostengründen auf einfachen automobilen Steuergeräten vermieden werden.
-
Es ist eine Aufgabe der Erfindung, eine programmiersprachenunabhängige einheitliche, portable und einfache Repräsentation eines Programms bereitzustellen, die zur ressourceneffizienten und sicheren Ausführung flexibel nachladbarer Programme auf einem eingebetteten System eines Fahrzeugs verwendet werden kann. Insbesondere ist eine Aufgabe der Erfindung, ein Verfahren zum Ausführen eines nachladbaren Programms auf einem eingebetteten System eines Fahrzeugs bereitzustellen, das die sichere und zuverlässige Ausführung des Programms auf einfache und kostengünstige Weise ermöglicht.
-
Diese Aufgabe wird durch den Gegenstand der unabhängigen Ansprüche gelöst. Vorteilhafte Ausgestaltungen der Erfindung sind in den Unteransprüchen angegeben.
-
Bei dem erfindungsgemäßen computerimplementierten Verfahren zum Ausführen eines nachladbaren Programms auf einem eingebetteten System eines Fahrzeugs wird Code in einer Programmierhochsprache durch einen standardisierten ersten Compiler für die Programmierhochsprache übersetzt in einen stackbasierten, statisch validierbaren und strikt typisierten Befehlssatz zur Repräsentation des Programms. Der Befehlssatzes wird durch eine Trusted Computing Base in Form einer Laufzeitumgebung unabhängig von einer Unterstützung für eine Hardwarevirtualisierung, einer Funktion für die Hardwarevirtualisierung oder einer Anforderung an ein Betriebssystem des eingebetteten Systems des Fahrzeugs ausgeführt, wobei der Befehlssatz statisch validiert, installiert und auf dem eingebetteten System des Fahrzeugs ausgeführt wird.
-
Unter einem eingebettetem System (embedded system) wird ein elektronischer Rechner oder auch Computer verstanden, der in einen technischen Kontext eingebunden, also eingebettet ist. Dabei übernimmt der Rechner entweder Überwachungs-, Steuerungs- oder Regelfunktionen oder ist für eine Form der Daten- bzw. Signalverarbeitung zuständig, beispielsweise beim Ver- bzw. Entschlüsseln, Codieren bzw. Decodieren oder Filtern. Im Kontext eines Fahrzeugs stellt eine elektronische Kontrolleinheit (Electronic Control Unit, ECU), auch Steuergerät genannt, ein eingebettetes System eines Fahrzeugs dar. Funktionalitäten, die mit einem nachladbaren Programm auf dem eingebetteten System des Fahrzeugs abgebildet werden können, umfassen beispielsweise ein dynamisches Datensammeln, wobei z.B. nach einer Auslieferung eines Fahrzeugs over-the-air, also drahtlos, ein Programm auf dem Steuergerät im Fahrzeug installiert wird, das entweder periodisch oder z.B. Event-basiert, beispielsweise bei Erkennen bestimmter Fahrzeugzustände oder Fehlerzustände, bestimmte Signale auf dem Steuergerät entweder an ein anderes Steuergerät über das Fahrzeugbordnetz weiterleitet oder an einen Backend-Server bzw. in die Cloud schickt, Machine-Learning auf dem Steuergerät, z.B. als konkretes Lernen oder auch bloßes Auswerten von Daten mit bestehenden neuronalen Netzen, Apps, also Applikationen, auch Anwenderprogramme genannt, die Nutzerfunktionalität abbilden, z.B. ein Laden von Updates zum Einbinden von Handys und/oder Smartphones in eine Freisprecheinrichtung eines Fahrzeugs, die bei Übernahme des Fahrzeugs noch nicht auf dem Markt waren.
-
Der Begriff Fahrzeug umfasst PKW, LKW, Busse, Wohnmobile, Krafträder, etc., die der Beförderung von Personen, Gütern, etc. dienen. Insbesondere umfasst der Begriff Kraftfahrzeuge zur Personenbeförderung. Ergänzend oder alternativ kann das Hybrid- oder Elektrofahrzeug gemäß Ausführungsformen ein reines Elektrofahrzeug (BEV) oder ein Plugin-Hybridfahrzeug (PHEV) sein. Es können jedoch auch andere Antriebsformen verwendet werden, beispielsweise in Form eines diesel- oder benzinbetriebenen Fahrzeugs. Das Fahrzeug kann auch in Form eines Schienenfahrzeugs vorliegen.
-
Code in einer Programmierhochsprache kann in C, C++ oder Rust vorliegen, wobei andere Programmierhochsprachen möglich sind. Stackbasiert bedeutet, dass Variablen des Befehlssatzes hauptsächlich über einen sogenannten „Stack“, also Stapel, gehandhabt werden, d.h. jede Interaktionen mit verwendeten Variablen passiert auf diesem Variablenstapel. Im Allgemeinen kann jeweils nur mit den obersten Variablen des Stacks interagiert werden, so dass ein Variablenzugriff einem LIFO (Last-in-first-out) Prinzip folgt. Statisch validierbar bedeutet, dass die Integrität des Programms durch formale Methoden zur Validierung der Struktur des Programms überprüft werden kann. Dieser Prozess wird im Allgemeinen vor der Ausführung des Programms durchlaufen, sodass fehlerhaft strukturierte Programme direkt verworfen und nicht ausgeführt werden. Die Trusted Computing Base, auch TCB genannt, eines Computersystems ist die Gesamtheit aller Hardware-, Firmware- und/oder Softwarekomponenten, die für die Sicherheit des Systems entscheidend sind. Fehler oder Schwachstellen, die innerhalb der TCB auftreten, können die Sicherheitseigenschaften des gesamten Systems gefährden. Die TCB umfasst die Menge an Quellcode, der eine Komponente des Computersystems vertrauen muss. Die Laufzeitumgebung (runtime environment, RTE), auch Ausführungsumgebung oder seltener Ablaufumgebung genannt, beschreibt die zur Laufzeit von Computerprogrammen verfügbaren und festgelegten Voraussetzungen eines bestimmten Laufzeitsystems (runtime system). Dieses ist durch die elementaren Bestandteile der Programmiersprache wie das Verhalten von Sprachkonstrukten und weitere Funktionen wie Typprüfung, Debugging, Codegenerierung und -optimierung definiert. Zur Laufzeitumgebung gehören weiterhin Laufzeitbibliothek, Standardbibliotheken, Programmierschnittstellen, Laufzeitvariablen sowie auf Hard- und Softwarekomponenten über Betriebssystemfunktionen.
-
Mit dem erfindungsgemäßen Verfahren wird eine stackbasierte Virtuelle Maschine als plattformübergreifende Trusted Computing Base (TCB) für ressourcenbeschränkte Steuergeräte zur Verfügung gestellt. Ein stackbasierter Befehlssatz wird als Compiler-Ziel für einen standardisierten Compiler verwendet. Dieser standardisierte Compiler nutzt eine Programmierhochsprache wie C, C++ oder Rust und übersetzt Code von dieser Programmiersprache in eine stackbasierte Sprache bzw. Repräsentation von Programmlogik des nachzuladenden Programms. Dies erlaubt eine standardisierte Entwicklungstoolkette. Der resultierende stackbasierte Befehlssatz wird auf dem eingebetteten System, z.B. einem Steuergerät, durch die Trusted Computing Base ohne Unterstützung und Funktionen für eine Hardwarevirtualisierung oder konkrete Anforderungen an das unterliegende Betriebssystem, z.B. das des eingebetteten Systems, wenn auf diesem System die Trusted Computing Base ausgeführt wird, ausgeführt.
-
Zur Repräsentation von Programmen wird ein statisch validierbarer, strikt typisierter, virtueller Befehlssatz (instruction set) verwendet, der inhärent eine sichere Ausführung des Programms und eine Isolation des Programms von anderen Hard- und Softwarekomponenten des eingebetteten Systems, die durch das nachgeladene Programm nicht angesprochen/beeinflusst werden sollen, garantiert. Ein Programm in einer portablen Repräsentation dieses Befehlssatzes, z.B. Bytecode, wird auf das eingebettete System geladen. Der Bytecode wird definiert als eine Sammlung von Befehlen für eine virtuelle Maschine, wobei bei einer Kompilierung eines Quelltextes mancher Programmiersprachen oder Umgebungen, wie Java, nicht direkt Maschinencode, sondern ein Zwischencode, der Bytecode, erstellt wird. Der Bytecode ist in der Regel unabhängig von realer Hardware und entsteht als Resultat einer semantischen Analyse des Quelltexts und ist im Vergleich zu diesem oft relativ kompakt und wesentlich effizienter interpretierbar als der originale Quelltext. Der Befehlssatz wird, z.B. von einem Entwickler, durch einen ersten Compiler, der stromaufwärts oder der Trusted Computing Basse vorgelagert und außerhalb des Fahrzeugs, also offboard, angeordnet ist, aus der Computerhochsprache erzeugt. Auf dem eingebetteten System oder außerhalb des Fahrzeugs wird dieses Programm nach einfachen vorgegebenen Regeln statisch validiert und auf dem eingebetteten System installiert und ausgeführt.
-
In vorteilhafter Weise wird die Trusted Computing Base als Laufzeitumgebung, auf der ein Interpreter oder ein zweiter Compiler ausgeführt wird, bereitgestellt. Als Interpreter wird ein Computerprogramm bezeichnet, das eine Abfolge von Anweisungen scheinbar direkt ausführt, wobei das Format der Anweisungen vorgegeben ist. Der Interpreter liest dazu eine oder mehrere Quelldateien ein, analysiert diese und führt sie anschließend Anweisung für Anweisung aus. Ein Compiler, auch Kompilierer oder Übersetzer genannt, ist ein Computerprogramm, das Quellcode einer bestimmten Programmiersprache, beispielsweise den Befehlssatz, in eine Form übersetzt, die von dem eingebetteten System ausgeführt werden, also in Maschinencode.
-
Eine erste Ausführungsform der TCB ist eine Laufzeitumgebung basierend auf Interpretertechnologie, also eine Laufzeitumgebung, auf der ein Interpreter ausgeführt wird oder die einen Interpreter neben möglicherweise anderen Softwaremodulen umfasst. Der Interpreter kann in portablem Standard C-Programmcode entwickelt sein, ohne besondere Rücksichtnahme auf eine konkrete Prozessorarchitektur. Der Interpreter kann RAM-Verbräuche (RAM: Random Access Memory, Speicher mit willkürlichem Zugriff) nahe denen von nativen, direkt zum Prozessorbefehlssatz kompilierten, Softwaremodulen erreichen. In einer alternativen Ausführungsform kann die TCB als einfacher zweiter Compiler mit beschränkten Optimierungsverfahren ausgeführt werden. Der einfache zweite Compiler kann als optimierender oder nicht optimierender Einzelpass- oder alternativ Multipass-Compiler ausgeführt sein. Der zweite Compiler erbringt als einfacher Compiler Performanz sowohl in Hinblick auf Laufzeit als auch Speichereffizienz in Größenordnungen von nativen Implementierungen. In der Ausführungsform als einfacher zweiter Compiler ist die Implementierung im Gegensatz zur Ausführungsform als Interpreter aufgrund der Bindung an den konkreten Befehlssatz des Zielprozessors zum Teil CPU-spezifisch (CPU: Central Processing Unit, zentrale Verarbeitungseinheit) und muss für weitere CPU-Architekturen entsprechend angepasst werden. Beide Ausführungsformen garantieren eine sichere Ausführung des Programms und Speichersicherheit durch ihre korrekte und inspizierbare minimale Implementierung auf dem eingebetteten System des Fahrzeugs.
-
Die Ausführung des Programmes kann also je nach Anforderung des eingebetteten Systems auf zwei Wegen passieren: 1. durch einen Interpreter oder 2. durch einen zweiten on-target Compiler, also auf dem eingebetteten System laufend, oder durch einen zweiten offboard-Compiler, also außerhalb des Fahrzeugs laufend. Die Laufzeitumgebungen, die den Interpreter/den zweiten Compiler umfassen, stellen eine Einhaltung von definierten Vorgaben in Bezug auf RAM und CPU-Anforderungen sicher. Dies bedeutet ein Sandboxing in Hinblick auf Speicherzugriffe und Laufzeit. Eine Sandbox bezeichnet allgemein einen isolierten Bereich, innerhalb dessen jede Maßnahme keine Auswirkung auf die äußere Umgebung hat. Das Programm kann also nur den ihm zugeordneten Speicherbereich verändern und lesen. Jeder Speicherzugriff wird durch die Laufzeitumgebung validiert. Zusätzlich kann die Ausführung des Programmes bei zu langer Laufzeit nach einer vorgegebenen Regel pausiert und zu einem späteren Zeitpunkt wieder fortgesetzt oder abgebrochen werden. Dem Programm kann als Teil der Sandbox Schnittstellen (API Funktionen) zur Kommunikation mit dem Restsystem außerhalb der Sandbox zur Verfügung gestellt werden.
-
Aufgrund der Tatsache, dass ein auf die Notwendigkeiten reduzierter Befehlssatz, auch Instruktionsset genannt, verwendet wird, kann die Implementierung beider Ausführungsformen der Laufzeitumgebung in Bezug auf Code-Umfang und Komplexität so einfach gehalten werden, dass manuelle Reviews und formelle beweisbare Richtigkeit möglich sind. Somit liegt die Trusted Computing Base vor. Durch die Verwendung eines vorgelagerten, beispielsweise hochoptimierenden, ersten Compilers außerhalb des Fahrzeugs in der Toolkette wird mit einem einfachen zweiten Compiler und auch mit einem Interpreter eine hohe Performanz erreicht. Die Zwischenrepräsentation kann so gewählt werden, dass sie Optimierungen des ersten Compilers semantisch darstellen kann.
-
In einer weiteren vorteilhaften Ausführungsform erfolgt vor dem Ausführen des Befehlssatzes durch die Trusted Computing Base in Form der Laufzeitumgebung außerhalb des Fahrzeugs, also offboard, ein Übersetzen des Befehlssatzes und der übersetzte Befehlssatz wird über eine gesicherte erste Datenverbindung an das eingebettete System des Fahrzeugs zum Ausführen des Befehlssatzes durch die Trusted Computing Base in Form der Laufzeitumgebung übertragen. So kann beispielsweise der zweite Compiler zum Übersetzen des Befehlssatzes auch offboard verwendet werden. Ein einfacher zweiter Compiler mit geringsten oder keinen Optimierungen muss nicht auf dem Ziel-Steuergerät als dem eingebetteten System ausgeführt werden, sondern kann offboard verwendet werden. Von dem zweiten Compiler ausgegebener Maschinencode kann über die gesicherte erste Datenverbindung an das eingebettete System des Fahrzeugs übertragen werden und auf dem Ziel-Steuergerät installiert und ausgeführt werden. Auf dem eingebetteten System kann für die Ausführung des übersetzten Befehlssatzes eine Erweiterung der Trusted Computing Base in Form eines minimalen Hypervisors vorhanden sein. Diese Ausführungsform kann als Variation von sogenannter „pre-virtualization“ angesehen werden. Pre-Virtualisierung (pre-virtualization) ist eine Virtualisierungstechnik, bei der, anstatt einen Host manuell zu paravirtualisieren oder zu versuchen, einen Binärcode zur Ladezeit neu zu schreiben, die Vor-Virtualisierung die Ausgabe des Compilers in Assemblersprache neu schreibt, was einen Prozess beschreibt, der als Compiler-Nachbrennen bezeichnet wird. Dies führt zu einem weitgehend automatisierten Prozess, der die ursprüngliche Plattform-API (API: Application Programming Interface, Programmierschnittstelle, die ein Programmteil ist, der von einem Softwaresystem anderen Programmen zur Anbindung an das Computersystem zur Verfügung gestellt wird) beibehält. Dadurch ist die Vor-Virtualisierung im Vergleich zur Para-Virtualisierung kostengünstiger, und es bleibt die Möglichkeit erhalten, eine einzelne Betriebssystem-Binärdatei entweder auf reiner Hardware oder auf einem unterstützten minimalen Hypervisor auszuführen. Zudem wird das eingebettete System von der TCB entbunden, die offboard ausgeführt wird, was vorhandene Ressourcen im eingebetteten System schont.
-
Alternativ zu einer offboard-TCB kann in besonders bevorzugter Ausführungsform das Ausführen des Befehlssatzes durch die Trusted Computing Base in Form der Laufzeitumgebung in dem Fahrzeug, also onboard, erfolgen und der nach dem Übersetzen des Codes in der Programmierhochsprache durch den ersten Compiler offboard vorliegende Befehlssatz kann über eine gesicherte zweite Datenverbindung an das eingebettete System des Fahrzeugs zum Ausführen des Befehlssatzes durch die Trusted Computing Base und zum Installieren und Ausführen des Befehlssatzes auf dem eingebetteten System des Fahrzeugs übertragen werden.
-
Die erfindungsgemäße Lösung kann in zwei Teile geteilt werden: Einerseits die Trusted Computing Base, die die sichere Ausführung des Befehlssatzes in wohldefinierten strikten Grenzen erlaubt. Andererseits standardisierte Schnittstellen zwischen dem nachgeladenen Code, z.B. in Form von maschinenlesbaren Befehlen oder Maschinencode, und dem Hostsystem in Form des eingebetteten Systems, wobei die standardisierten Schnittstellen dargestellt sein können durch eine Menge an API-Funktionen. Eine TCB zeichnet sich dadurch aus, dass sie jenen Teil der Infrastruktur darstellt, dem in vollem Maße vertraut werden kann und eine Codebasis besitzt, die manuell voll inspiziert und auf Sicherheit und Korrektheit überprüft werden kann, potentiell mit einem formellen Beweis der Korrektheit. Der Beitrag der vorliegenden Erfindung ist eine softwarebasierte TCB, die anstelle nur einer eine Virtuelle Maschine unterstützenden Programmiersprache eine Zwischenrepräsentation in Form des Befehlssatzes ausführt, der durch den ersten Compiler von einer Programmierhochsprache übersetzt ist. Der Befehlssatz kann menschenlesbar und hinsichtlich einer Bewertung und Validierung intuitiv sein. Das nachzuladende Programm wird also durch den ersten Compiler von einer Programmierhochsprache übersetzt, wobei das Resultat die Zwischenrepräsentation in Form des Befehlssatzes ergibt, der durch die Laufzeitumgebung effizient ausgeführt und validiert werden kann.
-
Die Installation des Programmes besteht nach erfolgreicher Validierung im Fall des Interpreters aus dem Speichern im Flash-Speicher des eingebetteten Systems, beispielsweise des Steuergeräts. Im Fall des zweiten on-target Compilers besteht die Installation aus der Übersetzung des portablen „virtuellen“ Befehlssatzes/instruction sets, z.B. in Bytecode vorliegend, in den Maschinencode des weiteren Befehlssatzes/weiteren instruction sets der Zielarchitektur des eingebetteten Systems und dem anschließenden Speichern dieses resultierenden Maschinencodes in dem Flash-Speicher. Die Performanz, also Rechenleistung/Rechengeschwindigkeit, der onboard-Compiler-basierten Laufzeitumgebung übersteigt deutlich, beispielsweise um einen Faktor 10 bis 50 höher/schneller, die des onboard Interpreters. Ein Speicherverbrauch an Flash-Speicher des eingebetteten Systems ist bei beiden Ausführungsformen Interpreter, zweiter Compiler ähnlich gering. Die Implementierung des zweiten Compilers ist jedoch im Allgemeinen CPU-spezifisch, also abhängig von einer Art einer CPU des eingebetteten Systems. Dies impliziert, dass je eine Variante mit dem zweiten Compiler für jede der verschiedenen Mikrocontroller-Architekturen und der verschiedenen weiteren instruction sets auf den verwendeten eingebetteten Systemen/Steuergeräten entwickelt wird. Der Interpreter innerhalb des Fahrzeugs ist dagegen im Allgemeinen portabel und kann für eine jeweils vorliegende Architektur des eingebetteten Systems kompiliert werden.
-
In einem konkreten Anwendungsfall wird damit gerechnet, dass auf einem eingebetteten System/Steuergerät eine große Anzahl an parallel aktiven Programmen installiert ist. Die Laufzeitumgebung kümmert sich somit zusätzlich um das Scheduling/die zur Ausführung sämtlicher Programme erforderliche Verteilung von CPU-Zeit unter den Programmen und um das Memory Management, also eine Verteilung von Speicherbereichen auf die Programme. Dies führt zu virtuellen Nanoprozessen, die auch ohne Betriebssystem parallel und sicher parallel zueinander von der TCB/Laufzeitumgebung im Fahrzeug, oder im Fall eines unterliegenden Betriebssystems innerhalb eines einzelnen Prozesses, ausgeführt werden können. Dies impliziert, dass bei sich verändernder Anzahl an auszuführenden Skripten keine Anpassungen des globalen Schedulers getroffen werden müssen. Bei Unterschreitung von minimalen verfügbaren Ressourcenanforderungen pro Skript kann über die festgelegte Priorität von einzelnen Skripten/Programmen eine Reihung/Reihenfolge getroffen und unwichtigere Skripte/Programme können von der TCB/Laufzeitumgebung pausiert oder gestoppt werden.
-
Mit Vorteil erfolgt das Ausführen des Befehlssatzes durch die Trusted Computing Base in Form der Laufzeitumgebung derart, dass eine Virtuelle Maschine mit einem generischen Sprachumfang in Form einer Befehlssatzarchitektur einer virtuellen CPU verwendet wird, wobei die Virtuelle Maschine eine definierte API-Schicht zur Regelung eines Zugriffs auf ein Hostsystem nutzt. Zur Ausführung des flexibel nachladbaren Programms wird eine Virtuelle Maschine mit einem generischen Sprachumfang verwendet. Als generischer Sprachumfang kann in Form einer Befehlssatzarchitektur (Instruction Set Architecture, ISA) als abstrakte Beschreibung der Verhaltensweise eines Rechners in Bezug auf seinen Befehlssatz, wobei die Befehlssatzarchitektur so formuliert ist, dass sie unabhängig von einer bestimmten Implementierung ist, vorliegen. Insbesondere kann der generische Sprachumfang in Form der Befehlssatzarchitektur einer virtuellen CPU) vorliegen. Die Virtuelle Maschine nutzt eine definierte API-Schicht, die den Zugriff, insbesondere jeden einzelnen Zugriff, auf das Hostsystem, das offboard oder in Form des eingebetteten Systems onboard vorliegen kann, regelt. Die Virtuelle Maschine wird durch das Hostsystem in Ihrem Speichermanagement und in ihrer maximalen Laufzeit für die Ausführung einer Funktion begrenzt. Die Befehlssatzarchitektur (ISA) kann sich auf einen Rechner mit reduziertem Befehlssatz (Reduced Instruction Set Computer, RISC) beziehen. Der Rechner mit reduziertem Befehlssatz ist eine Designphilosophie für Computerprozessoren, wobei das Designziel ein Verzicht auf einen komplexen, für eine Assemblerprogrammierung komfortablen Befehlssatz hin zu einfach zu dekodierenden und extrem schnell auszuführenden Befehlen war, was zudem höhere Taktfrequenzen ermöglichte. Die Befehlssatzarchitektur weist somit nur eine geringe Anzahl von Befehlen auf und erlaubt offboard oder onboard eine Implementierung und Integration mit einem kleinen Flash-Footprint und einem einfachen Code-Umfang. Als Flash-Footprint wird ein Speicherbedarf bezeichnet, den ein Programm im Programmspeicher einnimmt.
-
In vorteilhafter Ausführungsform wird die Trusted Computing Base für eine standardisierte Compiler-Toolkette, beispielsweise die standardisierte Compiler-Toolkette von WebAssembly, entwickelt. Für den Fall, dass die Trusted Computing Base für die standardisierte Compiler-Toolkette von WebAssembly entwickelt und die Trusted Computing Base als Laufzeitumgebung mit dem zweiten Compiler onboard bereitgestellt wird, kann ein zu dem Übersetzen des Codes in der Programmierhochsprache durch den ersten Compiler in den Befehlssatz zusätzlicher Übersetzungsschritt ausgeführt werden, um einen optimierten WebAssembly-Befehlssatz an den zweiten Compiler übertragen zu können.
-
Die TCB kann also für eine standardisierte Compiler-Toolkette wie WebAssembly, abgekürzt Wasm, entwickelt werden. WebAssembly ist ein Bytecode zur Ausführung in Webbrowsern, wobei ein Ziel der Entwicklung eine schnelle Ergänzung zu JavaScript ist, sowohl was Ladezeiten als auch die Ausführung betrifft. Daher zielt WebAssembly ursprünglich auf größere Systeme als eingebettete Systeme von Fahrzeugen ab, beispielsweise Desktopcomputer oder Server, mit geringeren Trust-Anforderungen als für Fahrzeuge erforderlich oder auf solche Systeme ab, die eine Unterstützung für eine Separierung von Laufzeitprozessen und/oder Hardwarevirtualisierung bieten. WebAssembly als stackbasierte Beschreibungssprache von Programmlogik weist Ähnlichkeiten zu der niedrigsten Zwischenrepräsentation (intermediate-representation) eines Compilers auf und kann daher effizient durch den ersten Compiler generiert werden, als auch effizient durch die Laufzeitumgebung ausgeführt werden. Die erfindungsgemäße Implementierung mit WebAssembly benötigt aufgrund des vom Umfang her kleinen Wasm-Befehlssatzes nur einen kleinen Umfang an Code-Zeilen und ist demnach einfach manuell inspizierbar, d.h. der konkrete Code der Laufzeitumgebung ist reviewbar, verifizierbar und auf formelle Richtigkeit überprüfbar. Die Implementierung mit WebAssembly kann einen zusätzlichen Kompilierungsschritt mit sich bringen, um den zweiten onboard Compiler in einfacher Ausführung, z.B. als Einzelpass-Compiler, zu ermöglichen. Die Verwendung eines existierenden industrialisierten Standards wie Wasm erlaubt, das vorgestellte Konzept einer TCB in der Praxis schneller zu implementieren und auf Steuergeräten zum Einsatz zu bringen.
-
WebAssembly bietet also aufgrund seiner Eigenschaften, nämlich Sandboxing, portabel, RISC, statisch validierbar, Vorteile bei einer Ausführung auf eingebetteten Systemen für Fahrzeuge. Zusätzlich lässt sich WebAssembly einfach und effizient in den nativen Maschinencode für die Ziel-Architektur des eingebetteten Systems übersetzen. Die Übersetzung läuft bevorzugt im Fall der Anwendung für ein Kraftfahrzeug auf dem Steuergerät des Kraftfahrzeugs ab. Die Laufzeitumgebung ist durch code-review und Absicherung sicher und stellt sicher, dass die Ausführung eines validierten WebAssembly Moduls ebenso sicher ist. Falls man das WebAssembly Modul direkt in Maschinencode umwandelt und den Maschinencode dann auf das Steuergerät überspielt, müsste man zur garantierten Sicherstellung von Sandboxing eine ggf. aufwendige Analyse bzw. Binärübersetzung (binary translation) zur Isolierung von Softwarefehlern (software fault isolation) des Maschinencodes durchführen. Roher Maschinencode kann ohne entsprechende Vorkehrungen grundsätzlich ungesicherte Speicherzugriffe ausführen und den Rest des eingebetteten Systems beeinflussen. Durch die Abstraktion durch WebAssembly hat man eine zusätzliche Sicherheitsschicht und macht somit das Programm selbst (WebAssembly) zu einem nicht-sicherheitskritischen Element, wobei die Sicherheit durch die Laufzeitumgebung sichergestellt wird. WebAssembly weist zusätzlich durch die Standardisierung durch W3C und der Unterstützung von Browsern eine Auswahl an Tools auf und garantiert Zukunftssicherheit. Die erfindungsgemäße Verwendung von WebAssembly kann folglich durch Compilerhinweise (compiler hints), Precompiler, auch Präkompilierer, Präcompiler, Vorkompilierer oder Vorübersetzer genannt, der ein Computerprogramm in der Softwareentwicklung ist, das einen Quellcode in einem Durchlauf vor dem eigentlichen Compiler bearbeitet (pre-compiler) und/oder WebAssembly Micro Runtime (WAMR), die eine eigenständige WebAssembly (WASM)-Laufzeitumgebung mit geringem Speicherbedarf ist, (micro-wasm) weiter vereinfacht werden.
-
Die Erfindung umfasst auch Softwareprogramm, das eingerichtet ist, das erfindungsgemäße computerimplementierte Verfahren auszuführen, wenn es auf einem Computer ausgeführt wird, wobei der Computer vorzugsweise Teil des eingebetteten Systems in Form einer elektronischen Kontrolleinheit des Fahrzeugs, eines mit dem Fahrzeug verbundenem Backend-Servers oder eines verteilten Computersystems ist, von dem vorzugsweise ein Teil in einem Cloud-Computersystem angeordnet ist. Das Softwareprogramm kann eingerichtet werden, um auf einem oder mehreren Prozessoren ausgeführt zu werden, und um dadurch das erfindungsgemäße Verfahren auszuführen. Das Softwareprogramm kann auf einem oder mehreren Speichermedien gespeichert sein.
-
Die Erfindung umfasst auch eine Anordnung zum Ausführen eines nachladbaren Programms auf einem eingebetteten System eines Fahrzeugs. Es umfasst einen ersten Compiler, der eingerichtet zum Übersetzen von Code in einer Programmierhochsprache durch den standardisierten ersten Compiler für die Programmierhochsprache in einen stackbasierten, statisch validierbaren und strikt typisierten Befehlssatz zur Repräsentation des Programms. Es umfasst weiter eine Laufzeitumgebung, die eingerichtet zum Ausführen des Befehlssatzes durch eine Trusted Computing Base in Form der Laufzeitumgebung unabhängig von einer Unterstützung für eine Hardwarevirtualisierung, einer Funktion für die Hardwarevirtualisierung oder einer Anforderung an ein Betriebssystem des eingebetteten Systems des Fahrzeugs, wobei der Befehlssatz statisch validiert wird, und das eingebettete System, das eingerichtet zum Installieren und Ausführen des von der Laufzeitumgebung ausgeführtem Befehlssatzes auf dem eingebetteten System des Fahrzeugs.
-
Die erfindungsgemäße Anordnung weist dem erfindungsgemäßen Verfahren entsprechende Vorteile und Effekte auf. Der erste Compiler, die Laufzeitumgebung und das eingebettete System können als separate Funktionseinheiten oder als integrierte Funktionseinheiten, beispielsweise die Laufzeitumgebung integriert in das eingebettete System in Form der elektronischen Kontrolleinheit des Fahrzeugs, vorliegen.
-
Der Befehlssatz kann in Bytecode, beispielsweise in WebAssembly, wie oben erwähnt vorliegen. Die Programmierhochsprache, auch höhere Programmiersprache genannt, kann wie oben erwähnt in C, C++ oder Rust vorliegen.
-
Ausführungsbeispiele der Offenbarung sind in den Figuren dargestellt und werden im Folgenden näher beschrieben. Es zeigen:
- 1 eine schematische Anordnung zum Ausführen eines nachladbaren Programms auf einem eingebetteten System eines Fahrzeugs gemäß einer ersten Ausführungsform der Erfindung,
- 2 ein schematisches Flussdiagramm mit Schritten zur Ausführung des erfindungsgemäßen Verfahrens, wobei auf einer Laufzeitumgebung im Fahrzeug ein Interpreter ausgeführt wird, gemäß einer zweiten Ausführungsform der Erfindung,
- 3 ein schematisches Flussdiagramm mit Schritten zur Ausführung des erfindungsgemäßen Verfahrens, wobei auf einer Laufzeitumgebung im Fahrzeug ein Compiler ausgeführt wird, gemäß einer dritten Ausführungsform der Erfindung, und
- 4 ein schematisches Flussdiagramm zu Übersetzungsschritten des Compilers gemäß 3 zur Übersetzung eines in WebAssembly ausgeführten Befehlssatzes in Maschinencode.
-
Im Folgenden werden, sofern nicht anders angegeben, für gleiche und gleichwirkende Elemente gleiche Bezugszeichen verwendet.
-
1 zeigt die erfindungsgemäße Anordnung zum Ausführen eines nachladbaren Programms auf einem eingebetteten System 2, beispielsweise ein Steuergerät, auch ECU genannt, eines Fahrzeugs 1 in einer ersten Ausführungsform. Die Anordnung umfasst einen ersten standardisierten Compiler 6, der eingerichtet ist, Code 5 in einer Programmierhochsprache wie C, C++ oder Rust in einen stackbasierten, statisch validierbaren und strikt typisierten Befehlssatz 7, der beispielsweise in Bytecode, insbesondere WebAssembly, vorliegen kann, zur Repräsentation des Programms in einem Übersetzungsschritt 6' zu übersetzen. Der erste Compiler 6, der Code 5 in der Programmierhochsprache und der durch den ersten Compiler 6 übersetzte Befehlssatz 7 liegen außerhalb des Fahrzeugs 1, also offboard, beispielsweise auf einem Backend-Server 3 vor. Von dem Backend-Server 3 wird der nach dem Übersetzen 6' des Codes 5 in der Programmierhochsprache durch den ersten Compiler 6 offboard vorliegende Befehlssatz 7 über eine gesicherte Datenverbindung an das eingebettete System 2 des Fahrzeugs 1 zum Ausführen des Befehlssatzes 7 durch eine Trusted Computing Base, z.B. in Maschinencode 15 bei Verwendung eines zweiten Compilers, und zum Installieren und Ausführen des interpretierten oder kompilierten Befehlssatzes 7 auf dem eingebetteten System 2 des Fahrzeugs 1 übertragen, 8'.
-
Die Anordnung umfasst weiter als Trusted Computing Base eine auf dem eingebetteten System 2 installierte Laufzeitumgebung 9 zum Ausführen des Befehlssatzes 7 unabhängig von einer Unterstützung für eine Hardwarevirtualisierung, einer Funktion für die Hardwarevirtualisierung oder einer Anforderung an ein Betriebssystem des eingebetteten Systems 2 des Fahrzeugs 1, wobei der Befehlssatz 7 statisch validiert wird. Das im Fahrzeug 1 angeordnete eingebettete System 2 dient einem Installieren und Ausführen des von der Laufzeitumgebung 9 ausgeführten Befehlssatzes 7 auf dem eingebetteten System 2 des Fahrzeugs 1, wodurch das Programm nachgeladen und ausgeführt wird.
-
2 zeigt schematisch ein Ablaufdiagramm zum erfindungsgemäßen Nachladen eines Programms auf dem eingebetteten System 2 des Fahrzeugs 1, wobei die als Trusted Computing Base auf dem eingebetteten System 2 installierte Laufzeitumgebung im Fahrzeug 1 als Interpreter 9a ausgeführt wird. Beispielsweise: wird der Code 5 in der Programmierhochsprache als C-Programmcode offboard bereitgestellt und in den Befehlssatz 7 in Form einer hochoptimierten Zwischenrepräsentation (Intermediate Representation, IR), z.B. in Webassembly offboard von dem ersten Compiler 6 übersetzt. Es folgt eine Übertragung 8' des Programms/Softwaremoduls zur Trusted Computing Base, abgekürzt TCB, die als Laufzeitumgebung (runtime environment, RTE) auf dem eingebetteten System 2, auch Plattform genannt, mit einer Funktion des Interpreters 9a ausgeführt wird. Auf der TCB erfolgt eine statische Validierung 10' des Programms/Softwaremoduls, dessen Befehlssatz 7 in WebAssembly vorliegt, ohne Ausführung des Programms. Es wird überprüft 11', ob es sich um ein für den Interpreter 9a geeignetes, also valides Modul, sprich Softwaremodul bzw. Programm, handelt. Falls dies nicht der Fall, erfolgt eine Abbruch 12.
-
Falls das Programm/Softwaremodul/Modul valide ist, wird das Softwaremoduls in einem Flash-Speicher des eingebetteten Systems 2 in Form eines Steuergeräts abgelegt, 13'. Anschließend wird der in WebAssembly vorliegende Befehlssatz 7 durch die TCB in Form des Interpreters 9a aus dem Flash-Speicher ausgeführt, 14'. Die TCB umfasst neben dem Interpreter 9a zusätzlich die Funktion der statischen Validierung 10' und der Abbruchfunktion 11', 12, falls kein valides Modul vorliegt.
-
In 3 ist schematisch der Ablauf zum erfindungsgemäßen Nachladen eines Programms auf dem eingebetteten System 2 des Fahrzeugs 1 gezeigt, wobei die als Trusted Computing Base auf dem eingebetteten System 2 installierte Laufzeitumgebung im Fahrzeug 1 als zweiter Compiler 9b ausgeführt wird. Das Ablauf hinsichtlich des Codes 5 in Programmierhochsprache C offboard, dem Befehlssatz 7 in WebAssembly, der Übertragung 8' des Befehlssatzes 7 an die Trusted Computing Base im Fahrzeug 1, der statischen Validierung 10' und der Überprüfung 11', ob ein valides Modul vorliegt, mit Abbruch 12 entspricht dem in Zusammenhang mit 3 erklärten Ablauf mit der Maßgabe, dass die Laufzeitumgebung der TCB nicht als Interpreter 9a, sondern als zweiter Compiler 9b, ausgeführt wird.
-
Falls es sich um ein valides Modul handelt, erfolgt eine Übersetzung/Kompilierung 16' des Programms/Softwaremoduls mittels des zweiten Compilers 9b, der als Einzelpass-(Singlepass) Compiler oder als Compiler mit einfachste Optimierungen wie GucklochOptimierungen (peephole optimizations), also ein mögliches Zusammenfügen von mehreren Befehlen/Instruktionen, vorliegt, also als Compiler ohne komplexe Compiler-/Optimierungsdurchläufe (Compiler-/Optimization-Passes). Der in WebAssembly vorliegend Befehlssatz 7 wird also von dem zweiten einfachen Compiler 6 in Maschinencode/Kompilat 15 übersetzt/kompiliert. Das Kompilat wird in einem Flash-Speicher des eingebetteten Systems 2 in Form eines Steuergeräts abgelegt und so auf dem eingebetteten System 2 installiert, 17'. Anschließend erfolgt eine direkte Ausführung 18' des Maschinencodes/Kompilats aus dem Flash-Speicher, also ein Ausführen des von der Laufzeitumgebung 9b ausgegebenen Maschinencodes 15 auf dem eingebetteten System 2 des Fahrzeugs 1. Die TCB umfasst neben dem Interpreter 9a zusätzlich die Funktion der statischen Validierung 10' und der Abbruchfunktion 11', 12, falls kein valides Modul vorliegt. Die TCB umfasst neben dem zweiten Compiler 9b zusätzlich die Funktion der statischen Validierung 10' und der Abbruchfunktion 11', 12, falls kein valides Modul vorliegt.
-
4 zeigt ein schematisches Flussdiagramm mit Übersetzungsschritten des Compilers 9a gemäß 3 zur Übersetzung eines in WebAssembly ausgeführten Befehlssatzes in Maschinencode.
-
Das Ziel der Compilerlogik des zweiten Compilers 9b, die im Folgenden aufgezeigt wird, ist es, eine Lösung für die onboard-Übersetzung/Kompilierung von WebAssembly-Modulen für eingebettete Systeme zur Verfügung zu stellen. Dies bedeutet, dass der Compiler 9b mit bestehenden Einschränkungen und den Grenzen eingebetteter Systeme 2 zurechtkommen muss. Der erfindungsgemäße zweite Compiler sorgt ferner für ein hinsichtlich Sicherheitsvorgaben des eingebetteten Systems 2 angemessenes Sandboxing der resultierenden ausführbaren Programms, mit nur minimaler Compilerlogik, und ist leicht auf andere Befehlssatzarchitekturen portierbar, was die große Vielfalt unterschiedlicher CPU-Architekturen, die in eingebetteten Systemen 2 verwendet werden, hinsichtlich einer Portierbarkeit erfordert. Mit dem zweiten Compiler ist es möglich, dass lediglich ein einziger Kompilierungsdurchlauf/Einzelpass über das Programm verwendet wird.
-
Die Erfinder gehen davon aus, dass die Struktur und die Ähnlichkeit von WebAssembly zu allgemein verwendeten Befehlssatzarchitekturen die meisten Compiler-Optimierungen auf der Schicht von WebAssembly überflüssig macht, sofern die vorgelagerte Compiler-Werkzeugkette, wie LLVM (Low Level Virtual Machine, eine modulare Compiler-Unterbau-Architektur mit einem virtuellen Befehlssatz, einer virtuellen Maschine, die einen Hauptprozessor virtualisiert, und einem übergreifend optimierenden Übersetzungskonzept) mit dem ersten Compiler 6 bereits aggressive Optimierungen durchführt und die meisten davon in die nachgelagerte Onboard-Kompilierung übergehen. Mit Bezug auf 1 wird die übergreifende Werkzeugkette (Toolchain) mit mehreren aufeinanderfolgenden Kompilierungsstufen auf separaten Plattformen ausgeführt. Ein höhersprachiges Programm mit dem Code 5 wird in den Befehlssatz 7 in WebAssembly übersetzt mittels des ersten komplexen Multipass-Optimierungs-Compilers 6. Der resultierende WebAssembly-Binärcode, also Befehlssatz 7, wird dann an das Fahrzeug 1, genau die Zielplattfom in Form des eingebetteten Systems 2 übertragen, wo er wiederum übersetzt wird in den entsprechenden Maschinencode 15 durch die erfindungsgemäßen minimalen Compiler 9b.
-
Theoretisch sollten die Implementierung von nur minimaler Compilerlogik und somit die Ausführung nur derjenigen Optimierungen, die teilweise rückgängig zu machen sind, um die Umwandlung von einer Zwischenrepräsentation wie LLVM IR (IR: Intermediate Representation, Zwischenrepräsentation) in ein gültiges und validierbares WebAssembly-Modul zu ermöglichen, daher in der Lage sein, eine angemessene resultierende Leistung zu liefern bei gleichzeitiger Reduzierung des Speicherbedarfs des zweiten Compilers 9b auf ein Minimum. Konkret wird vorgeschlagen, davon auszugehen, dass die Anwendung des Äquivalents von lediglich Guckloch- (Peephole) Optimierungstechniken und die Zusammenlegung von Befehlen/Anweisungen ausreichen, um eine angemessene Leistung zu liefern.
-
Die Hauptquelle von Overhead bei der Kompilierung von WebAssembly-Modulen ist auf redundante RAM-, genauer, Stapel-Interaktionen (stack interaction) zurückzuführen. Konkret sollte das Speichern und Laden von Registern in und vonaus dem RAM auf ein Minimum beschränkt werden, um den anfallenden Overhead durch Speicherzugriff zu reduzieren. Dies gilt insbesondere für Konstanten, die auf den Stapel/Stack geschoben werden, nur um im nächsten Zyklus für eine Berechnung in ein Register verschoben zu werden.
-
Die erfindungsgemäße Implementierung des zweiten einfachen Onboard-Compilers 9b basiert grundsätzlich auf der Logik, die Googles V8 Liftoff Basis-Compiler verwendet. V8 Liftoff ist ein Singlepass-Compiler, der eine direkte und sequenzielle Codegenerierung kurz nach dem Parsing jeder WebAssembly-Anweisung anstrebt. Der Compiler benutzt einen virtuellen WebAssembly-Stapel, der nur während der Kompilierungsphase existiert. Bei Konstanten zeichnet Liftoff z.B. nur den entsprechenden Wert im virtuellen Stapel/Stack auf und generiert zu diesem Zeitpunkt keinen Code. Wenn diese Konstante dann von einer nachfolgenden WebAssembly-Anweisung verwendet wird, wird konkreter Maschinencode für diesen Vorgang ausgegeben. Dadurch wird vermieden, dass der Wert auf einen tatsächlichen Laufzeit-WebAssembly-Stapel gespeichert werden muss. Gemäß der vorliegenden Erfindung wird die Leistung dieser allgemeinen Strategie weiter verbessert, indem WebAssembly-Anweisungen/Befehle (instructions) auf der Grundlage verschiedener Merkmale klassifiziert werden und somit faule (lazy) Bei-Bedarf- (On-Demand) Compiler-Stapel-Blöcke generiert werden, die nur dann ausgegeben werden, wenn dadurch Nebenwirkungen außerhalb des Kompilierungsstapels auftreten.
-
WebAssembly-Anweisungen weisen bestimmte Merkmale auf, die im Folgenden erörtert werden. Eine Klassifizierung nach diesen Eigenschaften führt zu einem Ansatz für die Implementierung der erfindungsgemäßen Compilerlogik für den zweiten Compiler 9b. Die Klassifizierung der Wertigkeit von WebAssembly-Instruktionen kann entsprechend der so genannten Wertigkeit eines WebAssembly-Instruktion erfolgen. Die Wertigkeit ist in diesem Zusammenhang ein inhärentes Merkmal von WebAssembly-Instruktionen und entspricht der Anzahl der Stapelelemente (stack elements), die eine bestimmte Anweisung verbraucht. Um diese Eigenschaft besser zu veranschaulichen, kann man an die „i32.add“-Anweisung denken. „i32.add“ verbraucht zwei 32-Bit-Ganzzahlwerte vom Stapel/Stack und gibt die Summe dieser Werte als eine einzelne 32-Bit-Ganzzahl auf den Stack zurück. So kann die Wertigkeit als zwei klassifiziert werden, während „i32.sqrt“ eine Wertigkeit von eins aufweist, da es nur ein einziges Stapelelement verbraucht.
-
WebAssembly-Anweisungen können als zu nebenwirkungsbehaftet oder als nebenwirkungsfrei eingestuft werden. Arithmetische Anweisungen, Typkonvertierungen und ReinterpretationenTypreinterpretationen, die von sich aus nur auf den WebAssembly-Stapel wirken, sind inhärent nebenwirkungsfrei. Nebenwirkungen in diesem Zusammenhang beschreiben Wirkungen, die über Auswirkungen auf den Stapel hinausgehen. Zum Beispiel wirken sich alle numerischen Anweisungen und Anweisungen wie die polymorphen Anweisungen „drop“ und „select“ nur auf Variablen aus, die auf dem Stapel vorhanden sind und somit als nebenwirkungsfrei klassifiziert werden. Umgekehrt weisen Kontrollflussanweisungen wie „br“, „br_if“, „call“ oder solche, die den linearen Speicher (das Lesen aus dem linearen Speicher ist im Wesentlichen noch nebenwirkungsfrei) Nebenwirkungen auf, indem sie sich (modifizierend) auf den linearen Speicherbereich auswirken oder zu einer Verzweigung führen, die wiederum den Programmzähler abändert.
-
Die beschriebene Klassifizierung von WebAssembly-Anweisungen führt zu dem Konzept erfindungsgemäßer Compiler-Stapel-Blöcke. Compiler-Stapel-Blöcke existieren auf dem virtuellen Kompilierungsstapel und manifestieren sich (logisch), sobald eine von einer Nebenwirkung betroffene Anweisung ihre Ausführung verlangt. Jeder Compiler-Stapel-Block besteht aus einer oder mehreren WebAssembly-Anweisungen und stellt eine Abstraktion von lebenden Variablen dar (sei es ein Register oder eine Speicherposition im RAM). Compiler-Stapel-Blöcke können beliebig verschachtelt und gestapelt werden. Zu einem bestimmten Zeitpunkt stellt ein Compiler-Stapel-Block ein einzelnes logisches Stapelelement dar, sobald jede auf dem Stapel vorhandene Anweisung ausgegeben und mit den jeweils benachbarten Anweisungen zusammengeführt wurde. Nachfolgende WebAssembly-Operationen (z.B. arithmetische) wirken sich logisch auf die Compiler-Stapel-Blöcke aus, als wären diese bereits aufgelöst worden. Diese prozedurale Auflösung, also die Ausgabe entsprechendem Maschinencodes, dieser Compiler-Stapel-Blöcke lässt sich durch Rekursion realisieren.
-
Die nachfolgende Abbildung zeigt einen beispielhaften virtuellen Kompilierungsstapel mit 6 Elementen.
-
Sobald eine von einer Nebenwirkung betroffene Anweisung („local.tee“, die in diesem Fall auf eine lokale Variable, die sich derzeit im x86 Register „%r8d“ befindet, ausgerichtet ist), wird die Wertigkeit der auslösenden Anweisung bestimmt. Da die Wertigkeit 1 ist („local.tee“ verbraucht ein Element vom Stack), löst der zweite Compiler 9b der oberste einzelne Compiler-Stapel-Block auf, die in diesem Fall keine Unter-Compiler-Stapel-Blöcke hat und aus drei virtuellen Stapelelementen besteht. Die entsprechende Maschinencodefolge wird dann ausgegeben und die Compiler-Stapel-Block wird vom Stapel genommen. (Compiler-Stapel-Blöcke sind von oben nach unten aufzulösen.) Da „local.tee“ die entsprechende lokale Variable setzt und unmittelbar am Stapel erhält, wird eine get-Anweisung für dieses Zielregister dann auf den virtuellen Stapel zurückgeschoben.
-
Aufgrund der inhärenten Faulheit in diesem Ansatz, die zu nur verzögerter Auflösung und Bei-Bedarf-Auflösung von Compiler-Stapel-Blöcke führt, wartet der zweite Compiler 9b mit der Ausgabe von Maschinencode, bis alle potenziell zusammenführbaren Anweisungen am Stapel verarbeitet und aufgezeichnet worden sind .
-
Sobald eine von Nebenwirkungen behaftete Anweisung angetroffen wird, wird die entsprechende Anzahl von Compiler-Stapel-Blöcken, die der Wertigkeit gerade dieser Anweisung entspricht, aufgelöst. Dies führt zu einer automatischen, strukturierten Guckloch/Peephole-Optimierung. Bei Auflösung der Compiler-Stapel-Blöcke werden die entsprechenden Maschinencode-Befehle/Anweisungen dann in einem Zwischenspeicher im RAM gespeichert und dann in den nichtflüchtigen Programmspeicher, beispielsweise Flash-Speicher geschrieben.
-
Den allgemeinen Kompilierungsprozess zeigt 4. Zu Beginn 20 wird eine Anweisung gelesen, 21, und geprüft, ob die Anweisung eine Nebenwirkung aufweist, 22. Falls dem so ist, wird für die Anweisung und N Compiler-Stapel-Blöcke Maschinencode generiert, 23, wobei N eine ganze Zahl größer oder gleich 1 ist und der Wertigkeit der Anweisung entspricht. Falls die Anweisung nebenwirkungsfrei ist, wird geprüft, ob es sich um eine Kennzeichnung/Label (label) handelt, 24. Falls dem so ist, wird die Kennzeichnung aufgezeichnet, 25. Anderenfalls wird die Anweisung auf den virtuellen Stapel geschoben, 26. Nach Ausführen der Funktionen 23, 25 und 26 wird jeweils, also nach Verarbeitung einer jeweiligen Anweisung stets, geprüft, ob eine Ende des Kompilierungsvorganges des zweiten Compilers 9b vorliegt und damit keine weiteren Anweisungen in WebAssembly zu verarbeiten, also in Maschinencode 15 zu übersetzen, sind, 27. Falls dem so ist, endet das Kompilierungsverfahren, 28.
-
Unter-Compiler-Stapel-Blöcke können rekursiv aufgelöst werden und sind von inneren Einheiten (dem „kleinsten Kind“) zu äußeren Einheiten aufzulösen. Die Ergebnisse der Ausgabe von inneren Unter-Compiler-Stapel-Blöcken werden entweder in einem CPU-Register oder im RAM-Speicher auf dem Laufzeitstapel der ausführbaren Datei gehalten. Ein abstraktes Element, das den Speicherort dieses Ergebnisses repräsentiert, ersetzt dann den Compiler-Stapel-Block auf dem virtuellen Stapel. Weiter außerhalb liegende Compiler-Stapel-Blöcke können dann auf diese variable Abstraktion zugreifen, als ob es sich um ein einfaches Eingabeelement handelt.
-
Alle abstrakten Variablen (Register oder solche im RAM-Speicher), die auf dem virtuellen Stapel vorhanden sind, sind jederzeit auf dem neuesten Stand. Wenn Variablen geändert werden (was eine nebenwirkungsbehaftete Operation bedingt) und gerade diese Variable außerhalb der N Compiler-Stapel-Blöcke auftritt, die während einem bestimmten Kompilierungsschritt auszuführen sind, ist sicherzustellen, dass die der aktuelle Wert (vor der Veränderung der Variable) in dieser Variable separat für die unteren Compiler-Stapel-Blöcke zwischengespeichert wird. Dies geschieht durch Speichern dieser Variable in den Laufzeitstapel oder in ein freies Register. Andernfalls wird ein niedrigerer Compiler-Stapel-Block (was aus der Sicht von WebAssembly einem zeitlich früheren Zugriff entspricht) auf den geänderten Wert zugreifen, anstatt auf der Wert, der vorhanden war, als die Zugriffsabstraktion auf den Stapel geschoben wurde.
-
Zur besseren Veranschaulichung der Auflösung von Compiler-Stapel-Blöcken zeigt die nachfolgende Abbildung ein Beispiel eines WebAssembly-Moduls und dessen virtuelle Stapelzwischenzustände während der Kompilierung, das nach x86_64 AT&T Syntax-Assembler-Code kompiliert wird. Gezeigt ist ein Beispiel für ein WebAssembly-Modul (links), seine entsprechenden virtuellen Stapelzustände während der Kompilierung (Mitte) und der resultierende AT&T-Syntax x86_64-Assembler-Code (rechts)
Speicherbezogenes Sandboxing wird durch den zweiten Compiler 9b garantiert, der zusätzlich zu eigentlichen WebAssembly-Logik Laufzeitkontrollen ausgeben kann. Diese Kontrollen müssen speziell ausgegeben werden für indirekte Funktionsaufrufe, Speicherzugriffe und Stapelinteraktion, um Stapelüberläufe zu verhindern.
-
Während der Kompilierungsphase können WebAssembly-Module gleichzeitig validiert werden. Da bereits Abstraktionen der vorherigen WebAssembly-Anweisungen auf dem virtuellen Stapel aufgezeichnet werden, kann die Integrität des WebAssembly-Moduls leicht validiert werden. Wenn eine Diskrepanz (falscher Typ einer Variablen, Stapelunterlauf oder ein nicht leerer Stapel am Ende einer Kompilierungsfunktion mit einem leeren Rückgabetyp) während der Validierung beobachtet wird, muss das Modul als ungültig angesehen werden, die Kompilierungsphase abgebrochen werden und, falls der Flash-Speicher bereits beschrieben wurde, müssen die entsprechenden Bereiche im Flash als ungültig markiert werden.
-
Erfindungsgemäß werden die meisten Optimierungen, die durch den ersten vorgelagerten Compiler 6 geführt werden, der eine höhere Programmiersprache zu WebAssembly übersetzt, bis zur WebAssembly-Phase bestehen bleiben. Die Kompilierungsstrategie, die in einer knappen Weise erklärt wurde, führt unweigerlich zu einigen Optimierungen, die im Wesentlichen Gucklochoptimierungen darstellen. Auf diese Weise werden Anweisungen zusammengeführt und Speicherzugriffe, die einen erheblichen Teil des Overheads ausmachen, beim Kompilieren von WebAssembly-Modulen über den zweiten Singlepass-Compiler 9b, minimiert.
-
Während der Kompilierungsphase muss der Compiler entscheiden, welche Variablen (WebAssembly-Lokale und Funktionsparameter) in Registern gehalten und welche auf den Stapel ausgelagert werden. Der Einfachheit halber wird erfindungsgemäß die Strategie der Registerzuweisung so grundlegend/einfach wie möglich gehalten. Da der zweite Compiler 9b ein Single-Pass-Compiler ist, sind komplexe Registerzuweisungsstrategien und deren Optimierung nicht möglich, da der Compiler nicht in der Lage ist, die Nutzung der Variablen zu analysieren. Die Argumente der WebAssembly-Funktion werden in definierten Registern gehalten. Die Argumente der Funktion werden wie lokale Variablen behandelt, was aufgrund ihrer inhärenten Veränderlichkeit im Funktionsumfang natürlich ist. Der Compiler führt eine Liste von Registern (für ganze Zahlen und potentiell Gleitkommazahlen) und verwendet diese in der vorgegebenen Reihenfolge für Funktionsargumente und lokale Variablen. Alle Variablen, die über die verfügbaren Register hinausgehen, werden auf dem Laufzeitstapel gehalten. Ein oder zwei zusätzliche Zwischen-Register (scratch register) werden frei gehalten, um die Implementierung bestimmter Operationen zu ermöglichen (zum Beispiel auf x86 jene nicht-kommutativen numerischen WebAssembly-Anweisungen wie „i32.sub“, die eine Konstante als erstes Argument haben).
-
Aufgrund des erfindungsgemäßen Einsatzes der beschriebenen Compiler-Logik des zweiten Compilers 9b auf eingebetteten Systemen 2, sollte der notwendige Speicher auf einen statisch zugewiesenen Teil des RAM beschränkt bleiben. Aufgrund der Tatsache, dass Flash-Speicher auf eingebetteten Systemen 2 in der Regel in atomaren „Pages“ geschrieben wird, wird ein RAM-Bereich von mindestens Flash-Page-Größe für Zwischenspeicherung der resultierenden Maschinencode-Anweisungen statisch reserviert. Aufgrund der sequentiellen Logik dieses zweiten Singlepass-Compilers 9b wird genau dieser Bereich in den Flash-Speicher geschrieben und geleert, sobald er voll oder die Kompilierung beendet ist.
-
Die sequentielle Logik des erfindungsgemäßen Compilers erfordert die Ausgabe von Maschinencode in einer zeitlich nahen Weise zum Parsen einer Bytecode-Anweisung. Abgesehen von Funktionsaufrufen und Rückgaben erlaubt WebAssembly im Allgemeinen auf zwei Arten von Codefluss-Änderungen: Vorwärtssprünge bis zum Ende eines Blocks und Rückwärtssprünge bis zur Kennzeichnung/zum Label einer Schleife. Sowohl Vorwärts- als auch Rückwärtsverzweigungen können nur für aktuell aktive (geöffnete) WebAssembly-Blöcke bzw. -Schleifen ausgeführt werden. Rückwärtssprünge sind relativ einfach auszuführen: Die Adresse des Ereignisses eines solchen Labels wird aufgezeichnet und im Speicher gehalten. Sobald eine Verzweigung zu diesem Label erkannt wird, wird eine (bedingte oder unbedingte) Sprungsanweisung zu dieser Adresse ausgegeben. Das Schließen offener Blöcke folgt einem garantierten LIFO-Mechanismus (Last In First Out, der zuletzt geöffnete Code-Block wird als erster wieder geschlossen) und kann daher leicht durch eine stapelartige Befehlsstruktur/Datenstruktur abgebildet werden.
-
Vorwärts gerichtete Verzweigungen stellen eine größere Unannehmlichkeit für Compiler dar, die nicht die Gesamtheit des resultierenden Maschinecodes im Speicher behalten. Um Flash-Schreibzyklen zu sparen und somit die Lebensdauer des Flash-Speichers auf dem eingebetteten System zu maximieren, wird erfindungsgemäß danach gestrebt, Flash nur in einer strikt sequentiellen Weise zu schreiben. Das bedeutet, dass, sobald eine Maschinencode-Flash-Page geschrieben ist, nicht zurückgegangen und die entsprechende Sprungadresse in diese Seite geschrieben werden kann.
-
Um dies zu überwinden, wird erfindungsgemäß folgende Logik vorgeschlagen: Sobald eine Vorwärtsverzweigung erkannt wird, wird eine Platzhalter für eine Sprunganweisung (bedingt oder unbedingt) an eine noch nicht näher bezeichnete Adresse (vorerst eine vorläufige Null-Adresse) ausgegeben. Wenn die entsprechende Vorwärts-Sprunganweisung geparst wird, während die temporäre Maschinecodeseite noch die Anweisung enthält, die auf diese Adresse zeigt, geht man gemäß Rückwärts-Sprunganweisungen vor und ersetzt einfach den entsprechenden Null-Zeiger mit der Adresse des Vowärts-Sprung-Kennzeichens. Wenn dies nicht der Fall ist, können Vorwärts-Sprunganweisungen als indirekte Sprunganweisungen über eine indizierte Sprungadress-Tabelle realisiert werden.
-
Durch die Nutzung der zuvor erläuterten Prinzipien für das Speicherlayout und dessen Handhabung, insbesondere in Hinblick auf die Ausführung von Vorwärts-Sprunganweisungen, führt dies zu einer gewissen RAM-Adaptivität der erfindungsgemäßen Compilerlogik. Abhängig von der Menge an RAM, die für die temporäre Speicherung der Sprungadress-Tabelle zugewiesen wird, werden Vorwärtssprünge entweder als direkter Sprung zu dieser Adresse oder als ein oder mehrere indirekte Sprünge (indirections) ausgegeben. Der andere Hauptbereich des Compilers, der eine dynamisch wachsende und vom Eingangsbytecode abhängige Größe aufweist und im Speicher gehalten werden muss, ist der virtuelle Bytecode-Compiler-Stapel selbst. Im Hinblick darauf kann man Kompilierungseinheiten vorzeitig auflösen, den resultierenden Maschinencode ausgeben und die entsprechenden Variablen auf dem Laufzeitstapel halten. Durch diese Methode kann man auf Kosten der Laufzeitleistung und der RAM-Nutzung die maximale virtuelle Stapelgröße während der Kompilierung eines WebAssembly-Moduls unter einem bestimmten Maximum halten.
-
Die maximale Höhe des virtuellen Stacks (der während der Kompilierungsphase im RAM liegt) hängt von der Strategie ab, mit der das WebAssembly-Modul vom vorgelagerten ersten Compiler 6 kompiliert wurde. Erfindungsgemäß wurde ein Fall identifiziert, bei dem Compiler eine „local.tee“-WebAssembly-Anweisung ausgeben und die entsprechende Variable lange auf dem Stapel behalten, ohne sie zu verwenden, und auch nicht die zu modifizierende Variable. Dies geschieht, um die Größe des WebAssembly-Moduls zu minimieren, indem eine zusätzliche „local.get“-Anweisung eingespart wird. Dies entspricht der Art und Weise, wie der vorgelagerte erste Compiler 6 lokale Zuweisungen behandelt. Diese beiden Aspekte bieten potenzielle Optimierungsmöglichkeiten durch die Koordination einer solchen Strategie über mehrere Compilerstufen hinweg, ohne dass die Leistung eines hoch optimierenden Compilers oder eines Just-in-Time-Compilers merklich beeinträchtigt wird oder die Größe des WebAssembly-Moduls in relevanter Weise beeinflusst wird. Dies kann daher zu dem Konzept harmonisierter, optimal in einem Durchgang kompilierbarer WebAssembly-Module führen. Diese Optimierungen können auch durch eine weitere separate Compiler-Zwischenstufe nachgelagert zu dem ersten Compiler 6, der WebAssembly-Module erzeugt, durchgeführt werden.
-
Obwohl die Erfindung im Detail durch bevorzugte Ausführungsbeispiele näher illustriert und erläutert wurde, so ist die Erfindung nicht durch die offenbarten Beispiele eingeschränkt und andere Variationen können vom Fachmann hieraus abgeleitet werden, ohne den Schutzumfang der Erfindung zu verlassen. Es ist daher klar, dass eine Vielzahl von Variationsmöglichkeiten existiert. Beispielhaft genannte Ausführungsformen stellen nur Beispiele dar, die nicht in irgendeiner Weise als Begrenzung etwa des Schutzbereichs, der Anwendungsmöglichkeiten oder der Konfiguration der Erfindung aufzufassen sind. Vielmehr versetzen die vorhergehende Beschreibung und die Figurenbeschreibung den Fachmann in die Lage, die beispielhaften Ausführungsformen konkret umzusetzen, wobei der Fachmann in Kenntnis des offenbarten Erfindungsgedankens vielfältige Änderungen beispielsweise hinsichtlich der Funktion oder der Anordnung einzelner, in einer beispielhaften Ausführungsform genannter Elemente vornehmen kann, ohne den Schutzbereich zu verlassen, der durch die Ansprüche und deren rechtliche Entsprechungen, wie etwa weitergehenden Erläuterungen in der Beschreibung, definiert wird.
-
Die unter Bezug auf die dargestellten Ausführungsformen beschriebenen Merkmale der Erfindung, beispielsweise die Verwendung von dem Befehlssatz 7 in WebAssembly bei der Laufzeitumgebung, die den Interpreter 9a ausführt, wie in 2 dargestellt, können auch bei anderen Ausführungsformen der Erfindung, z.B. bei der Verwendung von dem Befehlssatz 7 in WebAssembly mit der Laufzeitumgebung, die den zweiten Compiler 9b ausführt, wie in 3 dargestellt, vorhanden sein, außer wenn es anders angegeben ist oder sich aus technischen Gründen von selbst verbietet.
