Seminar LinuxBootSMM Architektur: SMM Ownership Transition, SMM-Payload vs. MM-Payload

Inhaltsverzeichnis

• Abstract
• Zielgruppe
• Voraussetzungen
• Lernziele
• Inhalte und Agenda
• Architektur-Workshops
• Ergebnisse und Transfer

Abstract

Dieses Seminar behandelt die Architekturidee, SMM-Ownership vom “Core Firmware”-Teil (z. B. coreboot) in die Payload-Schicht (LinuxBoot) zu verlagern. Der Fokus liegt auf Designoptionen und deren Konsequenzen: vollständiges Herausziehen der SMM-Setup-Logik (“SMM payload”) versus Brückenmodell, bei dem coreboot eine permanente Handler-Komponente als Bridge behält und payload-eigene Funktionalität über ein MM-Payload-Interface einhängt (“MM payload”). Zusätzlich werden Bootpfade und die Rolle von Loader/Parser-Komponenten besprochen.

Zielgruppe

• Firmware-Architektur, Tech Leads, Staff Engineers
• Security Engineering (Design Review, Risk Acceptance)
• Plattformverantwortliche (Board Enablement, Maintenance)

Voraussetzungen

• Grundlagen x86-Firmware-Bootflow: coreboot, UEFI, LinuxBoot und SMM & SMRAM Security: Architektur, Angriffsflächen, Risiko-Reduktion empfohlen
• Basiswissen coreboot/LinuxBoot Build (coreboot + LinuxBoot Build-Workshop: Toolchain, Konfiguration, Debugging) hilfreich

Lernziele

• Ownership-Transition als Architekturpattern definieren (Trust Boundaries, Interfaces)
• SMM-Payload-Ansatz und MM-Payload-Ansatz vergleichen und Entscheidungslogik ableiten
• Verantwortlichkeiten von Parser/Loader/Handler-Schichten verstehen
• S0 vs. coreboot + LinuxBoot Build-Workshop: Toolchain, Konfiguration, Debugging Resume Anforderungen als Design Constraints in Reviews nutzen

Inhalte und Agenda

Tag 1

• Motivation: SMM als blinder Fleck in Firmware-Security, Ownership als Risikotreiber
• Architekturvarianten: SMM payload vs. MM payload
• Module und Reihenfolgen (Parser → Handler → Loader) als Kontrollpunkte

Tag 2

• Bootpfade:Initial Boot vs. coreboot + LinuxBoot Build-Workshop: Toolchain, Konfiguration, Debugging Resume und deren Anforderungen
• Schnittstellen-Design: Welche Funktionen bleiben SoC-spezifisch, welche werden payload-seitig generisch
• Review-Design: Akzeptanzkriterien, Risiko-Register, “Definition of Done” für PoC vs. Produkt

Architektur-Workshops

• Ownership Transition Decision Canvas
  • Assets und Sicherheitsziele definieren (z. B. SMRAM-Integrität, Flash-Write-Policy)
  • Constraints sammeln (coreboot + LinuxBoot Build-Workshop: Toolchain, Konfiguration, Debugging-Pfad, SoC-Relocation, CPU-Parallellität)
  • Entscheidung SMM payload vs. MM payload anhand der Constraints treffen
  • Verifikationsplan definieren (welche Tests beweisen die Entscheidung)
• Interface Contract
  • Schnittstellenpunkte coreboot ↔ Payload identifizieren
  • “Must provide” Daten (Registerdefinitionen, Entry Points, Regions) festlegen
  • Validierungsregeln definieren (Range Checks, Signaturen, Größen)

Ergebnisse und Transfer

• Architekturentscheidungsvorlage für LinuxBootSMM-Programme
• Konkrete Akzeptanzkriterien für PoC und Portierung