mu_tiano_platforms - v9.0.0

Published by github-actions[bot] 25 days ago

What's Changed

⚠️ Breaking Changes

Contains the following changes:

QemuQ35Pkg: Drop S3 and Lock Box support

Drop SmmLockBox from build and flash image

This is a Traditional SMM module that cannot be dispached with
the Standalone MM model currently supported in QemuQ35Pkg.
Drop PEI and DXE S3 and Lock Box related modules from the
QemuQ35Pkg build and flash image.

gEfiMdeModulePkgTokenSpaceGuid.PcdAcpiS3Enable is FALSE which
disables S3 support. Code is also currently not being written to
support S3 boot script replay and S3 is not tested. Modern physical
platforms rarely support S3 and S3 presents its own security
related concerns and maintenance overhead.

Since S3 is not needed, the lock box code which is currently only
used to store the S3 boot script is not needed.

As a consequence, the following S3, boot script, and lock box
related PEI and DXE modules are removed from QemuQ35Pkg:
- BootScriptExecutorDxe
- CpuS3DataDxe
- S3Resume2Pei
- S3SaveStateDxe
Drop S3 and lock box related library instances from QemuQ35Pkg
build.

The following library instances also do not need to be build given
S3 is not supported and are removed from the QemuQ35Pkg build:
- MdeModulePkg/Library/PiDxeS3BootScriptLib/DxeS3BootScriptLib.inf
- MdeModulePkg/Library/SmmLockBoxLib/SmmLockBoxDxeLib.inf
- MdeModulePkg/Library/SmmLockBoxLib/SmmLockBoxPeiLib.inf
- MdeModulePkg/Library/SmmLockBoxLib/SmmLockBoxSmmLib.inf
- MdeModulePkg/Library/SmmLockBoxLib/SmmLockBoxStandaloneMmLib.inf
- QemuPkg/Library/LockBoxLib/LockBoxBaseLib.inf
- QemuQ35Pkg/Library/QemuFwCfgS3Lib/PeiQemuFwCfgS3LibFwCfg.inf

QemuQ35Pkg: Remove S3 and Lock Box related code

Removes libraries and modules that support S3 and Lock Box since S3
is not supported by QemuQ35Pkg.

QemuQ35Pkg/Sec: Drop S3 and Lock Box support

Always follow the non-S3 flow to decompress the main FV and load
the PEI core from it during SEC startup.

QemuQ35Pkg/PlatformPei: Drop S3 and Lock Box support

Removes platform initialization logic for S3 and the lock box.

Notably, the number of MMRAM regions is reduced from two to one since
the first MMRAM range was previously a 4KB page used to hold S3
resume structures.

The amount of ACPI NVS reservation is reduced substantially since
areas like the following do not need to be preserved for S3 resume:

CPU AP stack buffers
Temp RAM stack and heap
GUIDed section extraction handlers
Reset vector initial page tables

The lock box storage buffer is also not allocated at all. Previously,
it was allocated as boot services data (not ACPI NVS) since S3 was
never enabled. In any case, that space is no longer allocated.

Asserts are added in places through key control flow to alert a
developer if S3 is detected as enabled when it should not be.

QemuQ35Pkg/AcpiPlatformDxe: Drop S3 and Lock Box support

Removes S3 boot script related code since S3 is no longer supported.

QemuQ35Pkg/SmmControl2Dxe: Drop S3 and Lock Box support

Removes S3 and boot script related code to focus the module on simply
installing Trigger() and Clear() functionality for the SMM
Control protocol.

QemuQ35Pkg/SmmAccess: Drop S3 and Lock Box support

Main change is to compensate for the single MMRAM range used now that
the S3 resume area is removed from MMRAM. A single range is now used
to cover all of TSEG.

QemuQ35Pkg.fdf: Remove assignment of Lock Box PCDs

Removes the following PCDs since the lock box is no longer supported.

gQemuPkgTokenSpaceGuid.PcdOvmfLockBoxStorageBase
gQemuPkgTokenSpaceGuid.PcdOvmfLockBoxStorageSize

QemuSbsaPkg: Use LockBoxLib null instance

The QemuPkg LockBoxLib is being removed. Used the null instance here
for libraries (like PerformanceLib) that link against a LockBoxLib
instance.

QemuPkg: Remove LockBoxLib

Not needed since S3 support is not used requiring the Lock Box.

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

How This Was Tested

Boot to EFI shell and perform cold and warm reset
Verify Standalone MM drivers are dispatched and execute successfully

Integration Instructions

N/A - Affects platform firmware operation

🚀 Features & ✨ Enhancements

Contains the following changes:

QemuQ35Pkg: Drop S3 and Lock Box support

Drop SmmLockBox from build and flash image

This is a Traditional SMM module that cannot be dispached with
the Standalone MM model currently supported in QemuQ35Pkg.
Drop PEI and DXE S3 and Lock Box related modules from the
QemuQ35Pkg build and flash image.

gEfiMdeModulePkgTokenSpaceGuid.PcdAcpiS3Enable is FALSE which
disables S3 support. Code is also currently not being written to
support S3 boot script replay and S3 is not tested. Modern physical
platforms rarely support S3 and S3 presents its own security
related concerns and maintenance overhead.

Since S3 is not needed, the lock box code which is currently only
used to store the S3 boot script is not needed.

As a consequence, the following S3, boot script, and lock box
related PEI and DXE modules are removed from QemuQ35Pkg:
- BootScriptExecutorDxe
- CpuS3DataDxe
- S3Resume2Pei
- S3SaveStateDxe
Drop S3 and lock box related library instances from QemuQ35Pkg
build.

The following library instances also do not need to be build given
S3 is not supported and are removed from the QemuQ35Pkg build:
- MdeModulePkg/Library/PiDxeS3BootScriptLib/DxeS3BootScriptLib.inf
- MdeModulePkg/Library/SmmLockBoxLib/SmmLockBoxDxeLib.inf
- MdeModulePkg/Library/SmmLockBoxLib/SmmLockBoxPeiLib.inf
- MdeModulePkg/Library/SmmLockBoxLib/SmmLockBoxSmmLib.inf
- MdeModulePkg/Library/SmmLockBoxLib/SmmLockBoxStandaloneMmLib.inf
- QemuPkg/Library/LockBoxLib/LockBoxBaseLib.inf
- QemuQ35Pkg/Library/QemuFwCfgS3Lib/PeiQemuFwCfgS3LibFwCfg.inf

QemuQ35Pkg: Remove S3 and Lock Box related code

Removes libraries and modules that support S3 and Lock Box since S3
is not supported by QemuQ35Pkg.

QemuQ35Pkg/Sec: Drop S3 and Lock Box support

Always follow the non-S3 flow to decompress the main FV and load
the PEI core from it during SEC startup.

QemuQ35Pkg/PlatformPei: Drop S3 and Lock Box support

Removes platform initialization logic for S3 and the lock box.

Notably, the number of MMRAM regions is reduced from two to one since
the first MMRAM range was previously a 4KB page used to hold S3
resume structures.

The amount of ACPI NVS reservation is reduced substantially since
areas like the following do not need to be preserved for S3 resume:

CPU AP stack buffers
Temp RAM stack and heap
GUIDed section extraction handlers
Reset vector initial page tables

The lock box storage buffer is also not allocated at all. Previously,
it was allocated as boot services data (not ACPI NVS) since S3 was
never enabled. In any case, that space is no longer allocated.

Asserts are added in places through key control flow to alert a
developer if S3 is detected as enabled when it should not be.

QemuQ35Pkg/AcpiPlatformDxe: Drop S3 and Lock Box support

Removes S3 boot script related code since S3 is no longer supported.

QemuQ35Pkg/SmmControl2Dxe: Drop S3 and Lock Box support

Removes S3 and boot script related code to focus the module on simply
installing Trigger() and Clear() functionality for the SMM
Control protocol.

QemuQ35Pkg/SmmAccess: Drop S3 and Lock Box support

Main change is to compensate for the single MMRAM range used now that
the S3 resume area is removed from MMRAM. A single range is now used
to cover all of TSEG.

QemuQ35Pkg.fdf: Remove assignment of Lock Box PCDs

Removes the following PCDs since the lock box is no longer supported.

gQemuPkgTokenSpaceGuid.PcdOvmfLockBoxStorageBase
gQemuPkgTokenSpaceGuid.PcdOvmfLockBoxStorageSize

QemuSbsaPkg: Use LockBoxLib null instance

The QemuPkg LockBoxLib is being removed. Used the null instance here
for libraries (like PerformanceLib) that link against a LockBoxLib
instance.

QemuPkg: Remove LockBoxLib

Not needed since S3 support is not used requiring the Lock Box.

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

How This Was Tested

Boot to EFI shell and perform cold and warm reset
Verify Standalone MM drivers are dispatched and execute successfully

Integration Instructions

N/A - Affects platform firmware operation

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

mu_tiano_platforms - v8.0.1

Published by github-actions[bot] 25 days ago

What's Changed

The XenHypercallLib instance in QemuQ35Pkg has the following LIBRARY_CLASS value in its [DEFINES] section:

  [Defines.IA32, Defines.X64]
    LIBRARY_CLASS                  = XenHypercallLib|...

  [Defines.ARM, Defines.AARCH64]
    LIBRARY_CLASS                  = XenHypercallLib

However, the library instance is specified in QemuQ35Pkg.dsc against the "Common" architecture as it is placed in the [LibraryClasses] section.

This raises the following warning during build:

  INFO - QemuQ35Pkg.dsc(...): warning:
    Platforms\QemuQ35Pkg\Library\XenHypercallLib\XenHypercallLib.inf
    does not support LIBRARY_CLASS XenHypercallLib

This is printed from the _ValidateLibraryClass() function in BaseTools/Source/Python/Workspace/DscBuildData.py because the library class is bound by architecture in the INF file so it does not support the "Common" architecture.

This change maps the library instance to the XenHypercallLib class per the defined architectures (IA32 and X64) in QemuQ35Pkg.dsc.

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

How This Was Tested

QemuQ35Pkg before and after the change

Integration Instructions

N/A

Update mu_basecore to top of release/202405 and supervisor repo to pair up with the updated override tags.

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

Tested on QEMU Q35 and booted to shell.

Integration Instructions

N/A

Add an explicit set for resolver to use version 2. This is required for virtual workspaces as the rust edition cannot be inferred by the compiler.

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

I validated that cargo make build, test, and coverage did not change.

Integration Instructions

N/A

🛠️ Submodule Updates

Introduces 8 new commits in Common/MU_TIANO.

Signed-off-by: Project Mu Bot [email protected]

Introduces 22 new commits in Features/CONFIG.

Signed-off-by: Project Mu Bot [email protected]

You can trigger a rebase of this PR by commenting @dependabot rebase.

You can trigger Dependabot actions by commenting on this PR:

@dependabot rebase will rebase this PR
@dependabot recreate will recreate this PR, overwriting any edits that have been made to it
@dependabot merge will merge this PR after your CI passes on it
@dependabot squash and merge will squash and merge this PR after your CI passes on it
@dependabot cancel merge will cancel a previously requested merge and block automerging
@dependabot reopen will reopen this PR if it is closed
@dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
@dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
@dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
@dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
@dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

Introduces 22 new commits in Common/MU_OEM_SAMPLE.

Signed-off-by: Project Mu Bot [email protected]

You can trigger a rebase of this PR by commenting @dependabot rebase.

You can trigger Dependabot actions by commenting on this PR:

@dependabot rebase will rebase this PR
@dependabot recreate will recreate this PR, overwriting any edits that have been made to it
@dependabot merge will merge this PR after your CI passes on it
@dependabot squash and merge will squash and merge this PR after your CI passes on it
@dependabot cancel merge will cancel a previously requested merge and block automerging
@dependabot reopen will reopen this PR if it is closed
@dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
@dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
@dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
@dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
@dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

Introduces 22 new commits in Features/MM_SUPV.

Signed-off-by: Project Mu Bot [email protected]

You can trigger a rebase of this PR by commenting @dependabot rebase.

You can trigger Dependabot actions by commenting on this PR:

@dependabot rebase will rebase this PR
@dependabot recreate will recreate this PR, overwriting any edits that have been made to it
@dependabot merge will merge this PR after your CI passes on it
@dependabot squash and merge will squash and merge this PR after your CI passes on it
@dependabot cancel merge will cancel a previously requested merge and block automerging
@dependabot reopen will reopen this PR if it is closed
@dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
@dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
@dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
@dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
@dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

You can trigger a rebase of this PR by commenting @dependabot rebase.

You can trigger Dependabot actions by commenting on this PR:

@dependabot rebase will rebase this PR
@dependabot recreate will recreate this PR, overwriting any edits that have been made to it
@dependabot merge will merge this PR after your CI passes on it
@dependabot squash and merge will squash and merge this PR after your CI passes on it
@dependabot cancel merge will cancel a previously requested merge and block automerging
@dependabot reopen will reopen this PR if it is closed
@dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
@dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
@dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
@dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
@dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

Full Changelog: https://github.com/microsoft/mu_tiano_platforms/compare/v8.0.0...v8.0.1

mu_tiano_platforms - v8.0.0 Latest Release

Published by github-actions[bot] 2 months ago

What's Changed

edk2-pytool-extensions from 0.27.10 to 0.27.11
edk2-pytool-library from 0.21.9 to 0.21.10

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

How This Was Tested

N/A

Integration Instructions

N/A

This change re-enables the memory map test app fix by picking up the latest MU_PLUS and MU_SILICON_ARM.

Resolves https://github.com/microsoft/mu_tiano_platforms/issues/1017.

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

Integration Instructions

N/A

  </blockquote>
  <hr>
</details>

Produces an RNG PPI that is used by shared crypto to abstract platform RNG support.

Updates Mu Basecore to v2023110010.0.1
Updates Mu Tiano Plus to v2023110001.1.0
Updates Mu MM Supervisor to v12.0.1 (for overrides)
Updates pytools for compat with Mu Basecore Rust plugin
Impacts functionality?
Impacts security?
Breaking change?
Includes tests?
Includes documentation?

How This Was Tested

CI
Verified RngPei is launched
Verified RNG PPI is installed
Verified Shared Crypto can use RNG PPI as expected
EFI Shell Boot

Integration Instructions

N/A

The DxePagingAuditTestApp was failing on all architectures because of a misimplementation. That was fixed in
https://github.com/microsoft/mu_plus/pull/528. This patch pulls in the newer mu_plus to get that change and drops the exemption from Q35 and SBSA.

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 paging audit test and it succeeds.

Integration Instructions

N/A.

  </blockquote>
  <hr>
</details>

Pipelines are currently failing since the exception has expired.

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

Integration Instructions

N/A

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

Description

This change is created to support building SBSA using CLANGPDB.

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 locally using QEMU SBSA platform and booted to UEFI shell.

Integration Instructions

N/A

  </blockquote>
  <hr>
</details>

Passes the architecture for platform builds through the build flags.

For compatibility with the v10.0.0 Mu DevOps release: https://github.com/microsoft/mu_devops/releases/tag/v10.0.0

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

How This Was Tested

Pipeline build

Integration Instructions

N/A

This change picks up the v7.0.1 release of QEMU binaries with the fix of QEMU ARM64 missing a VGA binary._

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 SBSA in Windows.

Integration Instructions

N/A

⚠️ Breaking Changes

The Project Mu submodules have moved to release/202405 and as the final step in qualifying that, we move mu_tiano_platforms to the new submodules. Below is the list of major changes for this repo to accommodate the new submodules:

SBSA Dropping ArmVirtPkg Dependency

QemuSbsaPkg was dependent on ArmVirtPkg for two libraries and a set of device tree PCDs. These device tree PCDs were moved to OvmfPkg in edk2, which we do not carry in Project Mu. In general, ArmVirtPkg allows dependencies on OvmfPkg, which makes it not a good candidate for Project Mu to depend on. The PCDs were moved to QemuSbsaPkg, QemuVirtMemInfoLib was copied there, and the HobLib was pointed to the mu_basecore version, as the ArmVirtPkg version was not needed, thus breaking the dependency on ArmVirtPkg. Some other ArmVirtPkg unused PCDs were dropped entirely.

MM_SUPV Updates

There were a lot of MM_SUPV updates in release/202405, which led to needing to copy an instance of SmmRelocationLib from OvmfPkg to QemuQ35Pkg (originates from https://github.com/tianocore/edk2/commit/3dfd64305b7f46da6f98ae15c87227b0fb55f726). There was debt from previous integrations where changes from MmFeatureLib were not picked up, which were required to work with the new supervisor.

SourceLevelDebugPkg Dropped

Project Mu no longer carries SourceLevelDebugPkg, so all references and hooks were dropped from the repo.

Non-NX Compat Images Allowed to be Loaded

Previously, on Windows built FW's, we would block loading non-NX compat binaries. This prevents booting most modern Linuxes as shim/grub do not have the NX_COMPAT flag set for released versions. This was changed to not block loading non-NX Compat images so that Linux can boot on Q35/SBSA on Windows.

SBSA Qemu run without SME and SVE

Similar to requiring SSE support on Q35, Windows and Linux have started using SVE instructions on ARM64. However, TF-A in the SP_MM configuration does not support SME or SVE instructions, so TF-A would crash when one of those instructions occurred. Qemu is now configured to run without support for SME and SVE so that the OSes do not attempt to use them. It was also discovered that Qemu 9.0.2 or newer is required for booting an OS on SBSA now, it is not clear what changed.

Cleanups and Old References Dropped

As part of debugging some of the changes needed for release/202405, some DSC cleanups were made.
MemoryOverrideBinLib was not carried forward to release/202405, so it was dropped from DSCs.
AdvLoggerAccessLibNull is used for VariableStandaloneMmLib.inf in QemuSbsaPkg now instead of the actual instance, as we are not using AdvLogger there.

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

Booted Q35 and SBSA to Windows and Linux

Integration Instructions

Qemu 9.0.2 is required for Linux builds to boot into an OS now, it is unclear exactly what is broken with older versions.

  </blockquote>
  <hr>
</details>

🐛 Bug Fixes

SSE 4.1 and 4.2 support was added to Q35 in order to support more recent Windows versions that require it. However, this broke recent Linux versions, which saw the 4.1 and 4.2 support and assumed other SSE support, which was not there. This adds all SSE instruction sets to Q35 to support both Linux and Windows.

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

Booted both a formerly failing Linux and Windows to confirm both boot.

Integration Instructions

N/A.

  </blockquote>
  <hr>
</details>

🔐 Security Impacting

The Project Mu submodules have moved to release/202405 and as the final step in qualifying that, we move mu_tiano_platforms to the new submodules. Below is the list of major changes for this repo to accommodate the new submodules:

SBSA Dropping ArmVirtPkg Dependency

QemuSbsaPkg was dependent on ArmVirtPkg for two libraries and a set of device tree PCDs. These device tree PCDs were moved to OvmfPkg in edk2, which we do not carry in Project Mu. In general, ArmVirtPkg allows dependencies on OvmfPkg, which makes it not a good candidate for Project Mu to depend on. The PCDs were moved to QemuSbsaPkg, QemuVirtMemInfoLib was copied there, and the HobLib was pointed to the mu_basecore version, as the ArmVirtPkg version was not needed, thus breaking the dependency on ArmVirtPkg. Some other ArmVirtPkg unused PCDs were dropped entirely.

MM_SUPV Updates

There were a lot of MM_SUPV updates in release/202405, which led to needing to copy an instance of SmmRelocationLib from OvmfPkg to QemuQ35Pkg (originates from https://github.com/tianocore/edk2/commit/3dfd64305b7f46da6f98ae15c87227b0fb55f726). There was debt from previous integrations where changes from MmFeatureLib were not picked up, which were required to work with the new supervisor.

SourceLevelDebugPkg Dropped

Project Mu no longer carries SourceLevelDebugPkg, so all references and hooks were dropped from the repo.

Non-NX Compat Images Allowed to be Loaded

Previously, on Windows built FW's, we would block loading non-NX compat binaries. This prevents booting most modern Linuxes as shim/grub do not have the NX_COMPAT flag set for released versions. This was changed to not block loading non-NX Compat images so that Linux can boot on Q35/SBSA on Windows.

SBSA Qemu run without SME and SVE

Similar to requiring SSE support on Q35, Windows and Linux have started using SVE instructions on ARM64. However, TF-A in the SP_MM configuration does not support SME or SVE instructions, so TF-A would crash when one of those instructions occurred. Qemu is now configured to run without support for SME and SVE so that the OSes do not attempt to use them. It was also discovered that Qemu 9.0.2 or newer is required for booting an OS on SBSA now, it is not clear what changed.

Cleanups and Old References Dropped

As part of debugging some of the changes needed for release/202405, some DSC cleanups were made.
MemoryOverrideBinLib was not carried forward to release/202405, so it was dropped from DSCs.
AdvLoggerAccessLibNull is used for VariableStandaloneMmLib.inf in QemuSbsaPkg now instead of the actual instance, as we are not using AdvLogger there.

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

Booted Q35 and SBSA to Windows and Linux

Integration Instructions

Qemu 9.0.2 is required for Linux builds to boot into an OS now, it is unclear exactly what is broken with older versions.

  </blockquote>
  <hr>
</details>

📖 Documentation Updates

Updates the build instructions for using QEMU on windows and Linux to accurately specify that QEMU is provided automatically on Windows but should manually be downloaded on Linux. Additionally specifies that QEMU 9.0.2 or greater is necessary to boot the operating system on Linux.

Closes #1012

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>

🛠️ Submodule Updates

Introduces 16 new commits in Features/DFCI.

Signed-off-by: Project Mu Bot [email protected]

You can trigger a rebase of this PR by commenting @dependabot rebase.

You can trigger Dependabot actions by commenting on this PR:

@dependabot rebase will rebase this PR
@dependabot recreate will recreate this PR, overwriting any edits that have been made to it
@dependabot merge will merge this PR after your CI passes on it
@dependabot squash and merge will squash and merge this PR after your CI passes on it
@dependabot cancel merge will cancel a previously requested merge and block automerging
@dependabot reopen will reopen this PR if it is closed
@dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
@dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
@dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
@dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
@dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

Introduces 9 new commits in Common/MU_TIANO.

Signed-off-by: Project Mu Bot [email protected]

You can trigger a rebase of this PR by commenting @dependabot rebase.

You can trigger Dependabot actions by commenting on this PR:

@dependabot rebase will rebase this PR
@dependabot recreate will recreate this PR, overwriting any edits that have been made to it
@dependabot merge will merge this PR after your CI passes on it
@dependabot squash and merge will squash and merge this PR after your CI passes on it
@dependabot cancel merge will cancel a previously requested merge and block automerging
@dependabot reopen will reopen this PR if it is closed
@dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
@dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
@dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
@dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
@dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

Introduces 4 new commits in Features/CONFIG.

Signed-off-by: Project Mu Bot [email protected]

Introduces 1 new commits in Common/MU.

Signed-off-by: Project Mu Bot [email protected]

You can trigger a rebase of this PR by commenting @dependabot rebase.

You can trigger Dependabot actions by commenting on this PR:

@dependabot rebase will rebase this PR
@dependabot recreate will recreate this PR, overwriting any edits that have been made to it
@dependabot merge will merge this PR after your CI passes on it
@dependabot squash and merge will squash and merge this PR after your CI passes on it
@dependabot cancel merge will cancel a previously requested merge and block automerging
@dependabot reopen will reopen this PR if it is closed
@dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
@dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
@dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
@dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
@dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

Introduces 13 new commits in Features/CONFIG.

Signed-off-by: Project Mu Bot [email protected]

You can trigger a rebase of this PR by commenting @dependabot rebase.

You can trigger Dependabot actions by commenting on this PR:

@dependabot rebase will rebase this PR
@dependabot recreate will recreate this PR, overwriting any edits that have been made to it
@dependabot merge will merge this PR after your CI passes on it
@dependabot squash and merge will squash and merge this PR after your CI passes on it
@dependabot cancel merge will cancel a previously requested merge and block automerging
@dependabot reopen will reopen this PR if it is closed
@dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
@dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
@dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
@dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
@dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

Introduces 6 new commits in Silicon/Arm/MU_TIANO.

Signed-off-by: Project Mu Bot [email protected]

Introduces 8 new commits in Common/MU.

Signed-off-by: Project Mu Bot [email protected]

You can trigger a rebase of this PR by commenting @dependabot rebase.

You can trigger Dependabot actions by commenting on this PR:

@dependabot rebase will rebase this PR
@dependabot recreate will recreate this PR, overwriting any edits that have been made to it
@dependabot merge will merge this PR after your CI passes on it
@dependabot squash and merge will squash and merge this PR after your CI passes on it
@dependabot cancel merge will cancel a previously requested merge and block automerging
@dependabot reopen will reopen this PR if it is closed
@dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
@dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
@dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
@dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
@dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

Introduces 9 new commits in Features/CONFIG.

Signed-off-by: Project Mu Bot [email protected]

Introduces 21 new commits in MU_BASECORE.

Signed-off-by: Project Mu Bot [email protected]

Introduces 3 new commits in Common/MU_TIANO.

Signed-off-by: Project Mu Bot [email protected]

You can trigger a rebase of this PR by commenting @dependabot rebase.

You can trigger Dependabot actions by commenting on this PR:

@dependabot rebase will rebase this PR
@dependabot recreate will recreate this PR, overwriting any edits that have been made to it
@dependabot merge will merge this PR after your CI passes on it
@dependabot squash and merge will squash and merge this PR after your CI passes on it
@dependabot cancel merge will cancel a previously requested merge and block automerging
@dependabot reopen will reopen this PR if it is closed
@dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
@dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
@dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
@dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
@dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

Introduces 2 new commits in Common/MU_TIANO.

Signed-off-by: Project Mu Bot [email protected]

Introduces 18 new commits in Features/DFCI.

Signed-off-by: Project Mu Bot [email protected]

Introduces 17 new commits in Common/MU_TIANO.

Signed-off-by: Project Mu Bot [email protected]

Introduces 2 new commits in MU_BASECORE.

Signed-off-by: Project Mu Bot [email protected]

Full Changelog: https://github.com/microsoft/mu_tiano_platforms/compare/v7.0.1...v8.0.0

mu_tiano_platforms - v7.0.0

Published by github-actions[bot] 6 months ago

What's Changed

v9.0.0 fixed a few known issues blocking us from upgrading to QEMU of later than v7.2.0.

This change is made to upgrade the default QEMU to v9.0.0 to intake the latest 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

This change is tested locally on Windows and WSL environment.

Integration Instructions

Existing clones will need to perform PlatformBuild.py --update to download the latest version of QEMU.

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

Description

The TF-A v2.10 updated the footprint of images drastically and supported extra CPU models, causing the existing flash map not able to suit the BL1.

This change updated the flash map and improved the patching routine in post-build to fail the build next time.

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 functional on QEMU SBSA with max CPU model.

Integration Instructions

N/A

  </blockquote>
  <hr>
</details>

The DXE paging audit test app was updated to check for Enhanced Memory
Protection compliance. Project Mu is currently being updated to pass to
pass the remaining two checks (RP on free memory and RP on GCD
nonexistent regions). This PR updates the exemption date for
SBSA and Q35 so test failures don't block CI gates.

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 CI pipelines

Integration Instructions

N/A

Removes the qemu external dependency for linux and instead uses the qemu that is directly installed on the system.

Note: I've opted to keep the github action that produces the linux external dependency in-case we opt to switch back to using it, or as an example to anyone that needs to build it locally.

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>

Ingests the MU_FEATURE_DEBUGGER repo and enabled the software debugger for both Q35 and SBSA through the build flag BLD_*_DEBUGGER_ENABLED=TRUE to debug over the serial port specified by the runtime flag SERIAL_PORT=####.

Creates a debug transport for Q35 that wraps the IO port serial port lib implementation but swaps the UART port address before calling to allow the debugger to run on a separate port then the debug output.

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

How This Was Tested

Locally tested on both SBSA and Q35.

Integration Instructions

N/A

  </blockquote>
  <hr>
</details>

⚠️ Breaking Changes

This change updates the MU_BASECORE, MM_SUPV and MU_PLUS submodules and fixes integration errors:

Submodule	Version
MU_BASECORE	v2023110004.0.0
MM_SUPV	v11.0.1
MU_PLUS	v2023110000.0.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

This was tested on QEMU Q35 and SBS, both platforms booted to UEFI shell.

Integration Instructions

N/A

🛠️ Submodule Updates

You can trigger a rebase of this PR by commenting @dependabot rebase.

You can trigger Dependabot actions by commenting on this PR:

@dependabot rebase will rebase this PR
@dependabot recreate will recreate this PR, overwriting any edits that have been made to it
@dependabot merge will merge this PR after your CI passes on it
@dependabot squash and merge will squash and merge this PR after your CI passes on it
@dependabot cancel merge will cancel a previously requested merge and block automerging
@dependabot reopen will reopen this PR if it is closed
@dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
@dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
@dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
@dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
@dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

Introduces 1 new commits in MU_BASECORE.

Signed-off-by: Project Mu Bot [email protected]

Introduces 11 new commits in MU_BASECORE.

Signed-off-by: Project Mu Bot [email protected]

You can trigger a rebase of this PR by commenting @dependabot rebase.

You can trigger Dependabot actions by commenting on this PR:

@dependabot rebase will rebase this PR
@dependabot recreate will recreate this PR, overwriting any edits that have been made to it
@dependabot merge will merge this PR after your CI passes on it
@dependabot squash and merge will squash and merge this PR after your CI passes on it
@dependabot cancel merge will cancel a previously requested merge and block automerging
@dependabot reopen will reopen this PR if it is closed
@dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
@dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
@dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
@dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
@dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

Full Changelog: https://github.com/microsoft/mu_tiano_platforms/compare/v6.0.0...v7.0.0

mu_tiano_platforms - v6.0.0

Published by github-actions[bot] 6 months ago

What's Changed

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

Description

Current QEMU platforms do not support needed cmdlets for system status inspection.

This change added a few command options to the UEFI shell to further support necessary tests in the future.

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 and SBSA in UEFI shell environments.

Integration Instructions

N/A

  </blockquote>
  <hr>
</details>

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

Description

The fix is enlightened by the original QEMU thread here: https://gitlab.com/qemu-project/qemu/-/issues/1674.

The change fixed the garbled command prompt after returning from QEMU v8+ on Windows platforms.

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 v9.0.0-rc1 on Windows and confirmed it fixes the command prompt after returning from QEMU runner.

Integration Instructions

N/A

  </blockquote>
  <hr>
</details>

the UEFI windbg Extension has moved to https://github.com/microsoft/mu_feature_debugger.

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

How This Was Tested

N/A

Integration Instructions

N/A

  </blockquote>
  <hr>
</details>

The flattened device tree blob is placed in memory at the address specified by PcdDeviceTreeInitialBaseAddress. This PR creates a memory allocation HOB entry for the pages spanning the start and end of the FDT so it cannot be allocated during boot.

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

How This Was Tested

Tested by running SBSA and reviewing the memory allocation HOBs

Integration Instructions

N/A

  </blockquote>
  <hr>
</details>

The PDE.dat file is no longer produced by the paging audit, so the get_file call will fail.

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

How This Was Tested

Tested by running the paging audit on Q35 and SBSA

Integration Instructions

N/A

Windows requires both the SSE4.1 and SSE4.2 instructions to boot. Add these to the Q35 QEMU cmdline so that the VM has these available.

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

Booted a recent Windows edition, confirmed it does not boot without this and does boot with this.

Integration Instructions

Ensure this commit is pulled in to boot recent versions of Windows.

  </blockquote>
  <hr>
</details>

Update the qemu extdep to the latest mu_tiano_platforms release. This downgrades qemu to a more reliable version - 7.2.0 and also adds the following two roms:

efi-e1000e.rom
efi-virtio.rom
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

see #880

Integration Instructions

N/A

  </blockquote>
  <hr>
</details>

⚠️ Breaking Changes

The MU_BASECORE update changed the hash used in MmSupervisorPkg. This change updated both submodules to fix the auto-PRs build break.

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

Q35 platform is tested with QEMU 9.0.0-rc1 on Windows and booted to UEFI shell.

Integration Instructions

N/A

🔐 Security Impacting

Current platform configuration sets up the stack cookie library for all Standalone MM modules to use static stack cookie, which is unnecessary as long as the RNG works as expected.

Similarly, on ARM64 platform, the PEIM modules can use dynamic stack cookie as well. The Q35 PEIMs are left as they are considering XIP scenarios on x86.

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 platforms and confirmed booting to UEFI shell.

Integration Instructions

N/A

🛠️ Submodule Updates

Introduces 1 new commits in MU_BASECORE.

Signed-off-by: Project Mu Bot [email protected]

Introduces 3 new commits in Common/MU.

Signed-off-by: Project Mu Bot [email protected]

Introduces 3 new commits in MU_BASECORE.

Signed-off-by: Project Mu Bot [email protected]

Introduces 3 new commits in MU_BASECORE.

Signed-off-by: Project Mu Bot [email protected]

Introduces 4 new commits in Common/MU_TIANO.

Signed-off-by: Project Mu Bot [email protected]

Full Changelog: https://github.com/microsoft/mu_tiano_platforms/compare/v5.1.2...v6.0.0

mu_tiano_platforms - v5.1.2

Published by github-actions[bot] 7 months ago

What's Changed

Updates release pipeline for the qemu binary to release qemu v7.2.0 as a external dependency and to also provide the following roms:

efi-e1000e.rom
efi-virtio.rom
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 Terminal was not in an invalid state after exiting qemu, and that the above roms were successfully found at runtime.

Integration Instructions

Perform a release and update the qemu external dependency inside mu_tiano_platforms

  </blockquote>
  <hr>
</details>

Full Changelog: https://github.com/microsoft/mu_tiano_platforms/compare/v5.1.1...v5.1.2

mu_tiano_platforms - v5.1.1

Published by github-actions[bot] 8 months ago

What's Changed

The e1000 NIC is useful for OS debugging and general "real hardware"-like network access.

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

How This Was Tested

N/A

Integration Instructions

N/A

  </blockquote>
  <hr>
</details>

The Instruction Set Extension, specifically SSE4.2, is standard and used by Windows. This adds it to the default QEMU configuration for Q35.

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

How This Was Tested

Tested local Windows boot.

Integration Instructions

N/A

  </blockquote>
  <hr>
</details>

There's a large slowdown during GCD sync when the syncing logic debug dumps the GCD map thousands of times. I updated the syncing logic to skip the dump process if the GCD debug verbosity level is not set. Checking the verbosity is done via a call to DebugPrintLevelEnabled() in DebugLib which checks the fixed debug print PCD.

This PR sets the FixedAtBuild PCD to be the same as the PatchableInModule PCD so the map dump function is skipped.

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

How This Was Tested

Tested by booting SBSA and observing the improved boot time.

Integration Instructions

N/A

  </blockquote>
  <hr>
</details>

Use an external dependency for qemu rather than relying on it being installed by the user.

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

Ensured Boot to shell and Boot to windows using the Windows and Linux qemu external dependencies. Verified TPM Replay functionality continued to work as expected.

Integration Instructions

N/A

  </blockquote>
  <hr>
</details>

🔐 Security Impacting

The StackCheckLib instances have been updated in all subrepos. Thi PR updates all subrepos and the StackCheckLib instances for SBSA and Q35.

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>

🛠️ Submodule Updates

Introduces 5 new commits in MU_BASECORE.

Signed-off-by: Project Mu Bot [email protected]

Introduces 1 new commits in MU_BASECORE.

Signed-off-by: Project Mu Bot [email protected]

Introduces 1 new commits in Common/MU_TIANO.

Signed-off-by: Project Mu Bot [email protected]

Introduces 7 new commits in Features/CONFIG.

Signed-off-by: Project Mu Bot [email protected]

Full Changelog: https://github.com/microsoft/mu_tiano_platforms/compare/v5.1.0...v5.1.1

mu_tiano_platforms - v5.1.0

Published by github-actions[bot] 8 months ago

What's Changed

Add a new workflow that will build and prepare qemu binaries for both Windows and Linux. This workflow has three triggers:

A pull request to the main branch, which will only trigger when either the workflow itself, or the qemu version file is updated. This workflow will upload the binaries as an artifact to the workflow.
A release, which will upload the binaries as an artifact to the associated release
A manual trigger, which allows for testing the workflow on a custom branch. This will upload the binaries as an artifact to the workflow.

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

A release was performed using this github action on a personal branch (v0.1.9), and was used as an external dependency on a mu_tiano_platforms Draft PR, which is passing, and will be merged once this PR has been merged and a release has been executed.

Integration Instructions

N/A

  </blockquote>
  <hr>
</details>

Links the non-NULL instance of DxeHash2CryptoLib to QemuQ35Pkg and
QemuSbsaPkg so the Hash 2 Service Binding protocol is installed.

This can be used as a dynamic hashing interface by other modules.

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 Hash 2 Service Binding protocol is installed by MuCryptoDxe.

Integration Instructions

N/A

🚀 Features & ✨ Enhancements

Updates QemuQ35Pkg to use the RT DXE shared crypto driver and use
the RuntimeDxeCryptLib instance for RT DXE drivers.
Removes a binary VariableRuntimeDxe EFI image checked in (with
crypto statically linked) that was an intermediate solution while
RT DXE shared crypto was developed.
Updates paths that refer to shared crypto use the build variable
SHARED_CRYPTO_PATH that is set by the ext dep. This allows the
path to resolve to the ext dep regardless of where it is placed
in the code tree.
960ebde updated QemuQ35Pkg to resolve DSC parser warnings for a
suspicious expression comparison warning. This change also fixes
the warning for QemuSbsaPkg.

Updates some Mu submodules to their latest releases. The MU_BASECORE
update is required for these changes.

MU_BASECORE: v2023110001.0.1 (76b62eb)
- CryptoPkg/RuntimeDxeCryptLib: Make globals static
- BaseTools/GenFds: Resolve absolute workspace INF paths
MU_BASECORE: v2023110001.0.0 (0dd0d48)
- CryptoPkg/Driver: Remove directory
- .pytool/Plugin/DscCompleteCheck: Allow git ignore syntax
- pip: update edk2-pytool-library requirement from ~=0.21.2 to ~=0.21.3
- CryptoPkg: Add RT DXE shared crypto library instance
- Remove static initialization of gMmst for MM Core Lib
- Repo File Sync: Improve inline documentation in CodeQL workflow
- pip: update edk2-pytool-library requirement from ~=0.20.0 to ~=0.21.2
- Repo File Sync: synced file(s) with microsoft/mu_devops
Common/MU: v2023110000.0.1 (c3b9b01)
- pip: bump edk2-pytool-library from 0.21.2 to 0.21.3
- remove edk2-basetools
- Remove AdvancedLogger MmCoreArm dependence on global variables.
- Switch MmCoreArm advanced logger to use updated MMU functions
- Repo File Sync: Improve inline documentation in CodeQL workflow
- pip: bump edk2-pytool-library from 0.20.0 to 0.21.2
- Repo File Sync: synced file(s) with microsoft/mu_devops
Common/MU_TIANO: v2023110000.0.2 (f7e2628)
- pip: bump edk2-pytool-library from 0.21.2 to 0.21.3
- remove edk2-basetools

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

QemuQ35Pkg SMM and SMM_DISABLED build and boot to EFI shell and Windows OS
QemuSbsaPkg boot to EFI shell

Integration Instructions

N/A - Affects crypto used in this repo.

🔐 Security Impacting

Updates QemuQ35Pkg to use the RT DXE shared crypto driver and use
the RuntimeDxeCryptLib instance for RT DXE drivers.
Removes a binary VariableRuntimeDxe EFI image checked in (with
crypto statically linked) that was an intermediate solution while
RT DXE shared crypto was developed.
Updates paths that refer to shared crypto use the build variable
SHARED_CRYPTO_PATH that is set by the ext dep. This allows the
path to resolve to the ext dep regardless of where it is placed
in the code tree.
960ebde updated QemuQ35Pkg to resolve DSC parser warnings for a
suspicious expression comparison warning. This change also fixes
the warning for QemuSbsaPkg.

Updates some Mu submodules to their latest releases. The MU_BASECORE
update is required for these changes.

MU_BASECORE: v2023110001.0.1 (76b62eb)
- CryptoPkg/RuntimeDxeCryptLib: Make globals static
- BaseTools/GenFds: Resolve absolute workspace INF paths
MU_BASECORE: v2023110001.0.0 (0dd0d48)
- CryptoPkg/Driver: Remove directory
- .pytool/Plugin/DscCompleteCheck: Allow git ignore syntax
- pip: update edk2-pytool-library requirement from ~=0.21.2 to ~=0.21.3
- CryptoPkg: Add RT DXE shared crypto library instance
- Remove static initialization of gMmst for MM Core Lib
- Repo File Sync: Improve inline documentation in CodeQL workflow
- pip: update edk2-pytool-library requirement from ~=0.20.0 to ~=0.21.2
- Repo File Sync: synced file(s) with microsoft/mu_devops
Common/MU: v2023110000.0.1 (c3b9b01)
- pip: bump edk2-pytool-library from 0.21.2 to 0.21.3
- remove edk2-basetools
- Remove AdvancedLogger MmCoreArm dependence on global variables.
- Switch MmCoreArm advanced logger to use updated MMU functions
- Repo File Sync: Improve inline documentation in CodeQL workflow
- pip: bump edk2-pytool-library from 0.20.0 to 0.21.2
- Repo File Sync: synced file(s) with microsoft/mu_devops
Common/MU_TIANO: v2023110000.0.2 (f7e2628)
- pip: bump edk2-pytool-library from 0.21.2 to 0.21.3
- remove edk2-basetools

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

QemuQ35Pkg SMM and SMM_DISABLED build and boot to EFI shell and Windows OS
QemuSbsaPkg boot to EFI shell

Integration Instructions

N/A - Affects crypto used in this repo.

Full Changelog: https://github.com/microsoft/mu_tiano_platforms/compare/v5.0.0...v5.1.0

mu_tiano_platforms - v5.0.0

Published by github-actions[bot] 8 months ago

What's Changed

📢 This release moves to Mu 202311 branches.

defines SMM_CRYPTO_ARCH in QemuQ35Pkg.dsc to resolve parser warnings regarding suspicious expressions that occur because $(SMM_CRYPTO_ARCH) is not replaced with a value (because a value is not defined).

Prints multiple of the following parser warning:

INFO - Parser...
INFO - c:\src\mu_tiano_platforms\MU_BASECORE\CryptoPkg\Driver\Bin\Crypto.pcd.TINY_SHA.inc.dsc(112): warning: Suspicious expression: == Comparison between Operand of string type and Boolean/Number Type always return False.
INFO -     !if $(SMM_CRYPTO_ARCH) == X64

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

Built with and without SMM_CRYPTO_ARCH being defined, and verified the parser warning was removed when it was defined.

Integration Instructions

N/A

Updates edk2-pytool-extensions to v0.27.0 and edk2-pytool-library to v0.20.0, which moves Edk2DB away from using sqlite3 directly, instead using a ORM to manage the database schema and querying functionlity. Applies the necessary changes to convert Edk2DB querying from raw SQL queries to sqlalchemy (ORM) queries.

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

PlatformTest for QemuQ35Pkg and QemuSbsaPkg continues to work, and produces the same information.

Integration Instructions

N/A

The DXE paging audit test app was updated to check for Enhanced Memory Protection compliance. Project Mu is currently being updated to pass to the currently failing checks. This PR updates the exemption date for SBSA and Q35 so test failures don't block CI gates.

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

Adds commits that only applied Uncrustify formatting or 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.

Commits cover OvmfPkg. Although the package no longer exists, it is still in
the history of many files in derived 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

git blame

Integration Instructions

N/A

⚠️ Breaking Changes

This change updates all submodules to point to 202311 based MU submodules.

Code change specifically applicable to QEMU Q35:
https://github.com/tianocore/edk2/commit/dea6002d6e612ee3066fc755b5ad47558d84d645
https://github.com/tianocore/edk2/commit/24e6daa2bcfb64bbe871f76d8e9774d67f247717
https://github.com/tianocore/edk2/commit/12d3d60f51550a7166f8f3e758866b53b9a88e73

Specifically, the submodules are updated to:

Submodule	Version
MU_BASECORE	v2023110000.0.1
MU_PLUS	v2023110000.0.0
MU_OEM_SAMPLE	v2023110000.0.0
MU_TIANO_PLUS	v2023110000.0.0
MM_SUPV	v9.0.0
MU_SILICON_ARM	v2023110000.0.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

This branch was tested on QEMU Q35 and verified bootable to UEFI shell and Windows OS.

Integration Instructions

N/A

🚀 Features & ✨ Enhancements

Moving forward the OpenSSL submodule will no longer be present in
CryptoPkg and the only option to integrate crypto into the platform
will be shared crypto (via the binary crypto ext dep).

The option to enable/disable shared crypto is removed since disabling
it is no longer an option.

Notes:

Integrates newly available AARCH64 PEI and Standalone MM shared crypto binaries.
The BaseCryptLibUnitTest EFI shell test is removed since it depends on
functions not present in the PPI/Protocol instances of BaseCryptLib and
the crypto releases should have the tests run before the release is made.
- An issue to track this is here: https://github.com/microsoft/mu_crypto_release/issues/56
Runtime DXE crypto is not currently available. It is only needed at this time for
the non-SMM instance of QemuQ35Pkg (VariableRuntimeDxe). Since this is not the
primary target for QemuQ35Pkg, the Runtime DXE binary will be updated in the
future to unblock Mu Basecore updates in Mu Tiano Platforms.
- An issue to track that is here: https://github.com/microsoft/mu_crypto_release/issues/55

Updates these submodules to the following release points:

MU_BASECORE: v2023020013.1.0
Common/MU_TIANO: v2023020000.2.0
Features/MM_SUPV: v8.1.8

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

QemuQ35Pkg and QemuSbsaPkg CI build and boot.

Integration Instructions

These changes only affect the mu_tiano_platforms.

Updates Mu Basecore to include the Standalone MM shared crypto binaries
via the external dependency in CryptoPkg. Updates QemuQ35Pkg to use the
Standalone MM crypto binary.

QemuSbsaPkg is not modified as a Standalone MM binary is currently not
published for AARCH64.

Bump MU_BASECORE from 2023020010.0.0 to 2023020011.0.0

Introduces 9 new commits in
MU_BASECORE.

In particular, this release updates the shared crypto binary external
dependency in CryptoPkg to include the Standalone MM binaries.
QemuQ35Pkg: Use the Standalone MM shared crypto driver

Updates Standalone MM modules to use the BaseCryptLibOnProtocolPpi/StandaloneMmCryptLib.inf
instance of BaseCryptLib. This will allow those modules to use the gEdkiiSmmCryptoProtocolGuid
protocol instance published by the Standalone MM crypto binary.

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

QemuQ35Pkg local build and boot to EFI shell and Windows OS

Integration Instructions

N/A - Only impacts the QEMU Q35 platform.

🔐 Security Impacting

Moving forward the OpenSSL submodule will no longer be present in
CryptoPkg and the only option to integrate crypto into the platform
will be shared crypto (via the binary crypto ext dep).

The option to enable/disable shared crypto is removed since disabling
it is no longer an option.

Notes:

Integrates newly available AARCH64 PEI and Standalone MM shared crypto binaries.
The BaseCryptLibUnitTest EFI shell test is removed since it depends on
functions not present in the PPI/Protocol instances of BaseCryptLib and
the crypto releases should have the tests run before the release is made.
- An issue to track this is here: https://github.com/microsoft/mu_crypto_release/issues/56
Runtime DXE crypto is not currently available. It is only needed at this time for
the non-SMM instance of QemuQ35Pkg (VariableRuntimeDxe). Since this is not the
primary target for QemuQ35Pkg, the Runtime DXE binary will be updated in the
future to unblock Mu Basecore updates in Mu Tiano Platforms.
- An issue to track that is here: https://github.com/microsoft/mu_crypto_release/issues/55

Updates these submodules to the following release points:

MU_BASECORE: v2023020013.1.0
Common/MU_TIANO: v2023020000.2.0
Features/MM_SUPV: v8.1.8

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

QemuQ35Pkg and QemuSbsaPkg CI build and boot.

Integration Instructions

These changes only affect the mu_tiano_platforms.

Updates Mu Basecore to include the Standalone MM shared crypto binaries
via the external dependency in CryptoPkg. Updates QemuQ35Pkg to use the
Standalone MM crypto binary.

QemuSbsaPkg is not modified as a Standalone MM binary is currently not
published for AARCH64.

Bump MU_BASECORE from 2023020010.0.0 to 2023020011.0.0

Introduces 9 new commits in
MU_BASECORE.

In particular, this release updates the shared crypto binary external
dependency in CryptoPkg to include the Standalone MM binaries.
QemuQ35Pkg: Use the Standalone MM shared crypto driver

Updates Standalone MM modules to use the BaseCryptLibOnProtocolPpi/StandaloneMmCryptLib.inf
instance of BaseCryptLib. This will allow those modules to use the gEdkiiSmmCryptoProtocolGuid
protocol instance published by the Standalone MM crypto binary.

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

QemuQ35Pkg local build and boot to EFI shell and Windows OS

Integration Instructions

N/A - Only impacts the QEMU Q35 platform.

📖 Documentation Updates

Add section to debugging.md about using GDB for QEMU debugger and move to common debugging file.

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

How This Was Tested

N/A

Integration Instructions

N/A

🛠️ Submodule Updates

Introduces 4 new commits in Common/MU_TIANO.

Signed-off-by: Project Mu Bot [email protected]

Introduces 20 new commits in Features/CONFIG.

Signed-off-by: Project Mu Bot [email protected]

Introduces 16 new commits in Features/DFCI.

Signed-off-by: Project Mu Bot [email protected]

Introduces 1 new commits in Common/MU_TIANO.

Signed-off-by: Project Mu Bot [email protected]

Introduces 7 new commits in Common/MU.

Signed-off-by: Project Mu Bot [email protected]

Introduces 10 new commits in Common/MU_TIANO.

Signed-off-by: Project Mu Bot [email protected]

Introduces 8 new commits in Common/MU.

Signed-off-by: Project Mu Bot [email protected]

Introduces 12 new commits in Common/MU.

Signed-off-by: Project Mu Bot [email protected]

Introduces 8 new commits in MU_BASECORE.

Signed-off-by: Project Mu Bot [email protected]

Full Changelog: https://github.com/microsoft/mu_tiano_platforms/compare/v4.7.3...v5.0.0

mu_tiano_platforms - v4.7.1

Published by github-actions[bot] 11 months ago

What's Changed

Adds a PlatformTest.py per platform package which:

self verifies the platform host-based unit test dsc is up to date (no new hosted-based test INFs have been added locally or from a submodule that test source used by the platform).
Compiles the host-based unit tests.
Executes the host-based unit tests.
Optionally generates code coverage data.

Adds additional pipeline jobs to run the host-based tests and generate code coverage information.

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

Integration Instructions

CI

By default, the dev profile is used. The default build settings for the dev profile are documented here:
https://doc.rust-lang.org/cargo/reference/profiles.html#dev

Unmodified dev profile settings result in extraordinarily large binaries relative to UEFI FW. This especially impacts DEBUG builds which already have less optimized C code resulting in overall greater space occupation.

Without a change, the binaries are simply too large and will continue to push the limits of firmware volumes (on a real system constrained by flash size) over time.

Therefore, the below setting enables optimization level 3 (all optimizations) that is used by the release profile by default. This greatly reduces the overall binary size. [profile.dev.package."*"] is specified to apply the opt-level for all dependencies (but not a workspace member). This emphasizes debuggability of workspace code but optimizes dependencies. An individual dependency can be overridden by specifying the named package instead of "*". For example:

[profile.dev.package.foo]
opt-level = 0

That will likely allow the overall build to still fit in the FV, since other code is still optimized, but remove optimizations from an individual package that needs to be debugged.

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 build size of several config combinations (including the chosen one).
- ```
[profile.dev]
opt-level = 'z'
```
  - DXE FV: 11643648 (0xb1ab00) used (size opt of all packages)
- ```
[profile.dev.package."*"]
opt-level = 'z'
```
  - DXE FV: 12365056 (0xbcad00) used (size opt of dependencies)
- ```
[profile.dev.package."*"]
opt-level = 3
```
  - DXE FV: 12431104 (0xbdaf00) used (level 3 opt of dependencies)

Integration Instructions

N/A - Affects packages built in this workspace

🐛 Bug Fixes

Currently, FlashRomImage() in PlatformBuild.py checks if the
virtual drive file (VirtualDrive.img) exists. If so, make_drive()
is not called which is the only function that currently sets the
MTOOLSRC environment variable to the mtool.conf file path which
is consumed by mtools.

Typical mtool.conf file contents as used in VirtualDriveManager:

  drive+ a:
    file="/w/m/Build/QemuSbsaPkg/DEBUG_GCC5/VirtualDrive.img" exclusive

This means if VirtualDrive.img already exists (i.e. on an
incremental Linux build with the VIRTUAL_DRIVE parameter present),
the MTOOLSRC variable is not available to mtools resulting in the
following error:

  INFO - Can't open /dev/fd0: No such file or directory
  INFO - Cannot initialize 'A:'
  INFO - Bad target a:

This change sets MTOOLSRC on incremental builds so the existing
virtual drive can be used.

A separate commit also removes trailing whitespace from VirtualDriveManager.py
since there is a lot throughout the 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

With VIRTUAL_DRIVE parameter given:
- Linux build with VirtualDrive.img missing (clean build)
- Linux build with VirtualDrive.img present (incremental build)
  - Previously failed
- Linux build with VirtualDrive.img present and mtool.conf missing
  - Unexpected state but possible

Integration Instructions

N/A

🛠️ Submodule Updates

Introduces 5 new commits in Silicon/Arm/MU_TIANO.

Signed-off-by: Project Mu Bot [email protected]

Introduces 1 new commits in MU_BASECORE.

Signed-off-by: Project Mu Bot [email protected]

Introduces 4 new commits in MU_BASECORE.

Signed-off-by: Project Mu Bot [email protected]

Introduces 3 new commits in Common/MU.

Signed-off-by: Project Mu Bot [email protected]

Introduces 10 new commits in Silicon/Arm/MU_TIANO.

Signed-off-by: Project Mu Bot [email protected]

Introduces 2 new commits in Common/MU.

Signed-off-by: Project Mu Bot [email protected]

Introduces 5 new commits in Common/MU.

Signed-off-by: Project Mu Bot [email protected]

Introduces 2 new commits in MU_BASECORE.

Signed-off-by: Project Mu Bot [email protected]

Introduces 2 new commits in Common/MU.

Signed-off-by: Project Mu Bot [email protected]

Introduces 4 new commits in MU_BASECORE.

Signed-off-by: Project Mu Bot [email protected]

Full Changelog: https://github.com/microsoft/mu_tiano_platforms/compare/v4.7.0...v4.7.1

mu_tiano_platforms - v4.6.1

Published by github-actions[bot] 12 months ago

What's Changed

Add this scope so Rust related CI plugins run since the packages are
already building Rust 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

Verified CI builds with the scope set

Integration Instructions

N/A - Affects plugins run in this repo

🛠️ Submodule Updates

Introduces 3 new commits in Common/MU.

Signed-off-by: Project Mu Bot [email protected]

Introduces 4 new commits in MU_BASECORE.

Signed-off-by: Project Mu Bot [email protected]

Introduces 2 new commits in MU_BASECORE.

Signed-off-by: Project Mu Bot [email protected]

Full Changelog: https://github.com/microsoft/mu_tiano_platforms/compare/v4.6.0...v4.6.1

mu_tiano_platforms - v4.6.0

Published by github-actions[bot] 12 months ago

What's Changed

Note: Mouse support on Q35 was found to be broken (based on local testing) for
a while, covering at least several releases. It is verified to be functional in this release
(using the Rust based HID driver stack).

🚀 Features & ✨ Enhancements

QemuQ35Pkg: Update memory type information defaults

Updates the default values for PcdMemoryTypeEfiACPIReclaimMemory
and PcdMemoryTypeEfiReservedMemoryType to prevent a runtime
adjustment to the memory bucket sizes.

Based on the values calculated including buffer:

  Memory  Previous  Current   Minimum    Next
   Type    Pages     Pages     Pages     Pages
  ======  ========  ========  ========  =======
    0A    00000080  00000026  00000000  00000080
    09    00000010  00000012  00000000  00000016*
    00    00000080  0000040D  00000000  00000510*
    05    00000100  000000AF  00000000  00000100
    06    00000100  00000100  00000000  00000100
  Memory Type Information settings change.

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

QemuQ35Pkg build and boot

Integration Instructions

N/A

Per integration instructions in https://github.com/microsoft/mu_plus/pull/324,
UsbMouseAbsolutePointerDxe is removed and UsbHidDxe and UefiHidDxe are
added to the build.

The absolute pointer protocol will now be installed by the AbsolutePointer
crate in HidPkg linked against the UefiHidDxe 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

Verified QemuQ35Pkg and QemuSbsaPkg build and boot to EFI shell

Integration Instructions

N/A

📖 Documentation Updates

Since there's a couple build variables that can influence which front
page is built and how it is loaded, this change updates the currently
empty front page feature document to include the relevant build
variable information.

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 including markdownlint.

Integration Instructions

N/A

🛠️ Submodule Updates

Introduces 6 new commits in Features/CONFIG.

Signed-off-by: Project Mu Bot [email protected]

Introduces 1 new commits in MU_BASECORE.

Signed-off-by: Project Mu Bot [email protected]

Introduces 1 new commits in Common/MU.

Signed-off-by: Project Mu Bot [email protected]

Introduces 16 new commits in Features/MM_SUPV.

Signed-off-by: Project Mu Bot [email protected]

Introduces 15 new commits in Common/MU.

Signed-off-by: Project Mu Bot [email protected]

Introduces 8 new commits in Common/MU.

Signed-off-by: Project Mu Bot [email protected]

Introduces 16 new commits in Silicon/Arm/MU_TIANO.

Signed-off-by: Project Mu Bot [email protected]

Introduces 5 new commits in MU_BASECORE.

Signed-off-by: Project Mu Bot [email protected]

Full Changelog: https://github.com/microsoft/mu_tiano_platforms/compare/v4.5.3...v4.6.0

mu_tiano_platforms - v4.5.2

Published by github-actions[bot] about 1 year ago

What's Changed

VariablePolicyFuncTestApp now passes on Q35 and SBSA.

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 the CI pipelines

Integration Instructions

N/A

🛠️ Submodule Updates

Introduces 1 new commits in MU_BASECORE.

Signed-off-by: Project Mu Bot [email protected]

Full Changelog: https://github.com/microsoft/mu_tiano_platforms/compare/v4.5.1...v4.5.2

mu_tiano_platforms - v4.5.0

Published by github-actions[bot] about 1 year ago

What's Changed

🚀 Features & ✨ Enhancements

CodeQL was previously enabled in the repo to the point that it could
be run locally with the --codeql flag. It was not enabled in CI
because the pre-existing CodeQL GitHub workflow did not support platform
builds.

This change hooks PlatformBuild.py into the newer stuart_codeql helper
functionality, adds proper filtering support, and a platform workflow that
allows CodeQL to run in this repo on every PR.

Running CodeQL at a "platform" level is advantageous because it can catch
similar CodeQL violations found when building physical platform code.

Note: codeql-platform.yml is directly checked into the repo here as it has
been tested and it is more clearly explained attached to this PR. In the
future, it will be synced from mu_devops.
There is some similarity with the pre-existing CodeQL CI workflow but those
are relatively simple tasks not expected to change much and may be converged
in the future but that is not a goal right now.

Note: CodeQL is only enabled for QemuQ35Pkg as the CodeQL extractor fails
on Linux for edk2 style builds and QemuSbsaPkg does not build on Windows/
Visual Studio at this time.

pip: bump edk2-pytool-extensions from 0.24.0 to 0.24.1

Includes the edk2toolext.codeql functions needed in upcoming
changes.

QemuQ35Pkg/PlatformBuild.py: Add CodeQL filtering support

Makes a number of adjustments in PlatformBuild.py as outlined below.
The main improvement is adding support to recursively gather CodeQL
filter files within the repo.

Remove unused imports at the top of the file.
Use the CodeQL functions newly added to edk2-pytool-extensions.
Replace local functionality with common implementation in the
codeql module.
Remove trailing whitespace throughout the file.

Add CodeQL platform GitHub workflow

Adds a new GitHub workflow that allows CodeQL to run against platform
builds. Previously, only a "CI" CodeQL workflow existed that did not
support platform builders.

This file is being added directly to the repo as it is paired with
other changes that it has been tested alongside. In the future, it
will automatically be synced from mu_devops.

Nothing about the file is specific to mu_tiano_platforms or any
particular platform. It works by discovering all buildable platforms
in a repo before any dependencies are cloned and then verifying
the build files in the platform package directory support platform
build. If they do, it is checked if they support CodeQL. Only
platforms that meet all of these conditions are actually built via
a dynamic platform package matrix.

This allows the workflow to scale across platform repos and
automatically pick up new platforms as they onboard support for
CodeQL.

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 the QemuQ35Pkg CodeQL build locally
Ran the CodeQL - Platform GitHub workflow
- Verified successful detection and build of QemuQ35Pkg

Integration Instructions

Moving forward, it is recommended to run CodeQL locally when making C source
code changes in QemuQ35Pkg. Also, CodeQL success will become a required
status check in mu_tiano_platforms CI for QemuQ35Pkg. See the following
CodeQL plugin documentation for more info.

🛠️ Submodule Updates

Introduces 2 new commits in Common/MU_TIANO.

Signed-off-by: Project Mu Bot [email protected]

Introduces 2 new commits in Common/MU.

Signed-off-by: Project Mu Bot [email protected]

Introduces 1 new commits in MU_BASECORE.

Signed-off-by: Project Mu Bot [email protected]

Full Changelog: https://github.com/microsoft/mu_tiano_platforms/compare/v4.4.1...v4.5.0