Anbieter zum Thema

MicroConsult Academy GmbH

emlix GmbH

Komplementäre Ansätze für den Schutz vor Beeinflussung

Generell ist es das Beste, mit komplementären Techniken so viele Komponenten wie möglich voneinander zu isolieren.

Ein möglicher Ansatz ist die Betriebssystemarchitektur. Bei einem Betriebssystem mit Mikrokernel laufen alle Komponenten (auch Dateisystem, Gerätetreiber, Netzwerkstack usw.) in separaten Adressräumen und sind sowohl gegen den Kernel als auch gegeneinander isoliert. Weitere Ansätze wären:

• Adaptive Partitionierung — Bei der sogenannten adaptiven Zeitpartitionierung wird einer Gruppe von Threads ein Mindestanteil an Prozessorzeit zugewiesen, allerdings nur dann, wenn die Threads diesen auch benötigen. Sicherzustellen, dass Prozesse nicht mangels CPU-Zeit verhungern, wird durch adaptive Zeitpartitionierung deutlich vereinfacht. Diese Technik kann bei komplexen Systemen eingesetzt werden, für die sich RMS (ratenmonotones Scheduling) nicht eignet.

• Datendiversifizierung und Coded Processors — Unter Datendiversifizierung versteht man das Speichern von Daten in mehreren unterschiedlichen Semantiken. Durch eine solche Diversifizierung steigt das Konfidenzniveau bezüglich der Datenintegrität. Man stützt sich dabei auf die Annahme, dass ein Algorithmus zwar ein falsches Ergebnis liefern kann, es aber unwahrscheinlich ist, dass zwei unterschiedliche Algorithmen dasselbe falsche Ergebnis liefern.

• Erkennung von Anomalien — Schon seit Langem kommen Prädiktor-Korrektor-Methoden wie etwa Kalman-Filter zum Einsatz, um Anomalien in Sensordaten zu erkennen. Für die Erkennung von Anomalien in Systemvariablen, deren Wert nur selten von stochastischem Rauschen betroffen ist, eignen sich diese Methoden weniger gut.

• Fortschrittsüberwachung — Programme zur Überwachung des Fortschritts überwachen Systemindikatoren und ergreifen Maßnahmen, falls das System stehen bleibt bzw. ins Stocken gerät. Häufig werden Prozessausfälle überwacht – die extremste Form des Ausbleibens von Fortschritt.

Techniken zur Validierung des Komponentenschutzes

Auditoren und Aufsichtsbehörden verlangen Nachweise dafür, dass die Grenzen zwischen den isolierten Komponenten nicht verletzt werden. Es gibt zahlreiche Techniken und Tools, um zu beweisen, dass diese Anforderungen erfüllt sind.

Diskrete ereignisorientierte Simulation: Wenn die Korrektheit eines Algorithmus, Protokolls oder der Isolierung nicht bewiesen werden kann – wenn beispielsweise die Verteilung von Ereignissen nur empirisch ermittelt werden kann –, können diskrete ereignisorientierte Simulationen (DES) ein statistisches Konfidenzniveau für die Korrektheit der Annahmen liefern.

Formale Designprüfung: Der Zeitaufwand für Tests lässt sich deutlich reduzieren, wenn sich beweisen lässt, dass ein Design korrekt ist, und aus diesem Design sodann automatisch Code generiert wird.

Statische Code-Analyse: Eine Schwäche von statischer Codeanalyse besteht darin, dass sie dazu neigt, Fehler zu entdecken, die bei näherer Betrachtung gar keine sind. Außerdem ist statische Analyse bei den im Embeeded-Bereich verwendeten Sprachen (zum Beispiel C mit seinen Zeigern) wenig effektiv. Allerdings sind inzwischen ausgefeilte Tools für statische Analyse verfügbar, die speziell bei der Nutzung von sogenannten Codeverträgen sowie symbolischer Ausführung deutlich verbessert wurden.

Flow-Tagging: Mit Flow-Tagging lässt sich beweisen, dass unter den getesteten Bedingungen keine unangemessene Interaktion zwischen isolierten Komponenten aufgetreten ist. Kombiniert man diese Technik mit Assert-Anweisungen, die lineare temporale Logikinvarianten enthalten, sind anspruchsvolle Analysen der Interaktion von Komponenten möglich, die Aussagen bezüglich ihrer Isolation stützen können.

Vermeidung von Deadlocks und Livelocks

Coffmann stellte seine vier Bedingungen, die für einen Deadlock erfüllt sein müssen, bereits 1971 auf. Heute betrachten wir sowohl Deadlocks als auch Livelocks als Formen von Nichtfortschritt, also als nicht erfüllte Lebendigkeitsbedingungen. Der Beweis der Korrektheit von Annahmen über die Lebendigkeit ist per se schwierig, weil der abzusuchende Raum im Prinzip unbegrenzt ist: Was könnte das System in der Zukunft tun? Dennoch können Tools dabei helfen, Deadlocks und Livelocks in diversen Phasen der Systementwicklung zu erkennen.

Tools, die Deadlocks und Livelocks in der Designphase erkennen können, analysieren meist ein abstraktes Modell des Systems, das die Hardware und die Software einschließt. Einige Tools können Code aus dem Design generieren, wenn seine Korrektheit bewiesen werden konnte. Wird das Design dagegen manuell implementiert, besteht die Gefahr von Fehlern. Die korrekte Implementierung könnte so kompromittiert werden.

Statische Analyse-Tools, die in der Codierphase zum Einsatz kommen, können manchmal mögliche Deadlocks erkennen. Jedoch ist dies bei Sprachen wie C schwieriger als bei komplett definierten oder stark und statisch typisierten Sprachen. Diese Tools führen zahlreiche Operationen aus, die von der Extraktion von Semantikinformationen aus im Code eingebetteten Verträgen (in Sprachen, die keine vertragsbasierte Programmierung unterstützen, können diese Verträge als Kommentare vorliegen) bis zu symbolischer Ausführung reichen – einer Kreuzung aus dynamischem Test und statischer Analyse.

Laufendes System: Viele Systeme besitzen einen Hardware-Watchdog, der regelmäßig angestoßen werden muss. Die Entscheidung, welcher oder welche Prozess(e) den Wachhund anstoßen sollen, fällt jedoch schwer, weil der Watchdog für Deadlocks von Prozessen blind ist, von denen er gar nicht erwartet, dass sie ihn anstoßen. Es ist daher oft hilfreich, Bedingungen zu definieren, die garantieren, dass Fortschritt erfolgt, und einen Softwareprozess darauf anzusetzen, die Bedingung zu überwachen und im Fall von ausbleibendem Fortschritt Maßnahmen einzuleiten.

* Yi Zheng ist Produktmanagerin für Safe and Secure Systems bei QNX Software Systems.

* Chris Hobbs ist Senior Developer für Sichere Systeme bei QNX Software Systems.

(ID:43334953)