20 May 16:10

github-actions

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

22 Apr 17:12

github-actions

v2023110005.0.0

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 gaoliming@byosoft.com.cn
Reviewed-by: Star Zeng star.zeng@intel.com
Reviewed-by: Zhichao Gao zhichao.gao@intel.com
Cc: Zhiguang Liu zhiguang.liu@intel.com
Cc: Dandan Bi dandan.bi@intel.com
Cc: Star Zeng star.zeng@intel.com
Cc: Zhichao Gao zhichao.gao@intel.com
Cc: Benny Lin benny.lin@intel.com
Cc: Gua Guo gua.guo@intel.com
Cc: Michael D Kinney michael.d.kinney@intel.com
Cc: Liming Gao gaoliming@byosoft.com.cn

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

Releases: microsoft/mu_basecore

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

How This Was Tested

Integration Instructions

🐛 Bug Fixes

How This Was Tested

Integration Instructions

🔐 Security Impacting

How This Was Tested

Integration Instructions

📖 Documentation Updates

How This Was Tested

Integration Instructions

Contributors

v2023110005.0.1

What's Changed

🐛 Bug Fixes

How This Was Tested

Integration Instructions

Contributors

v2023020016.0.0

What's Changed

Description

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

🔐 Security Impacting

How This Was Tested

Integration Instructions

Contributors

v2023110005.0.0

What's Changed

Preface

Description