v4.0.0

What's Changed

• Use uefi-sdk common definitions @makubacki (#175)
  
  Change Details

    ## Description

  Replace common definitions and macros with those recently moved to uefi-sdk.

  • Impacts functionality?
  • Impacts security?
  • Breaking change?
  • Includes tests?
  • Includes documentation?

  How This Was Tested

  • Unit tests
  • QEMU boot

  Integration Instructions

  • N/A - Local integration of uefi-sdk changes in this repo.
    

  
  

  ---

• Remove release\_max\_level\_warn from log features. @joschock (#173)
  
  Change Details

    ## Description

  If this feature is specified here, consuming crates cannot override the release_max_* level for configuration of debug - i.e. consuming projects are forced to release_max_level_warn.

  Removing this is consistent with guidance from the log crate:

  Libraries should avoid using the max level features because they’re global and can’t be changed once they’re set.
  

  • Impacts functionality?
  • Impacts security?
  • Breaking change?
  • Includes tests?
  • Includes documentation?

  How This Was Tested

  Confirmed that consuming crates using dxe_core can now adjust release_max_level_* as desired.

  Integration Instructions

  N/A
  

  
  

  ---

  
  

• dxe\_core: Resolved unused code warnings. @Javagedes (#172)
  
  Change Details

    ## Description

  Within multiple modules that were previously standalone crates ( specifically, uefi_allocator, uefi_event, uefi_protocol_db, and uefi_gcd), multiple functions were unused in the code base. However these functions were marked as public and were part of the public interface for their respective crates, so no warnings were generated as this is typically expected.

  After moving these crates inwards, they are no longer apart of the crate's public interface. Due to this, the compiler correctly detects and reports that they are unused. An interesting note, however, is that the compiler does not detect this when building the crate itself, only when building a binary that consumes this crate.

  This commit resolves these warnings primarily by marking these functions with the #[allow(dead_code)] attribute, as they are hypothetically useful, and could start to be consumed in the future. A few of the functions were configured to only exist for test builds as they are for testing purposes only.

  • Impacts functionality?
  • Impacts security?
  • Breaking change?
  • Includes tests?
  • Includes documentation?

  How This Was Tested

  Passes CI, and qemu binaries continue to build

  Integration Instructions

  N/A
  

  
  

  ---

  
  

• uefi\_allocator: Remove panic on free pool signature mismatch @makubacki (#171)
  
  Change Details

    ## Description

  Replaces assert!() with debug_assert!() and return of an invalid parameter EFI status code when the given pool buffer signature is invalid.

  This is to reduce the fatality of the condition in release builds for misbehaving hardware while still brining attention to developers in debug builds.

  • Impacts functionality?
  • Impacts security?
  • Breaking change?
  • Includes tests?
  • Includes documentation?

  How This Was Tested

  • Build and unit tests
  • Boot to EFI shell on QEMU

  Integration Instructions

  N/A - Reduces strictness during free pool validation.
  

  
  

  ---

  
  

• [REBASE\&FF] Move multiple workspace crates into dxe\_core @Javagedes (#169)
  
  Change Details

    ## Description

  Moves the following workspace crates into dxe_core

  • uefi_allocator
  • uefi_gcd
  • uefi_event
  • uefi_protocol_db
  • uefi_tpl_mutex
  • uefi_pecoff

  The only major (but still minor) change with all of this is that the dependency on uefi_protocol_db had to be removed from uefi_depex. Previously uefi_depex required UefiProtocolDb. Now it just requires a slice of protocol guids to evaluate against.

  Additionally, all doc examples had to be removed as doc examples can only be used on public facing structs and functions. By mobing them into dxe_core, that api layer is removed and docs will fail to compile due to trying to access private members.

  Each commit is completely independent and can be compiled. Please review each commits comment for additional info.

  • Impacts functionality?
  • Impacts security?
  • Breaking change?
  • Includes tests?
  • Includes documentation?

  How This Was Tested

  N/A

  Integration Instructions

  N/A
  

  
  

  ---

  
  

⚠️ Breaking Changes

• Prevent memory map changes following ExitBootServices @berlin-with0ut-return (#168)
  
  Change Details

    ## Description According to UEFI spec, the memory map (represented by a key) should not change after exit_boot_services is called. To preserve this invariant, we add a guard against additional allocations/frees after EBS within the GCD.

  • Impacts functionality?
  • Impacts security? (possibly?)
  • Breaking change?
  • Includes tests?
  • Includes documentation?

  How This Was Tested

  All tests in the uefi_dxe_core repo still pass.
  Additionally, I added a "forced" EBS call in the HelloWorld driver and tested allocating/freeing there following EBS. Both calls were caught by the new GCD functions (verified using logs).

  Booting to Windows in UefiRust still functions as expected, so this should not break any functionality.

  Integration Instructions

  Can be merged without issue.
  

  
  

  ---

  
  

Full Changelog: v3.0.0...v4.0.0