patina_boot: Add SreBootManager skeleton with normal boot path#1492
Closed
kat-perez wants to merge 10 commits into
Closed
Conversation
…DevicePartnership#1225) Adds BootOrchestration component, simple console discovery, simple BootOption Config - [x] Impacts functionality? - [ ] Impacts security? - [ ] Breaking change? - [x] Includes tests? - [x] Includes documentation? QEMU Platform Integration: - Q35 - SBSA N/A
… boot options (OpenDevicePartnership#1272) ## Description Add hotkey detection support to the boot orchestrator, allowing platforms to configure alternate boot options that are used when a hotkey (e.g., F12) is pressed during boot. Changes: - Add `detect_hotkey()` helper function to check for hotkey press via SimpleTextInput protocol - Add `hotkey_devices` field and `with_hotkey_device()` builder to `BootOptions` - Update `BootOrchestrator` to use alternate boot options when hotkey is detected --- - [x] Impacts functionality? - [ ] Impacts security? - [ ] Breaking change? - [x] Includes tests? - [ ] Includes documentation? ## How This Was Tested - Unit tests for `detect_hotkey()` (no input handles case) - Unit tests for `hotkey_devices` config (single device, multiple devices, combined with hotkey) - `cargo test -p patina_boot` passes ## Integration Instructions Platforms can configure hotkey boot options: ```rust BootOptions::new() .with_device(primary_device) .with_hotkey(0x16) // F12 scancode .with_hotkey_device(alternate_device) ``` Closes OpenDevicePartnership#1228
…e_system_table (OpenDevicePartnership#1284) Release SYSTEM_TABLE lock (TPL_NOTIFY) before accessing ComponentDispatcher (TPL_APPLICATION) to avoid TPL violation. PR OpenDevicePartnership#1225 lowered ComponentDispatcher from TPL_NOTIFY to TPL_APPLICATION to allow components to use boot services, but this created a conflict when initialize_system_table held SYSTEM_TABLE while setting boot/runtime services on ComponentDispatcher. Fix: Extract boot/runtime services pointers while holding SYSTEM_TABLE lock, then release it before accessing ComponentDispatcher. - [x] Impacts functionality? - [ ] Impacts security? - [ ] Breaking change? - [ ] Includes tests? - [ ] Includes documentation? - Unit tests pass - QEMU Q35 boots without TPL violation panic N/A
…ion (OpenDevicePartnership#1290) Add support for expanding partial (short-form) device paths to full device paths by matching against the device topology. - Add `is_partial_device_path()` to detect partial paths (start with Media/Messaging nodes instead of Hardware/ACPI) - Add `expand_device_path()` to find matching full paths by enumerating device handles - Wire expansion into `boot_from_device_path()` for transparent handling - Currently supports HardDrive nodes with GPT partition signature matching This enables booting from Boot#### variables containing partial device paths like `HD(1,GPT,<GUID>)\EFI\BOOT\BOOTX64.EFI`. - [x] Impacts functionality? - [ ] Impacts security? - [ ] Breaking change? - [x] Includes tests? - [ ] Includes documentation? - Unit tests for `is_partial_device_path()`, `expand_device_path()`, and signature matching - `cargo test -p patina_boot` passes (32 tests) - QEMU Q35 platform test passes N/A Closes OpenDevicePartnership#1280
…stration design (OpenDevicePartnership#1333) ## Description Refactors `patina_boot` from a monolithic `BootOrchestrator` component + `Config<BootOptions>` pattern to a trait-based design: - **`BootOrchestrator` trait** — defines the boot flow interface with `execute() -> Result<!, EfiError>`, enforcing at the type level that successful boot never returns - **`BootDispatcher`** — the Patina component that installs the BDS architectural protocol and delegates to a `BootOrchestrator` implementation - **`SimpleBootManager`** — a default `BootOrchestrator` implementation for platforms with straightforward boot topologies - **`BootConfig`** — unified boot configuration (replaces previous `BootOptions` + `SimpleBootConfig` split), requires at least one device at construction (compile-time enforcement) Also updates `helpers.rs` imports from removed `uefi_protocol::device_path` to `device_path::paths`/`device_path::node_defs`. `patina_dxe_core` changes (image handle plumbing) split out to OpenDevicePartnership#1374. - [x] Impacts functionality? - [ ] Impacts security? - [x] Breaking change? - [x] Includes tests? - [ ] Includes documentation? ## How This Was Tested 1. Unit tests: 35 pass (`cargo test -p patina_boot`) 2. Integration tested on QEMU Q35 — all components dispatched, BDS phase ran, boot options attempted, failure handler fired correctly 3. CI: fmt, clippy, all platforms pass ## Integration Instructions Update boot orchestration usage from: ```rust use patina_boot::{component::BootOrchestrator, config::BootOptions}; // In configs(): add.config(BootOptions::new()...); // In components(): add.component(BootOrchestrator); ``` To: ```rust use patina_boot::{BootDispatcher, SimpleBootManager, config::BootConfig}; add.component(BootDispatcher::new(SimpleBootManager::new( BootConfig::new(primary_device_path()) .with_device(fallback_device_path()) .with_hotkey(0x16) .with_hotkey_device(usb_device_path()) .with_failure_handler(|| { /* ... */ }), ))); ```
…penDevicePartnership#1375) ## Description Rewrite `discover_console_devices()` from a stub into a full implementation that enumerates console protocol handles, builds multi-instance device paths, and writes `ConIn`, `ConOut`, and `ErrOut` UEFI global variables via `SetVariable`. - Adds `EFI_GLOBAL_VARIABLE` GUID to `patina::guids` - Adds `build_multi_instance_device_path()` helper for constructing multi-instance device paths from protocol handles - Updates `is_partial_device_path()` to recognize FV/FvFile paths as non-partial - Includes get_variable readback verification with device path display logging Depends on OpenDevicePartnership#1333. Closes OpenDevicePartnership#1230 - [x] Impacts functionality? - [ ] Impacts security? - [ ] Breaking change? - [ ] Includes tests? - [ ] Includes documentation? ## How This Was Tested Verified on QEMU Q35 with VGA enabled. Console variables written and read back successfully: - ConIn: 24 bytes (SimpleTextInput) - ConOut: 60 bytes (SimpleTextOutput + GOP) - ErrOut: 30 bytes (SimpleTextOutput) ## Integration Instructions N/A
…with DxeServices (OpenDevicePartnership#1422) ## Description Interleave controller connection with DXE driver dispatch during device enumeration. Connecting controllers can discover new firmware volumes (e.g., PCI option ROMs) that contain drivers for devices behind that controller. Those drivers must be dispatched before the next round of enumeration, otherwise the devices they serve will not be found. `SimpleBootManager` uses `interleave_connect_and_dispatch()` to alternate between connecting controllers and dispatching newly-discovered drivers until both stabilize. The `DxeDispatch` service trait (from OpenDevicePartnership#1421) is consumed via dependency injection. Note: `interleave_connect_and_dispatch()` currently uses `connect_all()` which connects every controller on every round. This is functional but inefficient for platforms with large device topologies — a future optimization could connect only newly-discovered controllers. - [x] Impacts functionality? - [ ] Impacts security? - [ ] Breaking change? - [x] Includes tests? - [ ] Includes documentation? ## How This Was Tested - Built SBSA DXE core binary with `BootDispatcher` + `SimpleBootManager` replacing TianoCore BdsDxe - Booted Windows ARM64 under QEMU SBSA-ref emulation with Patina BDS handling the full boot flow - Verified interleaving: controller connection discovered AHCI device, partial device path expanded to full path, Windows bootloader loaded, ExitBootServices completed ## Integration Instructions Depends on OpenDevicePartnership#1421 (`DxeDispatch` service trait) for platform binary integration. Remove TianoCore `BdsDxe.inf` from platform DSC/FDF since the `BootDispatcher` provides the BDS architectural protocol.
…penDevicePartnership#1447) ## Description Add `discover_boot_options()` helper to `patina_boot::helpers` that reads UEFI `BootOrder` and `Boot####` variables to build a `BootConfig` from standard UEFI boot options. This enables any `BootOrchestrator` implementation that consumes `BootConfig` to use UEFI-compliant boot variables instead of requiring platforms to hardcode device paths. The function: - Reads `BootOrder` to determine boot attempt order - Parses each `Boot####` `EFI_LOAD_OPTION` structure to extract device paths - Filters out inactive boot options (`LOAD_OPTION_ACTIVE`) - Gracefully skips unreadable or malformed entries - Returns a populated `BootConfig` with discovered devices in priority order --- - [ ] Impacts functionality? - [ ] Impacts security? - [ ] Breaking change? - [x] Includes tests? - [ ] Includes documentation? ## How This Was Tested - Unit tests covering: single/multiple boot options, inactive option filtering, unreadable variable handling, truncated load option data, empty BootOrder, and hex variable name generation - Integration tested with patina-dxe-core-qemu `feature/patina-boot` on QEMU Q35 — full boot to UEFI Shell 2.0 ## Integration Instructions Platforms can call `discover_boot_options()` with runtime services to automatically populate a `BootConfig` from UEFI boot variables instead of constructing device paths manually. This works with any `BootOrchestrator` implementation that accepts a `BootConfig`: ```rust let config = discover_boot_options(&runtime_services)?; add.component(BootDispatcher::new(SimpleBootManager::new(config))); ```
Contributor
✅ QEMU Validation PassedAll QEMU validation jobs completed successfully.
Workflow run: https://github.com/OpenDevicePartnership/patina/actions/runs/25223064312 Boot Time to EFI Shell
Dependencies
This comment was automatically generated by the Patina QEMU PR Validation Post workflow. |
Codecov Report❌ Patch coverage is
📢 Thoughts on this report? Let us know! |
kat-perez
force-pushed
the
kat-perez/issue-62-sre-boot-manager-skeleton
branch
from
8430ebc to
777968d
Compare
kat-perez
force-pushed
the
kat-perez/issue-62-sre-boot-manager-skeleton
branch
5 times, most recently
from
76dd53a to
6f70d74
Compare
Introduces lock_partition_write() in helpers.rs. Resolves the NVMe controller via locate_device_path against EFI_NVM_EXPRESS_PASS_THRU_PROTOCOL and issues NVMe Set Features FID 0x11 (Boot Partition Write Protection Configuration), placing both BP0 and BP1 in "Write Protect Until Power Cycle" state per NVMe Base Spec section 5.27.1.17. Inner FFI dispatch is split into an unsafe helper following the existing detect_hotkey_from_handles pattern; the raw-pointer path is integration- tested rather than mocked. Adds three unit tests covering locate_device_path failure, handle_protocol failure, and the CDW10/CDW11 encoding contract. Closes OpenDevicePartnership#61.
Adds SreBootManager implementing BootOrchestrator for platforms shipping a System Recovery Environment alongside the main OS. Skeleton — normal boot path only: 1. Interleave controller connection with DXE driver dispatch 2. Signal EndOfDxe (security lockdown) 3. Discover console devices 4. Write-lock the NVMe boot partition (lock_partition_write) 5. Signal ReadyToBoot 6. Boot the main OS device Hotkey detection (Power+Vol-Up to SRE), SRE WIM RAM-disk boot, and capsule-update pre-boot hook are tracked separately and will layer on top of this skeleton via subsequent issues. Adds six unit tests covering construction, the connect+dispatch interleave loop in three modes (single-round, dispatch error, max-rounds), type-level BootOrchestrator conformance, and Arc<dyn BootOrchestrator> construction. Stacked on the partition write-lock helper from OpenDevicePartnership#61 (PR OpenDevicePartnership#1488). Once that lands, this PR rebases trivially onto feature/patina-boot. Closes OpenDevicePartnership#62.
kat-perez
force-pushed
the
kat-perez/issue-62-sre-boot-manager-skeleton
branch
from
6f70d74 to
09fdca2
Compare
5 tasks
kat-perez
force-pushed
the
feature/patina-boot
branch
from
d9c454f to
adc19cd
Compare
5 tasks
Contributor
Author
|
Closing in favor of OpenDevicePartnership/odp-platform-common#91, which relocates |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
Adds
SreBootManagerimplementingBootOrchestratorfor platforms shipping a System Recovery Environment alongside the main OS. Skeleton — normal boot path only: connect+dispatch, EndOfDxe, console discovery, write-lock the boot partition, ReadyToBoot, boot the main OS.Hotkey detection, SRE WIM RAM-disk boot, and capsule-update pre-boot hook are tracked separately and will layer onto this skeleton.
Closes OpenDevicePartnership/odp-platform-common#62.
How This Was Tested
cargo make allIntegration Instructions
Stacked on #1488. Merge #1488 first, then this rebases trivially onto
feature/patina-boot.