22 Apr 17:12

github-actions

6e49e97

v2023110005.0.0

What's Changed

[CHERRY-PICK] MdePkg/SmBios.h: Add New ProcessorFamily definitions for SMBIOS Type4 @srilathasridharan (#813)
Change Details
The patch adds new ProcessorFamily definitions for SMBIOS Type4 based on SMBIOS 3.8.0.
Reviewed-by: Liming Gao [email protected]
Reviewed-by: Star Zeng [email protected]
Reviewed-by: Zhichao Gao [email protected]
Cc: Zhiguang Liu [email protected]
Cc: Dandan Bi [email protected]
Cc: Star Zeng [email protected]
Cc: Zhichao Gao [email protected]
Cc: Benny Lin [email protected]
Cc: Gua Guo [email protected]
Cc: Michael D Kinney [email protected]
Cc: Liming Gao [email protected]

Preface

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

Description

Cherry-picked from edk2.

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

Tested on Intel hardware.

Integration Instructions

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

.gitattributes: Prevent line ending conversion @makubacki (#809)
Change Details
## Description
Unsets the text attribute on all files to prevent their line endings
from being normalized.

See https://git-scm.com/docs/gitattributes for background.

This was previously accomplished solely by instructing users to set
core.autocrlf to false. However, that does not translate to pipelines
and setting in a pipeline requires the system level git configuration
to be modified prior to checkout. Git configs cannot be checked into
to a repo and automatically used for security reasons.

This is a simple way to check the change into the repo so it applies
for all users including pipelines to prevent line ending conversion.

This allows plugins like LineEndingCheck to produce similar results
in pipelines on Linux and Windows agents.

This commit is testing the change for a period of time in the
mu_basecore repo.

If no issues with git operations and impact on tools is discovered
after a couple weeks, it will be synced across all repos from
mu_devops.
- 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
- Clone mu_basecore repo with the change locally and verify a new file added
  with several commits of changes appears properly in git unified diffs like
  those from git format-patch, git diff, etc.
- Verify changes on existing files appear as expected in git history.
- Verify pipelines with the change properly preserve line endings so line ending
  checks (LineEndingCheck plugin) are consistent across agents.
Tested in the following mu_basecore Windows agent pipeline runs:
- Expect LineEndingCheck Failure
- Expect LineEndingCheck Pass
Tested in the following mu_basecore Linux agent pipeline runs:
- Expect LineEndingCheck Failure
- Expect LineEndingCheck Pass
Integration Instructions

N/A

⚠️ Breaking Changes

CryptoPkg/BaseCryptLib: add DigestLen to RsaOaepEncrypt(), RsaOaepDecrypt() @cmruffin (#797)
Change Details
## Description
Add DigestLen parameter to RsaOaepEncrypt(), RsaOaepDecrypt() so that SHA256, SAH384, SHA512 hash and MGF can be used with the API.
- Impacts functionality?
- Impacts security?
- Breaking change?
- Includes tests?
- Includes documentation?
How This Was Tested

Unit tests, wycheproof test vectors, end-to-end test with 3rd party application.

Integration Instructions

Build crypto release on private branch, update Crypto Driver with this PR.

(contains changes from edk2 commit 89ff5da)
(contains changes from edk2 commit 503344c)
(contains changes from edk2 commit c98c145)

🐛 Bug Fixes

DscCompleteCheck: Bugfix ignorepaths config option @Javagedes (#806)
Change Details
## Description
The DscCompleteCheck has support for .gitignore style ignore paths in a package configuration file. Per
edk2toollib.gitignore_parser.IgnoreRule.match(), the path must be an absolute path, so this commit updates the DscCompleteCheck to wait to convert the file paths to edk2 relative paths until after the ignore paths have been processed.

See: https://github.com/tianocore/edk2-pytool-library/blob/83db1e007f6ca7bbc0f7a59e9565695134a8c269/edk2toollib/gitignore_parser.py#L178
- 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 gitignore paths apply to packages that are not at the root of the directory.

Integration Instructions

N/A

🔐 Security Impacting

Add ARM and AARCH64 MSCVC Support to StackCheckLib @TaylorBeebe (#808)

Change Details

## Description
This PR adds the required .asm files for compiling StackCheckLib with MSVC for an ARM or AARCH64 target. This PR also updates the stack check failure instruction for AARCH64 to SVC instead of SMC...

Contributors

cmruffin, makubacki, and 3 other contributors

Assets 4

11 Apr 23:57

github-actions

v2023110004.0.0

afb07e5

v2023110004.0.0

What's Changed

Add Error Message and ASSERT When Loading non-NX\_COMPAT Image @TaylorBeebe (#802)
Change Details
## Description
When loading an image without the NX_COMPAT flag, the memory protection policy is queried to see if the image is allowed to load. If it is not, a security violation is returned which results in a single error message.

To make it more clear what happened and why, this PR adds a print explaining the reason behind blocking the image from loading and how to fix it. This PR also adds an ASSERT to stop DEBUG build execution when the security violation is encountered to ensure the violation isn't missed. Developers should either update the memory protection policy or the offending EFI app to resolve the ASSERT.
- 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 by loading a non NX_COMPAT image.

Integration Instructions

N/A

Add SMM\_REV\_ID definition for STM header @kuqin12 (#803)
Change Details
## Description
The SMM_REV_ID is defined in the STM specification: https://www.intel.com/content/www/us/en/content-details/671521/smi-transfer-monitor-stm-developer-or-user-guide.html?wapkw=stm, section 10.1.1.

This change adds it into the StmApi.h for potential STM usage.
- 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

Header file update only. No functional changes.

Integration Instructions

N/A

Added mock MmServicesTableLib and mock SmmVarCheck protocol @v-bhavanisu (#795)
Change Details
# Preface
Please ensure you have read the contribution docs prior
to submitting the pull request. In particular,
pull request guidelines.

Description

Added mock MmServicesTableLib and mock SmmVarCheck protocol

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

Added the mock MmServicesTableLib and mock SmmVarCheck protocol to a GoogleTest on Gen11 and ensured no VS2022 build errors

Integration Instructions

N/A

⚠️ Breaking Changes

[REBASE \& FF] Enable AARCH64 64k Runtime Page Allocation Granularity @os-d (#800)
Change Details
## Description
This is a big set of cherry-picks from edk2 to enable 64k runtime page allocation granularity for AARCH64. The changes are as follows:
- Revert a host based unit test that has been upstreamed and is getting pulled in in this PR
- Revert a MAT table fix that is upstreamed now and getting pulled down in this PR
- Cherry-Pick the ImagePropertiesRecordLib as 64k fixes went in upstream there and Mu doesn't have it
- Cherry-Pick the 64k fixes from edk2
- Revert the 4k runtime page allocation granularity commit from Mu now that 64k works
- Add a deprecated build option to revert to 4k runtime page allocation granularity for AARCH64 platforms that cannot support 64k
Because this is a large series of cherry-picking edk2 on top of Mu (instead of Mu on top of edk2 as we do in integrations), some of these cherry-picks have been massaged to work with Mu commits. In the next integration, this will all be cleaned up as we cherry-pick Mu on top on edk2.

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

Tested on various physical and virtual platforms to confirm MAT table correctly built on AARCH64 and AARCH64 64k page Linux can boot.

Integration Instructions

Do not use this option without an old platform that cannot support 64k.
For those platforms, set the following in the platform DSC:
```
MSFT:*_*_*_CC_FLAGS = /D __DEPRECATED_AARCH64_4K_RUNTIME_GRANULARITY
GCC:*_*_*_CC_FLAGS = -D __DEPRECATED_AARCH64_4K_RUNTIME_GRANULARITY
```
```
  </blockquote>
  <hr>
</details>
```

PixieFail Security Patches for TCBZ451 and TCB4542 @Flickdm (#799)
Change Details
## Description
This fixes the remaining two issues from PixieFail.

See https://blog.quarkslab.com/pixiefail-nine-vulnerabilities-in-tianocores-edk-ii-ipv6-network-stack.html
for more detailed information on:
1. CVE 2023-45236 (TCBZ4541)
2. CVE 2023-45237 (TCBZ4542)
- Impacts functionality?
- Impacts s...

Contributors

Flickdm, os-d, and 3 other contributors

Assets 4

09 Apr 23:55

github-actions

v2023110003.1.3

e8a14cb

v2023110003.1.3

What's Changed

🔐 Security Impacting

Add NO\_STACK\_COOKIE to Module Entry Points @TaylorBeebe (#793)
Change Details
## Description
When the DXE dispatcher dispatches an EFI module, execution starts with the ModuleEntryPoint of the EFI. If the stack cookie value is randomized during the library constructor process and the ModuleEntryPoint includes a stack cookie check, then the value of the stack cookie will change between the start and end of the ModuleEntryPoint function and cause a stack cookie check failure. With this change, the following is the structure which ensures the stack cookie check will not erroneously fail:
```
NO_STACK_COOKIE
ModuleEntryPoint (

  NO_STACK_COOKIE 
  ProcessLibraryConstructorList (

    NO_STACK_COOKIE 
    InitializeStackCookie ()
  )
)
```
- 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 to shell on Q35 built with GCC and VS2022, and by booting SBSA built with GCC.

Integration Instructions

N/A

Full Changelog: v2023110003.1.2...v2023110003.1.3

Contributors

TaylorBeebe

Assets 4

04 Apr 17:29

github-actions

v2023110003.1.1

8a0ac50

v2023110003.1.1

What's Changed

Added Mock Library for IoLib @v-bhavanisu (#788)
Change Details
# Preface
Please ensure you have read the contribution docs prior
to submitting the pull request. In particular,
pull request guidelines.

Description

Added Mock Library for IoLib

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

Added Mock IoLib to a Gen11 library and checked no build errors and ensured MockIolib definitions are called appropriately

Integration Instructions

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

Added mock library for SmmServicesTableLib and mock protocol for SmmCpu @v-bhavanisu (#784)
Change Details
## Description
Added mock library for SmmServicesTableLib and mock protocol for SmmCpu
- 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

Added this mock lib and mock protocol to Gen11 library and ensured no build errors

Integration Instructions

N/A

Full Changelog: v2023110003.1.0...v2023110003.1.1

Contributors

v-bhavanisu

Assets 4

02 Apr 23:16

github-actions

v2023110003.1.0

dcdd08f

v2023110003.1.0

What's Changed

Add CRC16 CCITT False Implementation @kuqin12 (#782)
Change Details
# Preface
Please ensure you have read the contribution docs prior
to submitting the pull request. In particular,
pull request guidelines.

Description

This change is added to incorporate basic implementation for CRC16-CCITT-FALSE algorithm.

This function is useful for providing CRC16 value used in other data structures that requires CRC16 value that complies with JEDEC SPD requirements, i.e. BDAT table.

The lookup table is inherited from https://crccalc.com/ and the result values are also compared against this site.

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

The function output is compared and matches with the results of 3rd party online CRC calculators.

Integration Instructions

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

Added Mock GoogleTest folder for PolicyLibCommon @v-bhavanisu (#780)
Change Details
# Preface
Please ensure you have read the contribution docs prior
to submitting the pull request. In particular,
pull request guidelines.

Description

Added Mock GoogleTest folder for PolicyLibCommon

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

Added this mock lib definition and declaration to one of the library under Gen 11 and made sure local build is successful

Integration Instructions

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

🚀 Features & ✨ Enhancements

Rework Buildtime Random Stack Cookie Values to Improve Incremental Build Times and Ensure Binary Reproducibility @TaylorBeebe (#773)
Change Details
## Description
If the stack cookie value is randomized in the AutoGen.h file each build, the build system will determine the module/library must be rebuilt causing effectively a clean build every time. This also makes binary reproducibility impossible.

This PR updates the early build scripts to create 32 and 64-bit JSON files in the build output directory which each contain 100 randomized stack cookie values for each bitwidth. If the JSON files are already present, then they are not recreated which allows them to be stored and moved to other builds for binary reproducibility. Because they are in the build directory, a clean build will cause the values to be regenerated.

The logic which creates AutoGen.h will read these JSON files and use a hash of the module GUID (the hash seed is fixed in Basetools) to index into the array of stack cookie values for the module bitwidth. This model is necessary because there isn't thread-consistent data so we cannot use a locking mechanism to ensure only one thread is writing to the stack cookie files at a time. With this model, the build threads only need to read from the 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?
  - 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 building and confirming the reduced build time for debug builds after the initial build.

Integration Instructions

N/A

🐛 Bug Fixes

BaseTools: InfBuildData: Fix Private dec data retrieval @Javagedes (#785)
Change Details
## Description
Private package dec sections (such as guids [Guids.Common.Private], Ppis [Ppis.Common.Private], and protocols [Protocols.Common.Private]) become inaccessible for components of the same package if the module's EFI_GUID value is overwritten (Which is commonly done to build the same module multiple times with different settings)

BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4730
- 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 private guids continue to be accessible to modules in the same package, even when the EFI_GUID is changed in the dsc.

Integration Instructions

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

Rework Buildtime Random Stack Cookie Values to Improve Incremental Build Times and Ensure Binary Reproducibility @TaylorBeebe (#773)

Change Details

## Description
If the stack cookie value is randomi...

Contributors

Javagedes, TaylorBeebe, and 2 other contributors

Assets 4

22 Mar 17:08

github-actions

v2023110003.0.1

884e5da

v2023110003.0.1

What's Changed

[CHERRY-PICK] MdeModulePkg/TraceHubDebugSysTLib: Use wider type for loop comparisons @makubacki (#775)
Change Details
## Description
Resolves a new CodeQL error due to the value being incremented in the
loop being a narrower type than the variable it is being compared
against.

The variable is changed to a UINT32 type so it has the same width as
the type it is being compared against.

Issue explanation: In a loop condition, comparison of a value of a
narrow type with a value of a wide type may result in unexpected
behavior if the wider value is sufficiently large (or small). This
is because the narrower value may overflow. This can lead to an
infinite loop.

Cc: Liming Gao [email protected]
Cc: Gua Guo [email protected]
Cc: Prakashan Krishnadas Veliyathuparambil [email protected]
Cc: K N Karthik [email protected]
Signed-off-by: Michael Kubacki [email protected]
Reviewed-by: Gua Guo [email protected]
(cherry picked from commit 33c81c2)
- 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
- CodeQL locally and in CI.
- MdeModulePkg build and CI.
Integration Instructions

N/A

[CHERRY-PICK] MdeModulePkg/Bus/Usb/UsbNetwork: Check array index range before access @makubacki (#774)
Change Details
## Description
Checks that an offset used to access array elements is within
the expected range before accessing the array item.

Cc: Liming Gao [email protected]
Cc: Ray Ni [email protected]
Cc: Rebecca Cran [email protected]
Cc: Richard Ho [email protected]
Signed-off-by: Michael Kubacki [email protected]
Reviewed-by: Liming Gao [email protected]
(cherry picked from commit 1f161a7)
- 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
- CodeQL locally and in CI.
- MdeModulePkg build and CI.
Integration Instructions

N/A

🐛 Bug Fixes

BmpCheckPlugin: Pass build vars to FDF parser @makubacki (#776)
Change Details
## Description
Updates the BmpCheckPlugin to pass build and DSC local variables
to the FDF parser.

Error example:
```
FileNotFoundError:
$(SHARED_CRYPTO_PATH)/Driver/Bin/CryptoDriver.DXE.inc.fdf
```
- 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
- Repro problem using the plugin with shared crypto set as a
  build variable (SHARED_CRYPTO_PATH) before the change.
- Verify the plugin succeeds after the change.
Integration Instructions

Update to the Mu Basecore revision if an error from BmpCheckPlugin
similar to the one in the error example given in the description
is observed.

🔐 Security Impacting

CryptoPkg: Update shared crypto to 2023.11.2 @makubacki (#777)
Change Details
## Description
Includes the following two changes:
- Crypto binary is based on the Mu Basecore 202311 branch
- CryptoPkg/BaseCryptLib: Add additional RSAES-OAEP crypto functions
This updates the crypto binary ext dep from a RC with the RSAES-OAEP release
(built from a one-off release branch) to a binary built from the
mu_crypto_release 202311 branch.

See the 2023.11.2 release notes for more details:
https://github.com/microsoft/mu_crypto_release/releases/tag/v2023.11.2
- 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 shared crypto binary release notes.

Integration Instructions

Updating to this Mu Basecore commit will include the interface changes in
CryptoPkg that need to be paired with the shared crypto binary updated in
this ext dep update.

CryptoPkg/BaseCryptLib: add additional RSAES-OAEP crypto functions @cmruffin (#771)
Change Details
## Description Expand the availability of the RSAES-OAEP crypto capability in BaseCryptLib. Applications using RSA crypto functions directly from OpensslLib can transition to BaseCryptLib to take advantage of the shared crypto feature in CryptoDxe.
- Impacts functionality?
- Impacts security?
- Breaking change?
- Includes tests?
- Includes documentation?
How This Was Tested

Host-based unit tests, end-to-end testing with shared crypto binary.

Integration Instructions

Depends on implementation in mu_crypt_release/CryptoBinPkg/OpensslLib.

**F...

Contributors

cmruffin and makubacki

Assets 4

19 Mar 01:55

github-actions

v2023110003.0.0

bb71205

v2023110003.0.0

What's Changed

⚠️ Breaking Changes

[Cherry-Pick] UefiCpuPkg: Add, Implement and Consume SmmCpuSyncLib library @apop5 (#766)
Change Details
## Description
SmmCpuSyncLib was introduced in EDK2 to move cpu synchronization tasks into their own library, out of the existing consuming code.

A newer version of platform reference code relies on this change. The platform reference code provides its own instance of the SmmCpuSyncLib to handle some additional conditions.
- 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 platform consuming these changes to windows.

Integration Instructions

SmmCpuSyncLib is a new library class added to UefiCpuPkg.

Existing projects consuming PiSmmCpuDxeSmm.inf will need to add a library instance for SmmCpuSyncLib to their dsc file.
SmmCpuSyncLib|UefiCpuPkg/Library/SmmCpuSyncLib/SmmCpuSyncLib.inf
```
  </blockquote>
  <hr>
</details>
```

[REBASE \& FF] Restructure ArmPkg Dependency Removal Commits @os-d (#769)
Change Details
## Description
Commit 881c831082c1b2367ade5c4217d0177549b43958 originally removed ArmPkg dependencies from MdeModulePkg, NetworkPkg, and StandaloneMmPkg as well as the EmbeddedPkg dependency from StandaloneMmPkg.

Since then, MdeModulePkg has dropped its dependency on ArmPkg here: tianocore/edk2@019feb4.

This patchset reverts the originally PR, cherry-picks the above edk2 PR, and splits the original commit into package level commits for easier maintainability.

This patchset is not bisectable in the middle due to the unacceptable dependencies being added back temporarily.

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

Tested in CI.

Integration Instructions

These commits do not need special platform integration other than to be pulled as a whole set and not be bisected in the middle.
```
  </blockquote>
  <hr>
</details>
```

Full Changelog: v2023110002.0.1...v2023110003.0.0

Contributors

os-d and apop5

Assets 4

05 Mar 18:49

github-actions

v2023110002.0.1

e6c62ff

v2023110002.0.1

What's Changed

🐛 Bug Fixes

Add BaseLib to StackCheckLib, Move Some Stack Check Functions to Assembly to Avoid Over Optimization @TaylorBeebe (#759)
Change Details
## Description
1. StackCheckLib depends on BaseLib and it was not listed in the library INF files.
2. CpuDeadLoop() within __GSHandlerCheck and __report_rangecheckfailure were being optimized out on release builds due to the /OPT:REF linker option. This PR moves __GSHandlerCheck and __report_rangecheckfailure to assembly code so CpuDeadLoop() is not optimized out.
- 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 MSVC build.

Integration Instructions

N/A

Full Changelog: v2023110002.0.0...v2023110002.0.1

Contributors

TaylorBeebe

Assets 4

Releases: microsoft/mu_basecore

v2023110005.0.0

What's Changed

Preface

Description

How This Was Tested

Integration Instructions

How This Was Tested

Integration Instructions

⚠️ Breaking Changes

How This Was Tested

Integration Instructions

🐛 Bug Fixes

How This Was Tested

Integration Instructions

🔐 Security Impacting

Contributors

v2023110004.0.0

What's Changed

How This Was Tested

Integration Instructions

How This Was Tested

Integration Instructions

Description

How This Was Tested

Integration Instructions

⚠️ Breaking Changes

How This Was Tested

Integration Instructions

Contributors

v2023110003.1.3

What's Changed

🔐 Security Impacting

How This Was Tested

Integration Instructions

Contributors

v2023110003.1.2

What's Changed

How This Was Tested

Integration Instructions

🐛 Bug Fixes

How This Was Tested

Integration Instructions

Contributors

v2023110003.1.1

What's Changed

Description

How This Was Tested

Integration Instructions

How This Was Tested

Integration Instructions

Contributors

v2023020015.0.0

What's Changed

How This Was Tested

Integration Instructions

⚠️ Breaking Changes

How This Was Tested

Integration Instructions

How This Was Tested

Integration Instructions

🚀 Features & ✨ Enhancements

Contributors

v2023110003.1.0

What's Changed

Description

How This Was Tested

Integration Instructions

Description

How This Was Tested

Integration Instructions

🚀 Features & ✨ Enhancements

How This Was Tested

Integration Instructions

🐛 Bug Fixes

How This Was Tested

Integration Instructions

Contributors

v2023110003.0.1

What's Changed