DEENESPTFRRUARHIKOZHNL
AUTOSAR_SWS_OS FIG-60f84531434bb3ee 748 × 802 px 2 Release(s)

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.

SHA-256 Inhalts-Fingerabdruck: 60f84531434bb3ee0f82d3232c0233a4d25cfa9e9167b15e9fec28c2be34f2da

Im Versions-Explorer öffnen

Kanonischer Bildausschnitt (144 DPI WebP, gerendert aus Original-Vektorgrafik) · nicht öffentlich, nur mit Anmeldung und Freigabe
✦ KI-generierte Bildanalyse & technische Beschreibung Modell: gemini-3.8-flash (via agy) · Rezept figure-series@1 · erstellt am 2026-10-08

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).

Versionsvergleich KI-generiert · gemini-3.8-flash (via agy)

R3.1.5 → R3.2.3 keine inhaltliche Änderung Nachfolger: FIG-7770893cb4061728

Keine inhaltlichen Änderungen erkennbar.

Zugeordnete Anforderungen

Diese Angaben zeigt der Versions-Explorer.

Aus dem Dokument extrahierter Text & Kontext

Beschriftungen im Schaubild:

sd Interactions | calling OS-Appl. | <trusted function | stub> | operating | system providing | OS-Appl. | alt Check permission | [denied] | [accepted] | system call dispatcher | <trusted function stub> | CallTrustedFunction(FunID,FunParPtr) | E_OS_SERVICEID | <trusted function> | <CheckAccess> | <Access Information> | E_OK | <return value>

Vorkommen in AUTOSAR-Releases (2)

Release Dokument Seite Nr. Bildunterschrift im Dokument
R3.0.7 AUTOSAR_SWS_OS S. 93 9.1 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.
R3.1.5 AUTOSAR_SWS_OS S. 93 9.1 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.