09 Apr 23:55

github-actions

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

05 Mar 15:24

github-actions

v2023110002.0.0

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

Releases: microsoft/mu_basecore

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

How This Was Tested

Integration Instructions

How This Was Tested

Integration Instructions

🐛 Bug Fixes

How This Was Tested

Integration Instructions

🔐 Security Impacting

How This Was Tested

Integration Instructions

How This Was Tested

Integration Instructions

Contributors

v2023110003.0.0

What's Changed

⚠️ Breaking Changes

How This Was Tested

Integration Instructions

How This Was Tested

Integration Instructions

Contributors

v2023110002.0.1

What's Changed

🐛 Bug Fixes

How This Was Tested

Integration Instructions

Contributors

v2023110002.0.0

What's Changed