v2023020003.2.0

What's Changed

🚀 Features & ✨ Enhancements

• AdvLoggerPkg: Add PanicLib instance @makubacki (#348)
  
  Change Details

    ## Description

  Adds an instance of PanicLib that outputs through advanced logger
  using AdvancedLoggerLib.

  This allows platforms already using advanced logger to use this
  library instance which can decrease the size impact as opposed to
  linking to output stacks like serial that might be redundant when
  advanced logger is active.

  • Impacts functionality?
    • Functionality - Does the change ultimately impact how firmware functions?
    • Examples: Add a new library, publish a new PPI, update an algorithm, ...
  • Impacts security?
    • Security - Does the change have a direct security impact on an application,
      flow, or firmware?
    • Examples: Crypto algorithm change, buffer overflow fix, parameter
      validation improvement, ...
  • Breaking change?
    • Breaking change - Will anyone consuming this change experience a break
      in build or boot behavior?
    • Examples: Add a new library class, move a module to a different repo, call
      a function in a new library class in a pre-existing module, ...
  • Includes tests?
    • Tests - Does the change include any explicit test code?
    • Examples: Unit tests, integration tests, robot tests, ...
  • Includes documentation?
    • Documentation - Does the change contain explicit documentation additions
      outside direct code modifications (and comments)?
    • Examples: Update readme file, add feature readme file, link to documentation
      on an a separate Web page, ...

  How This Was Tested

  • Physical IA32/X64 platform with advanced logger used in PEI

  ---

  Example of a test PANIC() placed in ResetSystemPei through this library
  instance:

  PANIC [ResetSystemPei] d:\src\ws\MU_BASECORE\MdeModulePkg\Universal\ResetSystemPei\ResetSystem.c(110): Test panic
  

  Integration Instructions

  Use this library instance if routing panic messages through advanced logger
  is preferred.
  

  
  

  ---

  
  

📖 Documentation Updates

• Add HID Keyboard support to UefiHidDxe @joschock (#347)
  
  Change Details

    ## Description

  Adds HID keyboard support to UefiHidDxe input driver.

  • Impacts functionality?
    • Adds keyboard support.
  • Impacts security?
  • Breaking change?
  • Includes tests?
  • Includes documentation?
    • standard rustdocs

  How This Was Tested

  Tested with USB keyboard support in QEMU. Early iterations also tested in hardware.

  Integration Instructions

  Platforms will need to add HiiKeyboardLayout = {path = "HidPkg/Crates/HiiKeyboardLayout"} to the [workspace.dependencies] in their cargo.toml if not already present.
  

  
  

  ---

  
  

• AdvLoggerPkg: Add PanicLib instance @makubacki (#348)
  
  Change Details

    ## Description

  Adds an instance of PanicLib that outputs through advanced logger
  using AdvancedLoggerLib.

  This allows platforms already using advanced logger to use this
  library instance which can decrease the size impact as opposed to
  linking to output stacks like serial that might be redundant when
  advanced logger is active.

  • Impacts functionality?
    • Functionality - Does the change ultimately impact how firmware functions?
    • Examples: Add a new library, publish a new PPI, update an algorithm, ...
  • Impacts security?
    • Security - Does the change have a direct security impact on an application,
      flow, or firmware?
    • Examples: Crypto algorithm change, buffer overflow fix, parameter
      validation improvement, ...
  • Breaking change?
    • Breaking change - Will anyone consuming this change experience a break
      in build or boot behavior?
    • Examples: Add a new library class, move a module to a different repo, call
      a function in a new library class in a pre-existing module, ...
  • Includes tests?
    • Tests - Does the change include any explicit test code?
    • Examples: Unit tests, integration tests, robot tests, ...
  • Includes documentation?
    • Documentation - Does the change contain explicit documentation additions
      outside direct code modifications (and comments)?
    • Examples: Update readme file, add feature readme file, link to documentation
      on an a separate Web page, ...

  How This Was Tested

  • Physical IA32/X64 platform with advanced logger used in PEI

  ---

  Example of a test PANIC() placed in ResetSystemPei through this library
  instance:

  PANIC [ResetSystemPei] d:\src\ws\MU_BASECORE\MdeModulePkg\Universal\ResetSystemPei\ResetSystem.c(110): Test panic
  

  Integration Instructions

  Use this library instance if routing panic messages through advanced logger
  is preferred.
  

  
  

  ---

  
  

Full Changelog: v2023020003.1.0...v2023020003.2.0

v2023020003.1.0

What's Changed

🚀 Features & ✨ Enhancements

• TpmTestingPkg: Add InputChannelLib @makubacki (#352)
  
  Change Details

    ## Description

  Adds a new library class (InputChannelLib) that allows the TPM replay
  event log to be passed through a platform-specific mechanism.

  • Impacts functionality?
    • Functionality - Does the change ultimately impact how firmware functions?
    • Examples: Add a new library, publish a new PPI, update an algorithm, ...
  • Impacts security?
    • Security - Does the change have a direct security impact on an application,
      flow, or firmware?
    • Examples: Crypto algorithm change, buffer overflow fix, parameter
      validation improvement, ...
  • Breaking change?
    • Breaking change - Will anyone consuming this change experience a break
      in build or boot behavior?
    • Examples: Add a new library class, move a module to a different repo, call
      a function in a new library class in a pre-existing module, ...
  • Includes tests?
    • Tests - Does the change include any explicit test code?
    • Examples: Unit tests, integration tests, robot tests, ...
  • Includes documentation?
    • Documentation - Does the change contain explicit documentation additions
      outside direct code modifications (and comments)?
    • Examples: Update readme file, add feature readme file, link to documentation
      on an a separate Web page, ...

  How This Was Tested

  • Passed FW CFG TPM event log through QemuQ35Pkg
  • Verified library integrated without a custom log being passed uses
    lower priority input channels as expected
  • Verified BaseInputChannelLibNull is functionally usable for skipping
    custom log input.

  Integration Instructions

  Add InputChannelLib|TpmTestingPkg/Library/BaseInputChannelLibNull/BaseInputChannelLibNull.inf
  to a platform that uses the TPM Replay feature but does not provide a custom input channel
  instance.
  

  
  

  ---

  
  

Full Changelog: v2023020003.0.1...v2023020003.1.0

v2023020003.0.1

What's Changed

🚀 Features & 📖 Documentation Updates

• Add HiiKeyboardLayout crate to support UEFI HII Keyboard Layouts @joschock (#342)
  
  Change Details

    ## Description

  This crate provides a rust wrapper around UEFI HII Keyboard Layout structures. The relevant structures defined in the UEFI spec are not well-suited for direct definition in rust; so this crate defines analogous rust structures and provides serialization/deserialization support for converting the rust structures into byte buffers and vice versa. This crate uses the scroll crate (https://github.com/m4b/scroll) to facilitate serialization/deserialization of the Hii structures.

  Examples and Usage

  Retrieving a default (en-US) layout, writing it to a buffer, and then reading the buffer back into a rust structure:

   use hii_keyboard_layout::{get_default_keyboard_pkg, HiiKeyboardPkg};
   use scroll::{Pread, Pwrite};
   let mut buffer = [0u8; 4096];
  
   let package = get_default_keyboard_pkg();
   buffer.pwrite(&package, 0).unwrap();
  
   let package2: HiiKeyboardPkg = buffer.pread(0).unwrap();
   assert_eq!(package, package2);

  • Impacts functionality?
    • Introduces a new crate providing support for HII layouts.
  • Impacts security?
  • Breaking change?
  • Includes tests?
    • Includes standard rust unit tests.
  • Includes documentation?
    • Includes standard rust documentation.

  How This Was Tested

  Verified by included unit tests.

  Integration Instructions

  This crate requires the "scroll," "num-traits" and "num-drive" crates, so platforms intending to use it will need to add these as dependencies in their workspace Cargo.toml files. This PR does this for the workspace Cargo.toml that is at the root of mu_plus.

  Sample:

  scroll = { version = "0.11", default-features = false, features = ["derive"]}
  num-traits = { version = "0.2", default-features = false}
  num-derive = { version = "0.4", default-features = false}

  ---

Full Changelog: v2023020003.0.0...v2023020003.0.1

v2023020003.0.0

What's Changed

• Update HelloWorldRustDxe to permit compiling for unit tests @joschock (#341)
  
  Change Details

    ## Description

  Update HelloWorldRustDxe to allow compiling tests.

  • Impacts functionality?
  • Impacts security?
  • Breaking change?
  • Includes tests?
    • adds a sample unit test for the HelloWorldRustDxe driver.
  • Includes documentation?

  How This Was Tested

  Cargo test executes sample unit test as expected.
  Build for UEFI target and execution QEMU work as expected.

  Integration Instructions

  N/A
  

  
  

  ---

  
  

⚠️ Breaking Changes

• Add PCD to allow device exclusions for UsbHidDxe @joschock (#340)
  
  Change Details

    ## Description

  Adds a PCD for configuring device exclusions for UsbHidDxe. Prior to this change, the UsbHidDxe driver included logic to exclude keyboard devices from being handled by HID, due to other parts of the stack not being fully implemented yet. This removes that code and replaces it with a PCD list that the platform integrator can use to disable particular devices as desired for the platform.

  • Impacts functionality?
    • Changes how UsbHidDxe exclusions are handled.
  • Impacts security?
  • Breaking change?
    Previously keyboard exclusion was hard-coded; to replicate this behavior platforms will need to add a PCD specification in the DSC files to exclude keyboards. See Integration Instructions below for more details.
  • Includes tests?
  • Includes documentation?

  How This Was Tested

  Verified with functional testing of several different exclusions in Qemu Q35.

  Integration Instructions

  To replicate existing behavior, platforms will need to add PCD specification to the DSC like the following to exclude USB keyboards:

  [PcdsFixedAtBuild]
  gHidPkgTokenSpaceGuid.PcdExcludedHidDevices|{0x3, 0x1, 0x1, 0x0, 0x0, 0x0}
  

  
  

  ---

  
  

Full Changelog: v2023020002.1.0...v2023020003.0.0

v2023020002.1.0

What's Changed

🚀 Features & ✨ Enhancements

• UefiHidDxe: Change HID descriptor read algorithm @joschock (#339)
  
  Change Details

    Resolves #338

  Description

  Updates the algorithm used to read the HID descriptor from HID devices. Empirical testing indicates that some devices do not support reading the HID descriptor via the class-specific Get_Report() method described in USB HID 1.11. This changes the HID read to read the entire configuration descriptor and parse the HID descriptor out of the larger structure, and gives compatibility with a broader range of devices.

  • Impacts functionality?
    Supports a broader range of devices.
  • Impacts security?
  • Breaking change?
  • Includes tests?
  • Includes documentation?

  How This Was Tested

  Verified against emulated USB devices in QEMU.

  Integration Instructions

  N/A
  

  
  

  ---

  
  

Full Changelog: v2023020002.0.4...v2023020002.1.0

v2023020002.0.4

What's Changed

• Use Absolute Pointer Protocol from r-efi 4.3.0 @makubacki (#336)
  
  Change Details

    ## Description

  The protocol was upstreamed to r-efi 4.3.0 and can be picked up from there now.

  • Impacts functionality?
    • Functionality - Does the change ultimately impact how firmware functions?
    • Examples: Add a new library, publish a new PPI, update an algorithm, ...
  • Impacts security?
    • Security - Does the change have a direct security impact on an application,
      flow, or firmware?
    • Examples: Crypto algorithm change, buffer overflow fix, parameter
      validation improvement, ...
  • Breaking change?
    • Breaking change - Will anyone consuming this change experience a break
      in build or boot behavior?
    • Examples: Add a new library class, move a module to a different repo, call
      a function in a new library class in a pre-existing module, ...
  • Includes tests?
    • Tests - Does the change include any explicit test code?
    • Examples: Unit tests, integration tests, robot tests, ...
  • Includes documentation?
    • Documentation - Does the change contain explicit documentation additions
      outside direct code modifications (and comments)?
    • Examples: Update readme file, add feature readme file, link to documentation
      on an a separate Web page, ...

  How This Was Tested

  • HidPkg build and QEMU Q35 shell boot

  Integration Instructions

  N/A
  

  
  

  ---

  
  

Full Changelog: v2023020002.0.3...v2023020002.0.4

v2023020002.0.3

What's Changed

• HidPkg/UsbHidDxe: Continue on failure to get descriptor @makubacki (#334)
  
  Change Details

    ## Description

  In case a HID device fails to return a valid HID descriptor, this change
  will return the error status from UsbHidDriverBindingStart() rather
  than assert to match previous behavior from HID drivers that required
  the boot protocol. The HID IO protocol will not be installed on these
  devices.

  • Impacts functionality?
    • Functionality - Does the change ultimately impact how firmware functions?
    • Examples: Add a new library, publish a new PPI, update an algorithm, ...
  • Impacts security?
    • Security - Does the change have a direct security impact on an application,
      flow, or firmware?
    • Examples: Crypto algorithm change, buffer overflow fix, parameter
      validation improvement, ...
  • Breaking change?
    • Breaking change - Will anyone consuming this change experience a break
      in build or boot behavior?
    • Examples: Add a new library class, move a module to a different repo, call
      a function in a new library class in a pre-existing module, ...
  • Includes tests?
    • Tests - Does the change include any explicit test code?
    • Examples: Unit tests, integration tests, robot tests, ...
  • Includes documentation?
    • Documentation - Does the change contain explicit documentation additions
      outside direct code modifications (and comments)?
    • Examples: Update readme file, add feature readme file, link to documentation
      on an a separate Web page, ...

  How This Was Tested

  • Verified functionality is unchanged on physical platform with UsbHidDxe integrated.
  • Verified boot previously encountering an assert on the QEMU virtual platform is
    not blocking boot.

  Integration Instructions

  Update to a Mu Plus release with this change.
  

  
  

  ---

  
  

Full Changelog: v2023020002.0.2...v2023020002.0.3

v2023020002.0.2

What's Changed

• [REBASE \&\& FF] Update DxePagingAuditTestApp with Additional Shell and HTML Tests @TaylorBeebe (#327)
  
  Change Details

    Adds 8 tests to the paging audit shell app. Which check the following: 1. Unallocated memory is EFI_MEMORY_RP 2. Memory Attribute Protocol is present 3. Calls to allocate pages and pools return buffers with restrictive access attributes 4. NULL page is EFI_MEMORY_RP 5. MMIO Regions are Non Executable 6. Image code sections are EFI_MEMORY_RO and and data sections are EFI_MEMORY_XP 7. BSP stack is EFI_MEMORY_XP and has EFI_MEMORY_RP guard page 8. Memory outside of the EFI Memory Map is inaccessible

  Adds 5 tests to the HTML templates:

  1. Test that the NULL page is EFI_MEMORY_RP
  2. Check that MMIO memory is non-executable.
  3. Check that EfiConventionalMemory is non-executable.
  4. Check that memory not in the EFI memory map is not accessible.
  5. Check that the memory attribute protocol is present on the platform.

  This also refactors much of the HTML, adds some quality of life updates to the output
  HTML paging audit, adds logical OR filtering capability, and adds the collection of
  Memory Attribute Protocol presence on the tested platform.

  Tested on Q35, SBSA, and on development devices at UEFI Plugfest.
  

  
  

  ---

  
  

📖 Documentation Updates

• Add HidIo protocol, USB HidIo implementation, and UefiHidDxe Rust input driver [Rebase \& FF] @joschock (#324)
  
  Change Details

    ## Description

  Adds support for Rust-based input stack.

  • Adds a new protocol interface that defines a general abstraction for HID devices: Protocols/HidIo.
  • Adds Rust protocol definition of HidIo.
  • Adds Rust protocol definition for AbsolutePointer
  • Adds UsbHidDxe driver - written in C, provides an implementation of HidIo over USB.
  • Adds UefiHidDxe driver - written in Rust, provides input report handling for HidIo pointer devices.

  Note: does not yet support HID keyboards. This is planned future work.

  • Impacts functionality?
    Adds new input support functionality.
     
  • Impacts security?
  • Breaking change?
  • Includes tests?
  • Includes documentation?
    • includes standard RustDocs.

  How This Was Tested

  Pointer verified in preboot console (UEFI setup menu and Bitlocker Recovery).

  Integration Instructions

  Assuming a project is setup to build rust modules generally, integration of the new stack is accomplished by:

  • Remove UsbMouseAbsolutePointerDxe
  • Add UsbHidDxe and UefiHidDxe to the build
    

  
  

  ---

• Document current data flow of debug logging filtering @kuqin12 (#332)
  
  Change Details

    ## Description

  This change adds a short description of how logging level works in advanced logger as well as a flowchart for visualization.

  • Impacts functionality?
    • Functionality - Does the change ultimately impact how firmware functions?
    • Examples: Add a new library, publish a new PPI, update an algorithm, ...
  • Impacts security?
    • Security - Does the change have a direct security impact on an application,
      flow, or firmware?
    • Examples: Crypto algorithm change, buffer overflow fix, parameter
      validation improvement, ...
  • Breaking change?
    • Breaking change - Will anyone consuming this change experience a break
      in build or boot behavior?
    • Examples: Add a new library class, move a module to a different repo, call
      a function in a new library class in a pre-existing module, ...
  • Includes tests?
    • Tests - Does the change include any explicit test code?
    • Examples: Unit tests, integration tests, robot tests, ...
  • Includes documentation?
    • Documentation - Does the change contain explicit documentation additions
      outside direct code modifications (and comments)?
    • Examples: Update readme file, add feature readme file, link to documentation
      on an a separate Web page, ...

  How This Was Tested

  N/A

  Integration Instructions

  N/A
  

  
  

  ---

  
  

Full Changelog: v2023020002.0.1...v2023020002.0.2

v2023020002.0.1

What's Changed

🐛 Bug Fixes

• AdvLoggerPkg: BaseAdvancedLoggerLib: Fixing a missed PCD for AARCH64 usage @kuqin12 (#331)
  
  Change Details

    # Preface

  Please ensure you have read the contribution docs prior
  to submitting the pull request. In particular,
  pull request guidelines.

  Description

  There was a missed PCD not caught in the previous PR (#311) when it comes to the usage on AARCH64 platform. This change added the PCD entry in the library inf file.

  For each item, place an "x" in between [ and ] if true. Example: [x].
  (you can also check items in the GitHub UI)

  • Impacts functionality?
    • Functionality - Does the change ultimately impact how firmware functions?
    • Examples: Add a new library, publish a new PPI, update an algorithm, ...
  • Impacts security?
    • Security - Does the change have a direct security impact on an application,
      flow, or firmware?
    • Examples: Crypto algorithm change, buffer overflow fix, parameter
      validation improvement, ...
  • Breaking change?
    • Breaking change - Will anyone consuming this change experience a break
      in build or boot behavior?
    • Examples: Add a new library class, move a module to a different repo, call
      a function in a new library class in a pre-existing module, ...
  • Includes tests?
    • Tests - Does the change include any explicit test code?
    • Examples: Unit tests, integration tests, robot tests, ...
  • Includes documentation?
    • Documentation - Does the change contain explicit documentation additions
      outside direct code modifications (and comments)?
    • Examples: Update readme file, add feature readme file, link to documentation
      on an a separate Web page, ...

  How This Was Tested

  This was tested on FVP based AARCH64 platform.

  Integration Instructions

  N/A

    </blockquote>
    <hr>
  </details>
  

Full Changelog: v2023020002.0.0...v2023020002.0.1

v2023020002.0.0

What's Changed

• Only call HdwPortWrite if DebugLevel Met @os-d (#311)
  
  Change Details

    ## Description

  The DebugLevel is checked twice in the hot path on serial path writes and the HdwPortWrite call is made even if the upper layer knows that the message being logged does not meet the DebugLevel criteria.

  Closes #309.

  In order to maintain backwards compatibility, if the LoggerInfo block is found to have a version less than the hardware logging level version, the PCD is checked to decide whether to call HdwPortWrite or not.

  In SEC, because we may not have the LoggerInfo structure, we check the PCD to see if the message should be logged at this DebugLevel.

  For each item, place an "x" in between [ and ] if true. Example: [x].
  (you can also check items in the GitHub UI)

  • Impacts functionality?
    • Functionality - Does the change ultimately impact how firmware functions?
    • Examples: Add a new library, publish a new PPI, update an algorithm, ...
  • Impacts security?
    • Security - Does the change have a direct security impact on an application,
      flow, or firmware?
    • Examples: Crypto algorithm change, buffer overflow fix, parameter
      validation improvement, ...
  • Breaking change?
    • Breaking change - Will anyone consuming this change experience a break
      in build or boot behavior?
    • Examples: Add a new library class, move a module to a different repo, call
      a function in a new library class in a pre-existing module, ...
  • Includes tests?
    • Tests - Does the change include any explicit test code?
    • Examples: Unit tests, integration tests, robot tests, ...
  • Includes documentation?
    • Documentation - Does the change contain explicit documentation additions
      outside direct code modifications (and comments)?
    • Examples: Update readme file, add feature readme file, link to documentation
      on an a separate Web page, ...

  How This Was Tested

  Build tested.

  Integration Instructions

  If a bespoke AdvLoggerHdwPortLib is used, AdvLoggerHdwPortWrite should not check DebugLevel, but simply write the message to the hardware port.
  

  
  

  ---

  
  

⚠️ Breaking Changes

• [REBASE \&\& FF] Add FlatPageTableLib, Make Spellcheck Fixes, Update Paging Audit to Use FlatPageTableLib @TaylorBeebe (#322)
  
  Change Details

    ## Description

  Makes some spellcheck fixes.

  Creates a new library, FlatPageTableLib, which works on X64 and AARCH64 platforms and converts the page table to a "flat" version. The flat version is a one-dimensional array where each entry is an address, a length, and attributes. The library will walk the page/translation table and combine blocks/leaves with the same attributes into a single entry in the flat array. The attributes mask for each architecture is defined in the header and includes both the upper and lower block/leaf attributes. On both X64 and AARCH64, the hierarchical inheritance of attributes is factored into the determination of block/leaf attributes. This allows the consumer of the library to easily check the attributes of any region in the page/translation table.

  Updates DxePagingAuditTestApp to use FlatPageTableLib which allows us to delete the custom parsing logic in the test app.

  • Impacts functionality?
    • Functionality - Does the change ultimately impact how firmware functions?
    • Examples: Add a new library, publish a new PPI, update an algorithm, ...
  • Impacts security?
    • Security - Does the change have a direct security impact on an application,
      flow, or firmware?
    • Examples: Crypto algorithm change, buffer overflow fix, parameter
      validation improvement, ...
  • Breaking change?
    • Breaking change - Will anyone consuming this change experience a break
      in build or boot behavior?
    • Examples: Add a new library class, move a module to a different repo, call
      a function in a new library class in a pre-existing module, ...
  • Includes tests?
    • Tests - Does the change include any explicit test code?
    • Examples: Unit tests, integration tests, robot tests, ...
  • Includes documentation?
    • Documentation - Does the change contain explicit documentation additions
      outside direct code modifications (and comments)?
    • Examples: Update readme file, add feature readme file, link to documentation
      on an a separate Web page, ...

  How This Was Tested

  Tested by running the paging audit on SBSA and Q35 and by comparing the output against the Memory Attribute Protocol

  Integration Instructions

  Platforms which build the paging audit will need to add an instance of FlatPageTableLib to their platform
  DSC files.
  

  
  

  ---

  
  

Full Changelog: v2023020001.5.2...v2023020002.0.0