## 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
- [x] Impacts functionality?
- **Functionality** - Does the change ultimately impact how firmware
functions?
- Examples: Add a new library, publish a new PPI, update an algorithm,
...
- [x] 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, ...
- [x] 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.
(cherry picked from commit f26f86dd85)
# Description
In commit
29987744ef
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.
- [X] 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 VM
## Integration Instructions
NA
## Description
FreeMemoryMapStack() within CoreConvertPagesEx() may allocate pages
which, if the converted memory is being freed (implied by the new type
being EfiConventionalMemory), could cause the memory currently being
freed to be allocated during the convert process it if
CoreFreeMemoryMapStack() is called after AddRange(). So, if the convert
is being done due to a free pages call, free the memory map stack before
adding memory to the free list.
- [x] 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
## Description
Cherry-picked from
[release/202311](https://github.com/microsoft/mu_basecore/pull/799)
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?
- [X] Impacts security?
- Fixes vulnerabilities identified by Pixie Fail
- Updates the ISN generation to follow the
[specification](https://datatracker.ietf.org/doc/html/rfc9293#section-3.4.1)
- Replaces all instances of NET_RANDOM with the random number generator
provided by the platform.
- [X] Breaking change?
- Yes this depends on the Hash2ServiceProtocol. A platform must publish
these in order for these patches to work.
- [ ] Includes tests?
- [ ] Includes documentation?
## How This Was Tested
This was tested on a physical platform by PXEBooting and performing TCP
Connections through DFCI
## Integration Instructions
Ensure the platform publishes the HASH 2 Protocol.
---------
Signed-off-by: Doug Flick <dougflick@microsoft.com>
## Description
Some AARCH64 platforms are incompatible with 64k runtime granularity.
This PR adds a build option that is consumed to enable a deprecated
option to set the runtime page allocation granularity to 4k. This option
should not be used except for old platforms that cannot be updated to
comply with 64k runtime granularity. Using this option breaks
compatibility with the UEFI spec.
For each item, place an "x" in between `[` and `]` if true. Example:
`[x]`.
_(you can also check items in the GitHub UI)_
- [x] 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 with setting flag and unsetting.
## 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:
```c
MSFT:*_*_*_CC_FLAGS = /D __DEPRECATED_AARCH64_4K_RUNTIME_GRANULARITY
GCC:*_*_*_CC_FLAGS = -D __DEPRECATED_AARCH64_4K_RUNTIME_GRANULARITY
```
## 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 ()
)
)
```
- [x] Impacts functionality?
- **Functionality** - Does the change ultimately impact how firmware
functions?
- Examples: Add a new library, publish a new PPI, update an algorithm,
...
- [x] 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
## Description
When this patchset was sent to edk2, it was correctly reported that
VirtualSize should be used instead of SizeOfRawData. That patch cannot
be directly cherry-picked to release/202302 because the
ImagePropertiesRecordLib does not exist in this branch. See
1fb6462c67
for more details.
- [x] Impacts functionality?
- **Functionality** - Does the change ultimately impact how firmware
functions?
- Examples: Add a new library, publish a new PPI, update an algorithm,
...
- [x] 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 several virtual and physical platforms to an OS.
## Integration Instructions
N/A.
## 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.
- [x] Impacts functionality?
- **Functionality** - Does the change ultimately impact how firmware
functions?
- Examples: Add a new library, publish a new PPI, update an algorithm,
...
- [x] 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
## Description
There were a lot of issues with 64k as a runtime page allocation
granularity for ARM64 when this was removed from Project Mu. These
issues have been fixed and 64k OSes have been confirmed to boot with
proper Memory Attribute Tables.
See https://github.com/microsoft/mu_basecore/pull/764 for the last group
of core changes required for 64k runtime page allocation granularity on
ARM64.
This reverts commit
e640f2cc23.
- [x] Impacts functionality?
- **Functionality** - Does the change ultimately impact how firmware
functions?
- Examples: Add a new library, publish a new PPI, update an algorithm,
...
- [x] 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, ...
- [x] 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 multiple ARM64 physical and virtual platforms.
## Integration Instructions
ARM64 platforms should set the section alignment of RUNTIME_DXE_DRIVERs
to 0x10000 to match the expectations of the UEFI spec 2.10.
When an ImageRecord is created in some places, it reports the
CodeSegmentSize as the SizeOfRawData from the image. However, the image
as loaded into memory is aligned to the SectionAlignment, so
SizeOfRawData is under the actual size in memory. This is important,
because the memory attributes table uses these image records to create
its entries and it will report that the alignment of an image is
incorrect, even though the actual image is correct.
This was discovered on ARM64, which has a 64k runtime page granularity
alignment, which is backed by a 64k section alignment for
DXE_RUNTIME_DRIVERs. The runtime code and data was correctly being
loaded into memory, however the memory attribute table was incorrectly
reporting misaligned ranges to the OS, causing attributes to be
ignored for these sections for OSes using greater than 4k pages.
This patch correctly aligns the CodeSegmentSize to the SectionAlignment
and the corresponding memory attribute table entries are now correctly
aligned and pointing to the right places in memory.
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Leif Lindholm <quic_llindhol@quicinc.com>
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Sami Mujawar <sami.mujawar@arm.com>
Cc: Taylor Beebe <taylor.d.beebe@gmail.com>
Signed-off-by: Oliver Smith-Denny <osde@linux.microsoft.com>
This commit enforces the heap guard limitation that systems with
a runtime page allocation granularity that does not equal the
EFI_PAGE_SIZE cannot have page or pool guards set for
EfiRuntimeServicesCode, EfiRuntimeServicesData, EfiACPIMemoryNVS,
and EfiReservedMemoryType. This is to preserve alignment requirements
without extending the page guard size to very large granularities.
Currently, there are multiple issues when page or pool guards are
allocated for runtime memory regions that are aligned to
non-EFI_PAGE_SIZE alignments. Multiple other issues have been fixed
for these same systems (notably ARM64 which has a 64k runtime page
allocation granularity) recently. The heap guard system is only built
to support 4k guard pages and 4k alignment.
Today, the address returned to a caller of AllocatePages will not be
aligned correctly to the runtime page allocation granularity, because
the heap guard system does not take non-4k alignment requirements into
consideration.
However, even with this bug fixed, the Memory Allocation Table cannot
be produced and an OS with a larger than 4k page granularity will not
have aligned memory regions because the guard pages are reported as
part of the same memory allocation. So what would have been, on an
ARM64 system, a 64k runtime memory allocation is actually a 72k
memory allocation as tracked by the Page.c code because the guard
pages are tracked as part of the same allocation. This is a core
function of the current heap guard architecture.
This could also be fixed with rearchitecting the heap guard system to
respect alignment requirements and shift the guard pages inside of the
outer rounded allocation or by having guard pages be the runtime
granularity. Both of these approaches have issues. In the former case,
we break UEFI spec 2.10 section 2.3.6 for AARCH64, which states that
each 64k page for runtime memory regions may not have mixed memory
attributes, which pushing the guard pages inside would create. In the
latter case, an immense amount of memory is wasted to support such
large guard pages, and with pool guard many systems could not support
an additional 128k allocation for all runtime memory.
The simpler and safer solution is to disallow page and pool guards for
runtime memory allocations for systems that have a runtime granularity
greater than the EFI_PAGE_SIZE (4k). The usefulness of such guards is
limited, as OSes do not map guard pages today, so there is only boot
time protection of these ranges. This also prevents other bugs from
being exposed by using guards for regions that have a non-4k alignment
requirement, as again, multiple have cropped up because the heap guard
system was not built to support it.
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4674
Github PR: https://github.com/tianocore/edk2/pull/5382
Cc: Leif Lindholm <quic_llindhol@quicinc.com>
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Sami Mujawar <sami.mujawar@arm.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Signed-off-by: Oliver Smith-Denny <osde@linux.microsoft.com>
Per the UEFI spec 2.10, section 2.3.6 (for the AARCH64 arch,
other architectures in section two confirm the same) the
memory types that need runtime page allocation granularity
are EfiReservedMemoryType, EfiACPIMemoryNVS, EfiRuntimeServicesCode,
and EfiRuntimeServicesData. However, legacy code was setting
runtime page allocation granularity for EfiACPIReclaimMemory
and not EfiReservedMemoryType. This patch fixes that error.
Cc: Leif Lindholm <quic_llindhol@quicinc.com>
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Sami Mujawar <sami.mujawar@arm.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Signed-off-by: Oliver Smith-Denny <osde@linux.microsoft.com>
Suggested-by: Ard Biesheuvel <ardb+tianocore@kernel.org>
CodeQL flags the Free Pages logic for not ensuring that
Entry is non-null before using it. Add a check for this
and appropriately bail out if we hit this case.
Signed-off-by: Oliver Smith-Denny <osde@linux.microsoft.com>
## 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.
- [x] 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
## 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.
- [x] Impacts functionality?
- **Functionality** - Does the change ultimately impact how firmware
functions?
- Examples: Add a new library, publish a new PPI, update an algorithm,
...
- [x] 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, ...
- [x] 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
Description
This change adds stack cookies to the build commands for IA32 modules
built with VS2019 and VS2022. It also adds stack cookies to GCC5
AARCH64 builds.
- [x] 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, ...
- [x] 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 on Q35 GCC and MSVC builds and an SBSA GCC build by
purposefully overflowing the stack.
Integration Instructions
Platforms will need to update to ensure that all modules have a
StackCheckLib instanced linked. The instances are:
StackCheckLibNull: Used to provide the cookie definitions but not
actually check the stack.
StackCheckLibBuildInit: Used to provide the cookie definitions where
the stack cookie value is initialized at
build time.
StackCheckLibRuntimeInit: Used to provide the cookie definitions where
the stack cookie value is initialized at
runtime.
Description
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.
- [x] Impacts functionality?
- **Functionality** - Does the change ultimately impact how firmware functions?
- Examples: Add a new library, publish a new PPI, update an algorithm, ...
- [x] 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, ...
- [x] 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 MSVC and GCC builds of Q35 and a GCC build of SBSA
by purposefully corrupting the stack.
Integration Instructions
Platforms will need to update their StackCheckFailureLib instance
to the new StackCheckFailureHookLib.
EXAMPLE:
```
StackCheckFailureHookLib|MdePkg/Library/StackCheckFailureHookLibNull/StackCheckFailureHookLibNull.inf
```
Description
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).
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).
This update also removes the stack cookie library definitions from
MdeLibs.dsc.inc due to GCC build issues when the instanced versions are
used during CI builds. The instanced versions will need to be explicitly
added to the platform DSC files, and this is acceptable because
platforms will likely want to mix and match the static and dynamic
versions of the library for each module type.
- [x] Impacts functionality?
- **Functionality** - Does the change ultimately impact how firmware functions?
- Examples: Add a new library, publish a new PPI, update an algorithm, ...
- [x] 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, ...
- [x] 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 a Q35 GCC and MSVC builds, and on an SBSA GCC build
by purposefully performing a stack overflow.
Integration Instructions
Platforms will need to explicitly declare the
StackCheckLib and StackCheckFailureLib instances for
their platforms.
EXAMPLE:
```
StackCheckFailureLib|MdePkg/Library/StackCheckFailureLibNull/StackCheckFailureLibNull.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
```
Description
This PR updates the GenC logic to generate a random stack cookie value
for the stack check libraries. These random values improve security
for modules which cannot update the global intrinsics.
- [x] 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 MSVC and GCC builds of Q35 and a GCC build of SBSA
by purposefully overflowing the stack.
Integration Instructions
N/A
Description
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.
- [x] 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 GCC and MSVC builds and an SBSA GCC build
by purposefully overflowing the stack when the NULL library
is in use.
Integration Instructions
N/A
Description
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.
- [x] 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
N/A
Removes edk2-basetools from pip-requirements.txt and any usage of it in
the CISettings.py. The is done as there are changes in the build tools
python source code that are available locally in BaseTools (as it is
managed by Project Mu) that is not available in edk2-basetools.
- [ ] Impacts functionality?
- **Functionality** - Does the change ultimately impact how firmware
functions?
- Examples: Add a new library, publish a new PPI, update an algorithm,
...
- [ ] Impacts security?
- **Security** - Does the change have a direct security impact on an
application,
flow, or firmware?
- Examples: Crypto algorithm change, buffer overflow fix, parameter
validation improvement, ...
- [ ] Breaking change?
- **Breaking change** - Will anyone consuming this change experience a
break
in build or boot behavior?
- Examples: Add a new library class, move a module to a different repo,
call
a function in a new library class in a pre-existing module, ...
- [ ] Includes tests?
- **Tests** - Does the change include any explicit test code?
- Examples: Unit tests, integration tests, robot tests, ...
- [ ] Includes documentation?
- **Documentation** - Does the change contain explicit documentation
additions
outside direct code modifications (and comments)?
- Examples: Update readme file, add feature readme file, link to
documentation
on an a separate Web page, ...
Verified the build system continues to use the local python source
N/A - only effects this repository's CI system.
# Preface
## Description
This integrates fixes for bugs 1-7 for the PixieFail NetworkPkg
vulnerabilities into mu_basecore.
- [ ] Impacts functionality?
- **Functionality** - Does the change ultimately impact how firmware
functions?
- Examples: Add a new library, publish a new PPI, update an algorithm,
...
- [X] Impacts security?
- Yes Patches the following CVEs:
- CVE-2023-45229
- CVE-2023-45230
- CVE-2023-45231
- CVE-2023-45232
- CVE-2023-45233
- CVE-2023-45234
- CVE-2023-45235
- [ ] Breaking change?
- No
- [X] Includes tests?
- Yes - provides unit tests to confirm the vulnerability has been fixed
and backwards compatibility has been maintained
- [X] Includes documentation?
- Yes - SecurityFixes.yaml explains which CVEs have been patched
## How This Was Tested
Unit Tests / PxeBoot on real hardware
## Integration Instructions
Take these changes if a merge conflict occurs
## Description
Some silicon code is making use of the CryptoPkg's Intrinsic lib.
Intrinsiclib was removed in 04bb719a6c.
Adding the functionality back to allow silicon code to use the library
while a better long term solution is created.
- [ ] Impacts functionality?
- **Functionality** - Does the change ultimately impact how firmware
functions?
- Examples: Add a new library, publish a new PPI, update an algorithm,
...
- [ ] Impacts security?
- **Security** - Does the change have a direct security impact on an
application,
flow, or firmware?
- Examples: Crypto algorithm change, buffer overflow fix, parameter
validation improvement, ...
- [ ] Breaking change?
- **Breaking change** - Will anyone consuming this change experience a
break
in build or boot behavior?
- Examples: Add a new library class, move a module to a different repo,
call
a function in a new library class in a pre-existing module, ...
- [ ] Includes tests?
- **Tests** - Does the change include any explicit test code?
- Examples: Unit tests, integration tests, robot tests, ...
- [ ] Includes documentation?
- **Documentation** - Does the change contain explicit documentation
additions
outside direct code modifications (and comments)?
- Examples: Update readme file, add feature readme file, link to
documentation
on an a separate Web page, ...
## How This Was Tested
## Integration Instructions
N/A
# Preface
Please ensure you have read the [contribution
docs](https://github.com/microsoft/mu/blob/master/CONTRIBUTING.md) prior
to submitting the pull request. In particular,
[pull request
guidelines](https://github.com/microsoft/mu/blob/master/CONTRIBUTING.md#pull-request-best-practices).
## Description
<_Please include a description of the change and why this change was
made._>
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
N/A
## Integration Instructions
N/A
Co-authored-by: Aaron <105021049+apop5@users.noreply.github.com>
## Description
Authenticated variables were updated to allow the choice of SHA256,
SHA384 or SHA512 for hashing. To accommodate this change, we need the
algorithms available for use. This change updates the STANDARD flavor of
shared crypto to include the SHA384 and SHA512 algorithms so that they
can be used by consumers of the binary.
There is no size impact for the STANDARD flavor because all of the SHA
implementations are built together in openssl. This simply enables their
use.
- [x] 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 locally generated binaries. SHA384 and SHA512 were available
to use.
## Integration Instructions
N/A
## Description
The GITHUB_TOKEN is used in the `gh release upload` command to
upload a new basetools release. This adds content write permission
to allow the upload to work when the default permission is read-only
for the token.
(cherry picked from commit 1cab22a70e)
- [ ] 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 failure with read-only token on fork. Confirmed success with
the change.
## Integration Instructions
N/A - Only affects local repro GitHub workflow.
Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
# Preface
Please ensure you have read the [contribution
docs](https://github.com/microsoft/mu/blob/master/CONTRIBUTING.md) prior
to submitting the pull request. In particular,
[pull request
guidelines](https://github.com/microsoft/mu/blob/master/CONTRIBUTING.md#pull-request-best-practices).
## Description
The existing assembly file for AARCH64 has a direct reference to
InternalAssertJumpBuffer, which is an external symbol, thus causing VC
to fail compilation for this file.
The change added the explicit import to resolve the symbol.
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 verified against QemuPkg CI build pipeline.
## Integration Instructions
N/A
(cherry picked from commit d51cd1b116)
## Description
Shared crypto binaries in this release include PEI and Standalone MM
AARCH64 builds.
- [x] Impacts functionality?
- **Functionality** - Does the change ultimately impact how firmware
functions?
- Examples: Add a new library, publish a new PPI, update an algorithm,
...
- [x] 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
- QemuQ35Pkg and QemuSbsaPkg CI, boot, and tests.
- Also test new AARCH64 binaries on a physical AARCH64 platform.
## Integration Instructions
Use the new PEI and Standalone MM AARCH64 binaries if needed for a
platform.
Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
## Description
The original implementation of autogenerated dsc files is requiring
platform owners to define all `CRYPTO_SERVICES` and `ARCH` variables
when the dsc is included. This would require certain platforms, such as
some AARCH64 platforms, to pull in unrelated library instances for BL32
or BL33 only builds.
This change updated the autogeneration script to only require `ARCH`
when `CRYPTO_SERVICES` is not `NONE`, and accordingly only include the
needed modules and libraries.
- [x] 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 was tested
## Integration Instructions
Platforms can define the `CRYPTO_SERVICES` to be `NONE` in order to
ignore all the libraries and components of this category.
The EFI_RNG_PROTOCOL can use the RngLib. The RngLib has multiple
implementations, some of them are unsafe (e.g. BaseRngLibTimerLib).
To allow the RngDxe to detect when such implementation is used,
add a GetRngGuid() function to the RngLib.
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Tested-by: Kun Qin <kun.qin@microsoft.com>
(cherry picked from commit 5443c2dc31)
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4504
The BaseRngLibTimerLib allows to generate number based on a timer.
This mechanism allows to have a basic non-secure implementation
for non-production platforms.
To bind and identify Random Number Generators implementations with
a GUID, an unsafe GUID should be added. This GUID cannot be added
to the MdePkg unless it is also added to a specification.
To keep the MdePkg self-contained, copy the BaseRngLibTimerLib to
the MdeModulePkg. This will allow to define an unsafe Rng GUID
in a later patch in the MdeModulePkg.
The MdePkg implementation will be removed later. This allows to give
some time to platform owners to switch to the MdeModulePkg
implementation.
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Tested-by: Kun Qin <kun.qin@microsoft.com>
In order to use PcdCpuRngSupportedAlgorithm in the MdePkg in a
following patch and to avoid making the MdePkg dependent on another
package, move PcdCpuRngSupportedAlgorithm to the MdePkg.
As the Pcd is only used for AARCH64, place it in an AARCH64
specific sections.
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Acked-by: Jiewen Yao <Jiewen.yao@intel.com>
Tested-by: Kun Qin <kun.qin@microsoft.com>
(cherry picked from commit 65b5dd828e)
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4441
The EFI_RNG_PROTOCOL can rely on the RngLib. The RngLib has multiple
implementations, some of them are unsafe (e.g. BaseRngLibTimerLib).
To allow the RngDxe to detect when such implementation is used,
a GetRngGuid() function is added in a following patch.
Prepare GetRngGuid() return values and add a gEdkiiRngAlgorithmUnSafe
to describe an unsafe implementation, cf. the BaseRngLibTimerLib.
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Tested-by: Kun Qin <kun.qin@microsoft.com>
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4441
The EFI_RNG_PROTOCOL can rely on the RngLib. The RngLib has multiple
implementations, some of them are unsafe (e.g. BaseRngLibTimerLib).
To allow the RngDxe to detect when such implementation is used,
a GetRngGuid() function is added in a following patch.
Prepare GetRngGuid() return values and add a gEfiRngAlgorithmArmRndr
to describe a Rng algorithm accessed through Arm's RNDR instruction.
[1] states that the implementation of this algorithm should be
compliant to NIST SP900-80. The compliance is not guaranteed.
[1] Arm Architecture Reference Manual Armv8, for A-profile architecture
sK12.1 'Properties of the generated random number'
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Tested-by: Kun Qin <kun.qin@microsoft.com>
(cherry picked from commit cf07238e5f)
## Description
The current dependency evaluator violates the memory access permission
when patching depex grammar directly in the read-only depex memory area.
Laszlo pointed out the optimization issue in the thread (1) "Memory
Attribute for depex section" and provided suggested patch to remove the
perf optimization.
In my testing, removing the optimization does not make significant perf
reduction. That makes sense that StandaloneMM dispatcher only searches
in MM protocol database and does not depend on UEFI/DXE protocol
database. Also, we don't have many protocols in StandaloneMM like
UEFI/DXE.
From Laszlo,
"The patch removes the EFI_DEP_REPLACE_TRUE handling altogether, plus it
CONST-ifies the Iterator pointer (which points into the DEPEX section),
so that the compiler catch any possible accesses at *build time* that
would write to the write-protected DEPEX memory area."
(1) https://edk2.groups.io/g/devel/message/113531
Signed-off-by: Nhi Pham <nhi@os.amperecomputing.com>
Tested-by: levi.yun <yeoreum.yun@arm.com>
Reviewed-by: levi.yun <yeoreum.yun@arm.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
(cherry picked from commit 2ddae5df31)
- [ ] 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
- QemuSbsaPkg boot (with StandaloneMmPkg core)
## Integration Instructions
- N/A
Co-authored-by: Laszlo Ersek <lersek@redhat.com>
## Description
Generates shared crypto files for PEI and Standalone MM AARCH64.
This will be used for an upcoming binary release from
mu_crypto_release
(cherry picked from commit 440050aa28)
- [ ] 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 PEI and Standalone MM AARCH64 files are produced in generated
output.
## Integration Instructions
- Use the PEI and Standalone MM AARCH64 binaries if needed for a
platform following
the normal shared binary integration instructions.
Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
## Description
Adds the IntrinsicLib library class to allow the library to satisfy
dependencies on that class where needed.
Adds a strcmp implementation which is needed when building OpenSSL
for AARCH64 (with Visual Studio or GCC).
(cherry picked from commit dea7433b0e)
- [x] 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
- Build OpensslPkg with VS for IA32, X64, and AARCH64
- Build OpensslPkg with GCC for IA32, X64, and AARCH64
- Verify intrinsic linking is satisfied
## Integration Instructions
- Use where IntriniscLib is needed if applicable
- Backward compatible
Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
## Description
The CryptoPkg/Private directory no longer exists. Replace with
the EDK II Crypto protocol definition in CryptoPkg/Include/Protocol
which
is identical.
(cherry picked from commit 46a55e136c)
- [ ] Impacts functionality?
- **Functionality** - Does the change ultimately impact how firmware
functions?
- Examples: Add a new library, publish a new PPI, update an algorithm,
...
- [ ] Impacts security?
- **Security** - Does the change have a direct security impact on an
application,
flow, or firmware?
- Examples: Crypto algorithm change, buffer overflow fix, parameter
validation improvement, ...
- [ ] Breaking change?
- **Breaking change** - Will anyone consuming this change experience a
break
in build or boot behavior?
- Examples: Add a new library class, move a module to a different repo,
call
a function in a new library class in a pre-existing module, ...
- [ ] Includes tests?
- **Tests** - Does the change include any explicit test code?
- Examples: Unit tests, integration tests, robot tests, ...
- [ ] Includes documentation?
- **Documentation** - Does the change contain explicit documentation
additions
outside direct code modifications (and comments)?
- Examples: Update readme file, add feature readme file, link to
documentation
on an a separate Web page, ...
## How This Was Tested
- Run `generate_cryptodriver.py` to generate crypto binaries
## Integration Instructions
N/A - Only impacts the script
Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
## Description
The UncrustifyCheck plugin passes os.stat.S_IWRITE to os.chmod, when
attempting to change file permissions. os.stat.S_IWRITE does not exist
as os.stat is a function. The correct value is stat.S_IWRITE.
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Sean Brogan <sean.brogan@microsoft.com>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
- [ ] 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 that when failing, the failure is no longer overshadowed by the
exception thrown for S_IWRITE not existing.
## Integration Instructions
N/A
Signed-off-by: Joey Vagedes <joey.vagedes@gmail.com>
## Description
Integrates edk2-pytool-extensions 0.27.0 and edk2-pytool-library 0.20.0,
which overhauls the database functionality to use an ORM for managing
the database schema and access to the database.
Updates the only plugin in MU_BASECORE that uses the database
functionality, HostBasedUnitTestRunner.
- [ ] 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, ...
- [x] 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 HostBaseUnitTestRunner works as expected with
`CC_REORGANIZE=TRUE`, which results in the Edk2DB functionality being
used.
## Integration Instructions
HostBasedUnitTestRunner will continue to work in the default
configuration, but setting `CC_REORGANIZE=TRUE` on the command line will
not work unless the consuming repository also updates the below:
- Update edk2-pytool-extensions >= v0.27.0
- Update edk2-pytool-library to >= v0.20.0
Description
Renames MemoryAttributeProtocol global to mMemoryAttributeProtocol
to match convention.
- [ ] 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, ...
- [x] 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
N/A
Integration Instructions
N/A
Description
As described in the enhanced memory protection document, entering
compatibility mode maps page zero, no longer applies attributes to
loaded images, allocates memory as RWX, and uninstalls the memory
attribute protocol. This patch implements compatibility mode in the
DXE Core as it is currently defined. Compatiblity mode is triggered
when a non-NXCOMPAT image is loaded.
- [x] Impacts functionality?
- **Functionality** - Does the change ultimately impact how firmware functions?
- Examples: Add a new library, publish a new PPI, update an algorithm, ...
- [x] 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 booting to Windows and SBSA booting to Ubuntu
Integration Instructions
N/A
Description
Because the memory attribute protocol may not be present on the
platform, this update uses the cpu arch protocol to update the
attributes of the AP buffer to avoid a fault when executing the
wakeup funnction.
- [x] 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 booting to Windows and SBSA booting to Ubuntu
Integration Instructions
N/A
Taylor Beebe
Sean Brogan
Doug Flick
Oliver Smith-Denny
Taylor Beebe
Joey Vagedes
kenlautner
Michael Kubacki
kuqin12
Project Mu UEFI Bot [bot]
dependabot[bot]
Pierre Gondois