Seminar Trusted Firmware-A – EL3 Runtime Services und SMCCC

Das Seminar führt von der SMC Calling Convention bis zu einem eigenen, sicher implementierten EL3-Laufzeitdienst. Registrierung, Initialisierung, Dispatch, Kontextverwaltung, Nebenläufigkeit und Schnittstellenhärtung werden anhand des TF-A-Frameworks praktisch umgesetzt. Dadurch entsteht ein klares Verständnis dafür, welche Dienste in EL3 gehören, welche Daten als nicht vertrauenswürdig gelten und wie stabile Firmware-ABIs gestaltet werden.

Inhaltsübersicht

1. SMC und SMCCC-Grundlagen
2. EL3-Runtime-Service-Framework
3. SMC-Dispatch und Parameterfluss
4. Kontextmanagement und World Switch
5. SiP- und OEM-Dienste entwerfen
6. Nebenläufigkeit und Sperrkonzept
7. Interrupts und asynchrone Ereignisse
8. Schnittstellenhärtung
9. Eigener EL3-Dienst als Abschlusslabor

Lernziele

• SMC Calling Convention, Owner-Bereiche und Aufruftypen korrekt anwenden.
• EL3-Laufzeitdienste registrieren, initialisieren und über Dispatch-Funktionen bereitstellen.
• Kontextwechsel und Zustandsverwaltung zwischen Sicherheitszuständen nachvollziehen.
• SiP- oder OEM-Dienste mit robuster Parameterprüfung und Fehlersemantik implementieren.
• Nebenläufigkeit, Interrupts, ABI-Stabilität und Angriffsflächen systematisch prüfen.

Seminarinhalte

1. SMC und SMCCC-Grundlagen

1. Schritt 1: SMC-Instruktion, Funktions-ID, Aufrufkonvention und Rückgaberegister werden zerlegt.
2. Schritt 2: Fast Calls, Yielding Calls, 32- und 64-Bit-Konventionen sowie Owner-Bereiche werden unterschieden.
3. Schritt 3: Versionierung, Discovery und standardisierte Fehlercodes werden als ABI-Bausteine eingeordnet.

Praxis: Mehrere SMC-Funktions-IDs werden dekodiert und auf Konsistenz geprüft.

2. EL3-Runtime-Service-Framework

1. Schritt 1: Service-Deskriptoren, Initialisierungsfunktionen und Handler werden im Quellbaum lokalisiert.
2. Schritt 2: Registrierungsreihenfolge und Überlappungen von Owner-Bereichen werden kontrolliert.
3. Schritt 3: Initialisierungsfehler werden so behandelt, dass kein unvollständiger Dienst aktiv bleibt.

Praxis: Ein minimaler Dienst wird registriert und beim Start mit einer eindeutigen Statusmeldung bestätigt.

3. SMC-Dispatch und Parameterfluss

1. Schritt 1: Eingangsregister werden ohne ungeprüfte Pointer-Nutzung in interne Werte überführt.
2. Schritt 2: Funktionsauswahl, Berechtigungsprüfung und Rückgabe werden in klar getrennte Schritte aufgeteilt.
3. Schritt 3: Unbekannte Aufrufe, falsche Breite und ungültige Kombinationen erhalten deterministische Fehlerantworten.

Praxis: Ein Handler mit mehreren Funktionen und vollständiger Negativprüfung wird implementiert.

4. Kontextmanagement und World Switch

1. Schritt 1: Gespeicherte Registergruppen und per-Welt-Kontexte werden analysiert.
2. Schritt 2: Eintritts- und Rückkehrpfade zwischen Non-secure, Secure und optional Realm werden verfolgt.
3. Schritt 3: Zusätzliche Architekturregister werden nur bei aktivierten Features in den Kontext aufgenommen.

Praxis: Ein Weltwechsel wird mit Registermarkierungen und kontrollierter Rückgabe nachvollzogen.

5. SiP- und OEM-Dienste entwerfen

1. Schritt 1: Plattformspezifische Funktionen werden von standardisierten Architekturdiensten getrennt.
2. Schritt 2: Funktionsgruppen, Versionen und optionale Capability-Abfragen werden festgelegt.
3. Schritt 3: Zugriff auf Geräte, Speicher und Schlüsselmaterial wird über minimale, prüfbare Operationen gekapselt.

Praxis: Für einen Plattformdienst wird eine kompakte ABI mit Versions- und Feature-Abfrage entworfen.

6. Nebenläufigkeit und Sperrkonzept

1. Schritt 1: Per-CPU- und globale Zustände werden identifiziert.
2. Schritt 2: Spinlocks, atomare Operationen, Bakery Locks und Unterbrechbarkeit werden nach Kontext gewählt.
3. Schritt 3: Reentrancy und Aufrufverschachtelung werden durch Zustandsautomaten oder explizite Ablehnung kontrolliert.

Praxis: Ein gemeinsamer Dienstzustand wird unter parallelen Aufrufen getestet und abgesichert.

7. Interrupts und asynchrone Ereignisse

1. Schritt 1: Synchroner SMC-Dispatch und asynchrone Interrupt-Behandlung werden sauber getrennt.
2. Schritt 2: Routing und Prioritäten werden mit dem aktiven Sicherheitszustand abgestimmt.
3. Schritt 3: Lange Operationen werden so entworfen, dass Latenz und Blockierung beherrschbar bleiben.

Praxis: Ein Dienst wird unter gleichzeitigem Interrupt-Ereignis auf korrekten Zustand geprüft.

8. Schnittstellenhärtung

1. Schritt 1: Alle Registerparameter, Adressen, Größen und Zustandsübergänge werden vor der Nutzung validiert.
2. Schritt 2: Fehlertexte und Logs werden auf Informationsabfluss geprüft.
3. Schritt 3: ABI-Kompatibilität, Deprecation und sichere Erweiterbarkeit werden in einem Versionsplan festgehalten.

Praxis: Ein vorhandener Handler wird anhand einer Härtungscheckliste überarbeitet.

9. Eigener EL3-Dienst als Abschlusslabor

1. Schritt 1: Anforderungen, Funktions-IDs, Datenmodell und Berechtigungen werden vor der Implementierung festgelegt.
2. Schritt 2: Dienst, Build-Integration, Client-Aufruf und Tests werden schrittweise umgesetzt.
3. Schritt 3: Positive, negative und parallele Aufrufe werden protokolliert und bewertet.

Praxis: Ein vollständiger SiP-Beispieldienst wird gebaut, aufgerufen und mit Regressionstests abgesichert.

Zielgruppe

Firmware- und Security-Entwickler, SoC-Integratoren, BSP-Entwickler und Entwickler plattformspezifischer EL3-Dienste.

Voraussetzungen

Gute C- und Arm-A-Kenntnisse, TF-A-Architekturgrundlagen, Verständnis von Exception Levels, Interrupts und Nebenläufigkeit.

Praxisumgebung

Linux-Arbeitsplatz mit TF-A-Quellbaum, AArch64-Toolchain, QEMU oder FVP und einem kleinen Non-secure Testclient.