v2023020004.1.1

What's Changed

• Add PeiCore method to find AdvancedLogger log buffer if LoggerInfo is… @apop5 (#389)
  
  Change Details

    ## Description

  This was discovered in a platform that uses AdvancedLogger Starting in Pei, but without permanent memory until after MRC runs.
  (i.e. AdvancedLoggerLib PeiCore instance allocates CAR heap for the log buffer)

  The platform makes uses of EFI_PEI_TEMPORARY_RAM_DONE_PPI, where is tears down all variable range MTRRs.

  When PeiCore is reentered after memory has become available, it will relocate Hobs to system memory, then it will go through the Hobs and fix up the memory allocation pointers to point to the system memory addresses instead of the Heap addresses.

  During this transition, the PlatformBlob pointer will become invalid, after CAR is torn down.

  During the PeiCore's PeiServicesInstallPpi (&mMemoryDiscoveredPpi);, a debug message will attempt to be output about the Install PPI: of the Memory Discovered Ppi, and the current logic will attempt to use the PlatformBlob, which results in a memory exception (the pointer is all Fs).

  This PR updates the logic in AdvancedLoggerGetLoggerInfo to verify the PlatformBlob pointer contains the correct signature before returning it, and if that fails, it then will go through Memory Allocation Hobs to try to find a memory allocation that corresponds to the AdvancedLogger buffer. If it fails, it will fall through to the existing functionality of creating a new allocation hob.

  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

  Verified that the system that was triggering an exception was able to function correctly after this change was incorporated.

  Integration Instructions

  N/A

    </blockquote>
    <hr>
  </details>
  

Full Changelog: v2023020004.1.0...v2023020004.1.1

v2023020004.1.0

What's Changed

🚀 Features & ✨ Enhancements

• Implement a new version of UefiHidDxeV2 with significant improvements to unit test capability and general architecture. @joschock (#374)
  
  Change Details

    ## Description

  This PR introduces a "v2" implementation of UefiHidDxe that has significant refactoring to support unit tests and architectural improvements.

  • UefiHidDxeV2 code coverage with unit tests is ~80% or greater for all modules of the UefiHidDxe crate
  • Better separation between FFI layers and native rust layers

  The long term plan is to eventually remove the original UefiHidDxe in favor of this implementation.

  • Impacts functionality?
    • Driver provides the same functionality as UefiHidDxe which should be considered deprecated going forward.
  • Impacts security?
  • Breaking change?
  • Includes tests?
    • Includes Rust unit tests covering all new modules.
  • Includes documentation?
    • Standard rustdocs included.

  How This Was Tested

  Tested under QEMU using simulated USB keyboard and mouse.

  Integration Instructions

  UefiHidDxeV2 is a drop-in replacement for UefiHidDxe; platforms that wish to move to the new implementation can do so by pulling in the new UefiHidDxeV2 and adding the necessary mockall crate to their workspace Cargo.toml.
  

  
  

  ---

  
  

📖 Documentation Updates

• Implement a new version of UefiHidDxeV2 with significant improvements to unit test capability and general architecture. @joschock (#374)
  
  Change Details

    ## Description

  This PR introduces a "v2" implementation of UefiHidDxe that has significant refactoring to support unit tests and architectural improvements.

  • UefiHidDxeV2 code coverage with unit tests is ~80% or greater for all modules of the UefiHidDxe crate
  • Better separation between FFI layers and native rust layers

  The long term plan is to eventually remove the original UefiHidDxe in favor of this implementation.

  • Impacts functionality?
    • Driver provides the same functionality as UefiHidDxe which should be considered deprecated going forward.
  • Impacts security?
  • Breaking change?
  • Includes tests?
    • Includes Rust unit tests covering all new modules.
  • Includes documentation?
    • Standard rustdocs included.

  How This Was Tested

  Tested under QEMU using simulated USB keyboard and mouse.

  Integration Instructions

  UefiHidDxeV2 is a drop-in replacement for UefiHidDxe; platforms that wish to move to the new implementation can do so by pulling in the new UefiHidDxeV2 and adding the necessary mockall crate to their workspace Cargo.toml.
  

  
  

  ---

  
  

Full Changelog: v2023020004.0.5...v2023020004.1.0

v2023020004.0.5

What's Changed

• Fix various non-functional issues [Rebase \& FF] @makubacki (#387)
  
  Change Details

    ## Description

  1. Add header guards missing in some files

     Some header files, such as those which define structures,
     cannot be included more than once within a translation unit, as doing
     so would cause a redefinition error. Such headers must be guarded to
     prevent ill-effects from multiple inclusion. Similarly, if header
     files include other header files, and this inclusion graph contains
     a cycle, then at least one file within the cycle must contain header
     guards in order to break the cycle. Because of cases like these, all
     headers should be guarded as a matter of good practice, even if they
     do not strictly need to be.

     Furthermore, most modern compilers contain optimizations which are
     triggered by header guards. If the header guard strictly conforms
     to the pattern that compilers expect, then inclusions of that
     header other than the first have absolutely no effect: the file
     isn't re-read from disk, nor is it re-tokenised or re-preprocessed.
     This can result in a noticeable, albeit minor, improvement to
     compilation time.

  2. MsWheaPkg/MsWheaEarlyStorageLib: Remove unused static function

     Removes MsWheaCMOSStoreClearAll() which is scoped to the file and
     not used. Improves code readability and maintenance.

  3. MsWheaPkg/MsWheaEarlyStorageLib: Remove unsigned comparisons to zero

     Removes an unnecessary condition since unsigned values are always
     greater than or equal to 0.

  • 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 and CI.

  Integration Instructions

  N/A
  

  
  

  ---

  
  

🐛 Bug Fixes

• MsGraphicsPkg/SimpleUIToolKit: Move array bounds check before access @makubacki (#386)
  
  Change Details

    ## Description

  Checks the index is within expected bounds before accessing the array.

  • 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

  CodeQL and package compilation.

  Integration Instructions

  N/A
  

  
  

  ---

  
  

Full Changelog: v2023020004.0.4...v2023020004.0.5

v2023020004.0.4

What's Changed

📖 Documentation Updates

• Adding policy check for advanced file logger @kuqin12 (#384)
  
  Change Details

    # Preface

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

  Description

  This change added support for enablement/disablement of advanced file logger through policy services. Platforms intending to support this functionality should produce policy prior to the driver load. The default configuration is set to file logger enabled.

  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 is tested on QEMU Q35 and verified that not creating policy will remain producing log files, and disabling the policy will prevent the driver from logging any files to ESP.

  Integration Instructions

  In platform code, use SetPolicy with gAdvancedFileLoggerPolicyGuid to produce a policy entry for file logger driver to consume.
  

  
  

  ---

  
  

Full Changelog: v2023020004.0.3...v2023020004.0.4

v2023020004.0.3

What's Changed

• Minor debug print updates for DxePagingAuditTestApp @kuqin12 (#382)
  
  Change Details

    ## Description

  This change updated some print levels and added the PDB name for images being looked at.

  • 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 on proprietary virtual ARM platform and verified updated prints works as expected.

  Integration Instructions

  N/A
  

  
  

  ---

  
  

🐛 Bug Fixes

• DxePagingAudit: Update MemoryOutsideEfiMemoryMapIsInaccessible Test @TaylorBeebe (#381)
  
  Change Details

    ## Description

  1. MemoryOutsideEfiMemoryMapIsInaccessible checks if memory not present in the EFI memory map has the EFI_MEMORY_RP attribute. The previous version of this test assumed that the memory range spanned by the EFI memory map was contiguous which is sometimes not the case on platforms. This update changes the flow of the test to look at interstitial gaps in the memory map and not just those on the flanks.

  2. The EFI memory map returned through the boot services table is sometimes out of order. This update sorts the memory map and memory space map whenever they're populated for a test.

  3. The X64 MemoryOutsideEfiMemoryMapIsInaccessible HTML test had a typo which is fixed in this update.

  • 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 on Q35 and ARM

  Integration Instructions

  N/A
  

  
  

  ---

  
  

Full Changelog: v2023020004.0.2...v2023020004.0.3

v2023020004.0.2

What's Changed

• Split MemoryProtectionTestApp to DXE and SMM Versions @TaylorBeebe (#379)
  
  Change Details

    ## Description

  MemoryProtectionTestApp was written before Project Mu supported an ARM platform and Standalone MM. The test app generates the test cases for both the SMM and DXE environments. The SMM tests will report failure for Arm platforms and platforms using Standalone MM, so this update separates the test app into SMM and DXE versions.

  The SMM version will still require a driver to handle the SMI calls. To reduce confusing naming, MemoryProtectionTestSmm (the driver supporting SMM memory protection testing) has been renamed to SmmMemoryProtectionTestDriver.

  NOTE: Removing the old test app will be delayed for a couple of weeks to give consumers a chance to switch references in their DSC files.

  • 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

  SMM test was checked on a physical x86 platform. The DXE test was checked on Q35 and SBSA

  Integration Instructions

  Instances of

  UefiTestingPkg/FunctionalSystemTests/MemoryProtectionTest/App/MemoryProtectionTestApp.inf

  will need to be updated to

  UefiTestingPkg/FunctionalSystemTests/MemoryProtectionTest/App/SmmMemoryProtectionTestApp.inf UefiTestingPkg/FunctionalSystemTests/MemoryProtectionTest/App/DxeMemoryProtectionTestApp.inf

  And instances of

  UefiTestingPkg/FunctionalSystemTests/MemoryProtectionTest/Smm/MemoryProtectionTestSmm.inf

  will need to be updated to

  UefiTestingPkg/FunctionalSystemTests/MemoryProtectionTest/Driver/SmmMemoryProtectionTestDriver.inf
  

  
  

  ---

  
  

Full Changelog: v2023020004.0.1...v2023020004.0.2

v2023020004.0.1

What's Changed

• MemoryProtectionTestApp: Separate Reset Method Init to Arch Specific Files @TaylorBeebe (#376)
  
  Change Details

    ## Description

  The reset test method is not supported on ARM platforms currently (support will be added later, but it's not high priority because this test method often takes 40+ minutes). This PR separates the initialization of this testing method to architecture specific logic so the test method is not attempted on ARM platforms.

  This also fixes a build error on ARM platforms caused by DefaultExceptionHandlerLib being included (which does not support UEFI_APPLICATION without a MU override).

  • 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

  Running the updated test app on Q35 and SBSA

  Integration Instructions

  N/A
  

  
  

  ---

  
  

---

🚀 Features & ✨ Enhancements

• MsCorePkg/SecureBootKeyStoreLib: Add Library implementation @Javagedes (#377)
  
  Change Details

    ## Description

  Adds SecureBootKeyStoreLib which provides secureboot key store options by consuming fixed at build PCDs that represent the Pk, Db, 3PDb, Kek, and Dbx.

  • Impacts functionality?
    • Adds 5 new PCDs to represent the Pk, Db, 3PDb, Kek, and Dbx, which are consumed by SedcureBootKeyStoreLibOem when configuring SecureBoot.
  • 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 secureboot is properly enabled on Qemu35Pkg for Microsoft and Microsoft 3rd party.

  Integration Instructions

  Generate the following PCDs for your platform DSC:

  1. gOemPkgTokenSpaceGuid.PcdDefaultKek
  2. gOemPkgTokenSpaceGuid.PcdDefaultDb
  3. gOemPkgTokenSpaceGuid.PcdDefault3PDb
  4. gOemPkgTokenSpaceGuid.PcdDefaultDbx
  5. gOemPkgTokenSpaceGuid.PcdDefaultPk

  It is highly suggested, but not required, that each pcd is generated by running BaseTools BinToPcd over the binary blobs created in secureboot_objects, then including them in the platform's DSC file.
  

  
  

  ---

  
  

Full Changelog: v2023020004.0.0...v2023020004.0.1

v2023020003.4.0

What's Changed

🚀 Features & ✨ Enhancements

• TpmTestingPkg/TpmReplay: Enhance decode support [Rebase \& FF] @makubacki (#366)
  
  Change Details

    ## Description

  Adds several enhancements to the TpmReplay feature script.

  ---

  Add crypto agile log format support

  Allows TCG event logs with the "crypto agile format" to be decoded
  similar to those generated for TPM Replay by the script.

  This includes the log produced by Windows (usually present in the
  C:\Windows\Logs\MeasuredBoot directory).

  The log is passed with the existing log input parameter "-e".

  Example:
  TpmReplay.py -e WindowsLog.log -o YamlLog.yaml -l TxtLog.txt -v

  ---

  Add UEFI variable decode support

  Adds the capability to recognize UEFI variable data in UEFI variable
  events (e.g. EV_EFI_VARIABLE_DRIVER_CONFIG) and output that to the
  YAML file and text log.

  This makes inspecting and configuring UEFI variables more user
  friendly.

  ---

  tcg_platform.py: Add SHA1 support

  Add support for accepting SHA1 hashes. Updates the JSON schema to
  accept 160-bit values for SHA1 hashes.

  ---

  Use a local logger

  Uses a local logger instance to avoid using the root logger to avoid
  picking up log output from external libraries.

  ---

  Add variable data hex view to log

  Updates the string formatting for UEFI variable data to return a
  hexadecimal string followed by a decoded ASCII representation to
  make the data easier to view.

  This can be seen in a file specified using the -l parameter in
  combination with -v to output verbose text to the file.

  ---

  Readme.md: Add new log and variable details

  Describes crytpo agile event log and UEFI variable decode support.

  ---

  Note: There are some general improvements that can be made to the overall design of
  the code. That would require a bit of a refactor that I don't have time for at
  the moment. Such as using inheritance in a few places that could benefit from it
  and reorganizing some of the code structure.

  ---

  • 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

  • Existing PCR0-7 YAML file to binary.
  • TPM replay log binary back to YAML file.
  • Windows event log to YAML file.
    • Resulting YAML file to TPM replay binary.

  Integration Instructions

  N/A - Details captured in readme. No backward incompatible changes.
  

  
  

  ---

  
  

📖 Documentation Updates

• RustAdvancedLoggerDxe: Remove spinlocks, add `function!()`, add `std` feature. @joschock (#363)
  
  Change Details

    ## Description

  This PR implements 3 enhancements for the RustAdvancedLoggerDxe driver:

  • Removes spinlocks altogether. State that used to be shared (in particular, the current log level while generating a multi-part log message) is now on the stack.
  • Add function!() macro that returns the current function name as a static string.
  • Add std feture that maps debug!() and by extension debugln!() macros to std::println;

  • Impacts functionality?
  • Impacts security?
  • Breaking change?
  • Includes tests?
    • Existing unit tests updated to accommodate new design.
  • Includes documentation?
    • Existing docs updated to accommodate new design.

  How This Was Tested

  Unit tests pass, new features validated in both unit test environment (std feature active and mapping to std::print) and qemu UEFI boot (std feature not active, using AdvLogger protocol).

  Integration Instructions

  N/A - existing code should function as-is.

  [dev-dependencies]
  RustAdvancedLoggerDxe = {workspace=true, features=["std"]}
  

  New code that wants to take advantage of std can activate it for tests by specifying it as a feature for RustAdvLoggerDxe in dev-dependencies as shown above.
  

  
  

  ---

  
  

Full Changelog: v2023020003.3.1...v2023020003.4.0

v2023020004.0.0

What's Changed

⚠️ Breaking Changes

• Create separate FrameBufferMemDrawLib inf for PEI and DXE @srilathasridharan (#373)
  
  Change Details

    ## Description

  Splitting inf's for PEI and DXE FrameBufferMemDrawLib to support building for 64bit PEIM.

  • 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?
      Remove old inf path and add the separate PEI and DXE inf to DSC files.
  • 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 platform packages consuming the library can build fine and FrameBufferDraw works as expected for PEI and DXE graphics.

  Integration Instructions

  Update dsc file to remove the old inf path and include separate PEI and DXE infs.
  

  
  

  ---

  
  

Full Changelog: v2023020003.4.0...v2023020004.0.0

v2023020003.3.1

What's Changed

🐛 Bug Fixes

• Add Unaccepted Memory Type to Memory Protection Test App @TaylorBeebe (#371)
  
  Change Details

    ## Description

  EDK2 added EfiUnacceptedMemoryType to the memory type list. This update adds this memory type to the memory protection test app and skips it because it is not allocatable.

  • 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

  Running the test on Q35

  Integration Instructions

  N/A
  

  
  

  ---

  
  

🔐 Security Impacting

• Use New Stack Cookie Library @TaylorBeebe (#367)
  
  Change Details

    ## Description

  Update one DSC file to use the new stack cookie library, and MdePkg/MdeLibs.dsc.inc contains the definitions for the new stack cookie libraries for the remaining DSC files.

  • 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 on Q35 GCC and MSVC builds

  Integration Instructions

  N/A
  

  
  

  ---

  
  

Full Changelog: v2023020003.3.0...v2023020003.3.1