06 Jun 18:54

github-actions

4298c31

v2023110008.1.0

What's Changed

[Rebase \& FF] Adding support for CLANGPDB build @kuqin12 (#848)
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 added the tools_def section for building AARCH64 target with CLANGPDB.

A few assembly files are fixed up to remove unsupported directives.

Lastly, an issue of uninitialized variable that might be used is fixed from DevicesPathLib.

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

This change is tested on QEMU SBSA platform and booted to UEFI shell.

Integration Instructions

Platforms that would like to build with CLANGPDB should specify TOOL_CHAIN_TAG=CLANGPDB to build with CLANGPDB.
```
  </blockquote>
  <hr>
</details>
```

[CHERRY-PICK] Pull in fixes in UefiCpuPkg where we can dereference a NULL pointer for mCpuHotPlugData.SmBase @kenlautner (#887)
Change Details
## Description
Cherry-pick the following two commits that fix some issues with previously cherry-picked UefiCpuPkg commits. This mainly fixes a NULL dereference bug.

tianocore/edk2@72c441d
tianocore/edk2@edc6681

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 Smm based intel physical platforms.

Integration Instructions

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

Added MockPciIoProtocol and MockLocalApicLib @v-bhavanisu (#890)
Change Details
# Preface
Please ensure you have read the contribution docs prior
to submitting the pull request. In particular,
pull request guidelines.

Description

Added MockPciIoProtocol and MockLocalApicLib to be used in GoogleTests

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

Integrated these into Intel Gen 11 for a GoogleTest and ensured no build errors

Integration Instructions

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

MuCodeQlQueries.qls: Pin to the 0.9.12 codeq/cpp-queries pack @makubacki (#882)
Change Details
## Description
The codeql/cpp-queries pack used in MuCodeQlQueries.qls was versioned
0.9.12 for the CodeQL CLI v2.17.3 release currently used.

https://github.com/github/codeql/blob/codeql-cli/v2.17.3/cpp/ql/src/qlpack.yml

This change pins that pack version to prevent the CodeQL CLI and
pack from getting out of sync until explicitly updated.
- Impacts functionality?
- Impacts security?
- Breaking change?
- Includes tests?
- Includes documentation?
How This Was Tested
- Verified the CodeQL query pack version listed is pulled.
Integration Instructions
- N/A - No change to queries used. Should prevent breaks in the future where
  the latest queries are no longer compatible with the current CodeQL CLI used.

🚀 Features & ✨ Enhancements

Add RNG PPI Support @makubacki (#881)
Change Details
## Description
MdePkg: Add Random Number Generator (RNG) PPI

Adds a new PPI that serves the same purpose as EFI_RNG_PROTOCOL in
DXE. This PPI can be produced by a PEIM to provide a dynamic interface
to RNG services in PEI.

This PPI is called EFI_RNG_PPI because it shares the exact same
interface with EFI_RNG_PROTOCOL which is described in the UEFI
Speficiation.

MdePkg: Add PeiRngLib

Adds a new PEI library instance for RngLib that uses the RNG services
provided by the RNG PPI.

This library instance will add a DEPEX on gEfiRngPpiGuid on modules
it links against. It can be used to allow PEIMs to get RNG support
over a dynamic interface.
- Impacts functionality?
- Impacts security?
- Breaking change?
- Includes tests?
- Includes documentation?
How This Was Tested
- MdePkg CI
- Verify the RNG PPI can be successfully produced and consumed
Integration Instructions

If a platform needs to share RNG support across a dynamic interface
between PEIMs, the RNG PPI can be used. PeiRngLib provides a RngLib
instance that use the RNG PPI. It will include a dependency on gEfiRngPpiGuid.

🐛 Bug Fixes

Set EFI\_MEMORY\_SP as System Memory @os-d (#886)
Change Details
## Description
When supplying DxeCore with a resource descriptor HOB, a platform can choose which memory type to specify. For EFI_MEMORY_SP resource descriptor HOBs, instead of blindly setting GcdReserved as the memory type, respect what the resource descriptor HOB specified. Closes #884.
- Impacts functionality?
  - Functionality - Does the change ultimately impact how firmware functions?
  - Examples:...

Contributors

makubacki, os-d, and 3 other contributors

Assets 4

24 May 00:55

github-actions

v2023020016.1.1

3ba6589

v2023020016.1.1

What's Changed

🔐 Security Impacting

Supports ARM Platforms without needing to disable PcdEnforceSecureRngAlgorithms @Flickdm (#855)
Change Details
## Description
This adds two additional options for "Secure RNG Algorithms"
```
 &gEfiRngAlgorithmArmRndr,           // unspecified SP800-90A DRBG via ARM RNDR register
 &gEfiRngAlgorithmRaw                  // Raw data from a NRBG (or a TRNG)
```
gEfiRngAlgorithmRaw takes data from the Hardware or CPU instruction
gEfiRngAlgorithmArmRndr is a newly proposed (and accepted) Guid that gets a "unspecified" SP800-90A algorithm from the CPU
- Impacts functionality?
  - Adds two new acceptable algorithms to NetworkPkg Secure list
- Impacts security?
  - Allows for additional ARM specific algorithm and RAW
- Breaking change?
- Includes tests?
- Includes documentation?
How This Was Tested

Tested on ARM platform

Integration Instructions

N/A

Full Changelog: v2023020016.1.0...v2023020016.1.1

Contributors

Flickdm

Assets 4

20 May 16:10

github-actions

v2023110007.1.0

b324d96

v2023110007.1.0

What's Changed

🚀 Features & ✨ Enhancements

Add the EFI\_RESOURCE\_ATTRIBUTE\_SPECIAL\_PURPOSE attribute. @Patrick-Payne (#851)
Change Details
## Description
Add the EFI_RESOURCE_ATTRIBUTE_SPECIAL_PURPOSE resource attribute as per the PI 1.8 spec. This flag is used to indicate that the memory should be treated as special purpose memory (SPM).

Also adds GCD code that marks the SPM with the EFI_MEMORY_SP bit in the memory map and sets the GCD memory type to EfiGcdMemoryTypeSystemMemory.
- Impacts functionality?
  - Functionality - Does the change ultimately impact how firmware functions?
  - This change impacts how special purpose memory is represented in HOBs and in the memory map.
- 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

stuart_ci_build passed clean.

Manual testing using UEFI firmware on a device showed the expected behavior when HOBs are marked with EFI_RESOURCE_ATTRIBUTE_SPECIAL_PURPOSE.

Integration Instructions

N/A

Full Changelog: v2023110007.0.0...v2023110007.1.0

Contributors

Patrick-Payne

Assets 4

24 Apr 04:12

github-actions

v2023110006.0.0

c3d12d3

v2023110006.0.0

What's Changed

⚠️ Breaking Changes

Set RO/XP On EfiRuntimeServicesCode Regions Outside of Loaded Image Memory @TaylorBeebe (#822)
Change Details
## Description
The Memory Attributes Table is generated by fetching the EFI memory map and splitting entries which contain loaded images so DATA and CODE sections have separate descriptors. The splitting is done via a call to SplitTable() which
marks image DATA sections with the EFI_MEMORY_XP attribute and CODE sections with the EFI_MEMORY_RO attribute when
splitting. After this process, there may still be EfiRuntimeServicesCode regions which did not have their attributes set because they are not part of loaded images.

This patch updates the MAT EnforceMemoryMapAttribute logic to set the access attributes of runtime memory regions which are not part of loaded images (have not had their access attributes set). The attributes of the code regions will be read-only and no-execute because the UEFI spec dictates that runtime code regions should only contain loaded EFI modules.

Refs:
1. https://edk2.groups.io/g/devel/topic/patch_v1_mdemodulepkg/105570114?p=,,,20,0,0,0::recentpostdate/sticky,,,20,2,0,105570114
2. https://edk2.groups.io/g/devel/topic/mdemodulepkg_fix_mat/105477564?p=,,,20,0,0,0::recentpostdate/sticky,,,20,2,0,105477564
- 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 Intel EDK2 consumers and on Q35

Integration Instructions

Project Mu consumers which allocate EfiRuntimeServicesCode regions outside of the PE loader may experience a break. If runtime executable code is necessary, this should be done via a loaded EFI module and not a random allocated buffer. If the EfiRuntimeServicesCode buffer only needs to be writable, then a buffer of type EfiRuntimeServicesData should be used instead.
```
  </blockquote>
  <hr>
</details>
```

🐛 Bug Fixes

Generate Random Stack Cookie Values in Module Build Path @TaylorBeebe (#825)
Change Details
## Description
If only a single module was being built instead of a platform DSC, the build scripts would not generate the random stack cookie values. On clean builds, this causes an error to be reported during the autogen process.

This PR updates build.py so the code path taken on module builds will generate the random stack cookie values.
- 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 specifying a build module on Q35.

Integration Instructions

N/A

🔐 Security Impacting

Set RO/XP On EfiRuntimeServicesCode Regions Outside of Loaded Image Memory @TaylorBeebe (#822)
Change Details
## Description
The Memory Attributes Table is generated by fetching the EFI memory map and splitting entries which contain loaded images so DATA and CODE sections have separate descriptors. The splitting is done via a call to SplitTable() which
marks image DATA sections with the EFI_MEMORY_XP attribute and CODE sections with the EFI_MEMORY_RO attribute when
splitting. After this process, there may still be EfiRuntimeServicesCode regions which did not have their attributes set because they are not part of loaded images.

This patch updates the MAT EnforceMemoryMapAttribute logic to set the access attributes of runtime memory regions which are not part of loaded images (have not had their access attributes set). The attributes of the code regions will be read-only and no-execute because the UEFI spec dictates that runtime code regions should only contain loaded EFI modules.

Refs:
1. https://edk2.groups.io/g/devel/topic/patch_v1_mdemodulepkg/105570114?p=,,,20,0,0,0::recentpostdate/sticky,,,20,2,0,105570114
2. https://edk2.groups.io/g/devel/topic/mdemodulepkg_fix_mat/105477564?p=,,,20,0,0,0::recentpostdate/sticky,,,20,2,0,105477564
- 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 Intel EDK2 consumers and on Q35

Integration Instructions

Project Mu consumers which allocate EfiRuntimeServicesCode regions outside of the PE loader may experience a break. If runtime executable code is necessary, this should be done via a loaded EFI module and not a random allocated buffer. If the EfiRuntimeServicesCode buffer only needs to be writable, then a buffer of type EfiRuntimeServicesData should be used instead.
```
  </blockquote>
  <hr>
</details>
```

📖 Documentation Updates

[Release/202311] Updates NetworkPkg/SecurityFixes.yaml to reflect the current state of CVE patches @Flickdm (#823)
Change Details
## Description
This updates the SecurityFixes.yaml file to indicate which CVE's have been patched in this repo. This commit makes the repo current with the state of NetworkPkg CVEs patched
- Impacts functionality?
- Impacts security?
- Breaking change?
- Includes tests?
- Includes documentation?
  - This updates the documentation
How This Was Tested

N/A

Integration Instructions

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

Full Changelog: v2023110005.0.1...v2023110006.0.0

Contributors

Flickdm and TaylorBeebe

Assets 4

23 Apr 22:03

github-actions

v2023110005.0.1

f26f86d

v2023110005.0.1

What's Changed

🐛 Bug Fixes

Bug: Fix incorrect CodeQL fix - REBASE with PR 6024 @spbrogan (#818)
Change Details
## Description
In commit 2998774 an unintentional code change in BmBoot BmExpandFileDevicePath was introduced. The change intended to fix a CodeQL error but introduced a failure with the boot managers ability to expand a "short" file device path boot option.
- 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 an x64 vm platform

Integration Instructions

n/a

Full Changelog: v2023110005.0.0...v2023110005.0.1

Contributors

spbrogan

Assets 4

Releases: microsoft/mu_basecore

v2023110008.1.0

What's Changed

Description

How This Was Tested

Integration Instructions

How This Was Tested

Integration Instructions

Description

How This Was Tested

Integration Instructions

How This Was Tested

Integration Instructions

🚀 Features & ✨ Enhancements

How This Was Tested

Integration Instructions

🐛 Bug Fixes

Contributors

v2023110008.0.0

What's Changed

How This Was Tested

Integration Instructions

How This Was Tested

Integration Instructions

How This Was Tested

Integration Instructions

How This Was Tested

Integration Instructions

⚠️ Breaking Changes

How This Was Tested

Integration Instructions

🚀 Features & ✨ Enhancements

Contributors

v2023020016.1.1

What's Changed

🔐 Security Impacting

How This Was Tested

Integration Instructions

Contributors

v2023020016.1.0

What's Changed

🚀 Features & ✨ Enhancements

How This Was Tested

Integration Instructions

📖 Documentation Updates

How This Was Tested

Integration Instructions

Contributors

v2023110007.1.0

What's Changed

🚀 Features & ✨ Enhancements

How This Was Tested

Integration Instructions

Contributors

v2023020016.0.1

What's Changed

How This Was Tested

Integration Instructions

🐛 Bug Fixes

How This Was Tested

Integration Instructions

Contributors

v2023110007.0.0

What's Changed

How This Was Tested

Integration Instructions

How This Was Tested

Integration Instructions

How This Was Tested

Integration Instructions

How This Was Tested

Integration Instructions

⚠️ Breaking Changes

🚀 Features & ✨ Enhancements

Specs

Changes

Contributors

v2023110006.0.0

What's Changed

⚠️ Breaking Changes