Figure 9.1: System Call sequence chart The above sequence describes a call to the CallTrustedFunction service. It starts with a user who calls a service which requires itself a call to a trusted function. The service then packs the argument for the trusted function into a structure and calls CallTrustedFunction with the ID and the pointer as arguments. Afterwards the OS checks if the access to the requested service is valid. If no access is granted E_OS_SERVICEID is returned. Otherwise the trusted service itself is called and the function checks the arguments for access right, etc.

1. Diagrammtyp & Architektur-Kontext

UML-Sequenzdiagramm (sd Interactions) aus der AUTOSAR Classic Platform Spezifikation des Operating Systems (AUTOSAR_SWS_OS). Das Diagramm modelliert den systemweiten Kontrollfluss und die Schutzmechanismen beim Aufruf einer Trusted Function (CallTrustedFunction) über Partitions- und Privilegiengrenzen hinweg (Wechsel von einer unprivilegierten calling OS-Appl. zu einer privilegierten providing OS-Appl. unter Vermittlung des Betriebssystems).

2. Komponenten, Entitäten & Schnittstellen

Entitäten / Lebenslinien:

• calling OS-Appl.: Aufrufende OS-Anwendung (typischerweise Non-Trusted, läuft im unprivilegierten Modus).
• <trusted function stub>: Clientseitiger Wrapper/Stub innerhalb der aufrufenden OS-Anwendung, der Parameter serialisiert und den OS-Dienst aufruft.
• providing OS-Appl.: Ziel-OS-Anwendung, welche die angeforderte Trusted Function im privilegierten Modus bereitstellt.
• operating system: AUTOSAR OS-Kern inklusive System Call Dispatcher (system call dispatcher), annotiert via UML-Notiz am Eingang der Systemaufruflinie.

Schnittstellen & Nachrichten:

• <trusted function stub>: Lokaler Funktionsaufruf von calling OS-Appl. an den Funktionsstub.
• CallTrustedFunction(FunID,FunParPtr): Synchroner Systemaufruf an das Betriebssystem mit der Funktionskennung (FunID) und dem Zeiger auf die Parameterstruktur (FunParPtr).
• <trusted function>: Privilegierter Aufruf der Zielfunktion durch das Betriebssystem in der providing OS-Appl..
• <CheckAccess> / <Access Information>: Interne OS-Dienstabfrage (z. B. CheckMemoryAccess) der Trusted Function an das OS zur Prüfung der Zeiger-/Pufferzugriffsrechte des Aufrufers.
• Rückgabewerte: E_OS_SERVICEID (Fehlercode bei verweigerter Aufruferlaubnis), E_OK (Erfolgsstatus des OS-Aufrufs), <return value> (funktionaler Rückgabewert des Stubs an die aufrufende Applikation).

3. Dynamisches Verhalten & Sequenzablauf

1. Anwendungsaufruf: Die calling OS-Appl. ruft den lokalen <trusted function stub> auf.
2. Systemaufruf: Der Stub verpackt die Argumente und setzt den synchronen Aufruf CallTrustedFunction(FunID,FunParPtr) an das operating system ab, der vom system call dispatcher entgegengenommen wird.
3. Berechtigungsprüfung (alt Check permission):
   • Zweig [denied]: Das Betriebssystem verweigert den Zugriff auf die angeforderte FunID und liefert die Fehlermeldung E_OS_SERVICEID direkt an den Stub zurück.
   • Zweig [accepted]: a) Das OS wechselt in den Kontext der providing OS-Appl. und führt die <trusted function> aus. b) Die <trusted function> ruft <CheckAccess> beim OS auf, um zu validieren, ob die via FunParPtr übergebenen Speicherbereiche für die aufrufende Anwendung zulässig sind. c) Das OS antwortet mit <Access Information>. d) Nach Abarbeitung kehrt die Funktion zum OS zurück (unbenannte Return-Nachricht). e) Das OS kehrt mit Status E_OK zum <trusted function stub> zurück.
4. Abschluss: Der Stub reicht das Ergebnis via <return value> an die calling OS-Appl. weiter.

4. Normative Relevanz & Entwickler-Hinweise

Normativ verbindlicher Ablauf für die Implementierung des Speicherschutzes (Memory Protection) und der Inter-OS-Application-Kommunikation über Trusted Functions:

• Autorisierungsprüfung: Das OS muss vor der Ausführung zwingend prüfen, ob die aufrufende OS-Application Zugriffsrechte auf die konfigurierte FunID besitzt; bei Fehlschlag ist E_OS_SERVICEID zurückzugeben.
• Verhinderung von Privilegienerweiterungen (Confused Deputy): Die Trusted Function läuft mit Supervisor-/Privilegierechten und muss über <CheckAccess> (bzw. OS-Speicherprüfdienste) explizit verifizieren, dass der Aufrufer Lese-/Schreibberechtigung auf die übergebenen Zeiger besitzt, bevor Daten gelesen oder manipuliert werden.
• Kapselung: Parameterübergabe erfolgt generisch über einen Zeiger auf eine anwendungsspezifische Struktur (TrustedFunctionParameterRefType).