patina-v15.1.0

What's Changed

• Additional zerocopy\_derive imports @makubacki (#1084)
  
  Change Details

    ## Description

  Adds more imports to those in e9bcdea.

  We opted to depend on zerocopy and zerocopy-derive directly instead of using the re-export of the derive macros in the zerocopy crate using the derives feature.

  In this case, the documentation states:

  derive Provides derives for the core marker traits via the
  zerocopy-derive crate. These derives are re-exported from
  zerocopy, so it is not necessary to depend on zerocopy-derive
  directly.

  However, you may experience better compile times if you instead
  directly depend on both zerocopy and zerocopy-derive in your
  Cargo.toml, since doing so will allow Rust to compile these crates
  in parallel. To do so, do not enable the derive feature, and list
  both dependencies in your Cargo.toml with the same leading non-zero
  version number; e.g:

  [dependencies]
  zerocopy = "0.X"
  zerocopy-derive = "0.X"

  To avoid the risk of duplicate import errors if one of your
  dependencies enables zerocopy’s derive feature, import derives as
  use zerocopy_derive::* rather than by name
  (e.g., use zerocopy_derive::FromBytes).

  From: https://docs.rs/zerocopy/latest/zerocopy/#cargo-features

  This follows the advice there to import derives from zerocopy_derive using a wildcard.

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

  How This Was Tested

  • cargo make all
  • cargo make build on each crate

  Integration Instructions

  • N/A

    </blockquote>
    <hr>
    

🐛 Bug Fixes

• [REBASE \& FF] Memory Management Improvements @os-d (#1072)
  
  Change Details

    ## Description

  This PR has a series of improvements for the memory management subsystem. The most substantial is the introduction of the MemoryProtectionPolicy struct where all memory protection policy decisions are centralized. Other code will call rules in implemented as associated functions (except in one case that requires an instance of the struct; the GCD owns this sole instance). This provides better auditability and ensuring consistency.

  The other commits were various issues discovered when refactoring. All commits have detailed descriptions. I attempted to nicely organize the commits to allow for bisectability, but don't guarantee it.

  Closes #385 and #765 .

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

  How This Was Tested

  Tested booting Q35/SBSA to Windows/Linux. Tested booting physical ARM64 and Intel platforms to Windows.

  Integration Instructions

  N/A.

    </blockquote>
    <hr>
  </details>
  

🔐 Security Impacting

• [REBASE \& FF] Memory Management Improvements @os-d (#1072)
  
  Change Details

    ## Description

  This PR has a series of improvements for the memory management subsystem. The most substantial is the introduction of the MemoryProtectionPolicy struct where all memory protection policy decisions are centralized. Other code will call rules in implemented as associated functions (except in one case that requires an instance of the struct; the GCD owns this sole instance). This provides better auditability and ensuring consistency.

  The other commits were various issues discovered when refactoring. All commits have detailed descriptions. I attempted to nicely organize the commits to allow for bisectability, but don't guarantee it.

  Closes #385 and #765 .

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

  How This Was Tested

  Tested booting Q35/SBSA to Windows/Linux. Tested booting physical ARM64 and Intel platforms to Windows.

  Integration Instructions

  N/A.

    </blockquote>
    <hr>
  </details>
  

Full Changelog: patina-v15.0.1...v15.1.0