Speaker
Yi-Yo Chiang
(Google)
Description
Android is evaluating the Linux EFI boot stub to standardize OS handoff and reduce bootloader feature duplication. We examine the architectural blockers that arise when dealing with strict embedded hardware constraints, aiming to brainstorm solutions.
Topics for Discussion:
-
EL2 Elevation and KVM within an EFI context
- The Problem: KVM requires booting the kernel at EL2. Since Android firmware operates at EL1, it must elevate to EL2 before kernel execution.
- Discussion: What are the options to elevate to EL2 before jumping to the kernel?
- Abuse
ExitBootServicesto hijack the boot flow? - Install a custom UEFI protocol callback that executes EL switch and takes over kernel jump?
- Abuse
-
Physical Image Placement and PE-COFF Relocation
- The Problem: Standard UEFI
LoadImage()operates as a PE loader, forcing the kernel to be relocated to a dynamically allocated address. - The Constraint:
- Boot Latency: Copying large kernel payloads increases boot latency.
- Static Architectural Expectations: Embedded firmware like Trusted Firmware-A (TF-A) often demands the OS load at a hardcoded address, which UEFI dynamic allocation violates.
- Discussion: How do we balance standard UEFI dynamic allocation with SoC firmware environments that strictly enforce fixed physical memory buffers for the OS?
- The Problem: Standard UEFI
-
Boot Command Line Serialization
- The Problem: The Linux ARM64 EFI stub ignores standard FDT
/chosen/bootargsand relies on UEFILoadOptions. - The Constraint: The bootloader builds the command line within the FDT, extracts it, and serializes it into UTF-16 UEFI
LoadOptions. The kernel's EFI stub then reads this back and overwrites the/chosen/bootargsnode within the FDT. - Discussion: How can we avoid this redundant string serialization cycle? Should the Linux EFI boot stub be modified to fallback to
/chosen/bootargsifLoadOptionsis empty?
- The Problem: The Linux ARM64 EFI stub ignores standard FDT