CryptoPkg/OpensslLib: Create SM3-only version of the library
Create a special OpensslLib implementation that only exposes the SM3
routines that MbedTlsLib borrows from OpensslLib, to avoid having to
pull in other parts of OpenSSL that are not needed (e.g., via the
library constructor)
SM3 needs to be tested so we can verify that alternative implementations
(such as the one I will be contributing to BaseCryptLibMbedTls) as well
as the reference implementation produce the expected value.
Mike Beaton [Wed, 18 Sep 2024 15:40:08 +0000 (16:40 +0100)]
BaseTools: Fix multiple 'invalid escape sequence' warnings in tests
In Python 3.12 invalid escape sequences in strings moved from
DeprecationWarning to SyntaxWarning
(ref https://docs.python.org/3/whatsnew/changelog.html#python-3-12-0-final
and search for gh-98401). In a future Python version this will become
SyntaxError.
Multiple instances of these SyntaxWarnings are currently printed when
running the BaseTools tests using Python 3.12 (though without actually
failing the affected tests).
This commit updates all lines which were causing this type of warning.
Typical examples which needed fixing are:
- "BaseTools\Source\Python" representing a path: "\S" and "\P" are invalid
escape sequences, therefore left unchanged, therefore the test works
(with a warning in Python 3.12). r"BaseTools\Source\Python" represents
the same string, but with escapes turned off completely thus no warning.
- Where '\t\s' is used as a regex pattern, then chr(9) + '\\s' is sent
to the regex parser (with a warning in Python 3.12) since '\s' is not a
valid Python escape sequence. This works correctly, though arguably for
the wrong reasons. r'\t\s' sends the same as '\\t\\s', as originally
intended and with no warning.
(Note that ' and " are not fundamentally different in Python.)
BaseTools: Update RETURN_ERROR Macro in BaseTypes.h
This patch is to sync RETURN_ERROR macro with the
MdePkg/Include/Base.h
Ref: 1a89d9887f MdePkg:Update Return Error Macro in Base.h
Fixing RETURN_ERROR macro.
It is causing problem in Coverity Static analysis tool
as we are directly converting the UINT value to INTN.
Changing value from UINT to INTN might cause problema
Here we know that the values would not be in loss of data.
To increase the code quality and increase the static tool
analysis score we have to change it
Min M Xu [Mon, 9 Sep 2024 05:33:51 +0000 (13:33 +0800)]
UefiCpuPkg/MtrrLib: MtrrLibIsMtrrSupported always return FALSE in TD-Guest
Currently, TDX exposes MTRR CPUID bit to TDX VM. So based on the CPUID,
the guest software components (OVMF/TDVF and guest kernel) will access
MTRR MSRs. One problem for guest to use of MTRR is the change of MTRR
setting needs to set CR0.CD=1, which will case #VE for TDX.
For Linux kernel, there is a mechanism called SW defined MTRR introduced
by the patch https://lore.kernel.org/all/20230502120931.
20719-4-jgross@suse.com/. If this is integrated for TDX guest, then Linux
kernel will not access any MTRR MSRs.
So we update MtrrLibIsMtrrSupported() to always return false for TD-Guest,
then TDVF will not access MTRR MSRs at all.
Cc: Ray Ni <ray.ni@intel.com> Cc: Rahul Kumar <rahul1.kumar@intel.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Jiaxin Wu <jiaxin.wu@intel.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Binbin Wu <binbin.wu@intel.com> Signed-off-by: Min Xu <min.m.xu@intel.com>
This patch is to support VTUTF8 type for Putty function key map.
In Putty, it is required for translating a stream of Unicode characters
for function keys on UTF8 correctly.
BaseTools/tools_def ARM: Disable stack protector with CLANGDWARF
Clang insists on emitting a movt/movw pair into the function
pro/epilogues to load the stack protector reference value from memory,
and this movt/movw pair may turn out non-consecutively in the
instruction stream.
The resulting symbol reference cannot be fixed up by GenFw, as PE/COFF
always treats movt/movw as a pair, and the ELF-to-PE conversion will
therefore fail.
Just disable the stack protector when using CLANGDWARF.
Maintainers: Remove Ard Biesheuvel from all packages
As a Tianocore maintainer, I am responsible for the packages that I
maintain, and am therefore expected to respond in a timely manner to
pull requests affecting those packages. With the updated GitHub-based
workflow, this now results in daily GitHub spam inviting me to respond
to each PR as they are created by the respective authors.
However, I strongly feel that with responsibility should come with
delegated authority as well, and this has been stripped away over the
past couple of years. When other maintainers fail to respond (which has
become more common recently), or when there are glitches in the CI, I no
longer have any means to take charge and correct the situation.
The upshot is that I am struggling to do my work as a maintainer,
spending 90% of my time dealing with GitHub CI technicalities, or being
blocked on other work that is completely ignored by the other
maintainers.
This is a waste of my time, and therefore, of my employer's money, so I
feel I can no longer justify my involvement. I am therefore stepping
down as a maintainer.
This patch is to avoid configure SMBASE if SmBase relocation has been
done. If gSmmBaseHobGuid found, means SmBase info has been relocated
and recorded in the SmBase array. No need to do the relocation in
SmmCpuFeaturesInitializeProcessor().
UefiPayloadPkg: Move FADT check to consumer coode.
ACPI FADT HW register interface fields are
optional but current UPL common entry code made it
as mandatory which caused compatibility issue on
some platforms.
Solution is to move those FADT HW register fields
check code to consumer code so only ASSERT when
those fields are consumed with error.
Currently only AcpiTimerLib and ResetSystemLib
consuming those register fields so if platforms
configured UPL to different library instances the
FADT HW register fields are not consumed thus will
not cause ASSERT.
For reasons that are unclear, the Linaro EDK2 CI is throwing errors when
building ArmCrashDumpDxe with CLANGDWARF, as the resulting build
contains non-adjacet MOVW/MOVT pairs, which cannot be relocated
correctly in PE/COFF.
Let's build it only for AARCH64 - its utility on ARM is doubtful anyway.
The existing HttpBootUninstallCallback was passing the wrong handle (the
PrivateData root controller handle, not the correct child IPv4 or IPv6
NIC controller handle; cf HttpBootInstallCallback for matching logic) and
was also passing the address of a pointer to the interface to be removed
rather than the pointer itself, so always failed with EFI_NOT_FOUND.
This resulted in the prior behaviour that if multiple HTTP boot attempts
were made, on the second and subsequent attempts the instance of this
protocol installed by the first attempt would be re-used. As long as only
one driver using the protocol is installed, this ends up producing the
same results as if the protocol had been uninstalled then reinstalled
correctly.
After this commit, the protocol is installed at the start of an HTTP boot
attempt and uninstalled it at the end of it (assuming nothing else has
accessed the protocol in a way which blocks the uninstall).
It might seem attractive to add an ASSERT to confirm when debugging
that the uninstall succeeds as expected, but this is recommended against
because uninstallation of protocol interfaces is allowed to fail under
the UEFI model:
https://edk2.groups.io/g/devel/message/117469.
An ASSERT could therefore arise from a sequence of events which is
perfectly valid - or at least is out of the control of this driver.
Dhaval [Tue, 13 Aug 2024 07:03:58 +0000 (12:33 +0530)]
UefiPayloadPkg: Add support for Root bridge parser
In order to properly enable multisegment RB, we need
to grab ecam data from the FDT for each bridge.
Current UNIVERSAL_PAYLOAD_PCI_ROOT_BRIDGES struct from
MdeModulePkg does not include definition for ecam. In
order to maintain backward compatibility and also avoid
diverging too much from core, we are going to define a
new HOB for UPL segment information and pass it to
GetPciSegmentInfo function. Ths function then grabs specifically
ecam info from the segment hob along with other rb specific
information to create final RB info required by multi segment
PCI driver.
Additionally we would like to support legacy implementations which
rely on ACPIBoard HOB to fill up segment info. So if UplSegmentInfo Hob
is not found we try and look for other hob.
Dhaval [Thu, 29 Aug 2024 05:06:59 +0000 (10:36 +0530)]
UefiPayloadPkg: Add support for Special Purpose memory
We need to let UEFI know that there are cetain memory types
which are special purpose (CXL/HBM) etc and we may want to
avoid using them for UEFI purposes. Hence UPL needs to know
about such memory types.
Dhaval [Mon, 12 Aug 2024 16:51:20 +0000 (22:21 +0530)]
UefiPayloadPkg: Remove unnecessary ACPI checks
We do not need to go deep into verifying all ACPI tables
at this stage. TODO: Just a simple ACPI header signature
check should be good enough. For now just commenting out
asserts that mandate one to have various tables which is
not applicable to all platforms.
Dhaval [Fri, 30 Aug 2024 14:56:34 +0000 (20:26 +0530)]
UefiPayloadPkg: Handle ordering issue with option node
Option node provides info that is to be consumed by during
metadata creation for other nodes like root bridge; pci-enum-done
etc. Handle that dependency by storing option values in a variable
and then apply it during post processing. Ideally such cross node
dependency should be avoided in design. Scope for futher improvements.
Gerd Hoffmann [Thu, 29 Aug 2024 07:20:29 +0000 (09:20 +0200)]
OvmfPkg/CpuHotplugSmm: delay SMM exit
Let APs wait until the BSP has completed the register updates to remove
the CPU. This makes sure all APs stay in SMM mode until the CPU
hot-unplug operation is complete, which in turn makes sure the ACPI lock
is released only after the CPU hot-unplug operation is complete.
Some background: The CPU hotplug SMI is triggered from an ACPI function
which is protected by an ACPI lock. The ACPI function is in the ACPI
tables generated by qemu.
Mike Beaton [Fri, 13 Sep 2024 07:23:17 +0000 (08:23 +0100)]
OvmfPkg/RiscVVirtQemu: Remove non-needed !include line
RiscVVirt.dsc.inc includes NetworkPkg/NetworkLibs.dsc.inc. However
RiscVVirt.dsc.inc is only ever included by RiscVVirtQemu.dsc, which
has already included NetworkPkg/Network.dsc.inc, a general include
file which brings in all the required includes for Network features
at once, including NetworkPkg/NetworkLibs.dsc.inc.
Pierre Gondois [Fri, 30 Aug 2024 11:42:52 +0000 (13:42 +0200)]
MdePkg/DxeRngLib: Add gEfiRngAlgorithmArmRndr to the secure algorithms
DxeRngLib iterates over a list of secure algorithms before trying
to use the default algorithm provided by the Rng protocol. Add
gEfiRngAlgorithmArmRndr to this list. The algorithm represented by
this GUID is a secure DRBG of an unknown type, implemented by the
aarch64 RNDR instruction.
On AARCH64 platform, use the RNDR instruction as the first option
if it is available.
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
Pierre Gondois [Thu, 29 Aug 2024 14:42:33 +0000 (16:42 +0200)]
MdePkg/DxeRngLib: Use PcdEnforceSecureRngAlgorithms for default algorithm
Use PcdEnforceSecureRngAlgorithms to allow using the Rng protocol
with the default algorithm. All previous call to the Rng protocol
are requesting a secure Rng algorithm.
Not specifying the Rng algorithm GUID to use is considered unsecure.
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
Add a library constructor which:
- locate the RNG prototocol and keep a reference to it in order to avoid
locating it multiple times (for each random number generation)
- check which secure algorithm is available on the platform.
This avoids to try each secure algorithm until finding one
available for each random number generation call.
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
Pierre Gondois [Thu, 29 Aug 2024 14:31:45 +0000 (16:31 +0200)]
MdePkg: Move PcdEnforceSecureRngAlgorithms from NetworkPkg
The PcdEnforceSecureRngAlgorithms Pcd enforces the use of RNG
algorithms defined by the UEFI spec. To re-use the Pcd in other
packages and have a generic mean to control the usage of unsecure
algorithms, move the Pcd to the MdePkg.
Continuous-integration-options: PatchCheck.ignore-multi-package Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
Leandro Becker [Tue, 27 Aug 2024 15:17:10 +0000 (12:17 -0300)]
NetworkPkg/HttpBootDxe: Resume an interrupted boot file download.
When the boot file download operation is interrupted for some reason,
HttpBootDxe will use HTTP Range header to try resume the download
operation reusing the bytes downloaded so far.
Signed-off-by: Leandro Gustavo Biss Becker <lbecker@positivo.com.br>
Ken Lautner [Wed, 28 Aug 2024 17:55:09 +0000 (10:55 -0700)]
MdeModulePkg: Fix buffer overflow in MergeMemoryMap
Check that the next map entry is valid before dereferencing to merge the
guard pages. If the final entry is at the end of a page with no valid page
following it, then this can cause an access violation.
Taylor Beebe [Fri, 14 Jun 2024 21:07:33 +0000 (14:07 -0700)]
BaseTools: Update Stack Cookie Logic
This patch 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.
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 patch 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.
Signed-off-by: Oliver Smith-Denny <osde@linux.microsoft.com>
Add StackCheckLib for Target and Host based unit tests. Host
based unit tests are treated specially, because MSVC built
host based unit tests use the MSVC C runtime lib to provide
the stack cookie definitions, but GCC built host based unit
tests use our implementation, as we do not link against a
C runtime lib that provides the definitions.
Signed-off-by: Oliver Smith-Denny <osde@linux.microsoft.com>
Taylor Beebe [Tue, 27 Aug 2024 21:34:35 +0000 (14:34 -0700)]
MdePkg: Create Stack Check Lib
StackCheckLib contains the required functionality for initializing
the stack cookie value, checking the value, and triggering an interrupt
when a mismatch occurs. The stack cookie is a random value placed on the
stack between the stack variables and the return address so that
continuously writing past the stack variables will cause the stack cookie
to be overwritten. Before the function returns, the stack cookie value
will be checked and if there is a mismatch then StackCheckLib handles the
failure.
Because UEFI doesn't use the C runtime libraries provided by MSVC, the
stack check code is written in assembly within this library. GCC and
Clang compilers have built-in support for stack cookie checking, so this
library only handles failures.
Signed-off-by: Oliver Smith-Denny <osde@linux.microsoft.com>
Taylor Beebe [Tue, 27 Aug 2024 21:31:48 +0000 (14:31 -0700)]
MdePkg: Create Stack Check Null Libs
Add Null libs for Stack Check and Stack Check Failure Hook Lib that
allow a platform to opt out of stack checks and the stack check failure
hook lib.
StackCheckLib allows implementation (or in this case null implementation)
of stack checks on binaries. There is a Host Application specific version
of this null lib because MSVC host applications must not be linked against
our lib (so the file here is a no-op but that doesn't cause the build
system to fail the build for not building a file for MSVC) as it links
against the MSVC C runtime lib that provides the stack cookie definitions.
GCC host applications do not link against such a C runtime lib and must
be linked against our version.
StackCheckFailureHookLib lets a platform do custom functionality when a
stack check failure occurs (such as log it to a platform defined
mechanism). The null lib simply returns.
Signed-off-by: Oliver Smith-Denny <osde@linux.microsoft.com>
This patch adds a PCD allowing a platform to specify
the interrupt vector to trigger on a stack check
failure. On x86, this is an offset into the IDT.
On ARM/AARCH64, this triggers a software interrupt
that can be decoded to indicate this was a stack
check failure.
Signed-off-by: Oliver Smith-Denny <osde@linux.microsoft.com>
Bret Barkelew [Thu, 28 Jan 2021 03:33:13 +0000 (03:33 +0000)]
UnitTestFrameworkPkg: Move common includes to their own file
Previously, the UnitTestFrameworkPkgHost.dsc.inc included the entire
UnitTestFrameworkPkgTarget.dsc.inc file. This is unnecessary for
most configurations, so copy the relevant common components to a
separate file.
This is required for stack cookies so that we can have stack
cookies on target based test apps but not on host base test apps.
Signed-off-by: Oliver Smith-Denny <osde@linux.microsoft.com>
NetworkPkg: PxeBcDhcp6GoogleTest: Fix Stack Smashing Unit Test
PxeBcDhcp6GoogleTest's MultipleDnsEntries test started to fail
with stack cookies added for host applications. Debugging this
showed that the test was attempting to copy two UINT16s to a
UINT8 Data[1] array allocated on the stack. This was moved to
a heap based allocation for a UINT32 to accommodate the proper
size. After this fix, the unit test passed with stack cookies
enabled.
Signed-off-by: Oliver Smith-Denny <osde@linux.microsoft.com>
Cache maintenance operations by set/way are not broadcast, and operate
on individual architected caches, making them suitable only for
en/disabling cache levels, which is the job of secure firmware, to be
carried out while the CPU in question is not taking part in the
cache coherency protocol.
Managing the clean/dirty state of a memory range can only be done using
cache maintenance by virtual address.
So drop the set/way handling from ArmLib for ARM and AARCH64, as there
is no context where it can be used correctly from EDK2.
MdePkg/ArmLib: Drop routines that maintain the entire D-cache
Cache maintenance on the D-cache hierarchy as a whole is not supported
by the ARM architecture, so drop the routines from ArmLib that pretend
to implement it.
7f17a15 (2024/02/22)
"OvmfPkg: Shell*.inc: allow building without network support"
breaks building OVMF with `-D NETWORK_ENABLE=0`.
Before this commit we could build OVMF e.g. with the following
command in the OvmfPkg directory:
./build.sh -D NETWORK_ENABLE=0
After the commit the same command fails early with:
/home/user/OpenSource/edk2/OvmfPkg/OvmfPkgX64.dsc(15):
error F001: Pcd (gEfiNetworkPkgTokenSpaceGuid.PcdAllowHttpConnections)
defined in DSC is not declared in DEC files referenced in INF files in
FDF. Arch: ['X64']
This problem also applies in the ArmVirtPkg
platforms which are modified here, but is currently
masked by another issue, namely that these platforms
incorrectly still include some network packages when
most are disabled. (A fix for this was previously applied,
for OvmfPkg Intel platforms only, by d933ec1 followed by 7f17a15 .)
This commit was created at the same time as the
commits resolving this issue in NetworkPkg and
OvmfPkg. It makes conditional the Pcd references
in ArmVirtPkg platforms which will become references to
undefined Pcds as and when the other issue mentioned
above is fixed.
7f17a15 (2024/02/22)
"OvmfPkg: Shell*.inc: allow building without network support"
breaks building OVMF with `-D NETWORK_ENABLE=0`.
Before this commit we could build OVMF e.g. with the following
command in the OvmfPkg directory:
./build.sh -D NETWORK_ENABLE=0
After the commit the same command fails early with:
/home/user/OpenSource/edk2/OvmfPkg/OvmfPkgX64.dsc(15):
error F001: Pcd (gEfiNetworkPkgTokenSpaceGuid.PcdAllowHttpConnections)
defined in DSC is not declared in DEC files referenced in INF files in
FDF. Arch: ['X64']
The problem applies in Intel OvmfPkg platforms.
Additionally, it applies in various other OvmfPkg
platforms, but is masked buy another issue; namely
that these platforms incorrectly still include some
network packages when most are disabled.
(A fix for that issue has previously been
made, in OvmfPkg Intel platforms only, by d933ec1 followed by 7f17a15 .)
This commit conditionally removes the undefined Pcd references
in all OvmfPkg platforms which are now affected by this
issue, and in all those which would be affected as and
when the other issue mentioned above is fixed.
7f17a15 (2024/02/22)
"OvmfPkg: Shell*.inc: allow building without network support"
breaks building OVMF with `-D NETWORK_ENABLE=0`.
Before this commit we could build OVMF e.g. with the following
command in the OvmfPkg directory:
./build.sh -D NETWORK_ENABLE=0
After the commit the same command fails early with:
/home/user/OpenSource/edk2/OvmfPkg/OvmfPkgX64.dsc(15):
error F001: Pcd (gEfiNetworkPkgTokenSpaceGuid.PcdAllowHttpConnections)
defined in DSC is not declared in DEC files referenced in INF files in
FDF. Arch: ['X64']
This commit conditionally removes the undefined Pcd reference in
NetworkPkg which is part of this issue.
Similar changes are needed in separate commits for
OvmfPkg (and for ArmVirtPkg, since the issue also
exists there, although masked by another issue).
As per the emailed RFC in
https://edk2.groups.io/g/devel/topic/rfc_move/107675828,
this patch moves CompilerIntrinsicsLib from ArmPkg to
MdePkg as this library provides compiler intrinsics, which
are industry standard.
This aligns with the goal of integrating ArmPkg into existing
packages: https://bugzilla.tianocore.org/show_bug.cgi?id=4121.
The newly placed CompilerIntrinsicsLib is added to MdeLibs.dsc.inc
as every DSC that builds ARM/AARCH64 needs this library added. The
old location is removed from every DSC in edk2 in this commit also
to not break bisectability with minimal hoop jumping.
AsmMacroIoLib.h and AsmMacroIoLibV8.h are used by the
CompilerIntrinsicsLib, which is moving to MdePkg. These
functions provide standard definitions for ARM/AARCH64
assembly code, respectively, and so are moved to the arch
directories in MdePkg to avoid MdePkg having a
dependency on ArmPkg.
Now that the files are in Arm/ and AArch64/ directories,
the filenames are changed to AsmMacroLib.h as we can
distinguish the architecture from the path.
ArmPkg: CompilerIntrinsicsLib: Use AsmMacroIoLibV8.h for AARCH64 ASM
AArch64/ashlti3.S was using AsmMacroIoLib.h which is the ARM version
of these definitions. AsmMacroIoLibV8.h is the AARCH64 version of
these defintions. This patch moves that file to use the proper arch
file.
Signed-off-by: Oliver Smith-Denny <osde@linux.microsoft.com>
After the loongarch flash block size is changed from 128K to 256K,
qemu requires that the UEFI firmware size be aligned with the flash block size(256K).
Otherwise, the firmware cannot be loaded,
Use the following code to resolve the old firmware loading problem:
mv QEMU_EFI.fd QEMU_EFI.fd-bak
cat QEMU_EFI.fd-bak /dev/zero | head -c 16m > ./QEMU_EFI.fd
mv QEMU_VARS.fd QEMU_VARS.fd-bak
cat QEMU_VARS.fd-bak /dev/zero | head -c 16m > ./QEMU_VARS.fd
For the new firmware, we refer to other architecture UEFI and
set the UEFI firmware size to align with the flash block size(256K).
So for this patch, we set the UEFI firmware size to 256K alignment.
Cc: Bibo Mao <maobibo@loongson.cn> Cc: Chao Li <lichao@loongson.cn> Signed-off-by: Xianglai Li <lixianglai@loongson.cn>
Ken Lautner [Sat, 24 Aug 2024 00:41:49 +0000 (17:41 -0700)]
MdeModulePkg: Enable Data Terminal at end of serial
When a Serial device resets, the Modem Control Register Data Terminal
Ready and Request to Send need to be cleared also. Otherwise the
registers will be left in their previous state, and the connected device
will not be able to transmit data.
The natural aligmenent seems to be failed on some cases. So, this patch
intends to add the pack(1) to ensure the structure aligned with a
one-byte boundary.
Ashraf Ali [Fri, 6 Sep 2024 15:12:42 +0000 (20:42 +0530)]
Refactor SetMemWrapper to reduce binary size
Moved SetMemN API to a separate file to eliminate unnecessary inclusion
of InternalMemSetMem64 and InternalMemSetMem32 APIs in driver binary.
When the compiler linking the Object files it may not remove all the
unused from NASM OBJs. This change is to reorganize the C files to
minimize the impact of the NASM behavior resulting is code size
reduction.
Signed-off-by: Ashraf Ali <ashraf.ali.s@intel.com>
Jason1 Lin [Wed, 28 Aug 2024 09:36:11 +0000 (17:36 +0800)]
MdeModulePkg/DxeCapsuleLibFmp: Check BootService Status to Use ESRT Cache
- In c36414b131dfd0a1ca51f10f87a18955bc110ff2 change, it was introduced
the ReadyToBoot event check to prevent the boot service got called
in runtime to cause the issue.
- In this patch introduced the ExitBootService event to replace it.
It would be better to base on the BootService status to decide
the source of ESRT table.
- Based on the BootService availability to decide,
- Exit : Use cache ESRT table in IF-condition
- Not Exit: Use boot service to locate protocol in ELSE-condition
Co-authored-by: Dakota Chiang <dakota.chiang@intel.com> Signed-off-by: Jason1 Lin <jason1.lin@intel.com>
[1] Add the event of system resource table installed callback.
- Register the event in DxeRuntimeCapsuleLibConstructor ()
- Unregister the event in DxeRuntimeCapsuleLibDestructor ()
[2] Migrate the event to update the module variable to cache ESRT table
from ReadyToBoot to system resource table installed.
[3] Add the condition to free the pool of buffer when the "mEsrtTable"
is not NULL.
Co-authored-by: Dakota Chiang <dakota.chiang@intel.com> Signed-off-by: Jason1 Lin <jason1.lin@intel.com>
Report PXE error status via Status Code, with this design,
it will be flexible to register a status code handler
via gEfiRscHandlerProtocolGuid to output the customized error code
to other telemetry service.
Zhiguang Liu [Tue, 18 Jun 2024 08:13:12 +0000 (16:13 +0800)]
IntelFsp2Pkg: Support FSP API to save and restore page table
A potential issue may happen when FSP creates/changes page table while
bootloader doesn't expect page table being changed in FSP.
Current, FSP API support to save/restore stack, IDT and general purpose
registers. Following the same pattern, add save/restore page table
support to solve this issue.
Note that this feature only impacts FSP API mode, and is controlled
by PCD PcdFspSaveRestorePageTableEnable. For compatibility, the PCD
default value is set as FALSE.
Signed-off-by: Zhiguang Liu <zhiguang.liu@intel.com>
.pytool/EccCheck: Trim leading path to modified directory
The code changes in the patch is for trimming the leading path
to the modified directory in the .pytool/EccCheck script.
This is necessary when running Ecc on other repositories,
such as edk2-platforms, where the platform package is located
in a subfolder, like Platform/AMD/AmdPlatformPkg.
The EccCheck script checks for modified directories and expects them to start with the package name.
#
# Skip directory names that do not start with the package being scanned.
#
if file_dir.split('/')[0] != pkg:
continue
However, if the package name is in a subfolder,
the "git diff" command gives a relative path,
like Platform/AMD, which causes the condition to be false.
"M Platform/AMD/AmdPlatformPkg/Universal/LogoDxe/Logo.c"
As a result, EccCheck does not happen on modified files.
To fix this issue, the leading path needs to be trimmed
so that it starts from the directory name.
This change will not affect the existing check for the edk2 repository,
where all package names are at the first level directory.
Cc: Sean Brogan <sean.brogan@microsoft.com> Cc: Joey Vagedes <joey.vagedes@gmail.com> Cc: Michael D Kinney <michael.d.kinney@intel.com> Cc: Liming Gao <gaoliming@byosoft.com.cn> Signed-off-by: Abdul Lateef Attar <AbdulLateef.Attar@amd.com>
If we search the codebase for &gEdkiiVariablePolicyProtocolGuid
we can find two drivers which install this policy:
VariableRuntimeDxe (installed in VariableDxe.c) and
VariableSmmRuntimeDxe (installed in VariablePolicySmmDxe.c).
The .inf file for VariableRuntimeDxe incorrectly lists the protocol
as CONSUMES in the comment, so change this to PRODUCES.
BaseTools was moved out to a separate repo and consumed as a pip
module by edk2 CI. This process has not led to the desired goals
of doing so, so this patch removes the pip based BaseTools from
edk2 CI.
The original goal of moving BaseTools to a pip module was
primarily to speed up the development process, as the old edk2
mailing list was slow. However, with edk2 moving to PRs, it now
actually slows the BaseTools development process to have to do
a PR in another repo, publish the module, and then make a PR
in edk2 to consume the new BaseTools. It also holds up using
the features in a new BaseTools in other PRs.
There were other goals of moving, such as allowing projects to
use the BaseTools outside of edk2. This can still be accomplished
outside of this PR, this PR simply stops edk2 CI from using the
pip module.
Mike Beaton [Sun, 8 Sep 2024 10:33:43 +0000 (11:33 +0100)]
NetworkPkg/DxeNetLib: Update misleading comment
Commit 6862b9d538d96363635677198899e1669e591259 makes
more explicit the previous logic of the code anyway, which is that
it is (and was) only a fatal error if all secure algorithms fail.
However the comment updated by this commit seems somewhat
incompatible with that change, and even with the previous code
(which operated as now, just logging different error messages).
This updates the comment to be more compatible with how the
code operates.
projects / people / aperard / ovmf.git / log