Seminar oreboot Intensivseminar 3: RISC-V, Payloads, Sicherheit und Upstream

Inhaltsverzeichnis

• Einordnung
• Kompetenzziele
• Seminarinhalte
• Praxisübungen
• Methodik
• Zielgruppe
• Vorkenntnisse

Einordnung

Das dritte Intensivseminar verbindet RISC-V-Privilegien, Mehrhart-Start, Trap-Pfade, SBI und RustSBI, LinuxBoot- und u-root-Payloads, Kernelübergabe, Bedrohungsmodell, Hardening, Update, CI, Upstream-Review und Wartung. Das Abschlussprojekt führt Firmware, Payload und Betriebsnachweise zusammen.

Kompetenzziele

• RISC-V-Modi, CSRs, Harts und Trap-Pfade für den Firmwareübergang beherrschen.
• SBI-Plattformadapter und Supervisor-Übergabe nachvollziehbar prüfen.
• LinuxBoot- oder u-root-Payload mit Device Tree und Initramfs integrieren.
• Firmwarelieferkette, Flash, Debug, Update und Recovery absichern.
• Reviewfähige Änderungen und wartbare Regressionstests vorbereiten.
• Ein technisch freigabefähiges End-to-End-Szenario dokumentieren.

Seminarinhalte

Modul 1: RISC-V-Privilegien, Harts und Trap-Verhalten

1. Schritt 1: Startprivileg bestimmen

   Machine-, Supervisor- und gegebenenfalls User-Modus werden den Firmware- und Betriebssystemaufgaben zugeordnet.

2. Schritt 2: CSR-Zustand prüfen

   Status-, Interrupt-, Trap-, Delegations- und Adressübersetzungsregister werden vor jedem Moduswechsel kontrolliert.

3. Schritt 3: Mehrere Harts koordinieren

   Boot-Hart, wartende Harts, Interprozessorunterbrechungen und gemeinsame Initialisierungsdaten werden ohne Rennen organisiert.

4. Schritt 4: Trap-Pfade testen

   Unerlaubte Instruktion, Zugriffsfault, Timer- und Softwareinterrupt werden mit eindeutigen Diagnoseinformationen behandelt.

Modul 2: SBI und RustSBI als Übergabeschicht

1. Schritt 1: SBI-Rolle festlegen

   Timer, Interprozessorunterbrechung, Systemreset, Hartzustand und herstellerspezifische Erweiterungen werden zwischen Firmware und Supervisor getrennt.

2. Schritt 2: Plattformadapter anbinden

   Timerquelle, Interruptmechanismus, Resetpfad und Konsolenausgabe werden in die SBI-Implementierung integriert.

3. Schritt 3: Übergaberegister setzen

   Hart-ID, Device-Tree-Zeiger, Supervisor-Einstieg, Statusregister und Delegationen werden vor dem Moduswechsel verifiziert.

4. Schritt 4: SBI-Aufrufe prüfen

   Kernelanforderungen, Fehlercodes, nicht unterstützte Erweiterungen und Systemreset werden mit reproduzierbaren Tests bewertet.

Modul 3: LinuxBoot- und u-root-Payloads

1. Schritt 1: Payloadformat festlegen

   Kernel, Initramfs, optionales u-root-Programm, Device Tree und Kommandozeile werden als klar versionierte Bestandteile definiert.

2. Schritt 2: Größe und Adresse planen

   Komprimierung, Ladeadresse, Entpackbereich, Initrd-Grenzen und Überschneidungen mit Firmware oder reserviertem Speicher werden geprüft.

3. Schritt 3: Frühen Userspace gestalten

   Hardwareerkennung, Netzwerkinitialisierung, Storagezugriff, Diagnose, Signaturprüfung und Übergang zum Zielsystem werden minimal zusammengesetzt.

4. Schritt 4: Fehlerfälle beherrschen

   Fehlender Datenträger, ungültige Konfiguration, nicht erreichbares Netzwerk und unbrauchbares Root-Dateisystem führen in einen kontrollierten Diagnosepfad.

Modul 4: Übergabe an Kernel und Betriebssystem

1. Schritt 1: Einstiegsvertrag prüfen

   Architekturabhängige Register, Privilegstufe, Interruptzustand, Cachezustand und erwarteter Einstiegspunkt werden festgehalten.

2. Schritt 2: Speicher freigeben

   Firmwarebereiche, reservierter Speicher, Device Tree, Initramfs und Kernel werden ohne Überlappung an das Betriebssystem übergeben.

3. Schritt 3: Gerätebeschreibung abstimmen

   Aktivierte Hardware, Konsolenpfad, Speicherkapazität, Interrupts und Bootargumente werden auf Konsistenz geprüft.

4. Schritt 4: Startnachweis führen

   Letzter Firmwaremarker, erster Kernelmarker, erkannter Speicher, Initialisierung der Konsole und Eintritt in den Userspace werden protokolliert.

Modul 5: Bedrohungsmodell für frühe Firmware

1. Schritt 1: Schutzgüter bestimmen

   Firmwareintegrität, Schlüssel, Gerätekonfiguration, Recovery-Fähigkeit, Bootprotokoll und Verfügbarkeit werden nach Kritikalität bewertet.

2. Schritt 2: Angriffsflächen erfassen

   Buildsystem, Abhängigkeiten, Flashzugriff, Debugschnittstellen, Bootmedien, Device Tree, Payload und Updateweg werden untersucht.

3. Schritt 3: Vertrauensanker zuordnen

   Boot-ROM-Funktionen, Hardwareoptionen, organisatorische Freigaben und kryptografische Prüfungen werden ihren tatsächlichen Grenzen zugeordnet.

4. Schritt 4: Maßnahmen priorisieren

   Reproduzierbare Builds, minimale Treiber, Schreibschutz, signierte Artefakte, Debugkontrolle und Recovery werden risikobezogen geplant.

Modul 6: Hardening, Update und Betriebsfreigabe

1. Schritt 1: Build absichern

   Gepinnte Abhängigkeiten, nachvollziehbare Toolchains, Reviewpflicht, Artefakthashes und getrennte Freigabeschritte werden eingerichtet.

2. Schritt 2: Laufzeit minimieren

   Nicht benötigte Treiber, Diagnosefunktionen, Protokolle und Schreibpfade werden aus dem Produktionsprofil entfernt oder kontrolliert.

3. Schritt 3: Updateweg gestalten

   Versionserkennung, Kompatibilitätsprüfung, atomare Aktualisierung, Rückfallabbild und Stromausfallverhalten werden festgelegt.

4. Schritt 4: Freigabe prüfen

   Bootzeit, Wiederholbarkeit, Recovery, Debugsperren, Protokollierung, bekannte Risiken und Wartungszuständigkeit werden vor der Inbetriebnahme abgenommen.

Modul 7: Testautomatisierung und Continuous Integration

1. Schritt 1: Prüfmatrix bilden

   Architekturen, Mainboards, Features, Debug- und Release-Builds sowie Payloadvarianten werden in einer wartbaren Matrix zusammengefasst.

2. Schritt 2: Statische Prüfungen integrieren

   Formatierung, Lints, Abhängigkeitskontrollen, Dokumentationsprüfung und Größenlimits werden vor dem Laufzeittest ausgeführt.

3. Schritt 3: Boottests ausführen

   Emulationsstart, serielle Sollmuster, Zeitgrenzen und definierte Fehlerfälle werden automatisch bewertet.

4. Schritt 4: Artefakte sichern

   Buildprotokolle, Firmwareabbilder, Disassemblierungen, Größenberichte und Testergebnisse werden je Änderung nachvollziehbar archiviert.

Modul 8: Upstream-Entwicklung und reviewfähige Änderungen

1. Schritt 1: Änderung zerlegen

   Infrastruktur, generischer Treiber, SoC-Unterstützung, Mainboardcode, Device Tree, Dokumentation und Tests werden in logisch getrennte Beiträge aufgeteilt.

2. Schritt 2: Commitqualität herstellen

   Jeder Commit erhält einen klaren Zweck, baut eigenständig, enthält keine Nebenänderungen und beschreibt beobachtbares Verhalten.

3. Schritt 3: Review vorbereiten

   Hardwarevoraussetzungen, Testablauf, Konsolenausgabe, bekannte Einschränkungen und Sicherheitsauswirkungen werden nachvollziehbar dokumentiert.

4. Schritt 4: Rückmeldungen einarbeiten

   Technische Einwände werden reproduziert, Änderungen gezielt überarbeitet und neue Testnachweise ohne unnötiges Umschreiben der Historie ergänzt.

Modul 9: Wartung, Regressionen und Releasepflege

1. Schritt 1: Unterstützungsstand inventarisieren

   Boards, SoCs, Toolchains, Payloads, bekannte Einschränkungen und zuständige Personen oder Teams werden in einer Wartungsmatrix geführt.

2. Schritt 2: Änderungsrisiko bewerten

   Compilerupdates, Crate-Aktualisierungen, Refactorings, neue Features und Plattformänderungen werden nach Bootkettenwirkung klassifiziert.

3. Schritt 3: Regressionen eingrenzen

   Letzter guter Stand, Buildunterschiede, Größenänderungen, Konsolenmarker und Hardwarevergleich werden zur Bisektion genutzt.

4. Schritt 4: Freigaben pflegen

   Version, Quellstand, Toolchain, Artefakte, Testprotokolle, Recovery-Abbild und bekannte Abweichungen werden gemeinsam veröffentlicht.

Modul 10: Flashing, Recovery und sichere Laborabläufe

1. Schritt 1: Bootpfade inventarisieren

   Normales Bootmedium, Boot-ROM-Modus, USB- oder serielle Recovery, Wechselmedium und externe Programmierung werden nach Priorität erfasst.

2. Schritt 2: Sicherungsabbild erstellen

   Originalinhalt, Gerätekonfiguration, eindeutige Hashwerte und Rücksicherungsanweisung werden vor Änderungen gesichert.

3. Schritt 3: Abbild schreiben

   Zieloffset, Löschbereich, Schreibgröße, Versorgung und Schreibschutz werden vor dem Programmiervorgang kontrolliert.

4. Schritt 4: Recovery proben

   Ein absichtlich nicht startendes Testabbild wird über den vorgesehenen Notfallpfad erkannt, ersetzt und anschließend verifiziert.

Modul 11: Hardwarelabor und Abnahmemessungen

1. Schritt 1: Laborzustand standardisieren

   Versorgung, Adapter, Kabel, Bootschalter, Flashinhalt, Messgeräte und Hostsoftware werden vor jedem Versuch dokumentiert.

2. Schritt 2: Beobachtungspunkte verbinden

   Serielle Konsole, JTAG, Logikanalysator und Strommessung werden so vorbereitet, dass Bootphasen zeitlich zugeordnet werden können.

3. Schritt 3: Testfälle ausführen

   Kaltstart, Warmstart, wiederholter Reset, fehlendes Medium, beschädigtes Abbild und Recovery werden mit festen Erwartungswerten geprüft.

4. Schritt 4: Abnahme protokollieren

   Firmwarehash, Boardrevision, Messergebnis, Konsolenausgabe, Abweichung und Entscheidung werden in einem reproduzierbaren Prüfprotokoll zusammengeführt.

Praxisübungen

• CSR-, Delegations- und Trapzustände für einen Supervisor-Start prüfen.
• SBI-Timer-, Reset- und Hartfunktionen in einem Plattformtest validieren.
• Kernel, Initramfs, u-root-Funktion und Device Tree als Payload integrieren.
• Negativfälle für fehlende Payload, ungültige Konfiguration und Recovery ausführen.
• Bedrohungsmodell und Hardeningprofil für Build und Zielgerät erstellen.
• Eine Änderung in logisch getrennte, reviewfähige Beiträge mit Testnachweis zerlegen.
• Releaseakte mit Quellstand, Toolchain, Hashwerten, Tests und Rückfallabbild erstellen.

Methodik

Fachliche Einordnung, kommentierte Demonstrationen und schrittweise Laboraufgaben werden eng miteinander verbunden. Jeder Arbeitsabschnitt beginnt mit einem überprüfbaren Zielzustand, wird anhand von Konsolen-, Build- oder Messdaten kontrolliert und endet mit einer dokumentierten Fehler- oder Abnahmeprüfung. Vorbereitete Negativfälle verhindern, dass ausschließlich der erfolgreiche Idealfall betrachtet wird.

Zielgruppe

RISC-V-Firmwareentwicklung, Embedded-Linux- und LinuxBoot-Teams, Product Security, CI- und Releaseverantwortliche sowie technische Maintainer.

Vorkenntnisse

Gute Kenntnisse in Firmwareboot, RISC-V-Grundlagen, Rust oder systemnaher Entwicklung und Linux. Für den Praxisteil wird eine vorhandene oreboot-Buildumgebung vorausgesetzt.