Um zu erkennen, warum Software-Lockstep eine interessante Lösung ist, sollte man die Problemfaktoren Physik und Komplexität näher betrachten. Stichwort Physik: Es gibt CPUs, die mit immer höheren Taktgeschwindigkeiten laufen und dabei mehr Wärme erzeugen, jedoch gleichzeitig mit kleineren Transistoren arbeiten, was sich mittlerweile über die Anzahl der Atome messen lässt. Wärme führt zu einem schnelleren Verschleiß, denn je heißer das Bauteil im Betrieb wird, desto früher fällt es aus. Verkleinerte Chips wiederum bedingen Transistoren, die extrem anfällig für Fehler sind, die durch elektromagnetische Störungen, die Auswirkungen von Alphateilchen und Neutronen sowie durch Übersprechen bei benachbarten Zellen hervorgerufen werden. Diese Probleme treten auch in DRAM-Systemen auf; bei modernen DRAMs mit mehreren Gigabyte gehen Experten dabei von Bitfehlern in einer Größenordnung von einem Fehler pro Stunde aus.

Software-Lockstep ermöglicht das Erkennen von Zufallsfehlern beim automatisiertes fahren.

Software-Lockstep ermöglicht das Erkennen von Zufallsfehlern. Fotolia

In Sachen Komplexität lässt sich konstatieren, dass die Hersteller immer mehr in Wechselbeziehung zueinander stehende Funktionen zu den einzelnen CPUs hinzugefügt haben. Leider enthalten CPUs Fehler, von denen viele erst gefunden werden, nachdem der Chip bereits in die Produktion gegangen ist; bekannte Fehler dokumentieren die Hersteller dabei in ihren Fehlerverzeichnissen. Solche Fehler können die Berechnungen beeinträchtigen und zu fehlerhaften Ergebnissen führen – und damit Sicherheitsschwachstellen schaffen. Die Wahrscheinlichkeit derartiger Fehler wirkt sich unmittelbar auf die ASIL-Einstufung gemäß ISO 26262 aus.

Überprüfung

Um solche Fehler zu erkennen und zu überwinden, müssen Systementwickler Kompensationsmechanismen implementieren. Ein möglicher Ansatz hierbei ist, dass das System jede Berechnung mindestens zweimal durchführt und dann die Ergebnisse vergleicht. Einige Mikrocontroller nutzen eine Technik, die unter dem Namen „Hardware Lockstep“ bekannt ist. Hierbei führen zwei CPUs gleichzeitig die gleichen Anweisungen aus, und eine spezielle Hardware vergleicht die Ergebnisse. Wenn die Hardware eine Abweichung entdeckt, ermittelt eine unabhängige Diagnose-Routine, welche CPU fehlerhaft war, und die Systemsoftware ergreift daraufhin Abhilfemaßnahmen. Leider unterstützt diese Technik in der Regel nur Repliken und keine verschiedenen Implementierungen. Zudem kann sie keine Softwarefehler erkennen – schließlich führen beide CPUs den fehlerhaften Code „korrekt“ aus – und sie ist nicht skalierbar, da die Anzahl der Repliken von der Hardware fest vorgegeben ist. Weiterhin ist diese Technik für die heutige Hochleistungshardware nicht sonderlich praktisch, da es bei einer Hardwareprüfung viel zu viele Informationen zum internen Status zu überprüfen gibt.

Eckdaten

Dieser Beitrag beschreibt eine Architektur, die eine äußerst flexible und dynamische Methode zum Erkennen von Zufallsfehlern darstellt, die die Sicherheit eines Systems beeinträchtigen. Dem liegt als tragendes Prinzip die feste Zuordnung von Ereignissen zu allen Mitgliedern einer Servergruppe zugrunde. Damit steht praktisch ein Software-Lockstep zur Verfügung, der nicht den Beschränkungen des Hardware-Lockstep unterliegt. Da die Serverinstanzen den Gruppen dynamisch beitreten und diese wieder verlassen können, kann der Grad der Widerstandsfähigkeit auf die Umgebung abgestimmt werden, in der das System aktiv ist. Wenn beispielsweise ein Fahrzeug auf einer Autobahn unterwegs ist, kann ein anderer Grad von Widerstandsfähigkeit erforderlich sein als bei einer Fahrt in einem Stadtzentrum.

In der Praxis kann ein System mittels Software die Funktion der Hardware überprüfen. Hierbei implementiert der Entwickler eine replizierte Kopie der Software, und mithilfe der zwei oder mehr Repliken wird dann die Überprüfung vorgenommen. Jede Replik führt sicherheitskritische Berechnungen durch – zum Beispiel „Kann unter diesen Bedingungen beschleunigt werden?“ – und Middleware nimmt die Berechnungen mit für die Anwendung unsichtbaren Synchronisationspunkten vor.

Jedes Replikationsmodell hat seine Vor- und Nachteile. In dem Modell mit der identischen Replikation ergeben zwei identische Berechnungen auf unterschiedlichen Threads mit unterschiedlichem Speicher das gleiche korrekte Ergebnis – es sei denn, ein vorübergehender Hardware- oder zufälliger Softwarefehler tritt auf. In diesem Fall betrifft der Fehler nur eine der Instanzen, aber nicht beide. Wenn es nur zwei Repliken gibt, ist irgendeine Form der Fehlerbehebung erforderlich, da hier nicht ermittelt werden kann, welche Replik richtig arbeitet. Gibt es mehr als zwei Repliken, dann kann das Mehrheitsergebnis verwendet werden.

Natürlich lassen sich mit diesem Vorgehen zwar die schwer zu fassenden Heisenbugs in der Software erkennen und kompensieren, aber eine Behebung von Bohrbugs in der Software ist damit nicht möglich. Um dies zu ermöglichen, könnte ein System „Bruderrepliken“ (Fraternal Replicas) verwenden, die die gleichen Berechnungen durchführen, dabei aber unterschiedliche Algorithmen verwenden. Wenn diese Repliken zu dem gleichen Schluss kommen und sich zum Beispiel beide einig sind, dass beschleunigt werden kann, ist das allgemeine Vertrauen in die Richtigkeit des Ergebnisses größer.

Thema auf der nächsten Seite: Implementierung einer Replikation.

Seite 1 von 3123