CPU-Designfehler Schutz kritischer Systeme vor Meltdown und Spectre

Das Forschungsprojekt SecForCARs unter Leitung von Infineon beschäftigt sich unter anderem mit der Frage, wie sich vernetzte und automatisierte Fahrzeuge sicherer entwickeln lassen. Dabei wollen die Partner neue Ansätze entwickeln.
Meltdown und Spectre decken grundlegende CPU-Designmängel auf.

Meltdown und Spectre decken grundlegende Designmängel auf, die schon seit Jahrzehnten bestehen. Am härtesten betroffen sind die Bereiche IIoT, Medizintechnik, Automotive. Die Entwickler kämpfen nun um Fehlerkorrekturen durch ein Mix aus Compiler-Updates, Kernel-Patches und CPU-Microcode-Patches.

Wie schon John Rushby, der Erfinder des Separation Kernels, voraussah [1], haben sich Patches als inadäquat erwiesen. Sie milderten das zugrunde liegende Problem nur teilweise und – wie in vielen Fällen festgestellt – destabilisieren bestehende Systeme sowohl auf der Software- als auch der Hardware-Ebene [2] [3] [4] [5]. Ein böses Erwachen, nicht so sehr wegen des Verlusts an vermeintlich geglaubter Sicherheit, sondern vielmehr wegen der alsbaldigen Realisierung, dass Sicherheit insgesamt völlig fehlt.

Ian Ferguson, Vice President für Marketing bei arm, sagte bereits im Jahr 2016: »Das Internet der Dinge kann erst dann den großen Durchbruch erleben, wenn wir ein Internet des Vertrauens geschaffen haben.« [6] Wie können Entwickler angesichts Meltdown und Spectre die erstrebten Vorgaben Safety und Security weiter erfüllen? Wie kann das gewünschte Internet of Trust geschaffen werden? Manche Quellen behaupten schon, dass die Voraussetzung einer wie auch immer gearteten Softwaresicherheit fundamental zerbrochen ist. Nicht mehr existiert. Aber ist das so?

Auf das Software-Design des Systems kommt es an

Meltdown und Spectre stellen die Gültigkeit langjähriger Software- und Hardware-Designs infrage. Sie verschaffen uns aber auch Einsicht, wie Systeme gegen eben diese Angriffe selbst verteidigt werden können.

Die Aufdeckung von Problemen ermöglicht passende Lösungen. Es waren ja nicht alle Systeme anfällig. Einige waren tatsächlich geschützt – und erforderten weder Patches, noch Rekonfigurationen, noch Rekompilierungen, noch Redesigns [7]. Was diese widerstandsfähige, nachhaltige Systeminfrastruktur unterschied, war eine einzigartige Separation Kernel-Technologie, die auf der Arbeit von John Rushby basiert [8]. Sie befähigt Systementwickler, kritische Rechenumgebungen durch eine verbesserte Hardwaresteuerung voneinander zu separieren.

In diesem Artikel beschreiben wir, wie Meltdown und Spectre funktionieren; wir stellen außerdem eine alternative Kernel-Technologie vor, die immun gegenüber Meltdown ist. Und last but not least bieten wir einen Systementwicklungsansatz, der Spectre-Attacken abschwächt.

Trennung und der »Meltdown-Lackmustest« 

Trennung ist ein fundamentales Konzept bei der funktionalen und bei der Datensicherheit und wird bei High-Assurance-Systemdesigns seit Jahrzehnten eingesetzt. In Bezug auf funktionale Sicherheit stützt sich die Partitionierung von Flugverkehrsystemen (DO-178C, CAST 32, Integrated Modular Avionics) auf die Trennung von Komponenten, um deren Schutz zu gewährleisten [9] [10] [11].

Was die Sicherheit der Daten betrifft, so ist die Trennung das Rückgrat der strengsten Standards. Die Multiple Independent Levels of Security-Architekturen (MILS) des US-amerikanischen Verteidigungsministeriums sind Implementierungen von Sicherheitsmodellen, die auf den Grundsätzen der Trennung und des kontrollierten Informationsflusses basieren [8] [12].

Innerhalb dieser Kontexte bedeuten Trennungsfehler geradezu zwangsläufig Sicherheitsmängel. Somit kann Meltdown den Entwicklern von kritischen eingebetteten Systemen als praktischer Lackmustest angesehen werden, der aufzeigt, wo eine sichere Trennung erreicht wurde und wo nicht.

Wahrung der Trennung, Wiederherstellung des Vertrauens

Obwohl sie sich in wichtigen Merkmalen unterscheiden (was wir auf den folgenden Seiten ausführen werden), handelt es sich bei Meltdown [13] und Spectre [14] um sogenannte Seitenkanalattacken, also Attacken, die auf Informationen basieren, die durch ein physikalisch implementiertes Computersystems generiert werden, im Gegensatz zu Schwächen innerhalb des implementierten Algorithmus selbst.

Der Angreifer verwendet eine fortgeschrittene subversive Methode (Cache-Timing-Analyse), um den Zustand des Cache zu untersuchen und dabei die Werte des temporär referenzierten Kernel-Speichers abzuleiten. Obwohl jede Variante einen anderen Designfehler ausnutzt, sind beide unumstritten in der Lage, die Sicherheitskontrollen herkömmlicher Betriebssysteme und Hypervisoren zu umgehen ohne administrativen Zugriff zu benötigen oder die privilegierte Codebasis infiltrieren zu müssen. Erhält ein Angreifer administrative Zugriffsberechtigung durch diese Art von Seitenkanaltechniken, schwappt die Bedrohung von Privatsphäre und Vertraulichkeit zur Übernahme des gesamten Systems über. Da Meltdown und Spectre – obgleich nicht identisch - als hardware-immanente (Prozessor) Designprobleme identifiziert wurden, sind Software-Entwickler möglicherweise der Meinung, dass sie nichts hätten tun können, um die Designs ihrer High-Assurance-Systeme zu schützen. Doch das stimmt nicht.

Wir zeigen, dass eine entsprechende Implementierung bewährter High-Assurance-Grundsätze die kritische Systemelemente komplett vor Meltdown schützen und die negativen Auswirkungen von Spectre wesentlich mildern kann. Außerdem können anfällige Systeme oftmals ohne Neudesign entsprechend widerstandsfähig gemacht werden. Zunächst einmal folgt unsere Analyse zu Meltdown.

Untersuchung von Meltdown

Bei Meltdown ist ein nichtprivilegierter Angreifer in der Lage, den gesamten physischen Speicher eines Betriebssystems (OS) oder Hypervisors mit ~100 bis 500 KB/s auszulesen. [13] Dies ist durch das Ausnutzen eines verbreiteten CPU-Performance-Features – Out-of-Order-Execution (OoOE) – möglich, indem der Angreifer indirekt auf den Kernel-Speicher zugreift, bevor die CPU erkennt, dass der Speicher, der geladen wird, nicht zum angreifenden Prozess gehört. [15] Dieser Exploit greift zwei Optionen beim Kernel-Design an: erstens einen allgemeinen Zugriff auf Systemspeicher und zweitens die kombinierte User- und Kernel-Space-Speicherverwaltung.

So gut wie alle OS/Hypervisor-Kernel-De­signs verlassen sich auf die Optimierungsmethoden der Software-Leis­tung, bei denen sowohl virtuelle Benutzerprozess-Adresskonvertierungen als auch Kernel-Adresskonvertierungen in den gleichen Lookup-Tabellen gespeichert werden, damit der Kernel Daten schnell zu und vom Anwendungsspeicher übertragen kann, um somit vom Adresskonvertierungs-Caching zu profitieren.

Bild 1 zeigt die Übersetzung von virtuellen zu physikalischen Adressen von Nutzeranwendungen und die herkömmlichen Aufzeichnungen des Hypervisor/OS-Kernels an den Systemspeicher kombiniert im gleichen Tabelleneintrag pro Applikation.

Studien zu Meltdown [13] haben gezeigt, dass OoOE die Berechtigungsauflösung zwischen Benutzer- oder Kernel-Adress-Lookups zurückstellt, was Benutzeranwendungen ermöglicht, direkt auf virtuelle Kernel-Adressen in ihrem Programm zuzugreifen, um »illegal« (temporär) referenzierten Speicher im CPU-Cache zu laden. Die CPU gibt letztlich einen Speicherzugriffsausnahmefehler für die Speicherreferenz des Angreifers auf Kernel-Adressen aus, stellt jedoch nicht den Zustand des Cache wieder her.

Daraufhin verwendet der Angreifer eine fortgeschrittene subversive Methode (Cache-Timing-Analyse) [16], um den Zustand des Cache zu untersuchen und dabei die Werte des temporär referenzierten Kernel-Speichers abzuleiten.

Wenn die CPU-MMU von Intel so entwickelt worden wäre, dass die Tabelleneintragsmarkierung der Kernel-Seite überprüft wird, bevor die temporäre Speicheroperation im OoOE-Handler in die Warteschlange gesetzt wird, oder wenn der OS/Hypervisor-Kernel so entwickelt worden wäre, dass die Kombination von Kernel-Adresskonvertierungseinträgen mit Benutzerprozesseinträgen im Speicher des Angreifers unterbunden wird, wären die Operationen umgehend fehlgeschlagen.

Die Lösung für Meltdown

Die einfache Lösung für Meltdown sind Seitentabellenisolation und Least-Privilege-Speicherzugriff. Methoden, die beim LynxSecure Separation-Kernel seit seiner Einführung integriert sind. In LynxSecure werden alle Kernel-zu-physischen-Adressen in einer komplett anderen Seitentabelle anstatt in Anwendungs-/Gast-OS-Seitentabellen gespeichert.

LynxSecure ist eine High-Assurance-Virtualisierungstechnologie auf der Grundlage robuster Designprinzipien. Alternativ zu herkömmlichen zentralisierten ressourcen- und dienstorientierten Designs, wie sie bei den meisten Betriebssystemen und Hypervisoren zu finden sind, ist LynxSecure sowohl aus Kernel-Konstruktions- als auch aus Benutzermodell-Perspektive tief in einem Least-Privilege-Design verwurzelt. LynxSecure erzwingt einen dezentralisierten Designansatz, bei dem jede Gast-Computing-Umgebung mit lokal verwalteten Ressourcen unabhängig ist. Durch die Autonomie jeder Gastumgebung wird vermieden, dass der Kernel globale Dienste bereitstellen muss. Dadurch wird die Durchführung von Meltdown ausgehebelt. Bild 2 zeigt das virtuelle Speicherverwaltungsschema von LynxSecure, in dem der Kernel seine eigene Seitentabelle hat und Speicherplatz nur für einen minimalen Gebrauch vorsieht.

Adresskonvertierungen des Kernels, ohne mit Benutzeroberflächen verbunden zu sein, widerstehen augenblicklich allen Meltdown-Angriffen, die versuchen, nicht autorisierte Speicheradressen vorübergehend in den CPU-Cache zu laden – unabhängig von den OoOE-Ausführungsdetails. Systeme auf LynxSecure-Basis waren daher stets immun gegenüber Meltdown.

Untersuchung von Spectre

Bei Spectre kann ein Angreifer unautorisierten Speicher von einem Adressraum einer Anwendung (zum Beispiel willkürlicher Stack und Head Memory) sowie adressraumübergreifend auslesen, einschließlich OS/Hypervisor-Kernel-Speicher [14]. Im Gegensatz zu Meltdown verwendet Spectre CPU-Sprungvorhersagen als Mechanismus zum Durchsuchen von temporären Code-Pfaden, um auf geschützten Speicher zuzugreifen. Der Angreifer kann zwar nicht direkt auf den Speicher zugreifen, ihn aber später per Cache-Timing-Analyse ableiten [16].

Sprungvorhersage ist eine Methode zur CPU-Leistungsoptimierung, die der CPU ermöglicht, den Zielwert einer Steuerungsflussoperation (zum Beispiel Sprung, Aufruf, Rückgabe usw.) »vorherzusagen«, damit die Ausführungs-Pipeline nicht auf die Auflösung des Zielspeicherortes warten muss.

Spectre stellt eine größere Assurance-Herausforderung dar als Meltdown und greift auf unprivilegierten Speicher im CPU-Cache des Angreifers zu, ohne den direkten Verweis auf den Speicher des Opfers im Angreifercode zu nutzen. Spectre visiert Codemuster an, die bedingungsbezogene Pfade enthalten, die zu einem unautorisierten Speicherzugriff führen können.

Bei der Spectre-Studie wurden zwei unterschiedliche Methoden identifiziert, um die Sprungvorhersage auszunutzen: Erstens Umgehen von Längenchecks und zweitens Manipulieren des Sprungadressenzwischenspeichers (Branch Target Injection).

Umgehen von Längenchecks

Bei der Längencheckumgehung handelt es sich um einen Angriff auf den Code des Opfers, bei dem mit zu großen Indizes auf Bereiche jenseits der Indexgrenze von Speicher-Arrays zugegriffen wird (Bild 3). Durch Trainieren des Branch-Predictors mit aufeinanderfolgenden Aufrufen der Funktion mittels »legaler« (nicht-temporärer) Indexwerte bringt der Angreifer die CPU dazu, spekulativ anzunehmen, dass es beim folgenden Funktionsaufruf sicher ist, zum Array-Lookup-Code zu springen.

Ist der Branch-Predictor erst einmal in dieser Weise trainiert, kann der Angreifer diesen Funktionsaufruf mit jedem Indexwert starten, wissend dass die CPU den Speicherinhalt nach den angreifergesteuerten Indices vorübergehend/transient in den Cache laden wird.

Manipulieren des Sprungadressenzwischenspeichers

Bei der Manipulation des Sprungadressenzwischenspeichers (Branch Target Buffer) wird mittels Branch-Instruktionen der Sprung zu variablen Zieladressen verursacht, die Code enthalten (sogenannte »Gadgets«), der auf privaten Speicher innerhalb des Adressraums des Ziels zugreift (Bild 4). Durch »Trainieren« des Branch-Predictors der CPU kann der Angreifer einen Sprung zu Gadgets verursachen, die normalerweise nicht zugänglich wären. 

In Bezug auf Angriffe, die auf einer spekulativen (OoOE) Ausführung basieren, hat man nur extrem wenige Möglichkeiten, um die Mechanismen des Angriffs zu entdecken, geschweige denn zu korrigieren. Der Angriffscode selbst wirkt harmlos, da er einfach wiederholt völlig normale Funktionen ausführt, um einen Branch-Predictor entsprechend zu »trainieren«, und Register festlegt, bevor ein Ziel aufgerufen wird. Außerdem ist es praktisch nicht umsetzbar, jeden Code untersuchen zu wollen, den ein Compiler erzeugt, um jedes mögliche Codemuster zu entfernen, das die Umgehung von Längenchecks und das Springen zu Gadgets ermöglicht.

Von den veröffentlichten Spectre-Patches erwies sich am effektivsten die Modifikation des Compilers für einen alternativen Maschinendatencode in Form eines bedingten Applikationscodes [17] [18]. Diese Milderung erfordert jedoch eine Rekompilierung aller bestehender Software und untersagt dennoch nicht die Anwendung ausnutzbarer CPU-Befehle.

Spectre stellt eine grundlegende Herausforderung an sicheres Softwaredesign an sich dar. Sicherheitsexperte Thomas Dullien von Google Project Zero [19] betont, dass Software ein beabsichtigter endlicher Zustandsautomat sei, den Entwicklungsingenieure auf einer CPU auszuführen beabsichtigen. Die Wahrheit ist, dass Prozessorkerne Befehle ausführen und die Logik einer Entwicklung lediglich emulieren können. Emuliert eine CPU den vom Entwickler beabsichtigten Zustand, schafft sie dadurch auch einen sichtbaren ungewünschten Zustand, der den beabsichtigten, durch den Entwickler-Code vorgegebenen Zustand unterminiert. Dullien nennt diesen beobachtbaren unterminierenden Zustand einen »weird state«. Im Unterschied zum »sane state«, der ganz der Absicht des Entwicklers entspricht. Spectre ist beispielhaft dafür, wie der geplante Schutz eines OS/Hypervisor-Kernel-Speichers durch eine CPU im »weird state« unterminiert werden kann, was sich auf sämtliche angeschlossenen Anwendungen auswirkt. Will man die implementierte spekulative Ausführung der CPU nicht umstellen, so bleibt als einziger Ausweg nur die Änderung des Systemsoftwaredesigns.

Angesichts von Spectre müssen sich die Systementwickler schon fragen, ob die Vertraulichkeit sensibler Daten durch ihr System noch gewährleistet ist. Wie weiß ein Systementwickler einer serviceorientierten, daher zentralisiert angelegten Architektur, ob Standardprozesse wie Benutzer-Login und Datenverschlüsselung nicht unterschwellig Geheimes wie Authentifizierungs- und Entschlüsselungspasswörter verraten? Bild 5 zeigt mögliche Angriffsvektoren auf eine herkömmliche zentralisierte ressourcen- und dienstorientierte Architektur. 

Schutz vor Spectre 

Bei Spectre-Angriffen (und Seitenkanalangriffen generell) wird die Code-Aktivität des Opfers gemessen, der auf ein gemeinsames Rechnersystem zugreift. In herkömmlichen zentralisierten ressourcen- und dienstorientierten Designs – in denen jede Anwendung von einem einzigen Kernel abhängt, um die Ausführung von Threads zu terminieren, Ressourcen zu managen und Daten bereitzustellen – wird die Aufgabe, einen Angreifer daran zu hindern, auf durch den Kernel gewahrte Systeminterna zuzugreifen, fast unlösbar. Noch schlimmer: Haben Anwendungen von Grund auf auch noch die Option, administrative Zugriffsrechte auf den OS/Hypervisor auf dynamische Weise zu gewinnen, werden spectre-ähnliche Angriffe dramatisch zunehmen. 

Das Least-Privilege- Prinzip als Grundlage

Um die angriffsfähige Kernel-Oberfläche möglichst klein zu reden, sprechen viele Anbieter von Betriebssystemen und Hypervisoren oftmals schon von Least-Privilege-Produkten, wenn sie ein zwingend vorgeschriebenes Zugangskontrollsystem vorweisen können oder die Treiber außerhalb des Kernel-Adressraums platzieren. Gegen Seitenkanalangriffe wie Spectre reicht das nicht.

Das Least-Privilege-Prinzip erfordert, dass in einem bestimmten Abstraction-Layer einer Rechenumgebung jedes Modul, das kann je nach Gegenstand ein Prozess, ein Nutzer oder ein Programm sein, nur auf die Informationen und Ressourcen zugreifen darf, die für seine rechtmäßige Aufgabe notwendig sind [21].

Der Separation-Kernel LynxSecure hebt die Least-Privilege-Architektur auf ein stringenteres Niveau. Er eliminiert die zentralen Ressourcenmanager, Datendienste und die administrativen Benutzerkontrollrechte. Das Kerneldesign erlaubt es immer noch, Anwendungen in Gastumgebungen unmodifiziert auszuführen. Der Unterschied ist, dass kritischer Code, der für die Initialisierung der Hardware und die Handhabung von Hardware-Ausnahmen (Exceptions) verantwortlich ist, von dem Code separiert wurde, der die Anwendungsdienste (Speichermanager, Gerätetreiber, Datenschutz etc.) unterstützt. Überdies ist jede Applikationsunterstützungsschicht autonom segmentiert.

Durch das Abkoppeln der Applikationsunterstützungsschichten von den lebenswichtigen Hardwaresteuerungsfunktionen und indem sichergestellt wird, dass jede Applikationsumgebung eigenständig unterstützt wird, haben die Anwendungen – aufgrund der Natur des zugrunde liegenden Konzepts – nur sehr eingeschränkten vorübergehenden Zugriff auf geheime »weird states« der CPU.

Verteilte Systemarchitektur 

Softwaredesigns mit zentralen Dienstfunktionen wie Datenschutz sind unverzichtbar, sie lassen sich nicht vermeiden. Mit einem Least-Privilege-Prinzip als Fundament lässt sich ein kritischer Sicherheitsservice vom Kernel abkoppeln, so dass er nur den Anwendungen ausgesetzt ist, die er kennen muss (need-to-know applications). Dennoch muss sich dieser Dienst stabil und widerstandsfähig gegenüber Seitenkanal-angriffe ausführen lassen.

LynxSecure bietet eine feinkörnige Systemkonfigurationskontrolle, die die Möglichkeit ausschließen kann, dass Gäste/Anwendungen auf sensible Informationen zugreifen können – einschließlich einer expliziten Zuordnung von Gästen für CPU-Kerne, einer expliziten Kontrolle der Speicheradressierung, und durch Schreiben/Lesen durchführbare Zuordnung aller CPU-addressierbarer Ressourcen (Speicher, I/O-Geräte, etc.). Wenn gewährleistet wird, dass etwas Geheimes auf CPU-Ressourcen ausgeführt wird, die komplett unabhängig von einem Benutzerprozess sind, dann können Schadprogramme auch nichts Geheimes finden.

Bei Systemen, die nicht über ausreichende Ressourcen verfügen, die kritischen Funktionalitäten zugeordnet werden könnten, muss dem Softwaredesign eine größere Aufmerksamkeit gewidmet werden. Spectre floriert in Softwaredesigns mit einer engen Kopplung zwischen Schad-anwendung und dem Code des Opfers. Herkömmliche OS/Hypervisor-System-APIs sind bevorzugte Ziele für Spectre-Angriffe, da der Angreifer sich in Schnittstellen des Opfers einlinken und den Zielcode des Opfers direkt aufrufen kann. Alternativ dazu koppelt die verteilte Systemarchitektur von LynxSecure Anwendungen und Dienste voneinander ab. Anwendungen können Dienste nicht einfach direkt aufrufen, sondern müssen eine Service-Anfrage stellen und für diese Dienste über Message-APIs Daten hinterlegen.

Dies erlaubt einen höheren Trennungsgrad zwischen Angriffs- und Opfer-Code. Hierdurch wird der Angreifer blind gegenüber der tatsächlichen Dienste-Schnittstelle des Opfers und der Dienste-Code kann auf Nicht-Schnittstellen-Rechenressourcen ausgeführt werden.

Bild 6 zeigt eine alternative System-architektur, wie sie LynxSecure unterstützt. Sowohl wurden erstens die Ressourcen kritischer Dienste physikalisch von den Anwendungen separiert sowie zweitens die Dienste mittels einer Message-API über eine System-Call-Schnittstelle an die Anwendungen angebunden.

Eine Red-Team-Perspektive 

Beim Entwurf von Designs, die auf Sicherheit ausgelegt sind, sollt man eine Red-Team-Perspektive einnehmen, sich fragen, wie Angreifer reagieren werden. Ehe Meltdown und Spectre publik gemacht wurden, dürften Systementwickler sich des zerstörerischen Potenzials nicht bewusst gewesen sein. Schlimmer noch, diese Angriffe sind bei den meisten Systemdesigns nur schwer (wenn nicht unmöglich) aufzudecken.

Dennoch gibt es, wie in diesem Beitrag ausgeführt, kritische Unterschiede zwischen den beiden Angriffstypen. Meltdown ist nachweisbar einfach auszuführen und erfordert wenig oder gar keine Kenntnis des Systems, um riesige Datenschätze zu erfassen. Spectre, auf der anderen Seite, ist viel komplexer und kontextabhängiger und erfordert vermutlich einen ausgeklügelten OS-spezifischen Angriff, um den Exploit erfolgreich zu nutzen.

Da Sicherheitsexperten bereits mögliche Probeangriffe von Hackern bemerkt haben [22], ist in den kommenden Monaten (Anm. d. Red.: seit Februar 2018) ein Angriff durch Meltdown wahrscheinlicher als durch Spectre. Gefolgt von spezifischen OS-konzentrierten Attacken durch Spectre, wenn normale generelle Hacker dann anspruchsvollere Vorgehensweisen der marktführenden Hacker ebenfalls umsetzen.

Deshalb sollte das Augenmerk zuerst auf Immunität gegenüber Meltdown gelegt und zweitens Anleitungen zur Eindämmung von Spectre überlegt werden.

Fazit 

Meltdown und Spectre decken Designfehler mit potenziell verheerenden Folgen für sicherheitskritische Systeme auf. Hierbei erweisen sich Patches abermals als »unzureichender Ansatz zur Bereitstellung von wirklich sicheren Systemen.« [1]

Nach einem ersten Versuch, Spectre zu patchen, riet Intel offiziell dazu, dass »OEMs, Cloud-Service-Anbieter, Systemhersteller, Softwareanbieter und Endbenutzer aufhören sollen, aktuelle Patches zu implementieren, da diese unerwartet viele Neustarts und anderes unvorhersehbares Systemverhalten verursachen könnten.« [5]

Die kritischen Daten von LynxSecure-Anwendern waren durch das Design vor Meltdown sicher. Diese Kunden erhielten auch Anleitungen und erforderliche Tools zur Abmilderung von Spectre. Diese Tools und Entwurfsmethoden haben Systementwickler nicht nur dazu befähigt, in Hinblick auf Meltdown und Spectre ein höchstgradiges Maß an Leistung und Sicherheit aufrechtzuerhalten. Diese können sich mit ihrer Hilfe nun auch besser auf die unvermeidlichen Angriffe der Zukunft vorbereiten.(fr)

Referenzen 

D. J. Rushby, »A Trusted Computing Base for Embedded Systems,« in Proceedings of the 7th Department of Defense/NBS Computer Security Conference, Gaithersburg, Maryland, United States, 1984.

L. Tung, »Meltdown-Spectre: More businesses warned off patching over stability issues,« 15 January 2018. [Online]. http://www.zdnet.com/article/meltdown-spectre-more-businesses-warned-off-patching-over-stability-issues/.

Industrial Control Systems Cyber Emergency Respsonse Team, »Alert (ICS-ALERT-18-011-01B): Meltdown and Spectre Vulnerabilities (Update B),« 11 January 2018. [Online]. https://ics-cert.us-cert.gov/alerts/ICS-ALERT-18-011-01B.

J. Leyden, »Now Meltdown patches are making industrial control systems lurch,« 15 January 2018. [Online]. https://www.theregister.co.uk/2018/01/15/meltdown_ics/.

N. Shenoy, »Root Cause of Reboot Issue Identified; Updated Guidance for Customers and Partners,« 22 January 2018. [Online]. https://newsroom.intel.com/news/root-cause-of-reboot-issue-identified-updated-guidance-for-customers-and-partners/.

I. Ferguson, Privacy, the Competitive Advantage (Conference), London, Greater London, 2016.

Lynx Software Technologies, »Lynx Customers Are Immune To Meltdown,« 22 January 2018. [Online]. Available: http://www.lynx.com/lynx-customers-immune-meltdown/.

D. J. Rushby, »Design and Verification of Secure Systems,« ACM Operating Systems Review Vol. 15 No. 5, pp. 12-21, December, 1981.

RTCA/DO-178C, »Software Considerations in Airborne Systems and Equipment Certification,« RTCA, Inc. [EUROCAE document number: 12C], 2011.

Certification Authorities Software Team, »Position Paper CAST 32-A: Multicore processors,« November 2016. [Online]. https://www.faa.gov/aircraft/air_cert/design_approvals/air_software/cast/cast_papers/media/cast-32A.pdf.

AIR-120, Aviation Safety -Aircraft Certification Service, Aircraft Engineering Division, »20-170 -Integrated Modular Avionics Development. Verification, Integration and Approval using RTCA/DO-297 and Technical Standard Order C153,« 28 October 2010. [Online]. https://www.faa.gov/documentLibrary/media/Advisory_Circular/AC%2020-170.pdf.