05 Feb 14:52

github-actions

d4cc801

v2023020013.1.2

What's Changed

[CHERRY-PICK] release-basetools.yml: Add contents write permission for publishing @makubacki (#717)
Change Details
## Description
The GITHUB_TOKEN is used in the gh release upload command to
upload a new basetools release. This adds content write permission
to allow the upload to work when the default permission is read-only
for the token.

(cherry picked from commit 1cab22a)
- 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 failure with read-only token on fork. Confirmed success with the change.
Integration Instructions

N/A - Only affects local repro GitHub workflow.

Full Changelog: v2023020013.1.1...v2023020013.1.2

Contributors

makubacki

Assets 4

20 Jan 02:12

github-actions

v2023020012.0.1

1cce692

v2023020012.0.1

What's Changed

[REBASE \&\& FF] Compatibility Mode Updates @TaylorBeebe (#683)
Change Details
## Description
Patches:
1. Linux shim currently incorrectly uses the UEFI memory attribute protocol causing a page fault. The broken shim does not have the NXCOMPAT flag, so compatibility mode can be used to uninstall the protocol when it is loaded. For flexibility, this patch adds a policy configuration option to allow platforms to choose not to install the protocol.
2. Because the memory attribute protocol may not be present on the platform, this update uses the cpu arch protocol to update the attributes of the AP buffer to avoid a fault when executing the wakeup function.
3. As described in the enhanced memory protection document, entering compatibility mode maps page zero, no longer applies attributes to loaded images, allocates memory as RWX, and uninstalls the memory attribute protocol. This patch implements compatibility mode in the DXE Core as it is currently defined. Compatiblity mode is triggered when a non-NXCOMPAT image is loaded.
4. Renames the MemoryAttributeProtocol global to mMemoryAttributeProtocol.
These changes were tested on Q35 by booting to Windows and on SBSA by booting to Ubuntu with a shim which misuses the memory attribute protocol and is not NX compatible.

Full Changelog: v2023020012.0.0...v2023020012.0.1

Contributors

TaylorBeebe

Assets 4

19 Jan 16:55

github-actions

v2023020012.0.0

04bb719

v2023020012.0.0

What's Changed

⚠️ Breaking Changes

Remove the openssl library and it's associated files from CryptoPkg. @kenlautner (#680)
Change Details
## Description
Project MU has encouraged the use of a crypto binaries for several years now but has allowed platforms to use the traditional DIY crypto implementations if they want to. This change finally removes Openssl from CryptoPkg along with its associated wrapper libraries and the BaseCryptLib implementation of it. Only the NULL implementation of BaseCryptLib will be available by default in CryptoPkg but it outlines the APIs to use for platforms.

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

Tested on Intel physical platforms and the Q35 QEMU virtual platform.

Integration Instructions

First you'll need to remove all references to the OpensslLib and IntrinsicLib libraries in your platform dsc file. Additionally, any non-NULL instance of BaseCryptLib needs to removed as well.

To use the crypto binary you need to make a few adjustments on your platform:
1. Define the service level that you want for each phase of UEFI in the defines sections of your DSC.
```
    [Defines]
        DEFINE PEI_CRYPTO_SERVICES = TINY_SHA
        DEFINE DXE_CRYPTO_SERVICES = STANDARD
        DEFINE SMM_CRYPTO_SERVICES = STANDARD
        DEFINE STANDALONEMM_CRYPTO_SERVICES = STANDARD
        DEFINE PEI_CRYPTO_ARCH = IA32
        DEFINE DXE_CRYPTO_ARCH = X64
        DEFINE SMM_CRYPTO_ARCH = X64
        DEFINE STANDALONEMM_CRYPTO_ARCH = X64
```
1. Add the DSC include.
  
  !include CryptoPkg/Driver/Bin/CryptoDriver.inc.dsc
2. Add the FDF includes to your platform FDF.
```
    [FV.FVBOOTBLOCK]
    !include CryptoPkg/Driver/Bin/CryptoDriver.PEI.inc.fdf

    [FV.FVDXE]
      !include CryptoPkg/Driver/Bin/CryptoDriver.DXE.inc.fdf
      !include CryptoPkg/Driver/Bin/CryptoDriver.SMM.inc.fdf
      !include CryptoPkg/Driver/Bin/CryptoDriver.STANDALONEMM.inc.fdf
```
For the fdf includes you don't need both the STANDALONEMM and SMM versions. You typically should include only one of them.

BaseTools: Add Cargo Feature support for build @Javagedes (#682)
Change Details
## Description
Adds build support for setting cargo features via EDKII Feature Pcds.
Adds a new makefile variable, CARGO_FEATURES [a comma separated list]
that is generated per module based on any FeaturePcds in the INF that
are enabled. any build rule can consume this makefile variable.

Updates the build rules for building rust crates to consume this
variable.

Updates cargo make's config to pass the variable to the underlying
build command.

WARNING: Makefile.toml will be updated via mu_devops (microsoft/mu_devops#298)
```
diff --git a/.sync/rust_config/Makefile.toml b/.sync/rust_config/Makefile.toml
index 3019bc95..fdcf5643 100644
--- a/.sync/rust_config/Makefile.toml
+++ b/.sync/rust_config/Makefile.toml
@@ -7,6 +7,7 @@ RUSTC_BOOTSTRAP = 1
 ARCH = "X64"
 TARGET_TRIPLE = { source = "${ARCH}", mapping = { "X64" = "x86_64-unknown-uefi", "IA32" = "i686-unknown-uefi", "AARCH64" = "aarch64-unknown-uefi", "LOCAL" = "${CARGO_MAKE_RUST_TARGET_TRIPLE}" }, condition = { env_not_set = [ "TARGET_TRIPLE" ] } }
 
+CARGO_FEATURES_FLAG = {value = "--features ${FEATURES}", condition = {env_set = ["FEATURES"], env_true = ["FEATURES"]}}
 BUILD_FLAGS = "--profile ${RUSTC_PROFILE} --target ${TARGET_TRIPLE} -Zbuild-std=core,compiler_builtins,alloc -Zbuild-std-features=compiler-builtins-mem -Zunstable-options --timings=html"
 TEST_FLAGS = { value = "", condition = { env_not_set = ["TEST_FLAGS"] } }
 COV_FLAGS = { value = "--out html --exclude-files **/tests/*", condition = { env_not_set = ["COV_FLAGS"] } }
@@ -47,15 +48,17 @@ description = """Builds a single rust package.
 Customizations:
     -p [development|release]: Builds in debug or release. Default: development
     -e ARCH=[IA32|X64|AARCH64|LOCAL]: Builds with specifed arch. Default: X64
+    -e FEATURES=[feature,...]: Builds with the specified features. Default: none
 
 Example:
     `cargo make build RustModule`
     `cargo make -p release build RustModule`
     `cargo make -e ARCH=IA32 build RustLib`
+    `cargo make -e FEATURES=feature1,feature2 build RustLib`
 """
 clear = true
 command = "cargo"
-args = ["build", "@@split(INDIVIDUAL_PACKAGE_TARGETS, )", "@@split(BUILD_FLAGS, )"]
+args = ["build", "@@split(INDIVIDUAL_PACKAGE_TARGETS, )", "@@split(BUILD_FLAGS, )", "@@split(CARGO_FEATURES_FLAG, ,remove-empty)"]
 dependencies = ["individual-package-targets"]
 
 [tasks.check]
```
- 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

Created a featurePCD and ensured that the rust feature is passed to cargo. Ensured that when the featurepcd is set to true, the feature is enabled in cargo. Ensured that when the featurepcd is set to false, the feature is not enabled in cargo.

Integration Instructions

Developers will need to complete the following:
1. Remove the temporary Conf file, so that it can be repopulated.
2. Update consuming repository's Makefile.toml from mu_devops.

🔐 Security Impacting

Remove the openssl library and it's associated files from CryptoPkg. @kenlautner (#680)
Change Details
## Description
Project MU has encouraged the use of a crypto binaries for several years now but has allowed platforms to use the traditional DIY crypto implementations if they want to. This change finally removes Openssl from CryptoPkg along with its associated wrapper libraries and the BaseCryptLib implementation of it. Only the NULL implementation of BaseCryptLib will be available by default in CryptoPkg but it outlines the APIs to use for platforms.

All Openssl files have been moved to the MU_CRYPTO_RELEASE repo that you can find here
- 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 (...

Contributors

Javagedes and kenlautner

Assets 4

18 Jan 01:49

github-actions

v2023020011.0.0

cc6cf6f

v2023020011.0.0

What's Changed

CryptoPkg/OpensslLibFull: Add Arm CC flags @makubacki (#679)
Change Details
## Description
A number of flags are needed to successfully build OpenSSL code. For
example, the code triggers several Visual Studio warnings. This
change brings the CC flags already present in other crypto lib INFs
to the OpensslLibFull instance.

This allows the library instance to compile on VS(2022) for AARCH64.
- 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
- AARCH64 build with VS2022. Fails before due to compiler warnings, passes after.
Integration Instructions

N/A - Impacts module build specific to VS toolchain and Arm architecture. Adds
support without impacting existing builds.

Fix Incorrect Mock RNG Prototypes @Flickdm (#672)
Change Details
# Preface
Description

Corrects and error with the MOCK Rng Prototypes

For each item, place an "x" in between [ and ] if true. Example: [x].
(you can also check items in the GitHub UI)
- Impacts functionality?
  - No
- Impacts security?
  - No
- Breaking change?
  - No
- Includes tests?
  - No
- Includes documentation?
  - No
How This Was Tested

Unit tests in a private repository

Integration Instructions

N/A

.git-blame-ignore-revs: Ignore Line Ending and Uncrustify only commits @makubacki (#670)
Change Details
## Description
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.
- 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

CryptoPkg: Add Standalone MM Crypto Support [Rebase \& FF] @makubacki (#676)
Change Details
## Description
Contributes to microsoft/mu_crypto_release#46
1. CryptoPkg: Add CryptoStandaloneMm and StandaloneMmCryptLib
Adds a Standalone MM instance of BaseCryptLib intended to only be
used with the CryptoStandaloneMm driver added. The library instance
can be linked against Standalone MM drivers to the use the
gEdkiiSmmCryptoProtocolGuid protocol instance produced by
CryptoStandaloneMm.
1. CryptoPkg: Generate unique include FDF files per PI phase
Removes the "BOOTBLOCK" file that served as PEI previously and
instead use a straightforward mapping of PI phase to include.

This allows PI phases supported in thee future such as Standalone
MM to seamlessly have a FDF generated that is separated from DXE
and SMM. It also simplifies integration.
1. CryptoPkg: Add Standalone MM shared binary build file generation
Adds support to update the include DSC/FDF files for including
Standalone MM binaries and generate Standalone MM INFs.
1. CryptoPkg: Add Standalone MM shared binary build file generation
Adds support to update the include DSC/FDF files for including
Standalone MM binaries and generate Standalone MM INFs.
- 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
- Standalone MM driver build
- Standalone MM driver runtime dispatch on physical and virtual X64 platform
- Standalone MM UEFI variable driver usage of gEdkiiSmmCryptoProtocolGuid
Integration Instructions

Include file changes:
- [BREAKING CHANGE]: CryptoDriver.BOOTBLOCK.inc.fdf is removed (renamed to CryptoDriver.PEI.inc.fdf)
- [BREAKING CHANGE]: CryptoDriver.DXE.inc.fdf no longer includes SMM (DXE_SMM_DRIVER) modules by default
- CryptoDriver.SMM.inc.fdf is new and contains SMM modules (DXE_SMM_DRIVER)
- CryptoDriver.STANDALONEMM.inc.fdf is new and contains Standalone MM modules (MM_STANDALONE)
Update platform FDF files to include the renamed BOOTBLOCK file.
Include either the SMM or STANDALONEMM file based on platform need.

A new build rule may be needed in a platform FDF to integrate Standalone MM binaries. An
example to use the Standalone MM shared crypto driver is shown below:
```
[Rule.Common.MM_STANDALONE.BINARY]
  FILE MM_STANDALONE = $(NAMED_GUID) {
    SMM_DEPEX SMM_DEPEX Optional      |.depex
    PE32      PE32                    |.efi
    UI        STRING="$(MODULE_NAME)" Optional
    VERSION   STRING="$(INF_VERSION)" Optional BUILD_NUM=$(BUILD_NUMBER)
  }
```
Note that the Standalone MM binaries are compiled with libraries specific to the Project Mu
MM Supervisor.

🔐 Security Impacting

CryptoPkg: Update shared crypto to 2023.2.6 @makubacki (#681)
Change Details
## Description
Crypto binaries in this release include Mu Basecore up to
v2023020010.0.0 and Standalone MM binaries.
- 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
    ...

Contributors

Flickdm and makubacki

Assets 4

10 Jan 19:47

github-actions

v2023020010.0.0

ae88c09

v2023020010.0.0

What's Changed

Adding MockRNG to the Google Test Mock @Flickdm (#668)
Change Details
# Preface
Please ensure you have read the contribution docs prior
to submitting the pull request. In particular,
pull request guidelines.

Description

Adds MockRNG to the Google Test Mock

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 - No
- Impacts security?
  - Security - No
- Breaking change?
  - Breaking change - No
- Includes tests?
  - Tests - No
- Includes documentation?
  - Documentation - No
How This Was Tested

Local Tests

Integration Instructions

N/A

Don't Assert if InitializeSeparateExceptionStacks() Fails @TaylorBeebe (#669)
Change Details
## Description
ARM platforms don't initialize separate exception stacks. The ARM CpuExceptionHandler libraries always return EFI_SUCCESS in InitializeSeparateExceptionStacks() to sidestep this exception. To accommodate the use of the NULL library instance which returns EFI_UNSUPPORTED, just print an error when the routine fails.
- Impacts functionality?
  - Functionality - Does the change ultimately impact how firmware functions?
  - Examples: Add a new library, publish a new PPI, update an algorithm, ...
- Impacts security?
  - Security - Does the change have a direct security impact on an application,
    flow, or firmware?
  - Examples: Crypto algorithm change, buffer overflow fix, parameter
    validation improvement, ...
- Breaking change?
  - Breaking change - Will anyone consuming this change experience a break
    in build or boot behavior?
  - Examples: Add a new library class, move a module to a different repo, call
    a function in a new library class in a pre-existing module, ...
- Includes tests?
  - Tests - Does the change include any explicit test code?
  - Examples: Unit tests, integration tests, robot tests, ...
- Includes documentation?
  - Documentation - Does the change contain explicit documentation additions
    outside direct code modifications (and comments)?
  - Examples: Update readme file, add feature readme file, link to documentation
    on an a separate Web page, ...
How This Was Tested

Tested on a Surface ARM platform

Integration Instructions

N/A

FdSizeReport: Handle empty FV sections in Build Report @Javagedes (#664)
Change Details
## Description
Updates the FdSizeReportGenerator to handle the scenario where the build report contains an empty FD region.

This scenario was not previously seen but has been verified and has been noted to happen when a nested FV does not contain any modules. In this scenario, the "Size: " line is not present and there is no subsection table where the included files would normally be present.

Example of empty FD region:
```
>----------------------------------------------------------------------------------------------------------------------<
Nested FV
Type:               FV
Base Address:       0x0
<---------------------------------------------------------------------------------------------------------------------->
```
- 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

Reproduced error on partner platform and verified changes resolved the issue.

Integration Instructions

N/A

BaseTools: Fix raw strings containing valid escape characters @Javagedes (#663)
Change Details
## Description
Fixes raw regex strings that contain valid (and purposeful) escape characters as they are being treated as individual characters rather than the single escaped character they represent (i.e. '\t' is being treated as a '\' and a 't' rather than a single tab character).

Note: This is the same patch series being added via https://edk2.groups.io/g/devel/message/112986, but seeing as this is a breaking change being seen by partners, I figured we should get this into MU_BASECORE as quickly as possible.
- Impacts functionality?
  - Functionality - Does the change ultimately impact how firmware functions?
  - Examples: Add a new library, publish a new PPI, update an algorithm, ...
- Impacts security?
  - Security - Does the change have a direct security impact on an application,
    flow, or firmware?
  - Examples: Crypto algorithm change, buffer overflow fix, parameter
    validation improvement, ...
- Breaking change?
  - Breaking change - Will anyone consuming this change experience a break
    in build or boot behavior?
  - Examples: Add a new library class, move a module to a different repo, call
    a function in a new library class in a pre-existing module, ...
- Includes tests?
  - Tests - Does the change include any explicit test code?
  - Examples: Unit tests, integration tests, robot tests, ...
- Includes documentation?
  - Documentation - Does the change contain explicit documentation additions
    outside direct code modifications (and comments)?
  - Examples: Update readme file, add feature readme file, link to documentation
    on an a separate Web page, ...
How This Was Tested

Verified on multiple partner platforms

Integration Instructions

N/A

⚠️ Breaking Changes

Cherry pick and apply uncrustify changes @VivianNK (#609)
Change Details
## Description
Cherry pick uncrustify changes for cpp from edk2 and apply them to relevant files.
- Impacts functionality?
  - Functionality - Does the change ultimately impact how firmware functions?
  - Examples: Add a new library, publish a new PPI, update an algorithm, ...
- Impacts security?
  - Security - Does the change have a direct security impact on an application,
    flow, or firmware?
  - Examples: Crypto algorithm change, buffer overflow fix, parameter
    validation improvement, ...
- Breaking change?
  - Breaking change - Will anyone consuming this change experience a break
    in build or boot behavior?
  - Implements new uncrustify standard that needs to be applied to all .cpp files and some cpp-related .h files(GoogleTests). Will need to update the following repos:
    
    mu feature config (not dependent on this PR - only cpp file changes) PR
    
    mu feature ipmi (not dependent on this PR - only cpp file changes) PR
    
    mu tiano plus Draft PR
- Includes tests?
  - Tests - Does the change include any explicit test code?
  - Examples: Unit tests, integration tests, robot tests, ...
- Includes documentation?
  - Documentation - Does the change contain explicit documentation additions
    outside direct code modifications (and comments)?
  - Examples: Update readme file, add feature readme file, link to documentation
    on an a separate Web page, ...
How This Was Tested

Local CI build

Integration Instructions

WIll need to have up to date mu_tiano_plus branch once merged.

🐛 Bug Fixes

Ensure Stack Guard Init is Performed Regardless of Platform NX Policy @TaylorBeebe (#671)

Change Details

## De...

Contributors

Flickdm, VivianNK, and 2 other contributors

Assets 4

22 Dec 01:11

github-actions

v2023020009.0.3

3915925

v2023020009.0.3

What's Changed

Update iasl ext dep to 20230628 @Javagedes (#658)
Change Details
## Description
Updates the default iasl external dependency from 20210105 to 20230628.
- 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
- mu_basecore: CI Pipelines
- mu_tiano_platforms: QemuQ35, QemuSbsa
Integration Instructions

N/A
```
  </blockquote>
  <hr>
</details>
```

[CHERRY-PICK] BaseTools: Resolve regex syntax warnings @Javagedes (#659)
Change Details
## Description
Switches regex patterns to raw text to resolve python 3.12 syntax warnings in regards to invalid escape sequences, as is suggested by the re (regex) module in python.

Cc: Rebecca Cran [email protected]
Cc: Liming Gao [email protected]
Cc: Bob Feng [email protected]
Cc: Yuwei Chen [email protected]

Reviewed-by: Rebecca Cran [email protected]
- 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>
```

release-basetools.yml: Update for compatibility with v4 GitHub actions @makubacki (#655)
Change Details
## Description
Commit edd2738 updated the actions/download-artifact GitHub action
in this workflow to v4. Both actions/download-artifact and
actions/upload-artifact recently released a v4 version with
significant breaking changes.

Relevant to this workflow and this change, is that a v4 download
action must be paired with a v4 upload action. See:
https://github.com/actions/download-artifact?tab=readme-ov-file#v4---whats-new
Breaking Changes
1. On self hosted runners, additional firewall rules may be required.
2. Downloading artifacts that were created from
  action/upload-artifact@v3 and below are not supported.
This results in the release-basetools.yml workflow currently
failing when attempting to download the artifacts in the publish
step (which only runs on a GitHub publish event - not tested in PRs).
- 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 workflow skipping conditional on publish step on my mu_basecore fork.

Integration Instructions

N/A

Full Changelog: v2023020009.0.2...v2023020009.0.3

Contributors

makubacki and Javagedes

Assets 4

Releases: microsoft/mu_basecore

v2023110000.0.0

What's Changed

How This Was Tested

Integration Instructions

How This Was Tested

Integration Instructions

How This Was Tested

Integration Instructions

How This Was Tested

Integration Instructions

How This Was Tested

Integration Instructions

Contributors

v2023020013.1.2

What's Changed

How This Was Tested

Integration Instructions

Contributors

v2023020013.1.1

What's Changed

Description

How This Was Tested

Integration Instructions

🔐 Security Impacting

How This Was Tested

Integration Instructions

Contributors

v2023020013.1.0

What's Changed

🚀 Features & ✨ Enhancements

How This Was Tested

Integration Instructions

How This Was Tested

Integration Instructions

🐛 Bug Fixes

Contributors

v2023020013.0.0

What's Changed

How This Was Tested

Integration Instructions

⚠️ Breaking Changes

How This Was Tested

Integration Instructions

🚀 Features & ✨ Enhancements

How This Was Tested

Integration Instructions

How This Was Tested

Integration Instructions

🐛 Bug Fixes

Contributors

v2023020012.0.1

What's Changed

Contributors

v2023020012.0.0

What's Changed

⚠️ Breaking Changes

How This Was Tested

Integration Instructions

How This Was Tested

Integration Instructions

🔐 Security Impacting

Contributors

v2023020011.0.0

What's Changed

How This Was Tested

Integration Instructions

Description

How This Was Tested

Integration Instructions

How This Was Tested

Integration Instructions

⚠️ Breaking Changes

How This Was Tested

Integration Instructions

🔐 Security Impacting

Contributors

v2023020010.0.0

What's Changed

Description