What's Changed

This change updated the override validation tags. It also integrates the cherry-pick commit from https://github.com/microsoft/mu_basecore/commit/4d722ac91608d3c4fbe807b418b77f2a6e279117.

For details on how to complete to complete these options and their meaning refer to CONTRIBUTING.md.

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

How This Was Tested

This was tested on pipeline and passed override check. Also booted on Q35 branch.

Integration Instructions

The change needs to pair with basecore commit https://github.com/microsoft/mu_basecore/commit/4d722ac91608d3c4fbe807b418b77f2a6e279117 or later.

  </blockquote>
  <hr>
</details>

Full Changelog: https://github.com/microsoft/mu_feature_mm_supv/compare/v13.0.1...v13.0.2

What's Changed

This change updates the version information of this package and module. It also updates the document on how to integrate the latest changes into platforms that are picking up 202405.

The version number is updated from 11 to 13 to match the release version, which was missed in v12 release.

• 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: https://github.com/microsoft/mu_feature_mm_supv/compare/v13.0.0...v13.0.1

What's Changed

⚠️ Breaking Changes

This change integrates the upstream changes from 2405 release tag into supervisor

• 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

Change is tested on QEMU Q35 branch.

Integration Instructions

N/A

🔐 Security Impacting

This change integrates the upstream changes from 2405 release tag into supervisor

• 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

Change is tested on QEMU Q35 branch.

Integration Instructions

N/A

Full Changelog: https://github.com/microsoft/mu_feature_mm_supv/compare/v12.0.2...v13.0.0

What's Changed

🐛 Bug Fixes

Updated AllocatePageTableMemory to include a new input variable *NewAllocation. This variable is used to keep track of if new pages were allocated for use in the page table page pool. This fixes a bug where if we run out of page table pool pages while changing some pages memory attributes we'll recursively call into ConvertMemoryPageAttributes while allocating pages leading to unaccounted for pages in the original call. This leads to an assert by the ConvertMemoryPageAttributes code.

• 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 two separate physical platforms that experienced the issue in different circumstances. This fix tested on those reproing platforms have the issue resolved and no longer saw any asserts.

Integration Instructions

N/A

🔐 Security Impacting

Updated AllocatePageTableMemory to include a new input variable *NewAllocation. This variable is used to keep track of if new pages were allocated for use in the page table page pool. This fixes a bug where if we run out of page table pool pages while changing some pages memory attributes we'll recursively call into ConvertMemoryPageAttributes while allocating pages leading to unaccounted for pages in the original call. This leads to an assert by the ConvertMemoryPageAttributes code.

• 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 two separate physical platforms that experienced the issue in different circumstances. This fix tested on those reproing platforms have the issue resolved and no longer saw any asserts.

Integration Instructions

N/A

Full Changelog: https://github.com/microsoft/mu_feature_mm_supv/compare/v12.0.1...v12.0.2

What's Changed

Basecore 2023110009.0.0 included the change for consuming panic lib in place of CpuDeadloop.

Replaced CpuDeadloops in MmSupervisorCore with calls to PanicLib.

• 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

Local CI.

Integration Instructions

N/A - Panic lib was already consumed in module.

PiSmmCpuDxeSmm was updated to use Panic library and Panic calls instead of CPU_DEADLOOPs for error conditions.
This changed the generated override validation tag. mu_feature_mm_supv needed updated.

The consumption of PanicLib was not introduced at this time. Details can be seen at link below:
 
https://github.com/microsoft/mu_basecore/commit/bbbff00dc39a67dc1e44aa0ce392d460b12f66b9

• 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

Local CI, and a mu_tiano_platforms build with newer version.

Integration Instructions

N/A

Full Changelog: https://github.com/microsoft/mu_feature_mm_supv/compare/v12.0.0...v12.0.1

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 will cover a few more CLANG fixes, including uninitialized variables and unintentionally pulled in compiler intrinsics.

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 QEMU Q35.

Integration Instructions

N/A

  </blockquote>
  <hr>
</details>

The pipeline build is broken due to a commit cherry-picked in to basecore: https://github.com/microsoft/mu_basecore/commit/7f9a27e0d7bcefd06e8d45fc06d5e906b6898911.

This change is needed to unblock other PRs into this repo.

• 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

Primarily made to pull in this change UefiCpuPkg/PiSmmCpuDxeSmm: Use NonSmm BSP as default SMM BSP..

Also includes other optimizations to keep the file in sync with edk2. The history of the recent changes in the file in this repo vs edk2 are shown for reference.

• 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

• MmSupervisorPkg build.
• Intel physical platform build and boot to Windows OS.
• QemuQ35Pkg build and boot to Windows OS.

Integration Instructions

• N/A
  
  

⚠️ Breaking Changes

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

Description

This change is integrating the changes from BASECORE:
https://github.com/microsoft/mu_basecore/commit/ff7dabfdca8534a1d1b3551e91b739be20a5f8fc
https://github.com/microsoft/mu_basecore/commit/719bf756ea6d94ef800eaab4601d3ed52423ef35

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 change is tested with QEMU Q35.

Integration Instructions

This requires the platforms to update their BASECORE version to be later than https://github.com/microsoft/mu_basecore/commit/719bf756ea6d94ef800eaab4601d3ed52423ef35 of release/202311.

  </blockquote>
  <hr>
</details>

This change integrated the update from EDK2 where the MP information of the system will be pulled from the HOBs instead of gBS, which aligns with our existing implementation.

• 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 change was tested on QEMU Q35 and booted to UEFI shell.

Integration Instructions

N/A

🐛 Bug Fixes

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

Description

This change fixes a code path where the Status could get evaluated without being initialized.

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 QEMU Q35.

Integration Instructions

N/A

  </blockquote>
  <hr>
</details>

Full Changelog: https://github.com/microsoft/mu_feature_mm_supv/compare/v11.0.1...v12.0.0

What's Changed

We have not updated this field for too long, which will make the print out during runtime have discrepancy compared to the code release version. This change is made to fix that.

• 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 only a version change, no functional update.

Integration Instructions

N/A

Full Changelog: https://github.com/microsoft/mu_feature_mm_supv/compare/v11.0.0...v11.0.1

What's Changed

⚠️ Breaking Changes

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

Description

This change integrates 4 commits from MU_BASECORE to use the common library implementation for image record creation and resolve the corresponding override validation failures.

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 change was tested on QEMU Q35 and booted to UEFI shell.

Integration Instructions

Platform needs to include ImagePropertiesRecordLib in their platform dsc file to pick up this change.

  </blockquote>
  <hr>
</details>

Full Changelog: https://github.com/microsoft/mu_feature_mm_supv/compare/v10.0.0...v11.0.0

What's Changed

⚠️ Breaking Changes

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

Description

The BaseLib is updated with new support of CRC16-CCITT-FALSE implementation. This change added the change and updated the override hash.

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 change is tested on QEMU Q35 and booted to UEFI shell.

Integration Instructions

N/A

  </blockquote>
  <hr>
</details>

Full Changelog: https://github.com/microsoft/mu_feature_mm_supv/compare/v9.0.1...v10.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

The current exception handling routine has 2 issues:

1. When it comes to page fault, the miscellaneous exception handler will print the exception context and then hand off to the specific page fault handler, which will make the log appear as the system double fault.
2. When the page fault exception occurs, the existing setup will switch the system to use a separate stack, which is hardcoded to be 4KB from the top of supervisor stack. This size is insufficient after switching to PageTableLib based page table attribute manipulations.

This change should fix both issues.

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 change is tested on QEMU Q35 and verified bootable into UEFI shell.

Integration Instructions

N/A

  </blockquote>
  <hr>
</details>

Integrated the following commits from MU_BASECORE into the supervisor core (which themselves were taken from edk2):
https://github.com/microsoft/mu_basecore/commit/fba09d01a35746f4e8a3b03a70b1f13fb43342be
https://github.com/microsoft/mu_basecore/commit/f5417b804d5cb89dbbe384458fa6dfc0b81377ff
https://github.com/microsoft/mu_basecore/commit/d421e2b9c9d1af511aca95a20f6fe483f646909b
https://github.com/microsoft/mu_basecore/commit/bb7120572e7f8754fa46aaf01b76f9734ab4b29e

Additionally updated the override of UefiCpuPkg in the supervisor cores inf.

• 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 physical platforms with the latest MU 202311 branches. No issues observed.

Integration Instructions

N/A

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

Description

It does not seem that the edk2-basetools are not being used. This change will remove it.

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

Pipeline change, no firmware function changes.

Integration Instructions

N/A.

  </blockquote>
  <hr>
</details>

An instance of StackCheckLib must be in each DSC to accommodate -fstack-protector and /GS flags.

• 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 in pipelines

Integration Instructions

N/A

  </blockquote>
  <hr>
</details>

Full Changelog: https://github.com/microsoft/mu_feature_mm_supv/compare/v9.0.0...v9.0.1

What's Changed

This change updated the release version to v9 to reflect the new value from release template.

• 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

⚠️ Breaking Changes

This change integrates the edk2 upstream changes into applicable overridden modules.

Specifically, this change integrates the following commits:

• https://github.com/tianocore/edk2/commit/f1d31a6ec7d5a4251d441a62b2cc6f11f0f49da4
• https://github.com/tianocore/edk2/commit/b17a3a133b18fb41493fba7d86e9b5804ea6a8cf
• https://github.com/tianocore/edk2/commit/321240b135e37ac1b9be1317f78ce2a3b526bf02
• https://github.com/tianocore/edk2/commit/68e37f457881d222c68834920f4ffd6f668a2b77
• https://github.com/tianocore/edk2/commit/7b82da70edf7dda2c6f4e853f100df620bd5c0f3
• https://github.com/tianocore/edk2/commit/e4ff8521364062303cd93f87a0d9c0bacc9ebe65
• https://github.com/tianocore/edk2/commit/0c136bbba0cdcb227058fedbb3f676d15eee5cc2
• https://github.com/tianocore/edk2/commit/8c9983977676d68466c770846d3e64470b3d8668
• https://github.com/tianocore/edk2/commit/85c6c14c4c78d4e1c657632eab1d17e5a9098d94
• https://github.com/tianocore/edk2/commit/ec07fd0e35d90dbcc36be300a9ceeac29c5de2ad
• https://github.com/tianocore/edk2/commit/2e71876081706bef2d43a82ece3bb078706ee4cd
• https://github.com/tianocore/edk2/commit/4f441d024bee7e1a6438737b58e4b0b6856b3eab
• https://github.com/tianocore/edk2/commit/54051768cdf69e2b46dc4fe1a85455d631aa2634
• https://github.com/tianocore/edk2/commit/0da3df78ff469462c6c09d979fd6e2eeac0665bb
• https://github.com/tianocore/edk2/commit/ad6c8540cc9ce06235891cb6c4c713a5c8b272fc
• https://github.com/tianocore/edk2/commit/a87f5fdb3d1a23b9ad2475007c58c0969863293f
• https://github.com/tianocore/edk2/commit/2d212083d048ee8c0f5b4b7c61720f16165427cb
• https://github.com/tianocore/edk2/commit/6585ced55858fbab7c2dda8e61b0de99cb891ec9
• https://github.com/tianocore/edk2/commit/f51967280bcad35ba15faf8bd24df8a86052ce49
• https://github.com/tianocore/edk2/commit/7b6e7d009872af68319e9a91725911829cc59fb7
• https://github.com/tianocore/edk2/commit/d706d9c64ac6074f3066f0531b66f59f4991973b
• https://github.com/tianocore/edk2/commit/701b5797b260cbc9477380beb7fb071f3c5c88d1
• https://github.com/tianocore/edk2/commit/b4dde1ae6a8a573c84a70d197a4a341f7d5bfb3d
• https://github.com/tianocore/edk2/commit/7132df94aca29caf62b88beb049cd9c169c45c09
• https://github.com/tianocore/edk2/commit/4ceefd6dd1334e815d9e8393b727cecfaf441a1f
• https://github.com/tianocore/edk2/commit/f5c987fcac567b1f84a418826f30d8ef2b46860e
• https://github.com/tianocore/edk2/commit/fbb6f18e1c5a342285aafcdee5b53b66bf07989c
• https://github.com/tianocore/edk2/commit/589f2e49e5f9ff998bd4f08cbf28a1572ab7b544

The following commits are determined not relevant to this package:

• https://github.com/tianocore/edk2/commit/550f196e823a9f857e0313e632d89b6653946f88
• https://github.com/tianocore/edk2/commit/5bd2e5dfe6f8efa2cbbf643e4e7e46867a8a26b0
• https://github.com/tianocore/edk2/commit/e504b3917e2b5b0cdd6a381141efb7e303eeb6c1
• https://github.com/tianocore/edk2/commit/c4c7fb21744788e40de85630280e1c101b85294e
• https://github.com/tianocore/edk2/commit/eb20c21fcc12f1a2565259211a199ae4eb5b0356
• https://github.com/tianocore/edk2/commit/ded0b489af09cde5afa05d74acdb12cd4b4f8394
• https://github.com/tianocore/edk2/commit/7178047402c07d369a2a3a0b0e5118c5e3d90ddc
• https://github.com/tianocore/edk2/commit/6ceaef4804c52f0190fe9c09ff89cb19affbd56f
• https://github.com/tianocore/edk2/commit/b294633c68d4f4ed8c784501e8da321127121877
• https://github.com/tianocore/edk2/commit/6ceaef4804c52f0190fe9c09ff89cb19affbd56f
• https://github.com/tianocore/edk2/commit/56f65e4bad770b0d33eb54b3c180c9ec5057d8f2
• https://github.com/tianocore/edk2/commit/cb4820b6c148e62f9317799610b6e8dcd346c936
• https://github.com/tianocore/edk2/commit/c20408163f8bc8f72c42e054fbaaf8e40f0a8f0a
• https://github.com/tianocore/edk2/commit/a1386bb252066262c0b6664af9a6143306d88512
• https://github.com/tianocore/edk2/commit/089013a69724687f4051fc88367c9eb74def4284
• https://github.com/tianocore/edk2/commit/5bb7bfbe81e3fd6ffbc3909a96a87e685cfc267d
• https://github.com/tianocore/edk2/commit/9f12d6b6ecf8ffe9cd4d93fe0976fdbaf2ded4f0
• https://github.com/tianocore/edk2/commit/ef64ae06f8065eba5981cfcf0817a006933a306a
• https://github.com/tianocore/edk2/commit/b4394cca2dbe41f6adca06d600b330b3a8d7e0fc
• https://github.com/tianocore/edk2/commit/1fadd18d0c0c65ffde9e128a486414ba43b3387c
• https://github.com/tianocore/edk2/commit/cf82c09bac94aec00c0dd76d0a5c6c3f5fe41552
• https://github.com/tianocore/edk2/commit/2ce5ae43c2166984d20341993c4b9dbb337aad79
• https://github.com/tianocore/edk2/commit/ea628f28e59849ee7b91e6660c0ecd1a5c6e0884
• https://github.com/tianocore/edk2/commit/cbf0e4f5b370a874ace11a0b20533e891dbc25ab
• https://github.com/tianocore/edk2/commit/80bbea192aa44ab664ba8be29ac06c83f246e99c
• https://github.com/tianocore/edk2/commit/ae79efb7bd436068156605ae7111b93dab710546
• https://github.com/tianocore/edk2/commit/2b2705343a810538bc27f5e897da693984c82394
• https://github.com/tianocore/edk2/commit/1a66bd51ca21f341281d8e3157d3d3f4a94fd26c
• https://github.com/tianocore/edk2/commit/1497c4b074946f3ad9d46ddbb6d655c951e23ae8

• 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 change is tested on QEMU Q35 and SBSA virtual platform and booted to UEFI shell as well as host OS. This change is also verified bootable on proprietary hardware platform.

Integration Instructions

An update of 202311 based mu submodules are required to consume this change.

🐛 Bug Fixes

Contains the primary commit for the HOB calculation overflow and
a separate commit to build with the tip of mu_basecore release/202302.

CVE-2022-36765 - StandaloneMmHobLibSysCall: Prevent integer overflow in CreateHob()

Based on commit 9a75b030cf27d2530444e9a2f9f11867f79bf679 in edk2.

REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4166

Fix integer overflow in various CreateHob instances.
Fixes: CVE-2022-36765

The CreateHob() function aligns the requested size to 8
performing the following operation:

HobLength = (UINT16)((HobLength + 0x7) & (~0x7));

No checks are performed to ensure this value doesn't
overflow, and could lead to CreateHob() returning a smaller
HOB than requested, which could lead to OOB HOB accesses.

MmSupervisorPkg/BaseLibSysCall/BaseLib: Update override

The change that occurred in MdePkg/Library/BaseLib only affected
AARCH64 which does not exist in the instance in MmSupervisorPkg.

So, this change simply updates the override hash to the new value.

• 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

• MmSupervisorPkg CI.
• Upstream validation.
• Boot on QEMU.

Integration Instructions

N/A

🔐 Security Impacting

Contains the primary commit for the HOB calculation overflow and
a separate commit to build with the tip of mu_basecore release/202302.

CVE-2022-36765 - StandaloneMmHobLibSysCall: Prevent integer overflow in CreateHob()

Based on commit 9a75b030cf27d2530444e9a2f9f11867f79bf679 in edk2.

REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4166

Fix integer overflow in various CreateHob instances.
Fixes: CVE-2022-36765

The CreateHob() function aligns the requested size to 8
performing the following operation:

HobLength = (UINT16)((HobLength + 0x7) & (~0x7));

No checks are performed to ensure this value doesn't
overflow, and could lead to CreateHob() returning a smaller
HOB than requested, which could lead to OOB HOB accesses.

MmSupervisorPkg/BaseLibSysCall/BaseLib: Update override

The change that occurred in MdePkg/Library/BaseLib only affected
AARCH64 which does not exist in the instance in MmSupervisorPkg.

So, this change simply updates the override hash to the new value.

• 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

• MmSupervisorPkg CI.
• Upstream validation.
• Boot on QEMU.

Integration Instructions

N/A

Full Changelog: https://github.com/microsoft/mu_feature_mm_supv/compare/v8.1.8...v9.0.0

What's Changed

• Derived from edk2 commit: 2ddae5df31789853040f4c5261bb85e2f010c4a7
• Override hash updated to reflect change in mu_basecore

The current dependency evaluator violates the memory access permission
when patching depex grammar directly in the read-only depex memory area.

Laszlo pointed out the optimization issue in the thread (1) "Memory
Attribute for depex section" and provided suggested patch to remove the
perf optimization.

In my testing, removing the optimization does not make significant perf
reduction. That makes sense that StandaloneMM dispatcher only searches
in MM protocol database and does not depend on UEFI/DXE protocol
database. Also, we don't have many protocols in StandaloneMM like
UEFI/DXE.

From Laszlo,

"The patch removes the EFI_DEP_REPLACE_TRUE handling altogether, plus it
CONST-ifies the Iterator pointer (which points into the DEPEX section),
so that the compiler catch any possible accesses at build time that
would write to the write-protected DEPEX memory area."

(1) https://edk2.groups.io/g/devel/message/113531

Signed-off-by: Nhi Pham [email protected]
Tested-by: levi.yun [email protected]
Reviewed-by: levi.yun [email protected]
Reviewed-by: Ray Ni [email protected]

(cherry picked from commit 2ddae5df31789853040f4c5261bb85e2f010c4a7)

• 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

• CI and StandaloneMmPkg boot with change present.

Integration Instructions

N/A

Updates edk2-pytool-extensions and edk2-pytool-library to work with the latest commit of MU_BASECORE

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

N/A

Integration Instructions

N/A

Adds commits that only converted line endings to a
.git-blame-ignore-revs file so they are ignored by git blame. This is
supported by GitHub:
https://github.blog/changelog/2022-03-24-ignore-commits-in-the-blame-view-beta/

This helps clean up git blame by filtering out these changes.

Note: This file needs to be updated on rebase branches. Processes
like filter-branch can automatically update relevant SHAs.

• 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

• git blame

Integration Instructions

N/A

🐛 Bug Fixes

These libraries need to be linked against MmIplPei. Since they are
missing, linker failures can result depending on platform integration
of library instances against the module.

• 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

CI build.

Integration Instructions

N/A

Full Changelog: https://github.com/microsoft/mu_feature_mm_supv/compare/v8.1.7...v8.1.8

What's Changed

🔐 Security Impacting

This series transitions the core to use the new stack cookie libraries.
The stack cookie value no longer needs to be initialized before
image execution and can instead be initialized in the library
constructor.

• 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

Integration Instructions

N/A

Full Changelog: https://github.com/microsoft/mu_feature_mm_supv/compare/v8.1.6...v8.1.7

What's Changed

🐛 Bug Fixes

Fixes #182

The main change is to remove a NULL check for the CommBufferSize
parameter value in the MM_SUPERVISOR_REQUEST_FETCH_POLICY switch
case since it triggers a CodeQL alert as a redundant NULL check
operation. The actual parameter value is checked for NULL at the
beginning of the function and not modified until that line of code.

However, the function API and implementation is confusing so that's
cleaned up as well.

1. The Context parameter is not used at all. Since it is marked
   optional, it is left so the function prototype can remain
   consistent in case the parameter is needed in the future.
2. The CommBuffer and CommBufferSize parameters are also marked
   optional, but they're not. The function immediately returns
   EFI_INVALID_PARAMETER if they are not provided (null).

For (2), the optional modifier is simply removed from the arguments
to indicate the function expects valid pointers are passed.

• 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

• MmSupervisorPkg build and CI checks

Integration Instructions

N/A

Full Changelog: https://github.com/microsoft/mu_feature_mm_supv/compare/v8.1.5...v8.1.6

What's Changed

Updates the repo for a change that merged UefiCpuLib with CpuLib.

UefiCpuLib will be removed entirely soon so all references are updated to CpuLib.

• 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

• MmSupervisorPkg CI build
• Feature integration build (in QemuQ35Pkg)

Integration Instructions

N/A

Full Changelog: https://github.com/microsoft/mu_feature_mm_supv/compare/v8.1.4...v8.1.5

What's Changed

PcdUserCommBufferPages is currently set to 4. This buffer is
used for UEFI variable transactions where includes larger data like Intel
memory training and Secure Boot related UEFI variables.

16 pages provides 64KB by default which allows these common scenarios
to succeed in most cases without platform intervention.

• 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 on Qemu Q35 and a physical Intel platform.

Integration Instructions

If the default value was previously unmodified on a platform, expect that the
user mode communicate buffer will now be 48KB larger. If that's an issue, set
gMmSupervisorPkgTokenSpaceGuid.PcdUserCommBufferPages to 4 in the platform
DSC file to restore previous behavior.

Full Changelog: https://github.com/microsoft/mu_feature_mm_supv/compare/v8.1.3...v8.1.4

What's Changed

Current implementation of MmIsBufferOutsideMmValid for the user instance will only check to see if the requested space is unblocked from the perspective of MM supervisor, which could result in the issue that the region is only unblocked at the supervisor level is still not accessible from user space. If this is the case, FALSE should be returned.

• 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 change is tested on Q35 platform and booted to UEFI shell.

Integration Instructions

N/A

  </blockquote>
  <hr>
</details>

Full Changelog: https://github.com/microsoft/mu_feature_mm_supv/compare/v8.1.2...v8.1.3

What's Changed

Updates overrides for:

• MdeModulePkg/Core/PiSmmCore/PiSmmIpl.inf
• UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.inf

Relevant changes from https://github.com/microsoft/mu_basecore/pull/490

• 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

CI build and QemuQ35Pkg unit boot.

Integration Instructions

When updating Mu Basecore to include the changes linked in the
description, update the submodule with MmSupervisorPkg to
include these changes.

Full Changelog: https://github.com/microsoft/mu_feature_mm_supv/compare/v8.1.1...v8.1.2

What's Changed

Updates DumpInfo function for a policy to dump it's contents to any IO object, not just to stdout. By default, the DumpInfo function will dump to stdout, keeping existing logic, but allows the caller to specify any IO object via the outfs optional parameter.

Additionally changes the dump for the purpose of the SupervisorPolicyMaker helper script to dump to logging.DEBUG rather than as a print statement, as the print statement does not end up in the log file.

• 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

Virtual Platforms

Integration Instructions

N/A

  </blockquote>
  <hr>
</details>

Catching a bare exception is considered bad practice. Catching bare exceptions can make it impossible to interrupt the program (e.g., with Ctrl-C) and can disguise other problems. This removes all bare excepts and instead catches Exception which is the base class for all code-generated exceptions.

• 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>

Updates the UT_LOG_* messages to print a new line so the prints
do not run into the individual test section dividers.

Prints additional information when examining IOMMU regions to show
what regions are being considered and specific details about
potential range overlaps.

• 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

Ran test on a physical Intel platform and reviewed debug output.

Integration Instructions

N/A

Add a PrEval entry to all ci.yaml files. This enables the 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

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

Description

This change updated the unit test to inspect retrieved MM policy attribute against protected regions, such as TXT and IOMMU regions as defined by WHCP specification.

Although the specification only mentions that the regions should have no write access, this implementation will flag attributes on executable protected regions.

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 QemuQ35Pkg.

Integration Instructions

N/A

  </blockquote>
  <hr>
</details>

Full Changelog: https://github.com/microsoft/mu_feature_mm_supv/compare/v8.1.0...v8.1.1

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 bumps the version number to make a release before we transition to 202302.

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

N/A

Integration Instructions

N/A

  </blockquote>
  <hr>
</details>

⚠️ Breaking Changes

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

Description

This change integrates a series of patches checked into the overridden modules from supervisor repo.

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 QEMU virtual platform and proprietary hardware.

Integration Instructions

End user should update to release/202302 branches for other project MU repos to consume this.

🔐 Security Impacting

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

Description

This change integrates a series of patches checked into the overridden modules from supervisor repo.

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 QEMU virtual platform and proprietary hardware.

Integration Instructions

End user should update to release/202302 branches for other project MU repos to consume this.

Full Changelog: https://github.com/microsoft/mu_feature_mm_supv/compare/v7.3.2...v8.1.0