Speicherpartitionierung und implementierte funktionale Sicherheitsmechanismen

1. Anwendungssoftware

In der AUTOSAR-Architektur befindet sich die Anwendungssoftware über dem RTE und besteht aus miteinander verbundenen AUTOSAR-SWCs. Diese Komponenten kapseln atomar verschiedene Komponenten der Anwendungssoftware-Funktionalität.

Abbildung 1: Anwendungssoftware

AUTOSAR SWC ist hardwareunabhängig und kann daher auf jede verfügbare Steuergeräte-Hardware integriert werden. Um den Informationsaustausch innerhalb und innerhalb des Steuergeräts zu erleichtern, kommuniziert AUTOSAR SWC ausschließlich über RTE.

AUTOSAR SWC enthält viele Funktionen und Variablen, die interne Funktionalität bereitstellen. Die interne Struktur von AUTOSAR SWC, nämlich seine Variablen und Funktionsaufrufe, ist durch Header-Dateien vor der Öffentlichkeit verborgen. Nur externe RTE-Aufrufe werden auf der öffentlichen Schnittstelle wirksam.

Abbildung 2: SWC

AUTOSAR SWC enthält auch Funktionen, die zur Laufzeit aufgerufen werden müssen. Diese C-Funktionen werden in AUTOSAR Runnables genannt.

Runnables können nicht alleine ausgeführt werden; sie müssen einer ausführbaren Entität des Betriebssystems zugewiesen werden. Solche Zuweisungen können durch Einfügen von Funktionsaufrufen von Runnables in den OS-Task-Körper durchgeführt werden.

Die Runnables werden dann in einer Schleife und/oder ereignisgesteuert im Kontext der aufrufenden OS-Task ausgeführt. Die Zuteilung der Aufgaben durch Runnables erfolgt gemäß den Abbildungen 3 und 4.

​

Abbildung 3: AUTOSAR-Layer-Software-Architektur – Zuordnung von Runnables

2. Abbildung 4 zeigt die Erklärung der Beziehung in Abbildung 3. Gemäß diesem Diagramm werden Runnables in AUTOSAR SWC Betriebssystemaufgaben zugewiesen. Abbildung 4: Zuordnung von SWC zu Betriebssystemanwendungen Funktionseinheit. Alle Objekte, die zu denselben OS-Anwendungen gehören, können aufeinander zugreifen.

OS-Objekte in OS-Anwendungen können zu verschiedenen AUTOSAR-SWCs gehören. RTE implementiert einen Speicherbereich, auf den alle Mitglieder von Betriebssystemanwendungen uneingeschränkten Zugriff haben, um eine effiziente Kommunikation zwischen SWCs zu ermöglichen.

Betriebssystemanwendungen lassen sich in zwei Kategorien einteilen:

Vertrauenswürdige Betriebssystemanwendungen: „Vertrauenswürdige Betriebssystemanwendungen dürfen mit zur Laufzeit deaktivierten Überwachungs- oder Schutzfunktionen ausgeführt werden. Sie können ohne Einschränkung APIs betreiben, die auf Speicher zugreifen und Betriebssystemmodule müssen ihr Zeitverhalten zur Laufzeit nicht erzwingen und dürfen im privilegierten Modus ausgeführt werden.

Nicht vertrauenswürdige Betriebssystemanwendungen: „Ausführung nicht vertrauenswürdiger Betriebssystemanwendungen.“ mit zur Laufzeit deaktivierten Überwachungs- oder Schutzfunktionen ist nicht zulässig. Sie beschränken den Zugriff auf den Speicher, schränken den Zugriff auf die API des Betriebssystemmoduls ein und erzwingen dessen Zeitverhalten zur Laufzeit. Sie dürfen nicht im privilegierten Modus ausgeführt werden, wenn der Prozessor dies unterstützt.

3. Kommunikation und Code-Sharing

Gemäß Abbildung 4 und Abbildung 3 kann eine Betriebssystemanwendung mehrere AUTOSAR-SWCs und zugehörige Runnables enthalten. Nur Runnables dürfen direkt auf Variablen zugreifen und Funktionsaufrufe in ihren jeweiligen SWCs ausführen.

1. Die internen Funktionsaufrufe und Variablen von SWC sind für andere SWCs nicht öffentlich zugänglich, da ihre Definitionen nicht in den Header-Dateien der externen Schnittstellen bereitgestellt werden. Daher ist es nicht möglich, eine direkte Kommunikation über Variablen und die Ausführung des Codes anderer zu planen SWCs.
2. In Abbildung 5 veranschaulicht das Code-Sharing-Beispiel, dass die Code-Sharing nur innerhalb einer SWC erlaubt ist und nicht zwischen SWCs einer OS-Anwendung geteilt werden darf. Die Kommunikation mit anderen SWCs sollte über RTE erfolgen. Runnable4 ist möglicherweise nicht in der Lage, Funktionen auszuführen, die zu SWC2.2 gehören. Abbildung 5: Code in OS-Anwendungen teilen

   4. Speicherpartition in Anwendungssoftware

   AUTOSAR Anwendungssoftware im Steuergerät durch sicherheitsrelevante SWC- und nicht sicherheitsrelevante SWC-Komponenten gesteuert werden. Die Interferenzfreiheit zwischen SWCs mit unterschiedlichen ASIL-Leveln sollte gemäß den Anforderungen der ISO26262 gewährleistet sein.

   AUTOSAR OS ist immun gegen speicherbedingte Ausfälle, indem es Betriebssystemanwendungen in exklusiven Speicherbereichen platziert. Dieser Mechanismus wird als Speicherpartitionierung bezeichnet. Betriebssystemanwendungen sind voreinander geschützt, da Code, der in der Speicherpartition einer Betriebssystemanwendung ausgeführt wird, andere Speicherbereiche nicht ändern kann. Die entsprechenden Anforderungen in der AUTOSAR OS-Spezifikation sind in Tabelle 1 aufgeführt.

   Tabelle 1: Speicherpartition von AUTOSAR OS-OS-Anwendungen

   #🎜 🎜#

   Anwendungssoftware kann aus SWCs mit unterschiedlichen ASIL-Levels bestehen. SWCs mit unterschiedlichen ASIL-Bewertungen sollten jedoch nicht denselben Betriebssystemanwendungen zugewiesen werden. Die Speicherpartitionierung bietet keine Störsicherheit zwischen SWCs, die denselben Betriebssystemanwendungen zugeordnet sind. Das Betriebssystem verhindert lediglich, dass andere Betriebssystemanwendungen fehlerhafte Zugriffe ausführen. Verhindert nicht, dass eine fehlerhafte SWC Speicherbereiche anderer SWCs in denselben Betriebssystemanwendungen verändert.

   

   Hinweis: Einzelheiten zur Partitionierung auf Aufgabenebene finden Sie in der nachfolgenden Partitionierung. 5. Speicherpartitionierung in SWC

   Mixed ASIL SWC kann aus Runnables mit unterschiedlichen ASIL-Bewertungen bestehen, daher ist eine Unterstützung erforderlich nicht betroffen von der Ausführungsumgebung, die zwischen diesen Runnables interferiert. Aus folgenden Gründen ist es nicht möglich, verschiedene Runnables einer SWC in unterschiedlichen Speicherpartitionen auszuführen:

   Speicherpartitionen werden auf der Ebene der Betriebssystemanwendungen ausgeführt. Wie in Abbildung 3 und Abbildung 4 dargestellt, kann ein SWC nur einer Betriebssystemanwendung zugewiesen werden, sodass es nur eine Speicherpartition gibt. Darüber hinaus können SWC Runnables nur von einer Task von OS-Anwendungen aufgerufen werden.

   Wie in Abbildung 6 dargestellt, können SWC Runnables nicht auf Aufgaben mehrerer Betriebssystemanwendungen verteilt werden.

   Abbildung 6: SWC und Partitionen

   Speicherpartitionen können nicht sein Wird verwendet, um Runnables im selben SWC zu trennen. Wenn es erforderlich ist, dass der SWC Runnables mit unterschiedlichen ASILs enthält und diese Runnables unabhängig und störungsfrei ausgeführt werden müssen, reicht die Speicherpartitionierung auf der Ebene der Betriebssystemanwendungen nicht aus, sondern die Speicherpartitionierung muss auf der Aufgabenebene durchgeführt werden. Die Methode ist in Abbildung 7 dargestellt.

   

   Abbildung 7: Partitionierung auf Aufgabenebene Die zugehörigen Anforderungen zur Speicherpartitionierung auf Aufgabenebene sind in der AUTOSAR OS-Spezifikation in Tabelle 2 aufgeführt. Die Verwendung des schwachen Wortes „kann“ weist darauf hin, dass die Implementierung der Partitionierung auf Aufgabenebene für AUTOSAR OS optional ist. Daher unterstützt nicht jede AUTOSAR-Betriebssystemimplementierung die Speicherpartitionierung auf Aufgabenebene.

   Tabelle 2: AUTOSAR-Betriebssystemanforderungen – Speicherpartitionierung auf Aufgabenebene

   #🎜 🎜#

   6. Implementierung der Speicherpartitionierung Mithilfe des Speicherpartitionierungsmechanismus können verschiedene technische Sicherheitskonzepte auf System- und Softwareebene implementiert werden.

   Abbildung 8 zeigt eine mögliche Implementierung, während alle zugrunde liegenden Softwaremodule in einer Speicherpartition im vertrauenswürdigen/überwachten Modus ausgeführt werden (in Abbildung 8 rot hervorgehoben). Einige SWCs sind logisch gruppiert und in separaten nicht vertrauenswürdigen/Benutzermodus-Speicherpartitionen platziert (grün hervorgehoben). Das ausgewählte Softwaremodul gehört zur gleichen Speicherpartition im vertrauenswürdigen/verwalteten Modus wie das Basissoftwaremodul (siehe den vierten SWC, der in Abbildung 8 rot hervorgehoben ist). Möglicherweise gibt es mehrere nicht vertrauenswürdige/Benutzermodus-Partitionen, die jeweils eine oder mehrere SWCs enthalten.

   

   Die Ausführung von SWCs in nicht vertrauenswürdigen/Benutzermodus-Speicherpartitionen ist eingeschränkt und kann keine anderen Speicherbereiche ändern, während die Ausführung von SWCs in vertrauenswürdigen/überwachten Programmspeicherpartitionen nicht eingeschränkt ist.

   Moderne Mikrocontroller für sicherheitsrelevante Anwendungen unterstützen die Speicherpartitionierung durch dedizierte Hardware (Memory Protection Unit (MPU)).

   HINWEIS: Es wird davon ausgegangen, dass Memory Slicing auf einem Mikrocontroller mit MPU oder ähnlichen Hardwarefunktionen implementiert wird.

   Bei typischen MPU-Implementierungen kann einer nicht vertrauenswürdigen Anwendung der Zugriff auf mehrere Partitionen des Adressraums des Mikrocontrollers gestattet werden. Unter Zugriffskontrolle versteht man eine Kombination aus Lese-, Schreib- und Ausführungszugriff. Die MPU-Konfiguration ist nur im Monitormodus zulässig.

   HINWEIS: Bei einigen Mikrocontroller-Implementierungen ist die MPU in den Prozessorkern integriert. Daher kontrolliert die MPU nur den Zugriff auf den zugehörigen Kern. Andere Busmaster (z. B. DMA-Controller und andere Kerne) werden von dieser segmentierten MPU-Instanz nicht gesteuert.

   Die folgende Tabelle und Anwendungsfälle veranschaulichen eine Reihe möglicher Szenarien, wenn die Konfiguration der Speicherschutzeinheit von den Systemanforderungen abgeleitet wird. HINWEIS: Diese Tabelle ist möglicherweise nicht vollständig, wenn es um die Funktionen des verwendeten Hardwaregeräts geht. Tabelle 3: Speicherschutz-Konfigurationsschema Schlichtung usw.

   Anwendungsfall 1: SWC befindet sich in derselben Partition.

   SWCs in derselben Partition können auf die RAM-Bereiche des anderen zugreifen und daher möglicherweise den Speicherinhalt des anderen beschädigen.

   Per Definition können SWCs nicht auf Peripheriegeräte zugreifen, da sie nichts über die zugrunde liegende Mikrocontroller-Architektur wissen sollten. Wenn SWC den direkten Zugriff auf Peripheriegeräte gestattet, kann ein unsicheres System entstehen.

   Anwendungsfall 2: SWC in verschiedenen Partitionen.

   SWCs in unterschiedlichen Partitionen können nicht auf die RAM-Bereiche des anderen zugreifen und daher den Speicherinhalt des anderen nicht beschädigen.

   Per Definition können SWCs nicht auf Peripheriegeräte zugreifen, da sie nichts über die zugrunde liegende Mikrocontroller-Architektur wissen sollten. Wenn einem SWC direkter Zugriff auf ein Peripheriegerät gewährt wird, kann ein potenziell unsicheres System entstehen. Anwendungsfall 3: MCAL-Treiber

   Der MCAL-Treiber ist eine Sammlung von Funktionen wie Lesen/Schreiben/Initialisieren. Sie müssen von einer anderen Entität wie BSW oder CDD ausgeführt werden. Einzelheiten finden Sie in Abbildung 8.

   Der MCAL-Treiber erfordert Lese-/Schreibzugriff auf den Peripherieraum des entsprechenden Peripherie-Hardwaremoduls. Abhängig von der Hardwarearchitektur kann auch ein Monitormodus des Prozessors erforderlich sein.

   • 2.1.3 Erkennung und Reaktion
   Funktioneller Sicherheitsmechanismus Die Speicherpartitionierung bietet Schutz, indem sie den Zugriff auf Speicher und speicherzugeordnete Hardware einschränkt. In einer Partition ausgeführter Code kann den Speicher einer anderen Partition nicht ändern. Speicherpartitionen können schreibgeschützte Speichersegmente sowie speicherzugeordnete Hardware schützen. Darüber hinaus haben im Benutzermodus ausgeführte SWCs eingeschränkten Zugriff auf CPU-Anweisungen, wie z. B. Neukonfiguration.
   • 
     Der Speicherpartitionierungsmechanismus kann mit Unterstützung von Mikrocontroller-Hardware (z. B. Speicherschutzeinheit oder Speicherverwaltungseinheit) implementiert werden. Die Mikrocontroller-Hardware muss vom Betriebssystem ordnungsgemäß konfiguriert werden, um fehlerhafte Speicherzugriffe zu erkennen und zu verhindern. Überwachen Sie dann die Ausführung von SWC in der nicht vertrauenswürdigen/Benutzermodus-Speicherpartition.
   • Wenn in einer nicht vertrauenswürdigen/Benutzermodus-Partition eine Speicherzugriffsverletzung oder ein CPU-Befehlskonflikt vorliegt, wird der fehlerhafte Zugriff blockiert und die Mikrocontroller-Hardware löst eine Ausnahme aus. Betriebssystem und RTE beseitigen fehlerhafte Softwarepartitionen, indem sie alle Softwarepartitionen dieser Partition herunterfahren oder neu starten.
   • 
     HINWEIS: Die tatsächliche Reaktion des Betriebssystems kann über die Schutz-Hook-Implementierung konfiguriert werden. Weitere Einzelheiten finden Sie in der Dokumentation zu OS SWS[i].
   • HINWEIS: Das AUTOSAR-Dokument „Anleitung zur Fehlerbehandlung auf Anwendungsebene“[ii] bietet zusätzliche Informationen zur Fehlerbehandlung. In der Dokumentation wird erläutert, wie die Fehlerbehandlung erfolgt und wo die erforderlichen Daten (z. B. Ersatzwerte) erhältlich sind. Darüber hinaus enthält dieses Dokument detaillierte Anweisungen (Benutzerhandbuch) zum Durchführen der Beendigung und des Neustarts von Betriebssystemanwendungen/Partitionen in AUTOSAR.

   2.1.4 Einschränkungen

   1. Speicherpartitionen von SWCs mit derselben ASIL-Bewertung.

   Der ISO26262-Standard erfordert Immunität zwischen SWCs unterschiedlicher ASIL-Stufen [iii]. Der Standard fordert jedoch keine Störfestigkeit zwischen SWCs mit derselben ASIL-Bewertung.

   Ermöglicht die Verwendung von Betriebssystemanwendungen, die aus einer großen Anzahl von SWCs bestehen. Wenn ein einzelner SWC einen Konflikt verursacht, der dazu führt, dass eine gesamte Speicherpartition heruntergefahren oder neu gestartet wird, sind auch alle anderen funktionierenden SWCs für diese Speicherpartition betroffen.

   2. Die Speicherpartitionierung ist für vertrauenswürdige Betriebssystemanwendungen nicht verfügbar.

   Die Ausführung der Speicherpartition im vertrauenswürdigen/überwachten Modus wird nicht vom Betriebssystem und einigen MMU/MPU-Hardwareimplementierungen gesteuert.

   3. Die Speicherpartitionierung wird auf Aufgabenebene nicht unterstützt.

   Die Implementierung der Partitionierung auf Aufgabenebene ist für die AUTOSAR OS-Implementierung nicht erforderlich. Daher wird die Störfestigkeit in OS-Anwendungen möglicherweise nicht unterstützt.

   4. Leistungsverlust durch Speicherpartitionierung.

   Abhängig von der Architektur der Anwendungssoftware und der Implementierung der Mikrocontroller-Hardware und des Betriebssystems kann die Verwendung der Speicherpartitionierung die Leistung beeinträchtigen. Dieser Nachteil erhöht sich mit der Anzahl der pro Zeiteinheit durchgeführten Kontextwechsel.

   5. Keine grundlegende Softwarepartition.

   Die aktuelle Spezifikation für die Basissoftware legt keine Speicherpartitionierung für Basis-SWCs mit unterschiedlichen ASIL-Stufen von verschiedenen Anbietern fest.

Das obige ist der detaillierte Inhalt vonSpeicherpartitionierung und implementierte funktionale Sicherheitsmechanismen. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!