What's Changed

patina\_adv\_logger: Add logger info v6 support @makubacki (#1296)
Change Details
## Description
Support using the v6 logger info structure for the advanced logger.

Previously, only v5 was supported, in this change only v6 is supported. A future change may add support for both.
- Impacts functionality?
- Impacts security?
- Breaking change?
- Includes tests?
- Includes documentation?
How This Was Tested
- Verify advanced logger HOB is loaded during initialization
- Dump memory log at EFI shell to verify log contents
Integration Instructions
- This must be paired with the V6 logger changes in microsoft/mu_plus#826

Update gic\_manager to only initialize the current CPU's redistributor. @joschock (#1300)
Change Details
## Description
This change updates the GIC setup to only configure the GIC Redistrubtor associated with the boot core. Previously, the implementation called gic_v3.setup(), which attempted to initialize all GIC Redistributor instances. Initializing the Redistributor instances associated with unused cores resulted in instability and is unnecessary for the Patina interrupt model; this also aligns with existing EDK2 ArmGicDxe behavior.

Also opportunistically updates arm-gic crate to 0.7.2.
- Impacts functionality?
- Impacts security?
- Breaking change?
- Includes tests?
- Includes documentation?
How This Was Tested

Boot testing on an arm hardware platform; confirmed GIC initialization and interrupts work as expected.

Integration Instructions

N/A

Cargo.toml: Require time crate version 0.3.47 or higher @makubacki (#1297)

Change Details

## Description

The following security vulnerability exists in versions 0.3.45 or lower:

├ ID: RUSTSEC-2026-0009
├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0009
├ ## Impact

  When user-provided input is provided to any type that parses with the RFC 2822 format, a denial of
  service attack via stack exhaustion is possible. The attack relies on formally deprecated and
  rarely-used features that are part of the RFC 2822 format used in a malicious manner. Ordinary,
  non-malicious input will never encounter this scenario.

  ## Patches

  A limit to the depth of recursion was added in v0.3.47. From this version, an error will be returned
  rather than exhausting the stack.

  ## Workarounds

  Limiting the length of user input is the simplest way to avoid stack exhaustion, as the amount of
  the stack consumed would be at most a factor of the length of the input.
├ Announcement: https://github.com/time-rs/time/blob/main/CHANGELOG.md#0347-2026-02-05

Comes in through:

    ├ time v0.3.45
      └── compile-time v0.2.0
          └── patina_dxe_core v20.0.0
              ├── (dev) patina_adv_logger v20.0.0
              └── (dev) patina_mm v20.0.0
                  └── patina_performance v20.0.0
                      └── patina_dxe_core v20.0.0 (*)

Since 0.3.47 is available, this requires that patch version or higher.

How This Was Tested

cargo update
cargo make deny

Integration Instructions

N/A
```
</blockquote>
<hr>
```

dxe\_core: Add get\_existent\_memory\_descriptor\_for\_address() Helper Function @os-d (#1294)
Change Details
## Description
Currently, get_memory_descriptor_for_address() returns any descriptor found, including NonExistent descriptors. Because this function is used by the PI spec GetMemorySpaceDescriptor(), it needs to do that.

However, for the majority of Patina usage, we only want existent descriptors. Most of the cases using it is to apply attributes and we cannot do that on non-existent memory. We also would miss cases where we'd search for something, e.g. the stack region, and just move on if we found any descriptor, not specifically an existent one.

This commit adds a new helper function to return NotFound if get_memory_descriptor_for_address() returns a NonExistent descriptor. Usage across the tree is updated.
- Impacts functionality?
- Impacts security?
- Breaking change?
- Includes tests?
- Includes documentation?
How This Was Tested

Booting Q35 and SBSA to Windows. Observed a unit test not failing when it should have because the stack memory region was not present in the GCD. After this fix the test fails as expected.

Integration Instructions

N/A.
```
  </blockquote>
  <hr>
</details>
```

patina\_debugger: Issue Breakpoint Only When Debugger Initialized @os-d (#1287)
Change Details
## Description
Currently, patina_debugger has two breakpoint fns: breakpoint() and breakpoint_unchecked(). breakpoint() only issues a breakpoint if the debugger is enabled and breakpoint_unchecked() always issues a breakpoint.

However, there is a time window where the debugger is enabled but not yet initialized where calling breakpoint() will cause an unhandled exception.

This commit adds a new check to breakpoint() to ensure that the debugger is also initialized when that function is called before issuing the breakpoint. If the debugger is not initialized, but is enabled, an error log will be printed to alert the developer in case they want to cause an unhandled exception; they should use breakpoint_unchecked() if so.

It was considered to not check for enabled() and only check for initialized(), as the former depends upon the latter, but the debugger is obviously not a hot path and the extra layer of safety was kept.
- Impacts functionality?
- Impacts security?
- Breaking change?
- Includes tests?
- Includes documentation?
How This Was Tested

Using patina_debugger::breakpoint() before and after the debugger is initialized and seeing that it just logged the first time and broke in the second time.

Integration Instructions

Use patina_debugger::breakpoint() when wanting to break into the debugger with a breakpoint and patina_debugger::breakpoint_unchecked() when wanting to cause an exception no matter what.
```
  </blockquote>
  <hr>
</details>
```

patina\_dxe\_core: Prevent loading images for wrong machine type @makubacki (#1289)
Change Details
## Description
Fixes #1288

Check the machine type in the PE/COFF header against the architecture of the firmware. If they don't match, skip loading the image.

The same check is performed in the EDK II C DXE Core.
- Impacts functionality?
- Impacts security?
- Breaking change?
- Includes tests?
- Includes documentation?
How This Was Tested
- cargo make all (unit tests)
- Attempt to load a AARCH64 EFI application in Q35 (X64)
- Image rejected:
```
ERROR - core_load_pe_image failed: AdvancedLogDumper.efi unsupported machine type 0xaa64 (expected 0x8664)
```
Integration Instructions
- N/A

🐛 Bug Fixes

dxe\_core: Ensure Stack Guard Is Enabled When Init'ing Paging @os-d (#1277)
Change Details
## Description
Currently, the init_paging routine doesn't know about the stack guard, which is set up earlier. It ends up wiping this.

This commit moves the stack guard setup to init_paging to take it into account.

It was considered to make this more generic, to take already set attributes, but the number of cases where we expect access attributes to be set should just be the null page and stack guard page, so handle them explicitly.
- Impacts functionality?
- Impacts security?
- Breaking change?
- Includes tests?
- Includes documentation?
How This Was Tested

Tested on Q35 and SBSA with the memory protections test failing and then succeeding.

Integration Instructions

N/A.
```
  </blockquote>
  <hr>
</details>
```

[REBASE \& FF] patina\_dxe\_core: Fix inconsistent attributes and capabilities on initial memory @cfernald (#1292)
Change Details
## Description
This commit modified the memory block init code to use the memory policy attributes for the initial free memory block rather than explicitly only RP. This ensures that it will have consistent attributes when it is split up into allocated and freed blocks. Without this change those blocks cannot be coalesced leading to fragmented free memory which can cause failures in Windows allocations.

Additionally, this change uses the resource descriptor HOB to get the attributes and capabilities to ensure consistency and accuracy with the rest of the memory.
- Impacts functionality?
- Impacts security?
- Breaking change?
- Includes tests?
- Includes documentation?
How This Was Tested
- SBSA boot to OS
- Q35 boot to OS
- Unit tests
Integration Instructions

N/A
```
  </blockquote>
  <hr>
</details>
```

🔐 Security Impacting

dxe\_core: Ensure Stack Guard Is Enabled When Init'ing Paging @os-d (#1277)
Change Details
## Description
Currently, the init_paging routine doesn't know about the stack guard, which is set up earlier. It ends up wiping this.

This commit moves the stack guard setup to init_paging to take it into account.

It was considered to make this more generic, to take already set attributes, but the number of cases where we expect access attributes to be set should just be the null page and stack guard page, so handle them explicitly.
- Impacts functionality?
- Impacts security?
- Breaking change?
- Includes tests?
- Includes documentation?
How This Was Tested

Tested on Q35 and SBSA with the memory protections test failing and then succeeding.

Integration Instructions

N/A.
```
  </blockquote>
  <hr>
</details>
```

Full Changelog: patina-v20.0.0...v20.0.1

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

patina-v20.0.1

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

🐛 Bug Fixes

How This Was Tested

Integration Instructions

How This Was Tested

Integration Instructions

🔐 Security Impacting

How This Was Tested

Integration Instructions

Contributors

Uh oh!