DE102011108077A1

DE102011108077A1 - Verfahren zur Speicherplatzverwaltung in einem multitaskingfähigen Datenverarbeitungssystem

Info

Publication number: DE102011108077A1
Application number: DE102011108077A
Authority: DE
Inventors: Robert Breker; Alexander Schäffer
Original assignee: LFK Lenkflugkoerpersysteme GmbH
Current assignee: MBDA Deutschland GmbH
Priority date: 2010-08-13
Filing date: 2011-07-21
Publication date: 2012-03-22
Also published as: US8839264B2; US20120042324A1

Abstract

Die Erfindung betrifft ein Verfahren zur Speicherplatzverwaltung in einem multitaskingfähigen Datenverarbeitungssystem () mit einer Datenverarbeitungsi die Datenverarbeitungseinrichtung () zumindest eine CPU () und zumindest einen Arbeitsspeicher () aufweist und wobei die auf der CPU () ablaufende Software eine erste Computerprogrammanwendung und zumindest eine zweite Computerprogrammanwendung aufweist, die während des Ablaufs jeweils auf den von beiden Computerprogrammanwendungen gemeinsam genutzten Arbeitsspeicher () zugreifen; wobei Information der ersten Computerprogrammanwendung in zumindest einem Teil der Speicherplätze des Arbeitsspeichers () temporär gespeichert wird und wobei die Integrität der Inhalte dieser Speicherplätze nach einer Unterbrechung der Ausführung der ersten Computerprogrammanwendung überprüft wird und wobei die erste Computerprogrammanwendung nur dann weiter ausgeführt wird wenn durch die Überprüfung die Speicherintegrität bestätigt wird oder wenn die Speicherintegrität wiederhergestellt worden ist.

Description

TECHNISCHES GEBIET
Die vorliegende Erfindung betrifft ein Verfahren zur Speicherplatzverwaltung in einem multitaskingfähigen Datenverarbeitungssystem. Sie betrifft weiterhin ein Computersystem zur Durchführung eines derartigen Verfahrens sowie ein Computerprogrammprodukt. Des Weiteren ist die Erfindung gerichtet auf die Integration von sicherheitsrelevanter Software in einem mittels Software steuerbaren Gerät.
HINTERGRUND DER ERFINDUNG
Läuft auf einem mittels Software steuerbaren Gerät eine sicherheitsrelevante Software, die beispielsweise für die zuverlässige und sichere Funktionsfähigkeit des Geräts unabdingbar erforderlich ist und ist die Gewährleistung der Funktionsfähigkeit eine Voraussetzung für den Betrieb dieses Geräts, so muss sichergestellt sein, dass die sicherheitsrelevante Software nicht durch Störung von außen, beispielsweise durch andere Software, die auch zusammen mit der sicherheitsrelevanten Software auf einem Computer des Geräts läuft, außer Funktion gesetzt wird. Derartige Störungen können beispielsweise dann auftreten, wenn die nicht-sicherheitsrelevante Software in einem Arbeitsspeicher zwischengespeicherte Information (Daten oder Befehle) der sicherheitsrelevanten Software verändert oder löscht.
Sicherheitsrelevante Software ist folglich vor nicht-sicherheitsrelevanter Software räumlich und zeitlich zu separieren, um eine gegenseitige Beeinflussung unter anderem im Fehlerfall auszuschließen. Dies ist einen Nachweis der Sicherheit erforderlich, wie er beispielsweise bedingt für die IEC 61508, einer Norm für sicherheitsrelevante programmierbare Systeme erfolgen muss.
In dem im folgenden beschriebenen Szenario wird davon ausgegangen, dass auf einem System ein multitaskingfähiges Betriebssystem ohne ausreichende Sicherheitsintegrität betrieben wird. Das Betriebssystem hat vollen Zugriff auf die gesamte Hardware. Auf dem System soll eine sicherheitsrelevante Komponente ausgeführt werden. Diese nutzt für ihre Funktionserbringung keine Dienste oder Funktionen des Betriebssystems.
Obwohl keine Separierung zwischen Komponenten gewährleistet wird, soll eine sicherheitsrelevante Komponente jederzeit die eigene Integrität und damit Sicherheit gewährleisten können.
Mit dem Verzicht auf die Separierung haben niedriger eingestufte Komponenten vollen Zugriff auf den Speicher der sicherheitsrelevanten Komponente. Damit können infolge eines Fehlers beliebige Speicherinhalte der sicherheitsrelevanten Komponente überschrieben werden. Dies kann im besten Fall keine Auswirkungen haben, zu einem Absturz der sicherheitsrelevanten Komponente führen, oder auch die Funktion und das Verhalten der sicherheitsrelevanten Komponente beeinträchtigen. Von den letzten beiden Fällen geht eine Gefahr aus, welche vermieden werden muss. Der Gefahr kann durch das Sicherstellen der Speicherintegrität begegnet werden.
Speicherintegrität bedeutet, dass der Zustand einer Komponente, der zu einer Komponente gehörenden Speicher, nur durch Ausführung einer Komponente selbst und nicht durch Dritte verändert werden kann. Hierdurch wird gewährleistet, dass die sicherheitsrelevante Komponente stets die in ihr implementierte Funktion erbringt und keine hiervon abweichende. Die Zeitpunkte, an denen die Speicherintegrität verletzt werden kann, lassen sich klar eingrenzen. Zu Verletzungen kann es immer dann kommen, wenn niedriger eingestufte Komponenten ausgeführt werden. Damit muss nur immer genau dann die Speicherintegrität sichergestellt werden, wenn die sicherheitsrelevante Komponente gerade nicht aktiv ist.
STAND DER TECHNIK
In 1 ist ein Steuergerät 1 nach dem Stand der Technik gezeigt mit einem Prozessor 10 und einem sicherheitsrelevanten Betriebssystem 11, welches zur Sicherstellung der Speicherintegrität zertifiziert ist, sowie mit einer sicherheitsrelevanten und zertifizierten ersten Steuereinheit 12 und einer weiteren nicht-sicherheitsrelevanten und damit nicht-zertifizierten Steuereinheit 13. Die Steuereinheiten 12, 13 sind jeweils mit Sensoren 14 beziehungsweise 15 verbunden und geben jeweils Signale an Aktoren 16 beziehungsweise 17 ab.
In 2 ist als alternatives Design eines sicheren Computersystems ein Steuergerät 2 nach dem Stand der Technik gezeigt, welches zwei Prozessoren 20, 21 aufweist. Auf jedem dieser Prozessoren läuft ein eigenständiges Betriebssystem 22, 23 und jeder dieser Prozessoren umfasst eine eigene Steuereinheit 24, 25. Um die erforderliche Sicherheit zu gewährleisten, ist der Prozessor 20 mit einem sicherheitsrelevanten Betriebssystem 22 und einer sicherheitsrelevanten Steuereinheit 24 versehen. Sowohl das sicherheitsrelevante Betriebssystem 22 als auch die sicherheitsrelevante Steuereinheit 24 müssen entsprechend den jeweils geltenden Sicherheitsvorschriften, beispielsweise gemäß der IEC 61508, zertifiziert sein. Die Steuereinheiten 24, 25 sind jeweils mit Sensoren 16 beziehungsweise 27 verbunden und geben jeweils Signale an Aktoren 28 beziehungsweise 29 ab. Das Design in 2 setzt zudem voraus, dass auf der Hardwareplattform eine Speicherverwaltungseinheit (Memory Management Unit MMU) vorhanden ist. Ohne MMU ist die eigentlich nicht-sicherheitsrelevante Software doch sicherheitsrelevant.
3 zeigt als noch ein weiteres Design eines sicheren Computersystems ein Steuergerät 3 nach dem Stand der Technik mit zwei voneinander unabhängigen Hardware-Konfigurationen 30, 31, wovon eine Hardware-Konfiguration 30 zertifiziert ist. Diese zertifizierte Hardware-Konfiguration umfasst eine Hardware-Steuereinheit, die als zertifizierte sicherheitsrelevante Steuereinheit 32 ausgebildet ist. Die andere nicht-sicherheitsrelevante Hardwarekonfiguration 31 umfasst ein Betriebssystem 33 und eine als Software ausgebildete Steuereinheit 34. Die beiden Hardware-Konfigurationen 30, 31 sind jeweils mit Sensoren 36 beziehungsweise 37 zur Zuführung von Eingangssignalen verbunden und sind zur Abgabe von Steuersignalen mit Aktoren 38 beziehungsweise 39 verbunden.
Alternativ zu Betriebssystemen wird ebenfalls häufig ein sicherheitsrelevanter Hypervisor genutzt. Dieser kann entweder die Rolle eines Betriebssystems, wie in 2, einnehmen und zwei verschiedene Betriebssysteme, von welchen eines sicherheitsrelevant ist, ausführen, oder er kann zwei separate Hardwareplattformen, wie in 3 dargestellt, simulieren, auf denen jeweils Betriebssysteme ausgeführt werden.
Diese bekannten Designs von sicheren Computersystemen sind aufwendig aufgebaut und haben einen großen Zertifizierungsaufwand.
DARSTELLUNG DER ERFINDUNG
Aufgabe der vorliegenden Erfindung ist es daher, ein einfaches und kostengünstig realisierbares Verfahren zur Speicherplatzverwaltung in einem multitaskingfähigen Datenverarbeitungssystem anzugeben, bei welchem sichergestellt ist, dass eine sicherheitsrelevante Software nicht durch von einer nicht-sicherheitsrelevanten erfolgende Speicherzugriffe in ihrer Funktionsfähigkeit gestört wird, um so sicherheitsrelevante Software mit anderer Software auf einem Steuergerät ausführen zu können. Außerdem sollen ein das Verfahren implementierendes Computersystem und Computerprogrammprodukt angegeben werden.
Diese Aufgabe wird durch das im Patentanspruch 1 angegebene Verfahren gelöst.
Bei diesem Verfahren zur Speicherplatzverwaltung in einem multitaskingfähigen Datenverarbeitungssystem mit einer Datenverarbeitungseinrichtung und darauf laufender Software, wobei die Datenverarbeitungssystem zumindest eine CPU und zumindest einen Arbeitsspeicher aufweist und wobei die auf der CPU ablaufende Software eine erste (sicherheitsrelevante) Computerprogrammanwendung und zumindest eine zweite (nicht-sicherheitsrelevante) Computerprogrammanwendung aufweist, die während des Ablaufs jeweils auf den von beiden Computerprogrammanwendungen gemeinsam genutzten Arbeitsspeicher zugreifen, wobei Information der ersten Computerprogrammanwendung in zumindest einem Teil der Speicherplatz des Arbeitsspeichers temporär gespeichert wird, wird die Integrität der Inhalte dieser Speicherplätze nach einer Unterbrechung der Ausführung der ersten Computerprogrammanwendung überprüft und die erste Computerprogrammanwendung wird nur dann weiter ausgeführt, wenn entweder durch die Überprüfung die Speicherintegrität bestätigt wird oder wenn die Speicherintegrität wiederhergestellt worden ist.
VORTEILE
Auf diese Weise wird durch den erfindungsgemäßen Verfahrensablauf dafür Sorge getragen, dass die erste, sicherheitsrelevante Programmanwendung nicht durch einen Speicherfehler zum Absturz gebracht wird. Weitere wesentliche Vorteile sind:

– es wird kein sicherheitsrelevantes (zertifiziertes) Betriebssystem oder ein Hypervisor oder gegebenenfalls zusätzliche sicherheitsrelevante Software benötigt;
– die zusätzlich benötigte Rechenzeit ist oft geringer als bei Verwendung eines sicherheitsrelevanten Betriebssystems oder Hypervisors;
– seitens der Hardware wird keine Speicherverwaltungseinheit (MMU) benötigt, es wird weniger Speicher benötigt;
– Hardware, Entwicklung und Wartung erfordern geringere Kosten.

Eine erste vorteilhafte Ausführungsform des erfindungsgemäßen Verfahrens zeichnet sich dadurch aus, dass die Information der ersten Computerprogrammanwendung in den Speicherplätzen des Arbeitsspeichers zumindest zweifach gespeichert wird, dass nach dem Auslesen einer ersten Information aus den Speicherplätzen des Arbeitsspeichers und vor der Weiterverarbeitung der Information in der ersten Computerprogrammanwendung die ausgelesene erste Information mit der zweiten, parallel gespeicherten Information verglichen wird und bei Übereinstimmung die Speicherintegrität verifiziert wird. Bei dieser Ausführungsform werden somit die Speicherinhalte redundant vorgehalten und zur Verifizierung der Speicherintegrität miteinander verglichen. Der Vorteil dieser Methode besteht darin, dass die erforderliche Rechenkapazität minimal ist, wobei allerdings der Speicherplatzbedarf aufgrund der redundanten Speicherung hoch ist.
Eine zweite, alternative vorteilhafte Ausführungsform des erfindungsgemäßen Verfahrens zeichnet sich dadurch aus, dass für die in den Speicherplätzen des Arbeitsspeichers gespeicherte Information der ersten Computerprogrammanwendung vor dem Abspeichern eine Prüfsumme berechnet wird, die zusammen mit der Information abgespeichert wird, dass nach dem Auslesen der Information aus den Speicherplätzen des Arbeitsspeichers und vor der Weiterverarbeitung der Information in der ersten Computerprogrammanwendung erneut die Prüfsumme berechnet, mit der gespeicherten Prüfsumme verglichen wird und bei Übereinstimmung die Speicherintegrität verifiziert wird. Bei dieser Ausführungsform ist der Speicherplatzbedarf minimiert, allerdings wird für die Berechnung der Prüfsummen Rechenkapazität benötigt. Die Berechnung einer Prüfsumme erfolgt schneller als ein Vergleich oder eine Kopie von Speicherinhalten, da nur halb so viele Speicherzugriffe erforderlich sind.
Bei dieser zweiten vorteilhaften Ausführungsform des erfindungsgemäßen Verfahrens zeichnet sich eine vorteilhafte Weiterbildung dadurch aus, dass die erste Computerprogrammanwendung in einer Schleife ausgeführt wird, wobei vor dem Auslesen der Information aus den Speicherplätzen des Arbeitsspeichers und der Berechnung der Prüfsumme alle Interrupt-Routinen ausgeschaltet werden, die die erste Computerprogrammanwendung unterbrechen könnten, und wobei die Interrupt-Routinen erst dann wieder eingeschaltet werden, wenn die Information nach Berechnung der neuen Prüfsumme wieder im Arbeitsspeicher gespeichert worden ist.
Eine alternative vorteilhafte Weiterbildung der zweiten Ausführungsform erfordert, dass im Datenverarbeitungssystem ein eigenständiger Scheduler für die erste Computerprogrammanwendung vorgesehen ist, der von der ersten Computerprogrammanwendung auszuführende Aufgaben verwaltet und der unabhängig ist von Schedulern zur Verwaltung anderer auf der Datenverarbeitungseinrichtung laufender Computerprogrammanwendungen. Diese alternative Ausführungsform zeichnet sich dadurch aus, dass nach dem Aufrufen des eigenständigen Schedulers für die erste Computerprogrammanwendung zunächst alle Interrupt-Routinen, die die erste Computerprogrammanwendung unterbrechen könnten, ausgeschaltet werden bevor die in den Speicherplätzen des Arbeitsspeichers gespeicherte Information der ersten Computerprogrammanwendung abgerufen wird; dass die Interrupt-Routinen erst dann vom Scheduler wieder eingeschaltet werden wenn zumindest eine der von der ersten Computerprogrammanwendung auszuführenden Aufgaben abgearbeitet worden und die Information der ersten Computerprogrammanwendung in den Speicherplätzen des Arbeitsspeichers wieder gespeichert worden ist. Diese Ausführungsform hat gegenüber der vorherigen Ausführungsform den Vorteil, dass für die sicherheitsrelevante Computerprogrammanwendung auch präventives Multitasking genutzt werden kann.
Der das Computersystem betreffende Teil der Aufgabe wird gelöst durch ein Computersystem mit den Merkmalen des Patentanspruch 6.
Dieses erfindungsgemäße Computersystem ist mit einer multitaskingfähigen Ausführungsumgebung versehen, in der eine erste Computerprogrammanwendung und zumindest eine zweite Computerprogrammanwendung läuft, wobei die Ausführungsumgebung zumindest eine zentrale Prozessoreinheit (CPU) und zumindest einen Arbeitsspeicher aufweist. Das erfindungsgemäße Computersystem zeichnet sich aus durch Mittel zur Überprüfung der Integrität der Inhalte von Speicherplätzen des zumindest einen Arbeitsspeichers und Mittel, durch die der ersten Computerprogrammanwendung gemeldet wird, dass sie weiterlaufen kann, wenn bei der Überprüfung die Speicherintegrität verifiziert wurde. Ein Computersystem oder Datenverarbeitungssystem im Sinne der vorliegenden Erfindung umfasst Hardware und Software.
”Auf einem Computer Laufend” oder ”in einer Ausführungsumgebung laufend” bedeutet, dass das aus einem Computerprogramm samt Computer bestehende System ein Verfahren durchführt, das so geartet sein kann wie das Verfahren gemäß Patentanspruch 1 oder einem der auf Patentanspruch 1 rückbezogenen Verfahrensansprüche 2 bis 5.
Die Erfindung ist weiterhin gerichtet auf ein Computerprogrammprodukt, das direkt in einen Arbeitsspeicher eines digitalen Computersystems geladen werden kann und Softwarecodeabschnitte umfasst, mit denen die Schritte gemäß Anspruch 1 ausgeführt werden können. Selbstverständlich umfasst die Erfindung auch Computerprogrammprodukte, mit denen die Schritte der auf Anspruch 1 rückbezogenen Verfahrensansprüche 2 bis 5 ausgeführt werden können.
”In einen Computer geladen” bedeutet, dass der so programmierte Computer zur Durchführung eines Verfahrens, das so geartet sein kann, wie das Verfahren gemäß Patentanspruch 1, fähig oder hierfür entsprechend angepasst ist und somit ein System oder eine Vorrichtung beziehungsweise ein Gerät verkörpert, das so geartet sein kann, wie das Computersystem gemäß Patentanspruch 6.
Besonders vorteilhaft wird erfindungsgemäß ein Computerprogrammprodukt geschaffen, das auf einem computergeeigneten Medium gespeichert ist und Folgendes umfasst:

– computerlesbare Programmmittel, die einen Computer veranlassen, die Ausführung einer Computerprogrammanwendung zu überwachen;
– computerlesbare Programmmittel, die den Computer zur Überprüfung der Integrität der Inhalte von Speicherplätzen des zumindest einen Arbeitsspeichers veranlassen;
– computerlesbare Programmmittel, die den Computer zur Abgabe einer Meldung an die Computerprogrammanwendung veranlassen, dass sie weiterlaufen kann, wenn bei der Überprüfung die Speicherintegrität verifiziert wurde.

Selbstverständlich können dazu in diesem erfindungsgemäßen Computerprogrammprodukt auch noch computerlesbare Programmmittel vorgesehen sein, die eine Durchführung der in den vom Patentanspruch 1 abhängigen Verfahrensansprüchen 2 bis 5 spezifizierten Verfahrensschritte durchführen können.
Eine besonders vorteilhafte Applikation der Erfindung ist die Integration von sicherheitsrelevanter Software in einem mittels Software steuerbaren Gerät, welches einen softwareunterstützten Rechner mit wenigstens einer CPU und einem Betriebssystem enthält, mit wenigstens einem Speicher, einer bezüglich der Funktion des Geräts sicherheitskritischen ersten Software und wenigstens einer weiteren, rangmäßig niedrigeren und nicht sicherheitsrelevanten Software, mit einer als Hardware ausgeführten Watchdogschaltung, welche die Abläufe der ersten Software kontrolliert und im Fall einer Fehlfunktion einen Reset zumindest in einem abgesicherten Modus auslöst, wobei bei wechselweisem Zugriff der ersten und der weiteren Software auf den Speicher bei jedem Wechsel eine Prüfsumme über den Speicherinhalt berechnet wird und diese mit einer weiteren Prüfsumme verglichen wird, die nach einem weiteren Wechsel zu einer sicherheitskritischen Software errechnet wird, und wobei im Fall der Nichtübereinstimmung dieser Prüfsummen der Speicherinhalt vor dem Wechsel wieder aktiviert wird.
Auf besonders vorteilhafte Weise wird diese Integration bei einem Gerät verwirklicht, welches als Fluggerät mit einer Datenlinküberwachung ausgeführt ist.
Bevorzugte Ausführungsbeispiele der Erfindung mit zusätzlichen Ausgestaltungsdetails und weiteren Vorteilen sind nachfolgend unter Bezugnahme auf die beigefügten Zeichnungen näher beschrieben und erläutert.
KURZE BESCHREIBUNG DER ZEICHNUNGEN
Es zeigt:
1 ein Einsatz eines zertifizierten Betriebssystems gemäß dem Stand der Technik;
2 eine Trennung durch Einsatz mehrerer Prozessoren gemäß dem Stand der Technik;
3 eine Trennung durch Implementierung in Hardware (HW) gemäß dem Stand der Technik;
4 eine allgemeine Anwendung des erfindungsgemäßen Verfahrens;
5 eine projektspezifische Anwendung analog zur Anwendung in 6 zur Datenlinküberwachung in einem Flugführungsrechner;
6 ein Beispiel einer Implementierung des erfindungsgemäßen Verfahrens als Programmschleife;
7 ein Linkerscript für die Integritätsprüfung;
DARSTELLUNG VON BEVORZUGTEN AUSFÜHRUNGSBEISPIELEN
4 zeigt eine allgemeine Applikation gemäß der vorliegenden Erfindung. Diese Applikation weist ein Steuergerät 4 mit nur einem Prozessor 40 und einem nicht zertifizierten Betriebssystem 42 sowie einer sicherheitsrelevanten und zertifizierten ersten Steuereinheit 43 und einer weiteren nicht-sicherheitsrelevante und damit nicht-zertifizierten Steuereinheit 44 auf. Der sicherheitsrelevanten Steuereinheit 43 ist eine Hardware-Überwachungsschaltung, ein sogenannter Watchdog, 45 zugeordnet. Die sicherheitsrelevante Steuereinheit 43 ist weiterhin mit in der 4 nur schematisch dargestellten Sensoren 46 verbunden, von denen Sensorsignale an die Steuereinheit 43 geliefert werden. Die sicherheitsrelevante Steuereinheit 43 gibt ihrerseits Steuersignale an ebenfalls nur schematisch dargestellte Aktoren 48 aus. Auch die nicht-sicherheitsrelevante Steuereinheit empfängt Signale von mit ihr verbundenen Sensoren 47 und sendet Signale an mit ihr verbundene Aktoren 49. Die Steuereinheiten 43 und 44 sind in Software implementiert.
In 5 ist eine spezielle Applikation der in 4 gezeigten allgemeinen erfindungsgemäßen Anwendung dargestellt. Bei dieser projektspezifischen Anwendung handelt es sich um eine Datenlinküberwachung eines Lenkflugkörpers. Das Steuergerät ist hier von einem Flugführungsrechner (FFR) 4' gebildet und der Prozessor ist ein Power-PC-Prozessor (PPC) 40'. Als Betriebssystem 42' wird ein VxWorks-Betriebssystem eingesetzt. In dieser projektspezifischen Anwendung ist die als Software ausgebildete sicherheitsrelevante Steuereinheit eine Datenlinküberwachung 43', der eine Hardwareüberwachung 45' zugeordnet ist.
Die über den Sensoreingang der Datenlinküberwachung 43' empfangenen Signale kommen von einem Datenlinkempfänger 46' des Lenkflugkörpers und die von der Datenlinküberwachung 43' ausgesandten Signale werden an Aktoren 48' eines Ruderstellsystems des Lenkflugkörpers ausgegeben.
Die nicht-sicherheitsrelevante und ebenfalls als Software ausgebildete Steuereinheit 44' umfasst die Software des Flugführungsrechners, die als Sensorsignale Signale eines Suchkopfes 47' und einer inertialen Messeinheit (IMU) 47'' erhält. Die von der Steuersoftware 44' des Flugführungsrechners abgegebenen Steuersignale werden ebenfalls an Aktoren 49' des Ruderstellsystems ausgegeben.
Um zu gewährleisten, dass die als Software ausgebildete sicherheitsrelevante Steuereinheit 43, beispielsweise die Datenlinküberwachung 43', nicht durch Speicherzugriffe der nicht-sicherheitsrelevanten Steuereinheit 44, beispielsweise der Software 44' des Flugführungsrechners, in ihrem Ablauf dadurch gestört wird, dass durch Zugriff der nicht-sicherheitsrelevanten Steuereinheit auf von der sicherheitsrelevanten Steuereinheit belegte Speicherplätze gespeicherte Information (Daten oder Befehle) der sicherheitsrelevanten Steuereinheit verändert oder gelöscht wird, wird die Integrität der Inhalte der von der sicherheitsrelevanten und als Software ausgebildeten Steuereinheit belegten Speicherplätze nach Unterbrechung der Ausführung dieser sicherheitsrelevanten Steuereinheit überprüft. Die Software der sicherheitsrelevanten Steuereinheit wird nur dann weiter ausgeführt, wenn durch die Überprüfung die Speicherintegrität bestätigt wird. Diese Überprüfung der Speicherintegrität kann beispielsweise auf zwei unterschiedlichen Wegen durchgeführt werden.
Eine erste Möglichkeit der Überprüfung der Speicherintegrität besteht darin, alle Speicherinhalte redundant vorzuhalten. Bei einem Vergleich der Inhalte ist mit relativ hoher Wahrscheinlichkeit ausgeschlossen, dass die Speicherinhalte zwei Mal mit exakt denselben Werten überschrieben worden sind. Die Problematik hierbei ist, dass keine Wahrscheinlichkeit dafür bestimmt werden kann. Der Problemstellung kann durch eine kontrollierte Verschlüsselung der Speicherinhalte in Abhängigkeit von der Kopie oder durch das Hinzufügen von bestimmten Schlüsseln in Abhängigkeit von der Kopie begegnet werden.
Eine zweite, noch einfachere Möglichkeit zur Überprüfung der Speicherintegrität ist die Verwendung von Prüfsummen für die Speicherinhalte. Anhand von Prüfsummen kann mit einer berechenbaren Wahrscheinlichkeit verifiziert werden, dass die durch die Prüfsumme erfassten Speicherinhalte unverändert sind. Der Vorteil bei der Verwendung einer Prüfsumme ist, dass nicht die doppelte Menge an Speicher benötigt wird. Zudem ist die Berechnung der Prüfsumme schneller als ein Vergleich oder eine Kopie von Speicherinhalten, da nur halb so viele Speicherzugriffe erforderlich sind. Aufgrund der Vorteile wird im Folgenden ausschließlich der Ansatz mit der Prüfsumme beschrieben. Zur Sicherstellung der Speicherintegrität durch eine Prüfsumme muss vor jedem Kontextwechsel weg von einer sicherheitsrelevanten Komponente der Programmanwendung die Prüfsumme berechnet werden. Nach dem Wechsel hin zu einer sicherheitsrelevanten Komponente der Programmanwendung wird die Prüfsumme abermals berechnet und mit dem letzten Wert verglichen. Stimmt sie überein, so ist die Integrität gewährleistet und die sicherheitsrelevante Komponente der Programmanwendung kann ihre Ausführung fortsetzen.
Eine Option zur Umsetzung dieser zweiten Möglichkeit ist, die sicherheitsrelevante Komponente der Programmanwendung in einer Schleife zu implementieren, wie in 6 gezeigt ist. Die Task mit der Schleife wird hierbei als ganz normale Kernelmode-Task von dem Betriebssystem ohne ausreichende Sicherheitsintegrität gescheduled. Am Anfang der Schleife werden Interrupts und damit das Scheduling sowie unsichere Interruptroutinen ausgeschaltet. Somit sind Unterbrechungen durch eine nicht-sicherheitsrelevante Software ausgeschlossen. Anschließend wird die Prüfsumme berechnet und mit einem zuvor berechneten Wert verglichen. Stimmen die Werte überein, so ist die Integrität gewährleistet. Nachfolgend werden die anwendungsspezifischen sicherheitsrelevanten Tätigkeiten in einer separaten Funktion ausgeführt. Am Ende der Schleife wird die Prüfsumme aktualisiert, die Interrupts werden wieder aktiviert und die Kontrolle wird an eine andere Task abgegeben.
Die Berechnung der Prüfsumme muss alle sicherheitsrelevanten Speichersegmente der Task (Codesegment, Datensegment, Heap) mit einbeziehen. Die Prozessorregister und der Stack können ausgelassen werden, da diese keine sicherheitsrelevanten Informationen enthalten, während andere Komponenten auf den Speicher schreiben können. Hierzu muss allerdings sichergestellt sein, dass die sicherheitsrelevante Funktionalität in einer anderen Funktion als die Integritätsüberprüfung implementiert wird und dass der Compiler die sicherheitsrelevante Funktion nicht als Inline-Funktion kompiliert. Dies kann entweder durch Prüfung des Assembler-Codes oder durch eine Konfiguration des Compilers erreicht werden (zum Beispiel mittels des gcc-Parameters ”f-noinline”; das ist die für einen beispielhaft eingesetzten gcc-Compiler verwendete Konfiguration um inline-Funktionen zu vermeiden. Inline bedeutet, dass eine Funktion durch einen Compiler in eine andere kopiert wird, also nicht mehr eigenständig existiert.).
Ein Nachteil dieser Art der Umsetzung ist, dass die sicherheitsrelevante Komponente in einer Schleife umgesetzt werden muss. Es findet kein präemptives Multitasking statt. Damit können in der Komponente nur nicht-blockierende Funktionen genutzt werden. Zudem muss die Komponente selbst sicherstellen, dass sie die Schleife rechtzeitig verlässt und die Kontrolle abgibt, damit andere Tasks auf dem System ihre Deadline einhalten können. Es ist jedoch denkbar, mehrerer solcher Schleifen in jeweils unabhängigen Tasks auszuführen, um deren Komplexität gering zu halten.
Eine andere Option zur Umsetzung der zweiten Möglichkeit sieht einen eigenen Scheduler für die sicherheitsrelevante Komponente vor. Dies bietet einige Vorteile, ist aber deutlich aufwendiger. Wenn ein eigener Scheduler implementiert wird, so kann auch präemptives Multitasking für die sicherheitsrelevante Komponente genutzt werden. Damit ist die sicherheitsrelevante Komponente nicht auf die Nutzung einer Schleife begrenzt, sondern kann an beliebigen Zeitpunkten unterbrochen werden. Hierdurch können mitunter auch blockierende Operationen genutzt werden.
Der eigene Scheduler wird hierbei als normale Kernelmode-Task im Betriebssystem ohne ausreichende Sicherheitsintegrität betrieben. Der eigene Scheduler verwaltet unabhängig von der niedriger eingestuften Komponente und dessen Scheduler die Tasks der sicherheitsrelevanten Komponente. Wird der eigene Scheduler durch den anderen aufgerufen, so deaktiviert er zunächst wieder alle Interrupts, bis auf den Timer-Interrupt. Der Interrupt Handler des Timer-Interrupts wird während der Ausführung der sicherheitsrelevanten Komponente auf einen eigenen abgeändert. Anschließend prüft der Scheduler die Integritüt der sicherheitsrelevanten Komponente. Nachfolgend ruft er die erste sicherheitsrelevante Task auf. Bei einem Aufruf des Timer-Interrupt Handlers kann der eigene Scheduler in Abhängigkeit des Scheduling-Algorithmus die gerade ausgeführte Task wechseln oder weiter ausführen.
Nachdem alle sicherheitsrelevanten Tasks ausgeführt wurden, oder eine bestimmte Zeit abgelaufen ist, generiert der Scheduler eine neue Prüfsumme für die Komponente, setzt den Interrupt-Handler zurück und aktiviert wieder die übrigen Interrupts im System. Im Idealfall sollten hierbei möglichst mehrere Tasks einer sicherheitsrelevanten Komponente unmittelbar hintereinander ausgeführt werden, da hierdurch die Prüfsummenberechnung nicht für jede Task einzeln stattfinden muss. Die Integritätsprüfung muss bei dieser Art der Implementierung zusätzlich den Stack sowie die gespeicherten Prozessorregister der einzelnen Tasks mit einbeziehen, da diese nun jederzeit sicherheitsrelevante Informationen enthalten können.
Beide Möglichkeiten zur Umsetzung der zweiten Möglichkeit haben ein gemeinsames Problem. Es ist denkbar, dass eine nicht-sicherheitsrelevante Task aufgrund eines Fehlers in einen beliebigen Codebereich der sicherheitsrelevanten Komponente springt. Um das Risiko dieses Fehlers zu senken, ist es möglich, für die Codebereiche mithilfe einer Speicherverwaltungseinheit (Memory Management Unit – MMU) die Ausführungsrechte zu entziehen, wenn die sicherheitsrelevante Komponente nicht gerade aktiv ist. Allerdings könnte das rückgängig gemacht werden. Zudem setzt es das Vorhandensein einer MMU voraus.
Eine Möglichkeit der Realisierung ohne die Verwendung der MMU ist, dass der sicherheitsrelevante Code abgeändert wird, während er nicht aktiv ist. Hierzu können die Instruktionen entwertet oder verschlüsselt werden. Allerdings kostet dies Rechenzeit. Zudem gibt es ein neues Problem. Es ist denkbar, dass eine fehlerhafte Software exakt hinter die Prüfsummenüberprüfung und noch vor der Entschlüsselung einspringt. Damit wären die Schutzmaßnahmen wieder ausgehebelt. Hiervor kann man sich schützen, indem zusätzlich ein Sprung in die geschützte sicherheitsrelevante Funktion über einen Funktionszeiger erfolgt, der vor der Prüfsummenberechnung gesetzt wird. Somit erreicht man einen optimalen Schutz. Dass der Funktionszeiger zusätzlich zufällig mit dem richtigen Wert überschrieben wird, ist ausreichend unwahrscheinlich.
Ein anderer denkbarer Fehlerfall ist der, dass ausschließlich die Prüfsummenberechnung und Entschlüsselung mit No-Operation (NOP) Instruktionen überschrieben werden. Aber dieser Fehlerfall kann aufgrund der geringen Wahrscheinlichkeit ausgeschlossen werden.
Nachfolgend wird die Implementierung der Prüfsummenberechnung beschrieben.
Für die Prüfsummenberechnung ist die Verwendung der kryptografischen Hashfunktionen md5 oder SHA-256 ebenso wie die Verwendung einer Methode zur zyklischen Redundanzprüfung, wie CRC-32, denkbar. Die Auswahl der Methode kann nach unterschiedlichen Kriterien erfolgen. Voraussetzung ist in jedem Fall, dass die gewählte Funktion Veränderungen mit der für die Sicherheitseinstufung benötigten Wahrscheinlichkeit erkennt. Wichtig ist zudem der Zeitaufwand für das Berechnen der Prüfsumme, da dieser zwei Mal für jeden Schleifendurchlauf bzw. Scheduleraufruf anfällt. Weniger bedeutend ist, wieviel Speicher für die Prüfsumme benötigt wird.
Ein Argument für die zyklische Redundanzprüfung ist, dass sie aufgrund der einfacheren Implementierung deutlich schneller ist. Die Prüfsumme muss das Codesegment, das Datensegment, den Heap sowie ggf. den Stack und den gespeicherten Kontext einer Task erfassen. Eine offene Frage hierbei ist, wie man die entsprechenden Speicheradressen anspricht. Wenn Heap und Stack selbst implementiert werden, so sind die hierfür bereitgehaltenen Speicherbereiche bekannt. Beim Heap ist ferner denkbar, die einzelnen Zeiger zu prüfen, welche auf dynamisch allokierten Speicher verweisen. Wird der Stack nicht selbst implementiert, so kann man ihn oft von der Ausführungsumgebung erfragen. Ferner kann man auch vom aktuellen SP-Wert mittels der Backchain-Werte ebenso wie bei einem Debugger bis zum Anfang iterieren und so den aktuell genutzten Stackbereich ermitteln.
Deutlich schwieriger sind dem hingegen die Positionen des Code- und Datensegments zu erfassen. Es ist denkbar, alle Variablen aus dem Datensegment in einer Liste zu registrieren. Die Liste könnte anschließend in Regionen von zu überprüfenden Speicherbereichen zusammengefasst werden, um die Geschwindigkeit zu erhöhen. Allerdings funktioniert der Ansatz so nicht für Funktionen, da für diese im Gegensatz zu Variablen nicht mittels des vom Compiler bereitgestellten sizeof-Operators die Größe bestimmt werden kann.
Eine erste Alternative ist, aus der Symboltabelle die Speicheradresse und Größe sowohl von Funktionen als auch von Variablen auszulesen. Die Anzeige der Symboltabelle für Elf-Dateien ermöglicht beispielsweise das Tool ”nm” aus den GNU ”binutils”. Wenn sichere und unsichere Komponenten in einer Objektdatei zusammengefügt wurden, so kann in der Symboltabelle aussortiert werden, welche Einträge erfasst werden sollen und welche nicht. Allerdings ist dieser Ansatz mühsam.
Eine zweite, einfachere Alternative ist, sichere und unsichere Software anhand der Speichersegmente, in welche sie platziert werden, auseinander zu halten. Die Zuweisung von Segmenten kann beim Linken durch ein Linker Script beeinflusst werden. Hierbei kann auf Ebene der Objekte beziehungsweise der C/C++-Quelldateien eine Zuweisung in spezifische Speichersegmente vorgenommen werden.
Ein Beispiel für ein hierzu passendes Linker Script findet sich in der 2. Die beim Linken ermittelten Speicherbereiche müssen der Software zur Integritätsprüfung bekannt gemacht werden. Hierzu werden jeweils vor und hinter jedem Segment Symbole eingefügt. Die Symbole können in C-Code zur Adressierung verwendet werden. Hierzu deklariert man sie als extern und greift dann mittels Adressoperator (&) auf die Adresse zu. Beim Linken kann zudem auch in Daten- und Textsegment unterschieden werden, damit bei Verwendung einer MMU für das Datensegment die Ausführungsrechte sowie für das Codesegment die Schreibrechte entzogen werden können.
Die Prüfsumme muss bei der ersten Programmanwendung bereits bekannt sein, wenn die sicherheitsrelevante Software nicht noch vor der unsicheren Software ausgeführt wird, da die Software sonst vor der ersten Ausführung verändert werden könnte. Hierfür kann auf Basis der Binärdatei die Prüfsumme mit einem separaten Programm berechnet werden. Das Programm kann die Segmentinformationen mittels des Tools ”objdump” abfragen und kann dann ebenso wie die Software selbst, die Integrität anhand der Binärdatei berechnen.
Eine interessante Problemstellung ist jedoch, wie die Prüfsumme der bereits gelinkten Software bekannt gemacht wird. Eine Möglichkeit ist, die Variable der Prüfsumme in der sicheren Software als extern zu deklarieren und erst über eine zusätzliche Objektdatei zu definieren. Eine andere Möglichkeit ist, die Variable nicht als extern zu deklarieren, sondern die Speicheradresse der Variable mittels der Symboltabelle zu ermitteln und den zugehörigen Wert zu überschreiben. Ferner ist eine weitere Möglichkeit, das Programm erneut zu kompilieren und hierbei den Wert für die Prüfsumme im Code zu setzen. Sofern hierbei der eigentliche sicherheitsrelevante Code nicht geändert wird, und keine neuen Felder eingefügt werden, passt die Prüfsumme auch auf das neu kompilierte Programm.
Die vorgenannten drei Möglichkeiten sind gleichwertig. In jedem Fall darf die für die Berechnung der Prüfsumme verwendete Variable nicht in die Berechnung der Prüfsumme mit einbezogen werden. Das Aktualisieren der Prüfsumme kann beschleunigt werden, indem die Prüfsumme ausschließlich für geänderte Speicherbereiche berechnet wird. Ein einfacher Ansatz hierzu ist die Prüfsumme für das Datensegment zur Laufzeit zu aktualisieren, aber nicht die für das Codesegment. Ein anderer Ansatz ist, bei Änderung von Objekten deren zugehörige Prüfsumme unmittelbar neu zu berechnen. Hierbei wären die Prüfsummen auf einzelne Objekte aufgeteilt. Zur Umsetzung kann das Schreiben auf Objekte über eine besondere Funktion gekapselt werden, die zusätzlich die Prüfsumme aktualisiert.
Auch das Überprüfen auf Speicherintegrität könnte in ähnlicher Form optimiert werden, indem nur jeweils die Prüfsummen für genutzte Speicherbereiche überprüft werden.
Eine wesentliche Frage ist, wie auf den Verlust der Speicherintegrität reagiert wird. Es gibt Anwendungsfälle, in denen der Verlust der Speicherintegrität tolerierbar ist. Dies ist beispielsweise der Fall, wenn die Gefahrenquelle deaktiviert werden kann (fail-safe bzw. fail-soft).
In anderen Anwendungsgebieten ist der Verlust der Speicherintegrität nicht tolerierbar, da das System weiterlaufen soll (fail-operational). In diesen Fällen kann je nach Art der beschädigten Information, die Information rekonstruiert werden. Dies kann beispielsweise durch das Abfragen von Sensoren, durch Neustart der sicherheitsrelevanten Komponente oder des kompletten Systems erfolgen. Ferner ist es möglich, durch die Verwendung von doppelter Redundanz oder einfacher Redundanz in Verbindung mit der Prüfsumme, eine Möglichkeit zur Rekonstruktion von beschädigten Speicherinhalten zu schaffen. Trotzdem ist bei Verlust der Speicherintegrität jedem Fall ein Neustart des gesamten Systems anzuraten, da so auch die nicht identifizierbare Komponente, welche den Fehler verursacht hat, neu initialisiert wird.
Nachstehend wird das Verhalten der sicherheitsrelevanten Software bei unsicherem Scheduling beschrieben.
Für die sicherheitsrelevante Komponente einer Computerprogrammanwendung kann ohne eine Separierung von nicht-sicherheitsrelevanten Komponenten generell nicht sichergestellt werden, dass sie zu einer bestimmten Zeit ausgeführt wird. Die niedriger eingestufte (nicht-sicherheitsrelevante) Komponente kann, da sie uneingeschränkten Zugriff auf den Prozessor hat, jederzeit die Interrupts ausschalten und damit das Scheduling lahmlegen. Zudem wird in der bisher beschriebenen Implementierung das Scheduling der niedrigen eingestuften Komponente aktiv genutzt.
Es gibt Anwendungsfälle, bei welchen das Scheduling nicht sicher erfolgen muss. Dies ist beispielsweise der Fall, wenn die sicherheitsrelevante Komponente selbst eine gefährliche Funktion erbringt, die immer wenn die sicherheitsrelevante Komponente nicht gerade aktiv ist, keine Gefahr verursacht.
In anderen Anwendungsfällen muss das Scheduling in jedem Fall erfolgen. Dies ist der Fall, wenn das Gerät zunächst in einen sicheren Zustand überführt werden muss, damit keine Gefahr besteht, oder weil die sicherheitsrelevante Funktion auch weiterhin angeboten werden soll. In diesem Fall kann durch einen externen Hardware-Watchdog 45 (4) sichergestellt werden, dass die sicherheitsrelevante Komponente aufgrund eines Fehlers nicht für einen zu langen Zeitraum keine Rechenzeit bekommt. Hierzu wird nach Überprüfung der Speicherintegrität stets der Watchdog benachrichtigt. Tritt der Fehlerfall ein, so löst der Watchdog einen Hardware-Reset des Systems aus und leitet damit einen Neustart ein.
Der Neustart sollte zunächst nicht das gesamte System neu starten, sondern es muss zunächst nur sichergestellt werden, dass die sicherheitsrelevante Komponente ausgeführt wird. Diese kann das System in einen sicheren Zustand überführen oder nur eine sicherheitsrelevante Funktion ausführen. Es kann anschließend das übrige System neu gestartet werden.
Eine andere Möglichkeit ist, dem Hardware-Watchdog nach einem Fehlerfall die Überführung des Geräts in einen sicheren Zustand zu überlassen, in welchem vom System keine Gefahr mehr ausgeht. In einigen Anwendungsfällen kann es hierbei ausreichen, wenn dem Prozessor und damit der unsicheren Software oder den Aktoren die Stromversorgung entzogen wird. Unabhängig von der spezifischen Reaktion auf den Fehler, ist eine Betrachtung der Auswirkung auf das Scheduling im Fehlerfall interessant. Die sicherheitsrelevante Komponente hat bei der Funktionserbringung eine bestimmte Periode. Der Watchdog kann in dieser Periode von der Komponente ein Lebenszeichen erwarten. Bleibt in einer Periode die Reaktion aus, so kann er das System neu starten. Damit ergibt sich als Reaktionszeit auf einen Ausfall eine Verzögerung bestehend aus der Periode und dem Zeitaufwand, welche die Reaktion des Watchdogs selbst in Anspruch nimmt. Der sich so ergebende Zeitraum muss niedriger als die Deadline von der bzw. jeder sicherheitsrelevanten Tasks sein. Damit der Watchdog nicht durch einen Fehler in der unsicheren Software zurückgesetzt werden kann, muss der Watchdog eine nicht durch Fehler auslösbare Schnittstelle zur sicherheitsrelevanten Software haben. Es reicht nicht aus, einen zufälligen Wert an eine bestimmte Speicheradresse zu schreiben. Stattdessen könnte beispielsweise eine vom Watchdog vorgegebene Berechnung ausgeführt werden, oder ein bestimmter Schlüssel an eine Speicheradresse geschrieben werden.
Die unsichere Komponente hat auch über den Watchdog hinaus vollen Zugriff auf sämtliche I/O Geräte und kann somit beispielsweise sicherheitsrelevante Aktoren oder Sensoren ansteuern. Um dieser Problemstellung entgegen zu wirken, muss ein entsprechender Zugriffsschutz in den einzelnen Geräten, außerhalb des Systems implementiert werden. Alternativ ist auch denkbar, alle sicherheitsrelevanten Geräte über eine bestimmte externe Kommunikationsschnittstelle anzusprechen und in dieser den Zugriffsschutz umzusetzen.
Bezugszeichen in den Ansprüchen, der Beschreibung und den Zeichnungen dienen lediglich dem besseren Verständnis der Erfindung und sollen den Schutzumfang nicht einschränken.
Bezugszeichenliste

1: Steuergerät
2: Steuergerät
3: Steuergerät
4: Steuergerät
4': Flugführungsrechner (FFR)
10: Prozessor
11: Betriebssystem
12: erste Steuereinheit
13: zweite Steuereinheit
14: Sensor
15: Sensor
16: Aktor
17: Aktor
20: Prozessor
21: Prozessor
22: Betriebssystem
23: Betriebssystem
24: Steuereinheit
25: Steuereinheit
26: Sensor
27: Sensor
28: Aktor
29: Aktor
30: Hardware-Konfiguration
31: Hardware-Konfiguration
32: Steuereinheit
33: Betriebssystem
34: Steuereinheit
36: Sensor
37: Sensor
38: Aktor
39: Aktor
40: Prozessor
40': PPC
42: Betriebssystem
42': Betriebssystem
43: Steuereinheit
43: Datenlinküberwachung
44: Steuereinheit
44': Steuereinheit
45: Watchdog
45': Hardwareüberwachung
46: Sensor
46': Datenlinkempfänger
47: Sensor
47': Suchkopf
47'': intertiale Messeinheit
48: Aktor
48': Aktor
49: Aktor
49': Aktor

ZITATE ENTHALTEN IN DER BESCHREIBUNG
Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
Zitierte Nicht-Patentliteratur

IEC 61508 [0003]
IEC 61508 [0009]

Claims

Verfahren zur Speicherplatzverwaltung in einem multitaskingfähigen Datenverarbeitungssystem () mit einer Datenverarbeitungseinrichtung () und darauf laufender Software, – wobei die Datenverarbeitungseinrichtung () zumindest eine CPU () und zumindest einen Arbeitsspeicher () aufweist und – wobei die auf der CPU () ablaufende Software eine erste Computerprogrammanwendung und zumindest eine zweite Computerprogrammanwendung aufweist, die während des Ablaufs jeweils auf den von beiden Computerprogrammanwendungen gemeinsam genutzten Arbeitsspeicher () zugreifen; – wobei Information der ersten Computerprogrammanwendung in zumindest einem Teil der Speicherplätze des Arbeitsspeichers () temporär gespeichert wird und – wobei die Integrität der Inhalte dieser Speicherplätze nach einer Unterbrechung der Ausführung der ersten Computerprogrammanwendung überprüft wird und – wobei die erste Computerprogrammanwendung nur dann weiter ausgeführt wird – wenn durch die Überprüfung die Speicherintegrität bestätigt wird oder – wenn die Speicherintegrität wiederhergestellt worden ist.
Verfahren nach Anspruch 1, dadurch gekennzeichnet, – dass die Information der ersten Computerprogrammanwendung in den Speicherplätzen des Arbeitsspeichers zumindest zweifach gespeichert wird, – dass nach dem Auslesen einer ersten Information aus den Speicherplätzen des Arbeitsspeichers und vor der Weiterverarbeitung der Information in der ersten Computerprogrammanwendung die ausgelesene erste Information mit der zweiten, parallel gespeicherten Information verglichen wird und bei Übereinstimmung die Speicherintegrität verifiziert wird.
Verfahren nach Anspruch 1, dadurch gekennzeichnet, – dass für die in den Speicherplätzen des Arbeitsspeichers gespeicherte Information der ersten Computerprogrammanwendung vor dem Abspeichern eine Prüfsumme berechnet wird, die zusammen mit der Information abgespeichert wird, – dass nach dem Auslesen der Information aus den Speicherplätzen des Arbeitsspeichers und vor der Weiterverarbeitung der Information in der ersten Computerprogrammanwendung erneut die Prüfsumme berechnet, mit der gespeicherten Prüfsumme verglichen wird und bei Übereinstimmung die Speicherintegrität verifiziert wird.
Verfahren nach Anspruch 3, dadurch gekennzeichnet, – dass die erste Computerprogrammanwendung in einer Schleife ausgeführt wird, – wobei vor dem Auslesen der Information aus den Speicherplätzen des Arbeitsspeichers und der Berechnung der Prüfsumme alle Interrupt-Routinen ausgeschaltet werden, die die erste Computerprogrammanwendung unterbrechen könnten, und – wobei die Interrupt-Routinen erst dann wieder eingeschaltet werden wenn die Information nach Berechnung der neuen Prüfsumme wieder im Arbeitsspeicher gespeichert worden ist.
Verfahren nach Anspruch 3, wobei im Datenverarbeitungssystem ein eigenständiger Scheduler für die erste Computerprogrammanwendung vorgesehen ist, der von der ersten Computerprogrammanwendung auszuführende Aufgaben verwaltet und der unabhängig ist von Schedulern zur Verwaltung anderer auf der Datenverarbeitungseinrichtung laufender Computerprogrammanwendungen dadurch gekennzeichnet, – dass nach dem Aufrufen des eigenständigen Schedulers für die erste Computerprogrammanwendung zunächst alle Interrupt-Routinen, die die erste Computerprogrammanwendung unterbrechen könnten, ausgeschaltet werden bevor die in den Speicherplätzen des Arbeitsspeichers gespeicherte Information der ersten Computerprogrammanwendung abgerufen wird; – dass die Interrupt-Routinen erst dann vom Scheduler wieder eingeschaltet werden wenn zumindest eine der von der ersten Computerprogrammanwendung auszuführenden Aufgaben abgearbeitet worden und die Information der ersten Computerprogrammanwendung in den Speicherplätzen des Arbeitsspeichers wieder gespeichert worden ist.
Computersystem mit – einer multitaskingfähigen Ausführungsumgebung, in der eine erste Computerprogrammanwendung und zumindest eine zweite Computerprogrammanwendung läuft, wobei die Ausführungsumgebung zumindest eine CPU und zumindest einen Arbeitsspeicher aufweist, gekennzeichnet durch – Mittel zur Überprüfung der Integrität der Inhalte von Speicherplätzen des zumindest einen Arbeitsspeichers und – Mittel, durch die der ersten Computerprogrammanwendung gemeldet wird, dass sie weiterlaufen kann, wenn bei der Überprüfung die Speicherintegrität verifiziert wurde.
Computerprogrammprodukt, das direkt in einen Arbeitsspeicher eines digitalen Computersystems geladen werden kann und Softwarecodeabschnitte umfasst, mit denen die Schritte gemäß Anspruch 1 ausgeführt werden können.
Computerprogrammprodukt, das auf einem computergeeigneten Medium gespeichert ist und folgendes umfasst: – computerlesbare Programmmittel, die einen Computer veranlassen, die Ausführung einer Computerprogrammanwendung zu überwachen; – computerlesbare Programmmittel, die den Computer zur Überprüfung der Integrität der Inhalte von Speicherplätzen des zumindest einen Arbeitsspeichers veranlassen; – computerlesbare Programmmittel, die den Computer zur Abgabe einer Meldung an die Computerprogrammanwendung veranlassen, dass sie weiterlaufen kann, wenn bei der Überprüfung die Speicherintegrität verifiziert wurde.
Integration von sicherheitsrelevanter Software in einem mittels Software steuerbaren Gerät, welches einen softwareunterstützten Rechner mit wenigstens einer CPU und einem Betriebssystem enthält, mit wenigstens einem Speicher, einer bezüglich der Funktion des Geräts sicherheitskritischen ersten Software und wenigstens einer weiteren, rangmäßig niedrigeren und nicht sicherheitsrelevanten Software, mit einer als Hardware ausgeführten Watchdogschaltung, welche die Abläufe der ersten Software kontrolliert und im Fall einer Fehlfunktion einen Reset zumindest in einem abgesicherten Modus auslöst, wobei bei wechselweisem Zugriff der ersten und der weiteren Software auf den Speicher bei jedem Wechsel eine Prüfsumme über den Speicherinhalt berechnet wird und diese mit einer weiteren Prüfsumme verglichen wird, die nach einem weiteren Wechsel zu einer sicherheitskritischen Software errechnet wird, und wobei im Fall der Nichtübereinstimmung dieser Prüfsummen der Speicherinhalt vor dem Wechsel wieder aktiviert wird.
Integration von sicherheitsrelevanter Software in einem Gerät, dadurch gekennzeichnet, dass das Gerät als Fluggerät mit einer Datenlinküberwachung ausgeführt ist.