Echtzeit in Multicore-Designs braucht eine neue OS-Denkweise

| Autor / Redakteur: John Blevins * / Sebastian Gerstl

Der Elefant im Raum: Security ist inzwischen zu einem Thema geworden, mit dem sich jeder Entwickler befassen muss - egal ob auf Hardware- oder Software-Ebene.
Der Elefant im Raum: Security ist inzwischen zu einem Thema geworden, mit dem sich jeder Entwickler befassen muss - egal ob auf Hardware- oder Software-Ebene. (Bilder: Lynx Software)

Seitenkanalattacken oder unentdeckte Hardware-Sicherheitslücken sind wie Tretminen für die System-Security. Wie bleibt das OS sicher? Ein Umdenken bei der Betriebssystem-Implementierung ist gefragt.

Kommen bei einem Softwareentwickler für eingebettete Echtzeitsysteme angesichts der rasant zunehmenden Verbreitung von Mehrkernprozessoren im Systementwurf Bedenken auf? Bereitet es Sorge, dass das Wesentliche an einer Echtzeitsteuerung, im Bemühen um mehr Rechenleistung für noch weniger Größe, Gewicht und Leistungsverbrauch („Size, Weight and Power“, kurz SWaP), verlorengeht?

Wir werden unablässig darum ersucht, immer mehr Anwendungen und Dienste unterschiedlicher Kritikalität für das Gesamtsystem über das Betriebssystem (OS) auf Multicore-Prozessoren zu packen, und lassen dieses, oft Linux, mit den Komplexitäten einer Echtzeitsteuerung klarkommen. Doch erschaffen wir so eine Reihe neuer Probleme, die uns dann bei der Auslieferung dieser Systeme böse zu überraschen?

Security – ein offenes Problem, das keiner zu erwähnen wagt

Es geht um den berühmten ‚Elefant im Raum‘ - also ein Problem, das offensichtlich im Raum steht, aber dennoch von den Anwesenden nicht angesprochen wird. In Embedded Systemen ist das fast immer das Thema Sicherheit. Immer häufiger sind Anwendungen heute auf die Verbindung, mit anderen Systemen in der Regel über das Internet, angewiesen. Dies ist bekanntermaßen ein aggressiver Angriffsvektor, also müssen wir uns dagegen verteidigen.

Was wir jedoch nicht wissen ist, was in den unzähligen Threadsträngen, die Linux ausführt, vor sich geht. Wie können wir also jemals bequem unseren Programmleitern gegenüber behaupten, unsere Systeme seien ‚Secure by Design‘? Ist blindes Vertrauen in das OS gerechtfertigt? In einer zunehmend verbundenen Welt lautet die Antwort eindeutig ‘Nein’. Für Entwickler von Steuerungssystemen galt dies immer schon. Gleichzeitig müssen wir mit der Wiederverwendung von Legacy-Code umgehen, dessen Herkunft wir nur begrenzt verstehen, und all dies auf einen Multicore-Prozessor zu packen. Das mag sich wie ein übermächtiges, uneinholbares Problem anhören - ist es aber nicht. Es gibt Wege, den Wert von Multicore als Asset im Systementwurf wirklich zu erschließen und bestmöglich zu nutzen -- aber nicht durch ein Betriebssystem.

Das Problem des „Prinzips der geringsten Rechte“

Das Problem mit dem OS ist, dass es, da sich seine Dienste über mehrere Kerne erstrecken, nicht in der Lage ist, eines der Kernprinzipien sicherer Systembauweisen in angemessener Weise einzuhalten: das Prinzip des Least Privilege. Das Konzept der geringsten Rechte besagt, dass jedes Modul nur in der Lage sein dürfe, auf Informationen zuzugreifen, die für seinen rechtmäßigen Zweck notwendig sind. Die meisten OS-orientierten Angriffe, ob Multicore oder nicht, verfahren mittels einer Rechteausweitung (Privilegien-Eskalation) durch das Ausnutzen von Bugs.

In einem Mehrkern-Betriebssystem jedoch, das mehrere verschiedene Anwendungen ausführt, bedeutet dies, dass jede ausgenutzte Applikation ein Angriffsvektor für das Gesamtsystem ist und somit alle anderen Applikation nun gefährdet sind. Ganz klar müssen wir die systemweiten Konsequenzen einer Privilegien-Eskalation überdenken, vor allem wenn es um unbeaufsichtigte, Echtzeit-Überwachungssysteme geht und speziell auf zusammengeführten, konsolidierten Multicore-Systemen.

Einige Hacker setzen Seitenkanalangriffe ein, die in einigen Fällen – wie bei Meltdown und Spectre – Fehler in einem für Multicore optimierten Hardware-Design nutzen, um direkt auf Speicher zuzugreifen und ohne Berechtigung Daten auszulesen. Was zeigt, dass unsere Hardware die Grenzen ihrer Stabilität erreicht hat, die zur Entwicklung sicherer Systeme notwendig ist – oder doch nicht? Haben die Prozessorentwickler diese Probleme etwa vorausgesehen und infolgedessen die Softwareentwickler dabei unterstützt, diese Probleme mithilfe solider Secure-Design-Prinzipien anzugehen bzw. zu mildern? Die Antwort ist „Ja“ – doch bedarf es hierbei der Einführung einiger neuer Technologien für Multicores, die so gehandhabt werden, dass sie sowohl den vorangehenden Herausforderungen begegnen als auch dies eben nicht auf Betriebssystemebene tun.

Multicore muss kosteneffizient UND sicher einsetzbar sein

Diese Probleme wurden zuerst in Marktsegmenten erkannt, in denen es sowohl um funktionale Sicherheit (Safety) als auch Datensicherheit geht. Wenn Leben auf dem Spiel stehen – und die damit einhergehenden Klagen und Gerichtsverfahren – schärft das den Blick für das Wesentliche: ohne ‘Cybersecurity by Design’ kann ein vernetztes System kaum nachweisbar sicher sein.

Zwei Branchen, der Automobilbau und die Luftfahrt, waren führend bei der Suche nach Lösungen, Multicore sicher und kosteneffizient anzuwenden und dabei die eigenen Ziele hinsichtlich SWaP und Wiederverwendung von Legacy-Code zu realisieren – der Automobilbau und die Luftfahrt. Hinzu kommt noch der aufstrebende Air Mobility- Markt (Flugautos und PAVs), der ebenfalls diese Notwendigkeit zunehmend erkennt.

Im Automotive-Bereich entwickelte man Autosar hin zu Adaptive Autosar, damit sich mehr Systemfähigkeiten eines OS für weitere Anwendungen nutzen und sicher in ein Fahrzeug integrieren lassen. Im Avionik-Bereich gibt es eine Verschiebung hin zu einer zweiten Generation Integrierter Modularer Avionik (IMA) mit dem Ziel, Multicore für SWaP-Zwecke einsetzen zu können bei der gleichzeitigen Erkenntnis, dass die Integration auf einen Einzelkern größere Anforderungen an die Cybersecurity stellt. Die physikalische Isolierung in föderale Einheiten steht dem Systemarchitekten nicht länger als Asset zur Verfügung. Doch können vielleicht die Multicore-Designer entsprechende Tools bereitstellen, die Gleichwertiges liefern?

Was also ist das gängige Instrument der Systemsoftwareentwickler zum Schutz vor den Folgen der Privilegien-Eskalation und zur potentiellen Abwehr von Seitenkanalangriffen, auch wenn diese aus einem Fehler im Multicore-Design resultieren? Kurz, es ist die Virtualisierung. Und zwar nicht nur angewendet, um mehrere verschiedene OS hosten zu können, sondern tatsächlich als Sicherheitstechnologie. Richtig angewendet, bietet Virtualisierung einen weiteren Eckstein der Entwicklung sichererer Systeme: die Separierung, faktisch eine sichere Isolierung derjenigen gehosteten Betriebssysteme, die die Wiederverwendung von Legacy-Code für nachfolgende Systemgenerationen ermöglichen.

Sicherlich liefern alle Hypervisoren und VMMs diese Sicherheit? Überhaupt nicht. Es scheint eher so, dass die meisten von ihnen auf einem Kernel oder OS basieren und deshalb dem Problem der Privilegien-Eskalation zum Opfer fallen können. Und – was schlimmer ist – sie alle können Opfer der Seitenkanalattacken von Meltdown oder Spectre werden, was den zentralen Konstruktionsfehler der OS-basierten Virtualisierungslösung erneut aufzeigt. Solche Schwächen sind inakzeptabel in Systemen, bei denen Menschenleben auf dem Spiel stehen.

Immun gegenüber jeglicher Art von Privilegien-Eskalation

Um Gefahren durch Seitenkanalattacken oder On-Metal-Sicherheitslücken wie Meltdown oder Spectre vorzubeugen, empfiehlt sich die strike Separierung von Services oder Gast-Betriebssystemen durch einen Separation Kernel Hypervisor (rechts).
Um Gefahren durch Seitenkanalattacken oder On-Metal-Sicherheitslücken wie Meltdown oder Spectre vorzubeugen, empfiehlt sich die strike Separierung von Services oder Gast-Betriebssystemen durch einen Separation Kernel Hypervisor (rechts). (Bild: Lynx Software)

Das Problem geht inzwischen über die bloße Safety hinaus. Die Privatsphäre und Vertraulichkeit jedes Systems, ob im Internet oder anderweitig öffentlich bzw. halböffentlich verbunden, wurde jetzt mit dem Stichtag 25. Mai 2018 ein enormes Thema. In Europa riskiert, wer hinter der öffentlichen Erwartung an seine Vertrauenwürdigkeit zurückbleibt, Strafen von bis zu vier Prozent des jährlichen Firmenumsatzes (nicht des Gewinns!). Die DSGVO erzwingt eine Neuausrichtung des Bedarfs nach ‚Security by Design‘ hin zu einer ‚Privacy by Design‘. Das ist wahrscheinlich auch richtig so, wenn der digitale Wandel unseren Alltag immer stärker und wesentlicher bestimmt.

Das Betriebssystem erfüllt seine Rolle als portable Applikationsentwicklungsplattform. Doch als vertrauenswürdige Lösung zum Management einer Fusion verschiedener Fähigkeiten über hochintegrierte Cores hinweg, die Speicher und Caches sowie Ein-/Ausgänge teilen, hat sich sein Versagen allzu regelmäßig gezeigt. Das belegt das tägliche Auftreten von Hacks und Datenverlusten.

Die Lösung lautet: volle Nutzung der Fähigkeiten, die uns die Hersteller der Mehrkernprozessoren bereitstellen. Um die Auswirkungen der Privilegien-Eskalation zu begrenzen. Um bei der Anwendungsumgebung, die dem Hacker nicht standhalten konnte, dennoch bleiben zu können. Um eine Plattform bereitzustellen, die immun gegenüber Privilegien-Eskalation ist. Und schließlich, von besonderer Bedeutung, um auch die Hardware-unterstützten Module (OS, Bare-Metal-Anwendung oder -Service, oder Unikernel) mit sicherer Separierung zu bieten, die diese Multicores ermöglichen.

Die Lösung ist jedoch kein OS, nicht einmal ein Mikrokernel – es ist ein Separation Kernel Hypervisor, wobei ‘Kernel’ nur die sehr wohl verstandene Notwendigkeit widerspiegelt, die Entwicklung sicher isolierter Systemservices sowie gehosteter Gastbetriebssysteme zu unterstützen. Bei einem Separation Kernel Hypervisor handelt es sich um eine kleine zweckgebaute Sicherheitsschicht [ohne internes OS], das Hardware-Virtualisierungsanweisungen nutzt, damit virtualisierte Module [OS, RTOS, Bare-Metal] sichermit dedizierten, sicher separierten Hardware-Ressourcen auf ihm ausgeführt werden können. Behalten Sie Ihr favorisiertes OS oder Legacy-Software für die Applikationsentwicklung bei, aber sichern Sie diese mit virtualisierter Separation bei der Ausführung auf Multicore.

Software-Design zum Schutz kritischer Systeme vor Meltdown und Spectre

Software-Design zum Schutz kritischer Systeme vor Meltdown und Spectre

12.04.18 - Viele kritische Systeme sind anfällig für Meltdown und Spectre, müssen es aber nicht zwangsläufig sein. Die hier beschriebenen Tools und Entwurfsmethoden befähigen Systementwickler dazu, in Hinblick auf diese (und andere) Software- und Hardware-Schwachstellen ein hochgradiges Maß an Leistung und Sicherheit aufrechtzuerhalten. lesen

* John Blevins ist Director of Products bei Lynx Software Technologies in San Jose.

Kommentar zu diesem Artikel abgeben

Schreiben Sie uns hier Ihre Meinung ...
(nicht registrierter User)

Zur Wahrung unserer Interessen speichern wir zusätzlich zu den o.g. Informationen die IP-Adresse. Dies dient ausschließlich dem Zweck, dass Sie als Urheber des Kommentars identifiziert werden können. Rechtliche Grundlage ist die Wahrung berechtigter Interessen gem. Art 6 Abs 1 lit. f) DSGVO.
Kommentar abschicken
copyright

Dieser Beitrag ist urheberrechtlich geschützt. Sie wollen ihn für Ihre Zwecke verwenden? Kontaktieren Sie uns über: support.vogel.de/ (ID: 45397310 / Safety & Security)