What's Changed

Maintain r-efi under the patina/sdk Cargo.toml @makubacki (#1706)
Change Details
## Description
The Patina SDK re-exports r-efi. The change moves the r-efi crate dependency under its Cargo.toml to clarify that is should only be directly depended on by the Patina SDK.
- Impacts functionality?
- Impacts security?
- Breaking change?
- Includes tests?
- Includes documentation?
How This Was Tested
- cargo make all
Integration Instructions
- N/A

smbios: use r-efi constants @kat-perez (#1703)
Change Details
## Description
Require r-efi 7.1 and replace the remaining Patina-owned SMBIOS constants with the definitions released upstream in r-efi/r-efi#102.

The existing SMBIOS_HANDLE_PI_RESERVED and SMBIOS_STRING_MAX_LENGTH public names remain available as re-exports, so downstream Patina users do not need to change imports. The SMBIOS protocol GUID now comes directly from r_efi::efi::protocols::smbios::PROTOCOL_GUID.

Tracking: #1457
- Impacts functionality?
- Impacts security?
- Breaking change?
- Includes tests?
- Includes documentation?
How This Was Tested
- cargo make fmt
- cargo make test -p patina_smbios
- cargo make check
Integration Instructions

N/A

Ignore slow tests [Rebase \& FF] @makubacki (#1692)
Change Details
## Description
Since a small set of unit tests increase time significantly, this follows the guidance in the Rust Programming Language book to ignore them during normal test runs.
- cargo make test before avg (after clean): 192 seconds
- cargo make test after avg (after clean): 105 seconds
This does not include ignored tests in test coverage, though that's possible if preferred.

Ignore long-running tests by default

Excluding compile_fail_tests reduces "cargo make test" reduces the
test run time by about 45% (after clean). Since it is common to run
cargo make test throughout development, this has a significant
impact on iterative development.

This change marks these tests as ignored by default, so that they will
only run when explicitly requested with cargo test --ignored.

A few tests in components\patina_test\src\component.rs were
already using the #[ignore] attribute but don't successfully run.
The storage::new() calls initialize StandardBootServices. This
code ends up registering a Ready to Boot notification, but
create_event_ex() is not initialized in the Boot Services table and
panics with a message.

This change removes these tests for now with a tracking issue filed
to add them back when the UEFI services are available to mock.

Makefile.toml: Add test-ignored task

Adds a new task to run ignored tests excluding those in doctests.
- cargo make test - Runs all tests excluding ignored tests.
- cargo make test-ignored - Runs ignored tests excluding those in
  doctests.
cargo make all runs both sets.

This allows cargo make test to run much faster by ignoring a small
set of slow tests.
- Impacts functionality?
- Impacts security?
- Breaking change?
- Includes tests?
- Includes documentation?
How This Was Tested
- cargo make test
- cargo make test-ignored
- cargo make all
Integration Instructions
- N/A

SerialLogger: Add opt-in blocking, uncorrupted serial logging @vineelko (#1702)
Change Details
## Description
The existing SharedSerial implementation uses non-blocking serial port acquisition and returns DeviceError when the port is unavailable. When used by the Rust MM Supervisor, this can result in log messages being dropped, especially when multiple cores attempt to log concurrently.

Add an opt-in blocking mode that lets callers block while acquiring the serial port instead of returning DeviceError:
- SharedSerial::into_blocking() converts a wrapper to spin (block) on acquisition rather than failing fast on contention.
- Logger::with_blocking() enables blocking mode on the serial logger.
Blocking the port alone only makes each individual write_str fragment atomic, not a whole record. Because Format::write() emits a single log record via multiple write_str calls (prefix, level, message, terminator), concurrent cores could still interleave those fragments and produce corrupted lines such as:
```
INFO - AP (CPU INFO - AP (CPU 64) exiting holding pen
```
To fix this, add a logger-level write_lock that is held for the entire record when blocking mode is enabled, so a message is emitted atomically with respect to other cores.
```
UEFI_UART: 8/8/2026 12:42:14 AM | INFO - EBS completed successfully.
UEFI_UART: 8/8/2026 12:42:20 AM | INFO - BSP (CPU 0) waiting for APs to arrive...
UEFI_UART: 8/8/2026 12:42:20 AM | INFO - AP (CPU 68) checked in, entering holding pen...
UEFI_UART: 8/8/2026 12:42:20 AM | INFO - AP (CPU 16) checked in, entering holding pen...
UEFI_UART: 8/8/2026 12:42:20 AM | INFO - AP (CPU 24) checked in, entering holding pen...
UEFI_UART: 8/8/2026 12:42:20 AM | INFO - AP (CPU 64) checked in, entering holding pen...
UEFI_UART: 8/8/2026 12:42:20 AM | INFO - AP (CPU 8) checked in, entering holding pen...
UEFI_UART: 8/8/2026 12:42:20 AM | INFO - AP (CPU 66) checked in, entering holding pen...
UEFI_UART: 8/8/2026 12:42:20 AM | INFO - AP (CPU 70) checked in, entering holding pen...
UEFI_UART: 8/8/2026 12:42:20 AM | INFO - All 7 APs arrived
...
UEFI_UART: 8/8/2026 12:42:20 AM | INFO - AP (CPU 8) exiting holding pen
UEFI_UART: 8/8/2026 12:42:20 AM | INFO - AP (CPU 24) exiting holding pen
UEFI_UART: 8/8/2026 12:42:20 AM | INFO - AP (CPU 16) exiting holding pen
UEFI_UART: 8/8/2026 12:42:20 AM | INFO - AP (CPU 64) exiting holding pen
UEFI_UART: 8/8/2026 12:42:20 AM | INFO - AP (CPU 66) exiting holding pen
UEFI_UART: 8/8/2026 12:42:20 AM | INFO - AP (CPU 68) exiting holding pen
UEFI_UART: 8/8/2026 12:42:20 AM | INFO - AP (CPU 70) exiting holding pen
```
Existing consumers continue to use the default new() constructor and retain the current non-blocking, best-effort (lossy) behavior, making this change non-breaking. Consumers with use cases that require guaranteed, uncorrupted logging, such as the Rust MM Supervisor, can opt in through with_blocking().

Note: blocking mode reintroduces a self-deadlock hazard if the same core re-enters the logger/port while already writing a record (e.g. logging from a panic handler mid-write); it is intended for opt-in use where guaranteed logging outweighs that risk.
- Impacts functionality?
- Impacts security?
- Breaking change?
- Includes tests?
- Includes documentation?
How This Was Tested

Validated on physical platforms.

Integration Instructions

NA

rustfmt.toml: Drop unstable cargo fmt features @makubacki (#1695)
Change Details
## Description
A few cargo fmt features are being specified that result in warnings when running cargo fmt like the following:
```
Warning: can't set `wrap_comments = false`, unstable features
  are only available in nightly channel.
Warning: can't set `imports_granularity = Crate`, unstable features
  are only available in nightly channel.
Warning: can't set `reorder_impl_items = false`, unstable features
  are only available in nightly channel.
Warning: can't set `unstable_features = false`, unstable features
  are only available in nightly channel.
```
Referencing: https://rust-lang.github.io/rustfmt

The default value for these is already false:
- reorder_impl_items
- unstable_features
- wrap_comments
Those can be dropped with no change in behavior.

imports_granularity's default value is Preserve, not Crate.

Preserve leaves import granularity at what is written by the developer whereas Crate merges imports from the same crate into a single use statement while imports from different crates are split into separate statements.

For now, this commit drops imports_granularity which results in no immediate change to existing formatting (by definition). This option was already ineffective while using the stable toolchain.

In summary, this eliminates all warnings shown during cargo fmt.
- Impacts functionality?
- Impacts security?
- Breaking change?
- Includes tests?
- Includes documentation?
How This Was Tested
- cargo make fmt
- cargo make all
Integration Instructions
- N/A
Note: This change is being made first in the patina repo for visibility. It will also be made in patina-devops where it will be synced to all relevant patina repos.

Unify TPL mutex implementation @joschock (#1684)
Change Details
## Description
Unifies TPL mutex implementation and address incorrect ordering of atomic lock flag vs. TPL raise/restore in SDK.

All the business logic for the mutex now lives in the SDK, with a trait that abstracts the TPL operations. SDK version implements this trait via BootServices, whereas the core TplMutex has a trait implementation that wraps the core TPL routines directly.

Existing TplMutex APIs are maintained and there is no breaking change for downstream consumers of either TplMutex implementation.

Addresses #1667
- Impacts functionality?
- Impacts security?
- Breaking change?
- Includes tests?
- Includes documentation?
How This Was Tested

Passes existing unit tests; testing on hardware platforms with components that have extensive use of TplMutex in progrss.

Integration Instructions

N/A - API is maintained.

`--no-default-features` updates for tests [Rebase \& FF] @makubacki (#1677)
Change Details
## Description
Includes fixes for issues found while running test --no-default-features against individual crates.

sdk/patina: Uncouple test and alloc

Fixes failures running: cargo test -p patina --no-run --no-default-features

component/metadata.rs uses fixedbitset which is an optional crate
dependency:

fixedbitset = { workspace = true, optional = true }

It will only be pulled in when the alloc feature is active:

alloc = ["dep:goblin", "dep:fixedbitset"]

The decision on whether which features are enabled and dependencies
included is made before rustc runs for tests.

This made test in #[cfg(any(test, feature = "alloc"))] not work
when --no-default-features is used as alloc is not enabled and
fixedbitset is therefore not linked.

Since alloc is enabled by default, this does not change the normal
cargo test build. This will cause component to not be included on
--no-default-features test invocations which was already the case
for commands like cargo make check --no-default-features.

cargo test -p patina --no-run --no-default-features was run to
filter the modules down what could be enabled.

core: Gate dfs() method calls in tests on alloc

The dfs() method on the Bst and Rbt types is gated on the alloc
feature, so the calls to the methods in tests need to be as well.

Allows running tests with --no-default-features to succeed.

sdk: Gate c_ptr and status_code

sdk/patina/src/lib.rs gates the alloc crate:
```
#![cfg_attr(any(test, feature = "alloc"), feature(allocator_api))]
```
Code in sdk/patina/src/base/c_ptr.rs was using alloc::boxed::Box
without applying a similar gate. This change applies the gate on
usage there so the crate can be built without the alloc feature.

A similar fix in the sdk is made in status_code.rs. When built with
cargo hack check --workspace --no-default-features the following
error was seen:
```
error[E0599]: no method named `concat` found for array `[&[u8]; 2]` in the current scope
    let mut data_buffer = [any_as_u8_slice(&header), any_as_u8_slice(&data)].concat();
```
[T]::concat() on an array of slices returns Vec<u8> with alloc's
Concat trait.

Three changes were made for this:
1. Splitting the import block, so use core::{mem, ptr, slice} so
  mem and slice are gated on alloc.
2. Updating pub fn report_status_code_with_data<T> to be gated on
  the alloc feature.
3. Updating fn any_as_u8_slice<T: Sized>(p: &T) -> &[u8] to be
  gated on the alloc feature as well to avoid a dead code warning
  since it was only called by report_status_code_with_data<T>.
- Impacts functionality?
- Impacts security?
- Breaking change?
- Includes tests?
- Includes documentation?
How This Was Tested
- cargo test --no-default-features
- cargo hack check --workspace --no-default-features
- cargo hack test --no-run --workspace --no-default-features
- cargo make test
Note: #1680 tracks potentially using cargo-hack to perform no default testing on each crate in the future.

Integration Instructions
- N/A

📖 Documentation Updates

Devpath macros @joschock (#1650)

Change Details

## Description

Adds macros for build-time construction of device path byte arrays from string literals. This is an ergonomic change, but it helps change this:

   let mut path = [0u8; DEVICE_PATH_LENGTH];

    // ACPI(PNP0A03,0): PCI root bridge for segment 0.
    path[0] = 0x02;
    path[1] = 0x01;
    path[2] = ACPI_PCI_ROOT_NODE_LENGTH as u8;
    let pci_root_hid = 0x0A03_41D0u32.to_le_bytes();
    let mut index = 0;
    while index < pci_root_hid.len() {
        path[4 + index] = pci_root_hid[index];
        index += 1;
    }

    // Pci(0x11,0) on bus 0.
    let pci_offset = ACPI_PCI_ROOT_NODE_LENGTH;
    path[pci_offset] = 0x01;
    path[pci_offset + 1] = 0x01;
    path[pci_offset + 2] = PCI_NODE_LENGTH as u8;
    path[pci_offset + 4] = 0;
    path[pci_offset + 5] = 0x11;

into

const path: &[u8] =  &devpath!("PciRoot(0)/Pci(0x11,0)");

How This Was Tested

New macro includes unit tests and compilation tests.

Integration Instructions

N/A - usage is documented in the readme and rustdocs.

Full Changelog: patina-v23.0.1...v23.0.2

Navigation Menu

Uh oh!

patina-v23.0.2

Choose a tag to compare

Sorry, something went wrong.

Sorry, something went wrong.

Uh oh!

No results found

What's Changed

How This Was Tested

Integration Instructions

How This Was Tested

Integration Instructions

How This Was Tested

Integration Instructions

How This Was Tested

Integration Instructions

How This Was Tested

Integration Instructions

How This Was Tested

Integration Instructions

How This Was Tested

Integration Instructions

📖 Documentation Updates

How This Was Tested

Integration Instructions

Contributors

Uh oh!