05 Mar 15:24

github-actions

d92ffaf

v2023110002.0.0

What's Changed

Update Shared Crypto to version 2023.2.12 @apop5 (#757)
Change Details
## Description
See the following release notes for updates
v2023.2.12.
- 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
- The crypto release was tested per the test description in the release.
Integration Instructions

N/A

[CHERRY-PICK] Pull CpuPageTableLib Changes from EDK2 @TaylorBeebe (#758)
Change Details
## Description
Fixes made to CpuPageTableLib since 202311 must be cherry-picked to resolve booting issues caused by other cherry-picks updating code to use the library.
- Impacts functionality?
  - Functionality - Does the change ultimately impact how firmware functions?
  - Examples: Add a new library, publish a new PPI, update an algorithm, ...
- Impacts security?
  - Security - Does the change have a direct security impact on an application,
    flow, or firmware?
  - Examples: Crypto algorithm change, buffer overflow fix, parameter
    validation improvement, ...
- Breaking change?
  - Breaking change - Will anyone consuming this change experience a break
    in build or boot behavior?
  - Examples: Add a new library class, move a module to a different repo, call
    a function in a new library class in a pre-existing module, ...
- Includes tests?
  - Tests - Does the change include any explicit test code?
  - Examples: Unit tests, integration tests, robot tests, ...
- Includes documentation?
  - Documentation - Does the change contain explicit documentation additions
    outside direct code modifications (and comments)?
  - Examples: Update readme file, add feature readme file, link to documentation
    on an a separate Web page, ...
How This Was Tested

Tested on Q35

Integration Instructions

N/A

[CHERRY-PICK] Unit Test Unexpected Exception @VivianNK (#756)
Change Details
## Description Cherry pick from: https://github.com/tianocore/edk2/pull/5345
- Impacts functionality?
  - Functionality - Does the change ultimately impact how firmware functions?
  - Examples: Add a new library, publish a new PPI, update an algorithm, ...
- Impacts security?
  - Security - Does the change have a direct security impact on an application,
    flow, or firmware?
  - Examples: Crypto algorithm change, buffer overflow fix, parameter
    validation improvement, ...
- Breaking change?
  - Breaking change - Will anyone consuming this change experience a break
    in build or boot behavior?
  - Examples: Add a new library class, move a module to a different repo, call
    a function in a new library class in a pre-existing module, ...
- Includes tests?
  - Tests - Does the change include any explicit test code?
  - Examples: Unit tests, integration tests, robot tests, ...
- Includes documentation?
  - Documentation - Does the change contain explicit documentation additions
    outside direct code modifications (and comments)?
  - Examples: Update readme file, add feature readme file, link to documentation
    on an a separate Web page, ...
How This Was Tested

Local builds and CI tests ran.

Integration Instructions

N/A

Codeql update from 2.15.4 to 2.16.1 @apop5 (#743)
Change Details
## Description
Updating CodeQl ext_dep to version 2.16.1

When running 2.15.4 version, VS2022 ado pipelines were sometimes showing:
```
INFO - Not using precompiled PointerOverflow.qlx: This QLX (written by CodeQL 2.16.2) is too new for this CodeQL engine.
INFO - Compiling query plan for C:\Users\VssAdministrator\.codeql\packages\codeql\cpp-queries\0.9.4\Likely Bugs\Memory Management\PointerOverflow.ql.
INFO - [1/25] Compiled C:\Users\VssAdministrator\.codeql\packages\codeql\cpp-queries\0.9.4\Likely Bugs\Memory Management\PointerOverflow.ql.
```
- 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 local CodeQl over existing mu_basecore to see if new issues were reported on VS2022.
Local run was completed with additional build parameter --codeql during stuart_update, and stuart_ci_build
Verified that correct version of codeql existed in BaseTools\Plugin\CodeQL\codeql_windows_cli_extdep after update process.

Integration Instructions

No changes necessary, codeql ext_dep will be downloaded automatically.

CryptoPkg: Update to Shared Crypto 2023.2.11 @makubacki (#751)
Change Details
## Description
See the following release notes for updates v2023.2.11.
- 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
- The crypto release was tested per the test description in the release.
Integration Instructions

Platforms no longer have to explicitly specify that
a crypto service is "NONE". If a crypto service, is not used,
the arch no longer needs to be explicitly set to "NONE" either.

For example, a platform that only uses Standalone MM can now entirely
omit the following lines from the platform DSC file:
- SMM_CRYPTO_SERVICES = NONE
- SMM_CRYPTO_ARCH = NONE

⚠️ Breaking Changes

[CHERRY-PICK] Stack Cookie Updates @TaylorBeebe (#754)

Change Details

Contributors

VivianNK, makubacki, and 4 other contributors

Assets 4

05 Mar 15:20

github-actions

v2023020014.0.0

9571b96

v2023020014.0.0

What's Changed

⚠️ Breaking Changes

Move Stack Protector Global Flag in Toolsdef @TaylorBeebe (#755)
Change Details
## Description
-mstack-protector-guard=global flag is required to use stack cookies for GCC builds. Clang toolchains inherit flags from GCC defs in the tools_def and does not support the -mstack-protector-guard option. This PR moves the -mstack-protector-guard option to ensure it only targets GCC5 builds.
- 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

The Conf/ folder will need to be deleted for existing clones so it can be regenerated

[REBASE \&\& FF] Add Stack Cookie Support for IA32, ARM, and AARCH64 @TaylorBeebe (#714)
Change Details
This update changes the following:
Basetools update

CI builds would use the basetools installed via pip if available. Because we have Project Mu edits to basetools and the project has little support in EDK2, this update causes all builds to use our in-tree basetools.

Fix NULL lib parsing

When parsing INF files, Basetools treats both libraries and modules the same. When the library dependencies are being collected for a module/library, libraries linked via:

NULL|Path/To/Library

would be included in the list of dependencies for libraries which does not match how these expressions are expected to be interpreted. This update changes the evaluation loop to skip NULL links when collecting dependencies for libraries.

Add GCC ARM, AARCH64, IA32 support and MSVC IA32 support for StackCheckLibNull

MSVC IA32 requires the __security_check_cookie function to specify byte size (@__security_check_cookie@4). This change also declares __stack_chk_fail() in StackCheckLibNull.c to support GCC.

Implement Stack Cookie Support for MSVC IA32 and GCC IA32, ARM, and AARCH64

This update replaces StackCheckLib with StackCheckLibStaticInit and StackCheckLibDynamicInit. The new libraries have GCC support for ARM, AARCH64, IA32 and X64 builds. The libraries have MSVC support for IA32 and X64 builds.

StackCheckLibStaticInit does not have a library constructor and should be used whenever the stack cookie value cannot be updated during driver execution (i.e. when the stack cookie is not in a writable or no RNG library is available). The value of the stack cookie is generated at buildtime via a Basetools update.

StackCheckLibDynamicInit has a library constructor and should be used whenever the stack cookie value can be updated at runtime (i.e. for DXE modules and shadowed PEIMs).

Update StackCheckFailureLib to StackCheckFailureHookLib

To clarify the purpose of StackCheckFailureLib, this PR renames it to StackCheckFailureHookLib. Also, the failure address is passed as an argument to the hook function to allow the hook to trace the fault. An interrupt will still be called after the hook returns.

How This Was Tested

Tested on a Q35 GCC and MSVC builds by purposefully performing a stack overflow and verifying the stack check failure hook was called followed by the stack check failure interrupt.

Integration Instructions

Platforms will need to explicitly declare the StackCheckLib and StackCheckFailureLib instances for their platforms.
```
StackCheckFailureHookLib|MdePkg/Library/StackCheckFailureHookLibNull/StackCheckFailureHookLibNull.inf
[LibraryClasses.common.SEC, LibraryClasses.common.PEI_CORE]
  NULL|MdePkg/Library/StackCheckLibNull/StackCheckLibNull.inf

[LibraryClasses.common.PEIM, LibraryClasses.common.MM_CORE_STANDALONE, LibraryClasses.common.MM_STANDALONE]
  NULL|MdePkg/Library/StackCheckLib/StackCheckLibStaticInit.inf

[LibraryClasses.common.DXE_CORE, LibraryClasses.common.SMM_CORE, LibraryClasses.common.DXE_SMM_DRIVER, LibraryClasses.common.DXE_DRIVER, LibraryClasses.common.DXE_RUNTIME_DRIVER, LibraryClasses.common.DXE_SAL_DRIVER, LibraryClasses.common.UEFI_DRIVER, LibraryClasses.common.UEFI_APPLICATION]
  NULL|MdePkg/Library/StackCheckLib/StackCheckLibDynamicInit.inf
```
As shown in the example above.

🔐 Security Impacting

Move Stack Protector Global Flag in Toolsdef @TaylorBeebe (#755)
Change Details
## Description
-mstack-protector-guard=global flag is required to use stack cookies for GCC builds. Clang toolchains inherit flags from GCC defs in the tools_def and does not support the -mstack-protector-guard option. This PR moves the -mstack-protector-guard option to ensure it only targets GCC5 builds.
- 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

The Conf/ folder will need to be deleted for existing clones so it can be regenerated

[REBASE \&\& FF] Add Stack Cookie Support for IA32, ARM, and AARCH64 @TaylorBeebe (#714)

Change Details

This update changes the following:
Basetools update

CI builds would use the basetools installed via pip if available. Because we have Project Mu edits to basetools and the project has little support in EDK2, this update causes all builds to use our in-tree basetools.

Fix NULL lib parsing

When parsing INF files, Basetools treats both libraries and modules the same. When the library dependencies are being collected for a module/library, libraries linked via:

NULL|Path/To/Library

would be included in the list of dependencies for libraries which does not match how these expressions are expected to be interpreted. This update changes the evaluation loop to skip NULL links when collecting dependencies for libraries.

Add GCC ARM, AARCH64, IA32 support and MSVC IA32 support for StackCheckLibNull

MSVC IA32 requires the __security_check_cookie function to specify byte size (@__security_check_cookie@4). This change also declares __stack_chk_fail() in StackCheckLibNull.c to support GCC.

Implement Stack Cookie Support for MSVC IA32 and GCC IA32, ARM, and AARCH64

This update replaces StackCheckLib with StackCheckLibStaticInit and StackCheckLibDynamicInit. The new libraries have GCC support for ARM, AARCH64, IA32 and X64 builds. The libraries have MSVC support for IA32 and X64 builds.

StackCheckLibStaticInit does not have a library constructor and should be used whenever the stack cookie value cannot be updated during driver execution (i.e. when the stack cookie is not in a writable or no RNG library is available). The value of the stack cookie is generated at buildtime via a Basetools update.

StackCheckLibDynamicInit has a library constructor and should be used whenever the stack cookie value can be updated at runtime (i.e. for DXE modules and shadowed PEIMs).

Update StackCheckFailureLib to StackCheckFailureHookLib

To clarify the purpose of StackCheckFailureLib, this PR renames it to StackCheckFailureHookLib. Also, the failure address is passed as an ...

Contributors

TaylorBeebe

Assets 4

22 Feb 18:29

github-actions

v2023110001.1.0

d5379bd

v2023110001.1.0

What's Changed

RustEnvironmentCheck: Bugfix embedded quotes @Javagedes (#749)
Change Details
## Description
Replaces embedded double quotes with single quotes in the RustEnvironmentCheck plugin as embedded double quotes support when working with f-strings was only added in python 3.12, and this project should support python 3.10, 3.11, and 3.12.
```
File "C:\src\mu_plus\MU_BASECORE\BaseTools\Plugin\RustEnvironmentCheck\RustEnvironmentCheck.py", line 259
    f"  cargo binstall cargo-make {('--version ' + tool_versions.get("cargo-make", "")) if "cargo-make" in tool_versions else ""}"

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

Verified the plugin works on 3.10, 3.11, and 3.12

Integration Instructions

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

🚀 Features & ✨ Enhancements

Edk2ToolsBuild: override basetoolsbin\_ext\_dep @Javagedes (#745)
Change Details
## Description
Building a local copy of Edk2ToolsBuild does not automatically override the pre-compiled copy of the basetools provided by basetoolsbin_ext_dep.

This commit adds an id to the external dependency, that can then be overridden with override_id in the path_env file that is generated when you build the basetools locally with Edk2ToolsBuild.
- 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 EDK_TOOLS_BIN now points at the locally-built basetools once they have been built.

Integration Instructions

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

Full Changelog: v2023110001.0.3...v2023110001.1.0

Contributors

Javagedes

Assets 4

21 Feb 03:45

github-actions

v2023110001.0.3

35d06ff

v2023110001.0.3

What's Changed

remove edk2-basetools @Javagedes (#732)
Change Details
## Description
Removes edk2-basetools from pip-requirements.txt and any usage of it in the CISettings.py. The is done as there are changes in the build tools python source code that are available locally in BaseTools (as it is managed by Project Mu) that is not available in 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

Verified the build system continues to use the local python source

Integration Instructions

N/A - only effects this repository's CI system.

RustEnvironmentCheck: Check Version if specified @Javagedes (#737)
Change Details
## Description
Allows repository owners to enforce version requirements for some rust related tools needed for build. This includes cargo-make and cargo-tarpaulin.

RustEnvironmentCheck currently only checks that the necessary tooling exists on the system. The only version check it performs is for the compiler version. This update adds support for repository owners to optionally require specific versions for cargo-make and cargo-tarpaulin by setting the required version in the rust-toolchain.toml file at the workspace root.

Updates the install command suggestion for cargo make and cargo tarpaulin.

Example Usage:
```
# rust-toolchain.toml
[toolchain]
channel = "1.73.0"

[tool]
cargo-tarpaulin = "0.27.3"
cargo-make = "0.37.9"
```
- 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

Confirmed the following scenarios:
1. Tool missing, version specified
2. Tool missing, version not specified
3. Tool installed, version mismatch
Integration Instructions

Example Usage:
```
[toolchain]
channel = "1.73.0"

[tool]
cargo-tarpaulin = "0.27.3"
cargo-make = "0.37.9"
```
If a repository maintainer wants to manage the version, update the rust-toolchain.toml file similar to the example aove.

🐛 Bug Fixes

BaseTools/RustEnvironmentCheck: Allow no tools in toolchain file @makubacki (#746)
Change Details
## Description
The get_required_tool_versions() function currently assumes that a
tool match will be present in the workspace toolchain file. This
change prevents a NoneType AttributeError if no results are found
by first checking that match is not None.
- 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
- Run against rust-toolchain.toml file with a matching tool pattern
- Run against rust-toolchain.toml file without a matching tool pattern
Integration Instructions

N/A

Full Changelog: v2023110001.0.2...v2023110001.0.3

Contributors

makubacki and Javagedes

Assets 4

15 Feb 14:48

github-actions

v2023020013.1.3

69ca931

v2023020013.1.3

What's Changed

[CHERRY-PICK] Restore IntrinsicLib to CryptoPkg @kenlautner (#735)
Change Details
## Description
Some silicon code is making use of the CryptoPkg's Intrinsic lib.

Intrinsiclib was removed in 04bb719.

Adding the functionality back to allow silicon code to use the library while a better long term solution is created.
- 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

Integration Instructions

N/A

Full Changelog: v2023020013.1.2...v2023020013.1.3

Contributors

kenlautner

Assets 4

06 Feb 01:55

github-actions

v2023110000.0.1

c6e7c62

v2023110000.0.1

What's Changed

🔐 Security Impacting

Updated Crypto binaries to 2023.02.9 to include SHA384 and SHA512 functions @kenlautner (#726)
Change Details
## Description
Built new binaries to include SHA384 and SHA512 functions in the STANDARD flavor of the crypto binary. This is to support new authenticated variable logic that allows you to choose which SHA functions to use instead of always using SHA256.
- 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 QemuQ35 and on physical systems. SHA384 and SHA512 functions were usable.

Integration Instructions

Update your MU_BASECORE pin to include this change and it'll be pulled automatically.

Full Changelog: v2023110000.0.0...v2023110000.0.1

Contributors

kenlautner

Assets 4

Releases: microsoft/mu_basecore

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

⚠️ Breaking Changes

Contributors

v2023020014.0.0

What's Changed

⚠️ Breaking Changes

How This Was Tested

Integration Instructions

Basetools update

Fix NULL lib parsing

Add GCC ARM, AARCH64, IA32 support and MSVC IA32 support for StackCheckLibNull

Implement Stack Cookie Support for MSVC IA32 and GCC IA32, ARM, and AARCH64

Update StackCheckFailureLib to StackCheckFailureHookLib

How This Was Tested

Integration Instructions

🔐 Security Impacting

How This Was Tested

Integration Instructions

Basetools update

Fix NULL lib parsing

Add GCC ARM, AARCH64, IA32 support and MSVC IA32 support for StackCheckLibNull

Implement Stack Cookie Support for MSVC IA32 and GCC IA32, ARM, and AARCH64

Update StackCheckFailureLib to StackCheckFailureHookLib

Contributors

v2023110001.1.0

What's Changed

How This Was Tested

Integration Instructions

🚀 Features & ✨ Enhancements

How This Was Tested

Integration Instructions

Contributors

v2023110001.0.3

What's Changed

How This Was Tested

Integration Instructions

How This Was Tested

Integration Instructions

🐛 Bug Fixes

How This Was Tested

Integration Instructions

Contributors

v2023020013.1.4

What's Changed

🔐 Security Impacting

Description

How This Was Tested

Integration Instructions

📖 Documentation Updates

Description

How This Was Tested

Integration Instructions

Contributors

v2023110001.0.2

What's Changed

🔐 Security Impacting

Description

How This Was Tested

Integration Instructions

📖 Documentation Updates

Description

How This Was Tested

Integration Instructions

Contributors

v2023110001.0.1

What's Changed

How This Was Tested

Integration Instructions