Seminar Trusted Firmware-A – GIC, Interrupts, Exception Handling und SDEI

Das Seminar verbindet die Arm-Interruptarchitektur mit der konkreten Behandlung in TF-A. GIC-Konfiguration, Interruptgruppen, Routingmodelle, Exception-Vektoren, sichere Nutzlasten und SDEI werden vom Eintritt bis zur Rückkehr analysiert. Praktische Übungen konzentrieren sich auf korrekte Prioritäten, zustandsabhängiges Routing, asynchrone Ereignisse und die Diagnose schwer reproduzierbarer Interruptfehler.

Inhaltsübersicht

1. GIC-Architektur und Sicherheitsgruppen
2. TF-A Interrupt Management Framework
3. Exception-Vektoren in BL31
4. Secure Payload und SPM-Interaktion
5. SDEI-Grundmodell
6. SDEI-Portierung und Ereignisquellen
7. Latenz und Verschachtelung
8. Fehleranalyse und Race Conditions
9. Gesamtlabor

Lernziele

• GIC- und TF-A-Interruptkonzepte über Sicherheitszustände hinweg korrekt zuordnen.
• Exception-Vektoren und Handlerpfade in BL31 nachvollziehen und erweitern.
• Sichere, nicht sichere und EL3-behandelte Interrupts regelkonform routen.
• SDEI-Ereignisse registrieren, auslösen und sicher an Non-secure Handler delegieren.
• Latenz-, Prioritäts-, Verschachtelungs- und Race-Probleme systematisch diagnostizieren.

Seminarinhalte

1. GIC-Architektur und Sicherheitsgruppen

1. Schritt 1: Distributor, Redistributor, CPU-Interface und Interrupttypen werden angeordnet.
2. Schritt 2: Group 0, Secure Group 1 und Non-secure Group 1 werden nach Zielzustand und Zugriff getrennt.
3. Schritt 3: Priorität, Maskierung, Triggerart und Affinität werden als vollständige Interruptkonfiguration erfasst.

Praxis: Eine GIC-Konfiguration wird aus Registern und Plattformcode rekonstruiert.

2. TF-A Interrupt Management Framework

1. Schritt 1: Interrupttypen, Routingmodelle und registrierte Handler werden im Framework lokalisiert.
2. Schritt 2: Anmeldung, Aktivierung und Behandlung eines Interrupts werden vom Plattformcode bis zum Handler verfolgt.
3. Schritt 3: Ungültige Kombinationen werden früh erkannt und mit klaren Assertions abgesichert.

Praxis: Ein Plattforminterrupt wird registriert und kontrolliert an einen EL3-Handler gebunden.

3. Exception-Vektoren in BL31

1. Schritt 1: Vektortabelle, Stack-Auswahl und Eintrittszustand werden für synchrone und asynchrone Exceptions analysiert.
2. Schritt 2: Systemregister werden in der richtigen Reihenfolge gesichert und ausgewertet.
3. Schritt 3: Rückkehrpfad und SPSR-Konfiguration werden auf Ziel-EL und Sicherheitszustand geprüft.

Praxis: Ein vorbereiteter Exception-Fall wird vom Vektoreintritt bis zur Rückkehr protokolliert.

4. Secure Payload und SPM-Interaktion

1. Schritt 1: Interruptbesitz und Delegation zwischen EL3, SPMC und Secure Partition werden festgelegt.
2. Schritt 2: Verschachtelte Ereignisse und unterbrochene SMC- oder FF-A-Aufrufe werden bewertet.
3. Schritt 3: Zustand und Priorität werden so verwaltet, dass kein Endpunkt einen fremden Interrupt konsumiert.

Praxis: Ein Secure-Interrupt-Szenario wird mit Zustandswechsel und Rückkehr nachgestellt.

5. SDEI-Grundmodell

1. Schritt 1: Ereignisklassen, Registrierung, Aktivierung, Routing und Handlerkontext werden erklärt.
2. Schritt 2: Firmware-Ereignisse werden von Non-secure Handlern und normalen IRQs abgegrenzt.
3. Schritt 3: Bound, recurring und dispatched events werden nach Lebenszyklus unterschieden.

Praxis: Ein SDEI-Ereignis wird registriert und mit einem einfachen Non-secure Handler verarbeitet.

6. SDEI-Portierung und Ereignisquellen

1. Schritt 1: Plattformspezifische Ereignisnummern, Interruptquellen und Prioritäten werden definiert.
2. Schritt 2: Explizite und interruptgetriebene Dispatch-Pfade werden implementiert.
3. Schritt 3: Fehlerhafte Registrierung, Maskierung und Wiederaktivierung werden mit Negativtests geprüft.

Praxis: Eine Plattformereignisquelle wird an SDEI angebunden und unter Wiederholung getestet.

7. Latenz und Verschachtelung

1. Schritt 1: Lange Handler, globale Sperren und unerwartete Prioritätsinversion werden identifiziert.
2. Schritt 2: Zeitstempel und Laufzeitinstrumentierung messen Eintritts-, Bearbeitungs- und Rückkehrzeit.
3. Schritt 3: Kritische Pfade werden verkürzt und nicht dringende Arbeit ausgelagert.

Praxis: Ein Handler wird instrumentiert und anhand gemessener Latenzen optimiert.

8. Fehleranalyse und Race Conditions

1. Schritt 1: Verlorene, doppelte und dauerhaft aktive Interrupts werden nach einer festen Prüfreihenfolge untersucht.
2. Schritt 2: Mehrkern-Affinität, Redistributor-Zustand und CPU-Hotplug werden einbezogen.
3. Schritt 3: Race Conditions werden durch Ereignismarker, Wiederholung und gezielte Last reproduziert.

Praxis: Ein sporadischer Mehrkern-Interruptfehler wird eingegrenzt und abgesichert.

9. Gesamtlabor

1. Schritt 1: Eine Interruptquelle wird konfiguriert, registriert und mit klarer Zuständigkeit versehen.
2. Schritt 2: Der Pfad wird unter normalem Betrieb, Secure-World-Aktivität und CPU-Wiederanlauf geprüft.
3. Schritt 3: Latenz, Fehlerfälle und Regressionstests werden dokumentiert.

Praxis: Ein vollständiger Interrupt- und SDEI-Testfall wird aufgebaut und abgenommen.

Zielgruppe

Firmware-Entwickler, BSP-Entwickler, SoC-Integratoren, Entwickler sicherer Laufzeitumgebungen und Embedded-Debugging-Teams.

Voraussetzungen

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

Praxisumgebung

Linux-Arbeitsplatz mit TF-A-Quellbaum, QEMU oder FVP, GIC-fähiger Plattformkonfiguration und Non-secure Testpayload.