Autor: Jens Braunes, PLS Programmierbare Logik & Systeme GmbH<\/p>\n
F\u00fcr die Realisierung sicherheitskritischer Anwendungen ist eine strikte Trennung von Applikationen oder Betriebssystemen, die sich eine gemeinsame Rechnerplattform teilen, unabdingbar. Deshalb r\u00fcckt das Thema Virtualisierung und „Hypervisor“ auch im Embedded-Bereich immer mehr in den Vordergrund. Eine gro\u00dfe Herausforderung vor allem f\u00fcr Entwickler, die sich in einem sehr hardwarenahen Umfeld bewegen.<\/strong><\/p>\n Virtualisierung an sich ist nichts Neues. Im PC- und Serverumfeld wird sie schon seit vielen Jahren erfolgreich eingesetzt. Im Bereich der Embedded-Systeme wurde dem Thema bislang allerdings relativ wenig Beachtung geschenkt. Nachdem mit den immer leistungsf\u00e4higeren Multicore-SoCs mittlerweile gen\u00fcgend Performance zur Verf\u00fcgung steht, um verschiedene Applikationen und Betriebssysteme parallel betreiben zu k\u00f6nnen, zeichnet sich hier inzwischen allerdings eine Trendwende ab.<\/p>\n F\u00fcr Virtualisierungen im Embedded-Bereich gibt es grob unterteilt zwei grundlegende Motivationen: die Trennung echtzeitkritischer von weniger zeitkritischen Anwendungen auf einer gemeinsamen Rechnerplattform und die Gew\u00e4hrleistung der Sicherheit. Hierbei geht es haupts\u00e4chlich darum, weniger sicherheitskritische Anwendungen von sicherheitskritischen Anwendungen zu trennen. Verst\u00e4ndlicherweise ist gerade letzteres Thema mit gr\u00f6\u00dfter Umsicht zu behandeln. Vorf\u00e4lle wie der Chrysler-Hack aus dem Jahr 2015 [1], bei dem Sicherheitsforscher \u00fcber das Internet und eine Schwachstelle im Infotainment-System Zugriff auf so sicherheitskritische Fahrzeugsysteme wie die Bremse erhalten haben, f\u00fchren eindrucksvoll vor Augen, dass eine strikte Kapselung von Funktionalit\u00e4t aus Sicherheitsgr\u00fcnden unabdingbar ist. Dies gilt nicht nur f\u00fcr Automotive-Systeme, sondern auch f\u00fcr andere stark vernetzte Anwendungen beispielsweise im IoT- oder SmartHome-Bereich<\/p>\n Sollen mehrere Betriebssysteme \u2013 im nachfolgenden als Gastbetriebssysteme oder Gast bezeichnet \u2013 oder einzelne Bare-Metal-Anwendungen virtualisiert werden, ben\u00f6tigt man einen Hypervisor, der sich als Abstraktionsschicht \u00fcber die reale Hardware, also die Prozessorkerne, die Speicher und nicht zuletzt die Peripherals schiebt. Dabei ist grundlegend zwischen Typ 1- und\u00a0 Typ 2- Hypervisoren zu unterscheiden (Abbildung 1, s.\u00a0PDF<\/a>).<\/p>\n Der Typ-1-Hypervisor setzt direkt auf der Hardware auf und wird aus diesem Grund auch Bare-Metal-Hypervisor genannt. Er ben\u00f6tigt kein separates Betriebssystem, muss aber folglich alle Treiber f\u00fcr die Hardware selbst bereitstellen.<\/p>\n Beim Typ-2-Hypervisor wird ein Host-Betriebssystem ben\u00f6tigt, welches die Ger\u00e4tetreiber bereitstellt. Zwar k\u00f6nnen bei dieser Variante neben dem Hypervisor auch Applikationen laufen. F\u00fcr embedded Systeme ist diese Variante aber eher uninteressant, weil man den Hypervisor so schlank wie m\u00f6glich halten m\u00f6chte und vor allem eine starke Separierung der einzelnen Gastbetriebssysteme oder Applikationen erreichen will. Konzentrieren wir also im Weiteren auf Funktion und Anwendung von Typ-1-Hypervisoren.<\/p>\n Der Typ-1-Hypervisor \u00fcbernimmt neben grundlegenden Betriebssystemaufgaben wie die\u00a0 Verwaltung der Hardware-Ressourcen vor allem die Zuordnung, welches Gastbetriebssystem innerhalb einer virtuellen Maschine (VM) auf welchen physischen Rechenkernen ausgef\u00fchrt wird und wie deren Scheduling erfolgen soll. Die Gastbetriebssysteme sehen die physischen Cores nicht, vielmehr werden ihnen durch die jeweilige VM virtuelle Cores zur Verf\u00fcgung gestellt. Dabei ist es nicht zwingend, dass die Gesamtzahl der virtuellen Cores mit der Anzahl physischer Cores \u00fcbereinstimmen muss. Mehrere Gastbetriebssysteme k\u00f6nnen sich durchaus einen oder mehrere physische Cores teilen. In diesem Fall muss der Hypervisor allerdings ein Scheduling durchf\u00fchren. Jeder Gast bekommt eine Zeitspanne f\u00fcr die Abarbeitung auf den Cores zur Verf\u00fcgung gestellt. Beim Wechsel des aktiven Gastbetriebssystems muss der Verarbeitungskontext, also Core-Register, Systemregister, Status der Interrupt-Abarbeitung, etc., gesichert und wiederhergestellt werden. Dies ist vergleichbar mit dem Taskwechsel in einem Betriebssystem.<\/p>\n Bei der Virtualisierung von Echtzeitbetriebssystemen werden die virtuellen den physischen Cores typischerweise statisch zugeordnet. Der Entwickler entscheidet also selbst, wie sich die Verarbeitungslasten der einzelnen Gastbetriebssysteme auf die Prozessorressourcen, sprich auf die Kerne, verteilen. Damit wird ein deterministisches Verhalten des Gesamtsystems garantiert. Ob die Echtzeitf\u00e4higkeit bez\u00fcglich des zuzusichernden Zeitverhaltens auch wirklich erreicht wird, ist zwar in gro\u00dfem Ma\u00dfe von der gew\u00e4hlten Zuordnung und Verteilung abh\u00e4ngig, h\u00e4ngt jedoch nat\u00fcrlich auch von der Performance der eingesetzten Prozessorplattform ab.<\/p>\n Die Aufteilung der Gastbetriebssysteme auf verschiedene Cores erfolgt zusammen mit weiteren Konfigurationsinformationen wie beispielsweise der Zuordnung, in welche physikalischen Speicherbereiche die Gastbetriebssysteme geladen werden sollen oder welche Peripherals ihnen zur Verf\u00fcgung stehen und wird h\u00e4ufig fest in den Hypervisor einkompiliert bzw. gelinkt. Gleiches gilt auch f\u00fcr die Binaries der virtuellen Maschinen und die Gastbetriebssysteme. Zwar k\u00f6nnte daf\u00fcr auch auf externe Files zur\u00fcckgegriffen werden, die sich beispielsweise auf einem Massenspeicher oder auf einem Netzlaufwerk befinden. Doch so ein Vorgehen birgt nat\u00fcrlich immer auch ein gewisses Risiko hinsichtlich Integrit\u00e4t und Vertrauensw\u00fcrdigkeit der zu ladenden virtuellen Maschinen. Wenn soweit alles geklappt hat, steht am Ende ein aus allen Gastbetriebssystemen und dem Hypervisor bestehendes monolithisches Binary bereit, um vom Bootloader in den Speicher des Zielsystems geladen und letztendlich gestartet zu werden.<\/p>\n F\u00fcr eine wirklich sichere Abgrenzung der Gastbetriebssysteme muss der Hypervisor freilich auf einige wichtige Hardwarefunktionen des Zielprozessors zur\u00fcckgreifen k\u00f6nnen. Schauen wir uns diese zwingend erforderlichen Features am konkreten Beispiel eines ARM Coretx-A53 einmal n\u00e4her an. Dieses SoC bietet mit seinen bis zu vier Armv8-A Cores nicht nur die n\u00f6tige Rechenleistung; der auf dem Chip integrierte\u00a0Hardware Virtualization Support<\/em>\u00a0stellt gleichzeitig auch alle notwendigen Hardwarefunktionen f\u00fcr den Hypervisor zur Verf\u00fcgung:<\/p>\n Die Exception Level der Armv8-A Architektur legen die Privilegierung der aktuellen Software-Ausf\u00fchrung fest. Je h\u00f6her das Exception Level, desto h\u00f6her privilegiert ist die Ausf\u00fchrung. Konsequenterweise sieht die Armv8-A Architektur deshalb f\u00fcr den Hypervisor einen eigenen Exception Level (EL2) vor, um ihn sicher von den Gastbetriebssystemen (EL1 und EL0) zu separieren [2].<\/p>\n Damit die Gastbetriebssysteme den physikalischen Speicher des Cortex-A53 nutzen k\u00f6nnen, ohne sich der Existenz des Hypervisors bewusst zu sein und ohne unerlaubt auf dessen Speicher zuzugreifen, ist eine zweistufige Adressumrechnung in Form einer MMU implementiert. Der physikalische Speicher, den das Gastbetriebssystem zu sehen glaubt, ist eigentlich die sognannte\u00a0Intermediate Physical Address Map<\/em>. Diese wiederum liegt in der Verantwortung des Hypervisors. Nach der \u00dcbersetzung der virtuellen Adresse durch das Gastbetriebssystem in die\u00a0Intermediate Physical Address<\/em>\u00a0ist also noch eine weitere \u00dcbersetzung in die eigentliche physische Adresse notwendig (Abbildung 2, s.\u00a0PDF<\/a>).<\/p>\n \u00dcber Device Emulation oder Device Assignment erlangen die Gastbetriebssysteme Zugang zu den Hardware Devices bzw. Peripherals. Device Emulation ist dann notwendig, wenn ein Device f\u00fcr mehr als nur f\u00fcr einen Gast verf\u00fcgbar sein soll. Ein direkter Zugriff auf das Hardware-Device ist in diesem Fall nicht m\u00f6glich, da sonst Konflikte vorprogrammiert sind. Im Hypervisor werden die Devices deshalb in Software so nachgebildet, dass auch Zugriffe durch mehre Gastbetriebssysteme behandelt werden k\u00f6nnen. Greift ein Gast auf ein solches in den Speicher eingeblendetes emuliertes Device zu, resultiert dies in einen Trap in den Hypervisor (EL2) hinein. Dieser muss nun entsprechend reagieren und gegebenenfalls das reale Hardware Device ansprechen. In entgegengesetzter Richtung, wenn also der Gast mit Daten aus dem Device versorgt werden soll, werden virtuelle Interrupts durch den Hypervisor ausgel\u00f6st. Aus Sicht der Gastbetriebssysteme sehen diese wie normale Hardware Interrupts aus. Auch der Interrupt Controller steht als virtuelles Device zur Verf\u00fcgung. Reagiert der Gast dann mit einem Lesezugriff auf den Speicher oder auf Register des Devices, wird wie bereits beschrieben ein Trap in den Hypervisor ausgel\u00f6st. Dieser stellt dann die angefragten Daten zur Verf\u00fcgung.<\/p>\n Der Hypervisor kann selbstverst\u00e4ndlich auch Devices vor den Gastbetriebssystemen komplett verbergen oder nur f\u00fcr einen Gast exklusiv verf\u00fcgbar machen. Letzteres erlaubt die direkte Nutzung von Hardware Devices. Lediglich eine Adressumrechnung und die Anpassung der Interrupt-IDs durch den Hypervisor ist n\u00f6tig. Der gro\u00dfe Vorteil dabei ist nat\u00fcrlich, dass man sich den Overhead der Device Emulation spart.<\/p>\n Auch f\u00fcr Interrupts bzw. Exceptions gilt, dass diese aus Sicht der Gastbetriebssysteme direkt aus der Hardware kommen. Dem ist aber nicht so. Vielmehr werden Hardware Exceptions oder Interrupts durch den Hypervisor bearbeitet und gegebenenfalls als virtuelle Exceptions bzw. virtuelle Interrupts an den jeweiligen Gast weitergereicht.<\/p>\n Die Pr\u00e4senz eines Hypervisors wirkt sich auch auf das Debugging aus, wobei es hier \u00a0mehrere Sichtweisen und Aufgabenstellungen zu beachten gilt. Eine besondere Herausforderung stellt vor allem das hardwarenahe Debugging dar, bei dem der Entwickler naturgem\u00e4\u00df immer mit dem Hypervisor bzw. den VMs in Ber\u00fchrung kommt:<\/p>\n Auf das reine Debugging von Applikationen, die unter einem Gastbetriebssystem laufen, gehe ich an dieser Stelle ganz bewusst nicht n\u00e4her ein, weil hier ja eher selten direktes Hardware-Debugging betrieben wird. Schauen wir uns stattdessen die drei oben genannten Anwendungen noch etwas genauer an.<\/p>\n W\u00e4hrend sich der Entwickler beim letzteren Anwendungsfall explizit mit dem Hypervisor auseinander setzt, sollte ihm in den ersten beiden F\u00e4llen die Tatsache, dass es sich um eine Virtualisierung handelt, eigentlich verborgen bleiben. In der Praxis sieht dies jedoch meist anders aus. Setzt man zum Debuggen einen JTAG-Debugger wie die Universal Debug Engine (UDE) von PLS ein, dann hat dieser direkten Zugang zum Speicher, zu den Registern und zu den Prozessorkernen des Zielprozessors; also wenn man so will zu allem, was unterhalb des Hypervisors angesiedelt ist. Die Sicht der Bare-Metal-Applikation oder des Treibers, der entwickelt werden soll, endet aber oberhalb des Hypervisors. F\u00fcr diese sind n\u00e4mlich nur die virtuellen Hardware-Komponenten, also virtualisierter Speicher, emulierte Devices und virtuelle Prozessorkerne sichtbar. Das hat in der Praxis nat\u00fcrlich Konsequenzen.<\/p>\n Die Hypervisor-Awareness des Debuggers erlaubt zwar prinzipiell eine \u00a0Umrechnung der virtuellen und Intermediate-Physical-Adressen in physische Adressen, \u00a0allerdings funktioniert das nur bei realem Speicher (z.B. RAM oder FLASH) nicht aber bei emulierten Devices. Diese sind zwar in den virtuellen Speicher eingeblendet, haben aber keinen ihnen zugeordneten physischen Speicherbereich. Wenn ein Gast auf diesen Device-Speicher zugreift, ist das nat\u00fcrlich nicht problematisch. Es folgt wie weiter oben beschrieben ein Trap in den Hypervisor und die Verarbeitung durch die Device-Emulation. Die Adress\u00fcbersetzung durch den Debugger jedoch liefert einen ung\u00fcltigen Speicherbereich zur\u00fcck, weil er die Emulation des Devices nicht kennt. Die Verwendung von emulierten Devices innerhalb der virtuellen Maschine ist also nicht direkt debugbar. Das gilt nat\u00fcrlich nicht bei Devices, die direkt und exklusiv einer VM zugeordnet. Hier existiert reale Hardware, auf die der Debugger Zugriff hat.<\/p>\n Stoppt der Debugger an einem Breakpoint oder direkt von Anwender ausgel\u00f6st das System, werden neben allen physischen Cores auch der gesamte Hypervisor und somit auch alle virtuellen Maschinen angehalten. Das ist durchaus sinnvoll und konsequent, denn andernfalls m\u00fcsste sich der Hypervisor pl\u00f6tzlich mit einer virtuellen Maschine auseinandersetzen, die nicht mehr reagiert. Er k\u00e4me unweigerlich au\u00dfer Tritt und w\u00fcrde wom\u00f6glich abst\u00fcrzen.<\/p>\n Anders sieht es aus, wenn der Hypervisor einen Debug-Monitor anbietet. Dann ist er selbst in der Lage und daf\u00fcr verantwortlich, einzelne virtuelle Maschinen und deren Gastbetriebssysteme anzuhalten, w\u00e4hrend die anderen weiterlaufen k\u00f6nnen. Wenn der Debugger diesen Debug-Monitor nutzt, darf er allerdings selbstverst\u00e4ndlich keinen direkten Einfluss auf die Hardware mehr nehmen.<\/p>\n Das Setzen eines Breakpoints innerhalb des Kontextes einer virtuellen Maschine bei laufendem System erfordert vom Debugger einiges an Aufwand und l\u00e4sst sich leider auch nicht vollst\u00e4ndig reibungsfrei realisieren. Der Debugger muss daf\u00fcr n\u00e4mlich erst einmal den aktuellen Zustand des Gesamtsystems ermitteln, also welche virtuellen Maschinen gerade aktiv sind und welche nicht. Wirklich sicher funktioniert das jedoch nur im angehaltenen Zustand, weshalb der Debugger auch kurz das gesamte System anh\u00e4lt. Zwar bleibt dieser kurze Zwischenstopp dem Nutzer weitestgehend verborgen auf das Laufzeitverhalten der einzelnen virtuellen Maschinen hat er aber nat\u00fcrlich schon Einfluss.<\/p>\n Um das Scheduling des Hypervisors zu optimieren und feststellen zu k\u00f6nnen, ob Zusicherungen von Echtzeitverarbeitung von Gastbetriebssystemen eingehalten werden, ist es notwendig, Laufzeitmessungen durchzuf\u00fchren. Im einfachsten Fall liefert der Hypervisor diese Informationen selbst und der Debugger kann den Debug-Monitor dazu befragen. Wenn nicht, bleibt als Alternative eigentlich nur Trace. Letzteres erfordert jedoch sowohl vom Debugger als auch vom Anwender eine genaue Kenntnis der Verwaltungsstrukturen des Hypervisors, um die aufgezeichneten Trace-Daten nutzbringend auswerten zu k\u00f6nnen.<\/p>\n Ganz ohne Virtualisierung wird eine strikte Trennung von sicherheitskritischer oder echtzeitkritischer Software auf einer gemeinsamen Embedded-Prozessorplattform k\u00fcnftig kaum zu bew\u00e4ltigen sein. Allerdings gilt es hierbei zu ber\u00fccksichtigen, dass vor allem das hardwarenahe Debuggen von Treibern oder Bare-Metal-Applikationen in einer virtualisierten Umgebung auch unerw\u00fcnschte Effekte f\u00fcr das Gesamtsystem mit sich bringen kann. Zwar sind die Hersteller von Debug-Werkzeugen bestrebt, solche prinzipbedingten R\u00fcckwirkungen so gering wie m\u00f6glich zu halten, g\u00e4nzlich verhindern lassen sie sich jedoch leider nicht. Nur wer sich dessen vorab bewusst ist, wird unerwartete Effekte w\u00e4hrend der Systementwicklung auch richtig einordnen k\u00f6nnen.<\/p>\n [1]\u00a0\u00a0\u00a0 https:\/\/www.wired.com\/2015\/07\/hackers-remotely-kill-jeep-highway\/<\/p>\n [2]\u00a0\u00a0\u00a0 ARM Ltd:\u00a0ARM\u00ae Architecture Reference Manual, ARMv8, for ARMv8-A architecture profile<\/em><\/p>\n Jens Braunes<\/strong>\u00a0ist Product Marketing Manager bei der PLS Programmierbare Logik & Systeme GmbH. Er studierte Informatik an der TU Dresden und arbeitete dort als wissenschaftlicher Mitarbeiter. 2005 wechselte er zum Softwareteam von PLS und ist dort ma\u00dfgeblich an der Entwicklung der Universal Debug Engine beteiligt. Er erweiterte 2016 sein T\u00e4tigkeitsfeld auf das Produktmanagement und technische Marketing. Jens Braunes ist regelm\u00e4\u00dfig als Autor von Fachartikeln und als Referent auf Kongressen t\u00e4tig.<\/p>\n Beitrag als PDF downloaden<\/strong><\/a><\/p>\n Wollen Sie sich auf den aktuellen Stand der Technik bringen?<\/strong><\/p>\n Dann informieren Sie sich\u00a0hier<\/strong>\u00a0<\/a>zu Schulungen\/ Seminaren\/ Trainings\/ Workshops und individuellen Coachings von MircoConsult zum Thema Multicore \/Mikrocontroller.<\/p>\n Training & Coaching zu den weiteren Themen unseren Portfolios finden Sie\u00a0hier<\/a>.<\/strong><\/p>\n Wertvolles Fachwissen zum Thema Multicore \/Mikrocontroller steht\u00a0hier\u00a0<\/a><\/strong>f\u00fcr Sie zum kostenfreien Download bereit.<\/p>\nTrennung f\u00fcr mehr Sicherheit<\/h2>\n
Nicht ohne geeignete Hardware<\/h2>\n
\n
Hypervisor Awareness in der Entwicklung \u2013
\nHerausforderungen beim Debugging<\/h2>\n\n
\nDie Zugriffe auf Speicher und Peripherals werden nicht durch ein Betriebssystem gekapselt, stattdessen wird direkt auf die virtualisierte Hardware zugegriffen. F\u00fcr das Debugging sind also Speicherinhalte und Zugriffe auf die Device Register interessant.<\/li>\n
\nDieser Anwendungsfall ist im Gro\u00dfen und Ganzen identisch mit Punkt 1.<\/li>\n
\nHierbei geht es vorrangig um das Messen von Laufzeiten und der Lastverteilung. \u00a0Ziel dieser Messungen ist eine Optimierung der Hypervisor-Konfiguration, damit beispielsweise ein zugesichertes Zeitverhalten eines Echtzeitbetriebssystem als Gast auch tats\u00e4chlich eingehalten wird.<\/li>\n<\/ol>\nFazit<\/h2>\n
Referenzen<\/h2>\n
Autor<\/h2>\n
\nMulticore – unsere Trainings & Coachings<\/h2>\n
\nMulticore – Fachwissen<\/h2>\n