What's Changed

🚀 Features & ✨ Enhancements

Close the ReadyToBoot and ExitBootServices events in the reset notification. This prevents the file logger from trying to access the file system after its reset notification has run in the event that the platform implementation invokes one of those notifications in the reset path (which it shouldn't, but some do).

• Impacts functionality?
  • Should not impact functionality since the reset notification is expected to be the last point at which file log can be flushed on most architectures.
• Impacts security?
  • No security impact
• Breaking change?
  • Not breaking change.
• Includes tests?
  • No tests included as no new functionality is introduced.
• Includes documentation?
  • No docs changed as no new functionality is introduced.

How This Was Tested

Executed reset, confirmed that file log is flushed as expected. On a system that also invokes the exit boot services notification in the reset path, confirmed that log file is not flushed in the exit boot services notification. Confirmed that on normal boot path to OS, log flush is executed in the exit boot path notification.

Integration Instructions

N/A

  </blockquote>
  <hr>
</details>

Full Changelog: https://github.com/microsoft/mu_plus/compare/v2023020001.0.1...v2023020001.1.0

What's Changed

Added logic to delete the Memory Type Information variable on a capsule update. This is because in rare circumstance where a new memory type is added (or a memory type is removed) a capsule update will cause a mismatch of memory types. Removing the variable and thus forcing a clean memory bucket discovery solves this issue.

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

Tested on a platform where there is a capsule update between two versions of firmware with a different amount of memory types. Without this change the transition from temp ram to permanent memory breaks but with this change the device correctly goes to the default memory bucket configuration and is able to boot.

Integration Instructions

N/A

  </blockquote>
  <hr>
</details>

Adds PrEval entries for all packages to enable the new PrEval Policy 5.

• 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

  </blockquote>
  <hr>
</details>

🔐 Security Impacting

Fixed some CodeQL failures we're seeing in a variety of packages.

• 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 through CodeQL checks.

Integration Instructions

N/A

  </blockquote>
  <hr>
</details>

Full Changelog: https://github.com/microsoft/mu_plus/compare/v2023020001.0.0...v2023020001.0.1

What's Changed

⚠️ Breaking Changes

AdvLoggerSerialPortLib was using a library class that was not a true library class (not defined in any .dec file or have an associated .h).

This changes the library class to use the correct library class, SerialPortLib.

• 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

Successfully build multiple platforms and pass the newly added BaseTools change for verifying library override class names.

Integration Instructions

Any library class definitions in a dsc using AdvLoggerSerialPortLib needs to be switched to SerialPortLib.

Full Changelog: https://github.com/microsoft/mu_plus/compare/v2023020000.1.0...v2023020001.0.0

What's Changed

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

Description

This change added a few new matrix entries to support building mu_tiano_platforms on native ARM64 systems. The PR will cover both https://github.com/microsoft/mu_basecore/issues/369 and https://github.com/microsoft/mu_basecore/issues/305.

The PR should also be incorporated with mu_devops change.

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 selfhost-agents and existing agents.

Integration Instructions

Pipeline changes, N/A for integration.

  </blockquote>
  <hr>
</details>

🚀 Features & ✨ Enhancements

Cherry picks commits from PR #259 into release/202208 into release/202302.

Some platforms may not reach BDS on a boot mode expected by the
current implementation to update the ConIn variable with a new
console input device.

For example, support for a new device might be added in a firmware
update, the update is performed, and the system is reset one or
more times before reaching PlatformBootManagerBeforeConsole().

This change always evaluates a potential update to ConIn regardless
of boot mode to reduce ConIn update complexity.

• 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 the build and boot with the change. Since only the boot mode check
is removed, the underlying behavior within the boot mode condition remains
the same

Integration Instructions

Review the change to when console may be updated relative to boot mode in
change and the implementation of EfiBootManagerUpdateConsoleVariable()
being used by the platform to determine if you would like to make any
changes to that function. No required changes are expected.

Full Changelog: https://github.com/microsoft/mu_plus/compare/v2023020000.0.0...v2023020000.1.0

What's Changed

This is the first MU Plus 202302 release 🎉

The previous branch was 202208.

These versions correspond to edk2 stable release tags that the code is based upon.

Since edk2 makes a release every 3 months, two stable tags were actually picked up in this release:

• edk2-stable202211
• edk2-stable202302

Review those release notes to understand the changes coming in from edk2. In addition, Mu repos highlight important changes in their Readme files. Review the 202302 Readme before you move code to this branch to understand major changes.