Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=4682
Fixes: 725acd0b9c
Before commit 725acd0b9c ("UefiCpuPkg: Avoid assuming only one
smmbasehob", 2023-12-12), PiCpuSmmEntry() used to look up
"gSmmBaseHobGuid", and allocate "mCpuHotPlugData.SmBase" regardless of the
GUID's presence:
> - mCpuHotPlugData.SmBase = (UINTN *)AllocatePool (sizeof (UINTN) * mMaxNumberOfCpus);
> - ASSERT (mCpuHotPlugData.SmBase != NULL);
After commit 725acd0b9c, PiCpuSmmEntry() -> GetSmBase() would allocate
"mCpuHotPlugData.SmBase" only on the success path, and no allocation would
be performed on *any* of the error paths.
This caused a problem: if "mCpuHotPlugData.SmBase" was left NULL because
the GUID HOB was missing, PiCpuSmmEntry() would still be supposed to
allocate "mCpuHotPlugData.SmBase", just like earlier. However, because
commit 725acd0b9c conflated the two possible error modes (out of SMRAM,
and no GUID HOB), PiCpuSmmEntry() could not decide whether it should
allocate "mCpuHotPlugData.SmBase", or not. Currently, we never allocate if
GetSmBase() fails -- for any reason --, which means that on platforms that
don't produce the GUID HOB, "mCpuHotPlugData.SmBase" is left NULL, leading
to null pointer dereferences later, in PiCpuSmmEntry().
Now that a prior patch in the series distinguishes the two error modes
from each other, we can tell exactly when the GUID HOB is not found, and
reinstate the earlier "mCpuHotPlugData.SmBase" allocation for that case.
(With an actual error check thrown in, in addition to the original
"assertion".)
Cc: Dun Tan <dun.tan@intel.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Rahul Kumar <rahul1.kumar@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Reported-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Leif Lindholm <quic_llindhol@quicinc.com>
Reviewed-by: Rahul Kumar <rahul1.kumar@intel.com>
Reviewed-by: Gerd Hoffmann <kraxel@redhat.com>
Tested-by: Gerd Hoffmann <kraxel@redhat.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=4682
Commit 725acd0b9c ("UefiCpuPkg: Avoid assuming only one smmbasehob",
2023-12-12) introduced a helper function called GetSmBase(), replacing
the lookup of the first and only "gSmmBaseHobGuid" GUID HOB and
unconditional "mCpuHotPlugData.SmBase" allocation, with iterated lookups
plus conditional memory allocation.
This introduced a new failure mode for setting "mCpuHotPlugData.SmBase".
Namely, before commit 725acd0b9c, "mCpuHotPlugData.SmBase" would be
allocated regardless of the GUID HOB being absent. After the commit,
"mCpuHotPlugData.SmBase" could remain NULL if the GUID HOB was absent,
*or* one of the memory allocations inside GetSmBase() failed; and in the
former case, we'd even proceed to the rest of PiCpuSmmEntry().
In relation to this conflation of distinct failure modes, commit
725acd0b9c actually introduced a NULL pointer dereference. Namely, a
NULL "mCpuHotPlugData.SmBase" is not handled properly at all now. We're
going to fix that NULL pointer dereference in a subsequent patch; however,
as a pre-requisite for that we need to tell apart the failure modes of
GetSmBase().
For memory allocation failures, return EFI_OUT_OF_RESOURCES. Move the
"assertion" that SMRAM cannot be exhausted happen out to the caller
(PiCpuSmmEntry()). Strengthen the assertion by adding an explicit
CpuDeadLoop() call. (Note: GetSmBase() *already* calls CpuDeadLoop() if
(NumberOfProcessors != MaxNumberOfCpus).)
For the absence of the GUID HOB, return EFI_NOT_FOUND.
For good measure, make GetSmBase() STATIC (it should have been STATIC from
the start).
This is just a refactoring, no behavioral difference is intended (beyond
the explicit CpuDeadLoop() upon SMRAM exhaustion).
Cc: Dun Tan <dun.tan@intel.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Rahul Kumar <rahul1.kumar@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Leif Lindholm <quic_llindhol@quicinc.com>
Reviewed-by: Rahul Kumar <rahul1.kumar@intel.com>
Reviewed-by: Gerd Hoffmann <kraxel@redhat.com>
Tested-by: Gerd Hoffmann <kraxel@redhat.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4683
Add sample unit tests that always fail or generate unexpected
exceptions along with a new DSC file to build the unit tests
that always fail or generate unexpected exceptions. This can
be used to verify the log information on failures is accurate
and provides the correct information to determine the source
of the unit test failure.
Divide by zero is used to generate unexpected exceptions. The
compiler warnings for divide by zero are disables for the unit
tests that generate divide by zero exceptions on purpose.
These tests are not added to CI because CI would always fail.
The UnitTestFrameworkPkg.ci.yaml file is updated to ignore the
INF files for host-based testing that always fail.
Cc: Michael Kubacki <mikuback@linux.microsoft.com>
Cc: Sean Brogan <sean.brogan@microsoft.com>
Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Michael Kubacki <michael.kubacki@microsoft.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4683
Update GoogleTest samples to use EXPECT_ANY_THROW() instead
of ASSERT_DEATH(). ASSERT_DEATH() is a very slow method to
detect an expected ASSERT() condition. Throwing an exception
from ASSERT() and using EXPECT_ANY_THROW() is several orders
of magnitude faster.
Update GoogleTest sample with example of using EXPECT_THROW()
and EXPECT_THAT() to check for more specific ASSERT() conditions
that allow unit test cases to test functions that contain
more than one ASSERT() statement and verify that the expected
ASSERT() is the one that was actually triggered.
Update library mappings so target-based unit tests use
UnitTestDebugAssertLib.inf and host-based unit tests use
UnitTestDebugAssertLibHost.inf
Cc: Michael Kubacki <mikuback@linux.microsoft.com>
Cc: Sean Brogan <sean.brogan@microsoft.com>
Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Michael Kubacki <michael.kubacki@microsoft.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4683
Update GetActiveFrameworkHandle() to remove ASSERT() and require
caller to check for NULL.
This allows GetActiveFrameworkHandle() to be used to determine if the
current host-based test environment is framework/cmocka or gtest. In
the framework/cmocka host-based environment GetActiveFrameworkHandle()
returns non-NULL. In the gtest host-based environment
GetActiveFrameworkHandle() returns NULL.
Cc: Michael Kubacki <mikuback@linux.microsoft.com>
Cc: Sean Brogan <sean.brogan@microsoft.com>
Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Michael Kubacki <michael.kubacki@microsoft.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4683
Update MSFT CC_FLAGS for host-based unit tests to use /EHs
instead of /EHsc to support building C functions with SEH
(Structured Exception Handling) enabled. This is required to
build UnitTestDebugAssertLibHost.inf.
Update GCC CC_FLAGS for host-based unit tests to use -fexceptions
to support catching exceptions.
Update GoogleTestLib.h to include Throws() APIs that enable
unit tests to use EXPECT_THAT() to check for expected ASSERT()
conditions for a specific ASSERT() expression.
Update GCC CC_FLAGS to add --coverage for host-based builds
for all GCC tool chains.
Cc: Michael Kubacki <mikuback@linux.microsoft.com>
Cc: Sean Brogan <sean.brogan@microsoft.com>
Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Michael Kubacki <michael.kubacki@microsoft.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4683
Add /MT to MSFT CC_FLAGS to always use release libraries
when building host-based unit tests so any exceptions
generated during host-based test execution generate an
error message in stderr instead of a popup window.
Use /MTd when -D UNIT_TESTING_DEBUG is to use debug
libraries when building host-based unit tests so any
exceptions generated during host-based test execution
generate a popup window with option to attach a debugger.
Cc: Michael Kubacki <mikuback@linux.microsoft.com>
Cc: Sean Brogan <sean.brogan@microsoft.com>
Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Michael Kubacki <michael.kubacki@microsoft.com>
XenRealTimeClockLib is used to back the runtime services time functions,
so align the description of the function return values with the
defined values for these services as described in UEFI Spec 2.10.
REF: UEFI spec 2.10 section 8 Services ? Runtime Services
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Suqiang Ren <suqiangx.ren@intel.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
RealTimeClockLib is used to back the runtime services time functions, so
align the description of the function return values with the defined values
for these services as described in UEFI Spec 2.10.
REF: UEFI spec 2.10 section 8 Services ? Runtime Services
Cc: Leif Lindholm <quic_llindhol@quicinc.com>
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Signed-off-by: Suqiang Ren <suqiangx.ren@intel.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Reviewed-by: Leif Lindholm <quic_llindhol@quicinc.com>
RuntimeDxe is used to back the runtime services time functions,
so align the description of the function return values with the
defined values for these services as described in UEFI Spec 2.10.
REF: UEFI spec 2.10 section 8 Services ? Runtime Services
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Signed-off-by: Suqiang Ren <suqiangx.ren@intel.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
According to UEFI Spec 2.10 page 206, if any EFI_RUNTIME_SERVICES* calls
are not supported for use by the OS at runtime, an EFI_RT_PROPERTIES_TABLE
configuration table should be published describing which runtime services
are supported at runtime. So need to add EFI_UNSUPPORTED return for some
Runtime Service functions.
REF: UEFI spec 2.10 section 8 Services ? Runtime Services
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Zhiguang Liu <zhiguang.liu@intel.com>
Signed-off-by: Suqiang Ren <suqiangx.ren@intel.com>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
During the Incremental build GenerateByteArrayValue used to generate the
ByteArrayValue even when there is no change in the PCD/VPDs. which is
time consuming API based on the number of PCD/VPDs and SKU IDs.
The optimization is that GenerateByteArrayValue is used to store the
StructuredPcdsData in a JSON file for each of the arch. and during the
Incremental build this API will check, if there is any change in the
Structured PCD/VPDs then rest of the flow remains the same.
if there is no change then it will return the provious build data.
Flow:
during the 1st build StructuredPcdsData.json is not exists,
StructuredPcdsData will be dumped to json file. and it will copy the
output.txt as well.
Note: as the output.txt are different for different Arch, so it will be
stored in the Arch folder.
During the Incremental build check if there is any change in Structured
PCD/VPD. if there is a change in Structured VPD/PCD then recreate the
StructuredPcdsData.json, and rest of the flow remains same.
if there is no change in VPD/PCD read the output.txt and return the data
Unit Test:
Test1: Modified the Structured Pcds default from DEC file. current flow
is executing.
Test2: Override the default value of the PCD from DEC file. current flow
is executing.
Test3: Modified/Override the PCD from DSC file. current flow executing
Test4: Modified/Override the FDF from DSC file. current flow executing
Test5: update the default value from Command Line.current flow executing
Test6: Build without change in PCD in DSC, FDF, DEC and Command Line the
proposed changes will be executing, and the return data remains the same
with and without the changes.
Test7: Build with and without modified the include headers of Structured
PCDs. if there is any change in those Structured PCD header then
current flow will be executed.
With these changes it's helping to save around ~2.5min to ~3.5min of
Incremental build time in my build environment.
Sample PR: https://github.com/tianocore/edk2-basetools/pull/113
Cc: Yuwei Chen <yuwei.chen@intel.com>
Cc: Rebecca Cran <rebecca@bsdio.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Bob Feng <bob.c.feng@intel.com>
Cc: Amy Chan <amy.chan@intel.com>
Cc: Sai Chaganty <rangasai.v.chaganty@intel.com>
Cc: Digant H Solanki <digant.h.solanki@intel.com>
Signed-off-by: Ashraf Ali S <ashraf.ali.s@intel.com>
Reviewed-by: Yuwei Chen <yuwei.chen@intel.com>
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=4540
Bug Details:
PixieFail Bug #7
CVE-2023-45235
CVSS 8.3 : CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:H
CWE-119 Improper Restriction of Operations within the Bounds of
a Memory Buffer
Buffer overflow when handling Server ID option from a DHCPv6 proxy
Advertise message
Change Overview:
Performs two checks
1. Checks that the length of the duid is accurate
> + //
> + // Check that the minimum and maximum requirements are met
> + //
> + if ((OpLen < PXEBC_MIN_SIZE_OF_DUID) ||
(OpLen > PXEBC_MAX_SIZE_OF_DUID)) {
> + Status = EFI_INVALID_PARAMETER;
> + goto ON_ERROR;
> + }
2. Ensures that the amount of data written to the buffer is tracked and
never exceeds that
> + //
> + // Check that the option length is valid.
> + //
> + if ((DiscoverLen + OpLen + PXEBC_COMBINED_SIZE_OF_OPT_CODE_AND_LEN)
> DiscoverLenNeeded) {
> + Status = EFI_OUT_OF_RESOURCES;
> + goto ON_ERROR;
> + }
Additional code clean up and fix for memory leak in case Option was NULL
Cc: Saloni Kasbekar <saloni.kasbekar@intel.com>
Cc: Zachary Clark-williams <zachary.clark-williams@intel.com>
Signed-off-by: Doug Flick [MSFT] <doug.edk2@gmail.com>
Reviewed-by: Saloni Kasbekar <saloni.kasbekar@intel.com>
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=4539
Bug Details:
PixieFail Bug #6
CVE-2023-45234
CVSS 8.3 : CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:H
CWE-119 Improper Restriction of Operations within the Bounds of
a Memory Buffer
Buffer overflow when processing DNS Servers option in a DHCPv6
Advertise message
Change Overview:
Introduces a function to cache the Dns Server and perform sanitizing
on the incoming DnsServerLen to ensure that the length is valid
> + EFI_STATUS
> + PxeBcCacheDnsServerAddresses (
> + IN PXEBC_PRIVATE_DATA *Private,
> + IN PXEBC_DHCP6_PACKET_CACHE *Cache6
> + )
Additional code cleanup
Cc: Saloni Kasbekar <saloni.kasbekar@intel.com>
Cc: Zachary Clark-williams <zachary.clark-williams@intel.com>
Signed-off-by: Doug Flick [MSFT] <doug.edk2@gmail.com>
Reviewed-by: Saloni Kasbekar <saloni.kasbekar@intel.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4534
These tests confirm that the report bug...
"Out-of-bounds read when processing IA_NA/IA_TA options in a
DHCPv6 Advertise message"
..has been patched.
The following functions are tested to confirm an out of bounds read is
patched and that the correct statuses are returned:
Dhcp6SeekInnerOptionSafe
Dhcp6SeekStsOption
TCBZ4534
CVE-2023-45229
CVSS 6.5 : CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N
CWE-125 Out-of-bounds Read
Cc: Saloni Kasbekar <saloni.kasbekar@intel.com>
Cc: Zachary Clark-williams <zachary.clark-williams@intel.com>
Signed-off-by: Doug Flick [MSFT] <doug.edk2@gmail.com>
Reviewed-by: Saloni Kasbekar <saloni.kasbekar@intel.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4535
Confirms that reported issue...
"Buffer overflow in the DHCPv6 client via a long Server ID option"
..has been corrected by the provided patch.
Tests the following functions to ensure they appropriately handle
untrusted data (either too long or too small) to prevent a buffer
overflow:
Dhcp6AppendOption
Dhcp6AppendETOption
Dhcp6AppendIaOption
Cc: Saloni Kasbekar <saloni.kasbekar@intel.com>
Cc: Zachary Clark-williams <zachary.clark-williams@intel.com>
Signed-off-by: Doug Flick [MSFT] <doug.edk2@gmail.com>
Reviewed-by: Saloni Kasbekar <saloni.kasbekar@intel.com>
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=4535
Bug Details:
PixieFail Bug #2
CVE-2023-45230
CVSS 8.3 : CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:H
CWE-119 Improper Restriction of Operations within the Bounds
of a Memory Buffer
Changes Overview:
> -UINT8 *
> +EFI_STATUS
> Dhcp6AppendOption (
> - IN OUT UINT8 *Buf,
> - IN UINT16 OptType,
> - IN UINT16 OptLen,
> - IN UINT8 *Data
> + IN OUT EFI_DHCP6_PACKET *Packet,
> + IN OUT UINT8 **PacketCursor,
> + IN UINT16 OptType,
> + IN UINT16 OptLen,
> + IN UINT8 *Data
> );
Dhcp6AppendOption() and variants can return errors now. All callsites
are adapted accordingly.
It gets passed in EFI_DHCP6_PACKET as additional parameter ...
> + //
> + // Verify the PacketCursor is within the packet
> + //
> + if ( (*PacketCursor < Packet->Dhcp6.Option)
> + || (*PacketCursor >= Packet->Dhcp6.Option +
(Packet->Size - sizeof (EFI_DHCP6_HEADER))))
> + {
> + return EFI_INVALID_PARAMETER;
> + }
... so it can look at Packet->Size when checking buffer space.
Also to allow Packet->Length updates.
Lots of checks added.
Cc: Saloni Kasbekar <saloni.kasbekar@intel.com>
Cc: Zachary Clark-williams <zachary.clark-williams@intel.com>
Signed-off-by: Doug Flick [MSFT] <doug.edk2@gmail.com>
Reviewed-by: Saloni Kasbekar <saloni.kasbekar@intel.com>
CoreConnectSingleController() searches for the Driver Family Override
Protocol drivers by looping and checking each Driver Binding Handles.
This loop can be skipped by checking if any Driver Family Override
Protocol installed in the platform first, to improve the performance.
Cc: Ray Ni <ray.ni@intel.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
Signed-off-by: Zhi Jin <zhi.jin@intel.com>
CoreGetProtocolInterface() is called by CoreOpenProtocol(),
CoreCloseProtocol() and CoreOpenProtocolInformation().
Before CoreOpenProtocol() calls CoreGetProtocolInterface(), the input
parameter UserHandle has been already checked for validation. So does
CoreCloseProtocol().
Removing the handle validation check in CoreGetProtocolInterface()
could improve the performance, as CoreOpenProtocol() is called very
frequently.
To ensure the assumption that the caller of CoreGetProtocolInterface()
must pass in a valid UserHandle that is checked with CoreValidateHandle(),
add the parameter check in CoreOpenProtocolInformation(), and declare
CoreGetProtocolInterface() as static.
Reviewed-by: Ray Ni <ray.ni@intel.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
Signed-off-by: Zhi Jin <zhi.jin@intel.com>
This patch is to map SMRAM in 4K page granularity
during SMM page table initialization(SmmInitPageTable)
so as to avoid the SMRAM paging-structure layout
change when SMI happens (PerformRemainingTasks).
The reason is to avoid the Paging-Structure change
impact to the multiple Processors. Refer SDM section
"4.10.4" & "4.10.5".
Currently, SMM BSP needs to update the SMRAM range
paging attribute in smm page table according to the
SmmMemoryAttributesTable when SMM ready to lock
happens. If the SMRAM range is not 4k mapped in page
table, the page table update process may split 1G/2M
paging entries to 4k ones.Meanwhile, all APs are still
running in SMI, which might access the affected
linear-address range between the time of modification
and the time of invalidation access. That will be
a potential problem leading exception happens.
Signed-off-by: Dun Tan <dun.tan@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Reviewed-by: Jiaxin Wu <jiaxin.wu@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Rahul Kumar <rahul1.kumar@intel.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
This commit is to reduce and optimize access to
attribute in CpuPageTableLib.
Unreasonable writing to attribute of page table may
leads to expection.
The assembly code for C code Pnle->Bits.Present =
Attribute->Bits.Present looks like:
and dword [rcx], 0xfffffffe
and eax, 0x1
or [rcx], eax
In case Pnle->Bits.Present and Attribute->Bits.Present
is 1, Pnle->Bits.Present will be set to 0 for short
time(2 instructions) which is unexpected. If some other
core is accessing the page, it may leads to expection.
This change reduce and optimize access to attribute of
page table, attribute of page table is set only when it
need to be changed.
Signed-off-by: Zhou Jianfeng <jianfeng.zhou@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Reviewed-by: Jiaxin Wu <jiaxin.wu@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Rahul Kumar <rahul1.kumar@intel.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Code review tools like gerrit might use a 'Change-id' tag to track
the evolution of patches. This tag should be removed before
submitting a patch to the mailing-list.
It has been observed that contributors sometimes forget to remove
this tag. Add a check in PatchCheck.py to automate this.
Also add a '--ignore-change-id' command line parameter to ignore
the above check.
Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com>
Acked-by: Pedro Falcato <pedro.falcato@gmail.com>
Reviewed-by: Yuwei Chen <yuwei.chen@intel.com>
Reviewed-by: Rebecca Cran <rebecca@bsdio.com>
The current support within the boot SNP CPUID table processing mistakenly
swaps the ECX and EDX results. It does not have an effect at this time
because current CPUID results checking does not check ECX or EDX. However,
any future CPUID checks that need to check ECX or EDX may have erroneous
behavior.
Fix the assembler code to save ECX and EDX to the proper locations.
Fixes: 34819f2cac ("OvmfPkg/ResetVector: use SEV-SNP-validated CPUID values")
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
Reviewed-by: Michael Roth <michael.roth@amd.com>
Currently, if a MMI handler returns an unexpected failure status code,
ASSERT (FALSE) is used. It is more useful to use ASSERT_EFI_ERROR()
which also outputs the status code value.
Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
A recent change to the PciIoMap() function now propagates the return code
from the IoMmu protocol SetAttribute() operation. The implementation of
this operation in OvmfPkg/IoMmuDxe/CcIoMmu.c returns EFI_UNSUPPORTED,
resulting in a failure to boot the guest.
Provide an implementation for SetAttribute() that validates the IoMmu
access method being requested against the IoMmu mapping operation.
Suggested-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
Message-Id: <c0f9e95f557b601a045da015c1a97201e8aec2ab.1706634932.git.thomas.lendacky@amd.com>
Tested-by: Min Xu <min.m.xu@intel.com>
Reviewed-by: Min Xu <min.m.xu@intel.com>
The patch "[PATCH v3 1/2] StandaloneMmPkg: Make StandaloneMmCpu driver
architecture independent" (https://edk2.groups.io/g/devel/message/109178)
removed ArmPkg/ArmPkg.dec from the Packages section in the
INF file: StandaloneMmPkg/Drivers/StandaloneMmCpu/StandaloneMmCpu.inf
This change was done as part of making the StandaloneMmCpu driver
architecture independent.
Although this change is correct, it results in a side effect
here some platforms that utilise PCDs declared in ArmPkg.dec are
no longer declared.
An example of this issue can be seen when building
edk2-platforms/Platform/ARM/SgiPkg/PlatformStandaloneMm.dsc
$ build -a AARCH64 -t GCC -p Platform/ARM/SgiPkg/PlatformStandaloneMm.dsc
build.py...
/mnt/source/edk2-platforms/Platform/ARM/SgiPkg/PlatformStandaloneMm.fdf(23):
error F001: PCD (gArmTokenSpaceGuid.PcdFdBaseAddress) used in
FDF is not declared in DEC files.
As seen above, removing ArmPkg.dec from the Packages section in the
StandAloneMmCpu Driver Inf file triggers build failure.
Although, ArmPkg.dec is included in other Library Instances,
the build system does not include the declarations from
.dec files defined in Library instances.
The build system only includes the PCD declarations from DEC files
that are specified in INF files for Modules (components).
Therefore, extend the build system to include the Packages from
Library Instances so that the PCD declarations from the respective package
DEC files are included.
This patch can be seen on
https://github.com/LeviYeoReum/edk2/tree/levi/2848_dec_check_on_library
Signed-off-by: levi.yun <yeoreum.yun@arm.com>
Tested-by: Pierre Gondois <pierre.gondois@arm.com>
Reviewed-by: Rebecca Cran <rebecca@bsdio.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Provide an optional method for PEI to declare a specific address
range to use for the Memory Type Information bins. The current
algorithm uses heuristics that tends to place the Memory Type
Information bins in the same location, but memory configuration
changes across boots or algorithm changes across a firmware
updates could potentially change the Memory Type Information bin
location. If the bin locations move across an S4 save/resume
cycle, then the S4 resume may fail. Enabling this feature
increases the number of scenarios that an S4 resume operation
may succeed.
If the HOB List contains a Resource Descriptor HOB that
describes tested system memory and has an Owner GUID of
gEfiMemoryTypeInformationGuid, then use the address range
described by the Resource Descriptor HOB as the preferred
location of the Memory Type Information bins. If this HOB is
not detected, then the current behavior is preserved.
The HOB with an Owner GUID of gEfiMemoryTypeInformationGuid
is ignored for the following conditions:
* The HOB with an Owner GUID of gEfiMemoryTypeInformationGuid
is smaller than the Memory Type Information bins.
* The HOB list contains more than one Resource Descriptor HOB
with an owner GUID of gEfiMemoryTypeInformationGuid.
* The Resource Descriptor HOB with an Owner GUID of
gEfiMemoryTypeInformationGuid is the same Resource Descriptor
HOB that that describes the PHIT memory range.
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Aaron Li <aaron.li@intel.com>
Cc: Liu Yun <yun.y.liu@intel.com>
Cc: Andrew Fish <afish@apple.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Update GenericWatchdogDxe to disable watchdog interaction after exiting
boot services. Also, move the mEfiExitBootServicesEvent event to the top
of the file with the other static variables.
Signed-off-by: Rebecca Cran <rebecca@os.amperecomputing.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
The calculation of the timer period was broken. Introduce a global
mTimerPeriod so the calculation can be removed. Since mTimerFrequencyHz
is only used in one place, remove the global and make it a local
variable. Do the same with mNumTimerTicks.
Signed-off-by: Rebecca Cran <rebecca@os.amperecomputing.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
The generic watchdog offset register is 48 bits wide, and can be set by
performing two 32-bit writes.
Add support for writing the high 16 bits of the offset register and
update the signature of the WatchdogWriteOffsetRegister function to take
a UINT64 value.
Signed-off-by: Rebecca Cran <rebecca@os.amperecomputing.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4659
When HPET timer is used as the timer interrupt and nested
interrupts into the HPET timer interrupt handler occur, the
elapsed time passed into the DXE Core is sometime too large
and this causes the DXE Core internal system time to run too
fast. Fix the logic so the previous main counter value stored
in the module global variable mPreviousMainCounter is always
captured before the timer notification function is called.
Without this change, mPreviousMainCounter is updated after
the timer notification function is called and when nesting
occurs, it updates with the value from the first level of
nesting which is further back in time than the interrupt from
the deepest level of nesting. This causes the next two timer
interrupts to compute a TimerPeriod that is twice the actual
time period since the last interrupt and this causes the DXE
Core internal time to run faster than expected.
Cc: Ray Ni <ray.ni@intel.com>
Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
When generating _CPC objects, some fields are mandatory by spec [1].
Some fields cannot be supported by a the Juno platform, which is used
to test the _CPC generation. Therefore, rely on the
PcdDevelopmentPlatformRelaxations Pcd to either:
- warn about the missing fields and and let the OS handle the
missing information
- consider the missing fields as an error
_CPC fields that are exempted from checks when the Pcd is set:
- PerformanceLimitedRegister
- ReferencePerformanceCounterRegister
- DeliveredPerformanceCounterRegister
[1] Cf. non-optional fields in:
ACPI 6.5, s8.4.6.1 '_CPC (Continuous Performance Control)'
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Some development platforms might not be compliant on some
points of some specifications. In order to have a generic code
accurately checking against specifications while still allowing
some relaxation on specific points for the platforms that desire
it, add a Pcd acting as a bitfield to warn instead of returning
an error in case of non-compliance.
Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
The SCP holds some power information that could be advertised
through the _CPC object. The communication with the SCP is done
through SCMI protocols (c.f. ArmScmiDxe).
Use the SCMI protocols to query information and feed it to
the DynamicTablesPkg.
Acked-by: Leif Lindholm <quic_llindhol@quicinc.com>
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Make use of the newly added AmlCreatePsdNode() to generate
_PSD objects.
_PSD objects allow to describe 'performance control, P-state
or CPPC, logical processor dependency', Cf. ACPI 6.4,
s8.4.5.5 _PSD (P-State Dependency).
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
The _PSD object (cf. ACPI 6.5, s8.4.5.5 _PSD (P-State Dependency)
allows to describe CPU's power state dependencies. Add a PsdToken
field to the CM_ARM_GICC_INFO object so that interdependent CPUs
can reference the same CM_ARM_PSD_INFO object.
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
The DynamicTables framework uses the AmlLib to generate some
Aml objects. It is done by using structured known by both
frameworks, e.g. the AML_CPC_INFO/CM_ARM_CPC_INFO structures.
To prepare adding similar structures (e.g. representing _PSD
information), rename AmlCpcInfo.h to AcpiObjects.h. This new
file will contain all the structures used by the AmlLib and
the DynamicTables framework.
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
The PERFORMANCE_DESCRIBE_FASTCHANNEL Scmi command is available
since SCMI v2.0 and allows to query information about the supported
fast-channels of the Scmi performance protocol.
Add support for this command.
Also move SCMI_MESSAGE_ID_PERFORMANCE enum definition up in the file
to use it in SCMI_PERFORMANCE_DESCRIBE_FASTCHANNEL function
declaration.
Reviewed-by: Leif Lindholm <quic_llindhol@quicinc.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
Rename PERFORMANCE_PROTOCOL_VERSION to reflect the different
versions of the protocol. The macro is neither used in edk2 nor
in edk2-platforms.
Reviewed-by: Leif Lindholm <quic_llindhol@quicinc.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
Crypto in serveral case will use old version or latest version,
Platform may choose to only update Crypto drivers without updating
whole UPL, in this case the Crypto driver will provide by platform
payload outside the common UPL binary.
Reviewed-by: Chasel Chiu <chasel.chiu@intel.com>
Cc: Guo Dong <guo.dong@intel.com>
Cc: Sean Rhodes <sean@starlabs.systems>
Reviewed-by: James Lu <james.lu@intel.com>
Cc: Gua Guo <gua.guo@intel.com>
Signed-off-by: Gua Guo <gua.guo@intel.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4166
Fix integer overflow in various CreateHob instances.
Fixes: CVE-2022-36765
The CreateHob() function aligns the requested size to 8
performing the following operation:
```
HobLength = (UINT16)((HobLength + 0x7) & (~0x7));
```
No checks are performed to ensure this value doesn't
overflow, and could lead to CreateHob() returning a smaller
HOB than requested, which could lead to OOB HOB accesses.
Reported-by: Marc Beatove <mbeatove@google.com>
Reviewed-by: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Cc: John Mathew <john.mathews@intel.com>
Authored-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Gua Guo <gua.guo@intel.com>
REF: UEFI_Spec_2_10_Aug29.pdf page 1695.
In 35.5.4 EFI_HII_CONFIG_ACCESS_PROTOCOL.CallBack():
If the callback function returns with the ActionRequest set to
_QUESTION_APPLY, then the Forms Browser will write the current modified
question value on the selected form to storage.
Update the DriverSampleDxe, add a new question "Question apply test".
Signed-off-by: Ming Tan <ming.tan@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Dandan Bi <dandan.bi@intel.com>
Reviewed-by: Dandan Bi <dandan.bi@intel.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
REF: UEFI_Spec_2_10_Aug29.pdf page 1695.
In 35.5.4 EFI_HII_CONFIG_ACCESS_PROTOCOL.CallBack():
If the callback function returns with the ActionRequest set to
_QUESTION_APPLY, then the Forms Browser will write the current modified
question value on the selected form to storage.
Update the SetupBrowserDxe, if callback function return
EFI_BROWSER_ACTION_REQUEST_QUESTION_APPLY, then call SetQuestionValue
with GetSetValueWithHiiDriver to apply the change immediately.
Signed-off-by: Ming Tan <ming.tan@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Dandan Bi <dandan.bi@intel.com>
Reviewed-by: Dandan Bi <dandan.bi@intel.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
ResetSystem runtime call allows for sending reset data that
starts with a NULL terminated string. Add support to print
that string on console.
Signed-off-by: Ashish Singhal <ashishsingha@nvidia.com>
Reviewed-by: Zhichao Gao <zhichao.gao@intel.com>
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>
The IMD entry uses the 32bit start field as relative offset
to root. On Ia32X64 this works fine as UINTN is also 32 bit and
negative relative offsets are properly calculated due to an
integer overflow.
On X64 this doesn't work as UINTN is 64 bit and the offset
is no longer subtracted, but it's added to the root. Fix that
by sign extending the start field to 64 bit.
Test: Booting UefiPayloadPkg still works on Ia32X64 and now also
works on X64.
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-by: Gua Guo <gua.guo@intel.com>
Reviewed-by: Sean Rhodes <sean@starlabs.systems>
To avoid messy parsing of the Depex section of a Capsule, it would
be a lot easier for everyone involved if we preceded the Capsule Depex
Section with a length declaration. It provides simple bounds checking
to avoid having to parse the op-codes, but in the case of a malformed
depex being parsed, avoid other issues which can be messy.
REF: UEFI spec 2.10 Table 23.4
Signed-off-by: Yi Li <yi1.li@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Wei6 Xu <wei6.xu@intel.com>
Reviewed-by: Wei6 Xu <wei6.xu@intel.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
To avoid messy parsing of the Depex section of a Capsule, it would
be a lot easier for everyone involved if we preceded the Capsule Depex
Section with a length declaration. It provides simple bounds checking
to avoid having to parse the op-codes, but in the case of a malformed
depex being parsed, avoid other issues which can be messy.
REF: UEFI spec 2.10 Table 23.4
Signed-off-by: Yi Li <yi1.li@intel.com>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Zhiguang Liu <zhiguang.liu@intel.com>
Reviewed-by: Wei6 Xu <wei6.xu@intel.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
It is possible to find variable entries with State being 0xff, i.e. not
updated since flash block erase. This indicates the variable driver
could not complete the header write while appending a new entry, and
therefore State was not set to VAR_HEADER_VALID_ONLY.
This can only happen at the end of the variable list, so treat this as
additional "end of variable list" condition.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20240116171105.37831-6-kraxel@redhat.com>
Raise the limit for writes without block erase from two to four
P30_MAX_BUFFER_SIZE_IN_BYTES blocks. With this in place almost all efi
variable updates are handled without block erase. With the old limit
some variable updates (with device paths) took the block erase code
path.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20240116171105.37831-5-kraxel@redhat.com>
Replace the two NorFlashWriteBuffer() calls with a loop containing a
single NorFlashWriteBuffer() call.
With the changes in place the code is able to handle updates larger
than two P30_MAX_BUFFER_SIZE_IN_BYTES blocks, even though the patch
does not actually change the size limit.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20240116171105.37831-4-kraxel@redhat.com>
Introduce 'Start' and 'End' variables to make it easier to follow the
logic and code flow. Also add a ascii art diagram (based on a
suggestion by Laszlo).
This also fixes the 'Size' calculation for the NorFlashRead() call.
Without this patch the code will read only one instead of two
P30_MAX_BUFFER_SIZE_IN_BYTES blocks in case '*NumBytes' is smaller than
P30_MAX_BUFFER_SIZE_IN_BYTES but 'Offset + *NumBytes' is not, i.e. the
update range crosses a P30_MAX_BUFFER_SIZE_IN_BYTES boundary.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20240116171105.37831-3-kraxel@redhat.com>
This creates / adds a security file that tracks the security fixes
found in this package and can be used to find the fixes that were
applied.
Cc: Jiewen Yao <jiewen.yao@intel.com>
Signed-off-by: Doug Flick [MSFT] <doug.edk2@gmail.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
This creates / adds a security file that tracks the security fixes
found in this package and can be used to find the fixes that were
applied.
Cc: Jiewen Yao <jiewen.yao@intel.com>
Signed-off-by: Doug Flick [MSFT] <doug.edk2@gmail.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
This commit contains the patch files and tests for DxeTpm2MeasureBootLib
CVE 2022-36763.
Cc: Jiewen Yao <jiewen.yao@intel.com>
Signed-off-by: Doug Flick [MSFT] <doug.edk2@gmail.com>
Without enabling PcdUse1GPageTable, CloudHv guests are limited
to a 40-bit address space, even if the hardware supports more.
This limits the amount of RAM to 1TiB of CloudHv guests.
Signed-off-by: Thomas Barrett <tbarrett@crusoeenergy.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
In addition to initializing the PhysMemAddressWidth and
FirstNonAddress fields in PlatformInfoHob, the
PlatformAddressWidthInitialization function is responsible
for initializing the PcdPciMmio64Base and PcdPciMmio64Size
fields.
Currently, for CloudHv guests, the PcdPciMmio64Base is
placed immediately after either the 4G boundary or the
last RAM region, whichever is greater. We do not change
this behavior.
Previously, when booting CloudHv guests with greater than
1TiB of high memory, the PlatformAddressWidthInitialization
function incorrect calculates the amount of RAM using the
overflowed 24-bit CMOS register.
Now, we update the PlatformAddressWidthInitialization
behavior on CloudHv to scan the E820 entries to detect
the amount of RAM. This allows CloudHv guests to boot with
greater than 1TiB of RAM
Signed-off-by: Thomas Barrett <tbarrett@crusoeenergy.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
The PlatformScanE820 utility function is not currently compatible
with CloudHv since it relies on the prescence of the "etc/e820"
QemuFwCfg file. Update the PlatformScanE820 to iterate through the
PVH e820 entries when running on a CloudHv guest.
Signed-off-by: Thomas Barrett <tbarrett@crusoeenergy.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
When the value type is defined as number in Redfish schema, floating
point number is allowed. RedfishCrtLib raises assert without handling
this case now. Follow the way in EDK2 to call AsciiStrDecimalToUintnS
and handle the floating point number. Only the integer value is
returned.
Signed-off-by: Nickle Wang <nicklew@nvidia.com>
Cc: Abner Chang <abner.chang@amd.com>
Cc: Igor Kulchytskyy <igork@ami.com>
Cc: Nick Ramirez <nramirez@nvidia.com>
Reviewed-by: Abner Chang <abner.chang@amd.com>
Only need to include Network.dsc.inc to have all network
drivers/components be built. Otherwise, there were missing definition
that prevent them from be built for RiscVVirt platform.
Signed-off-by: Tuan Phan <tphan@ventanamicro.com>
Reviewed-by: Sunil V L <sunilvl@ventanamicro.com>
Change name of gMpInformationHobGuid2 to
gMpInformation2HobGuid. It's to align with
the file name MpInformation2.h and the
structure name MP_INFORMATION2_HOB_DATA.
Signed-off-by: Dun Tan <dun.tan@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Cc: Rahul Kumar <rahul1.kumar@intel.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
When creating smm page table, limit maximum
supported physical addresses bits returned by
CalculateMaximumSupportAddress() to 47 if
5-Level Paging is disabled.
This commit is to avoid issue that more than
47-bit physical addresses are requested in smm
page table when 5-level paging is disabled.
4-level paging supports translating 48-bit
linear addresses to 52-bit physical addresses.
Since linear addresses are sign-extended,
linear-address space of 4-level paging is:
[0, 2^47-1] and
[0xffff8000_00000000, 0xffffffff_ffffffff].
So only [0, 2^47-1] linear-address range maps
to the identical physical-address range when
5-Level paging is disabled.
Signed-off-by: Dun Tan <dun.tan@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Reviewed-by: Gerd Hoffmann <kraxel@redhat.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Rahul Kumar <rahul1.kumar@intel.com>
PatchSmmSaveStateMap patches the SMM entry (code) and SmmSaveState
region (data) for each core, which can be improved to flush TLB once
after all the memory entries have been patched.
FlushTlbForAll flushes TLB for each core in serial, which can be
improved to flush TLB in parallel.
Reviewed-by: Ray Ni <ray.ni@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Rahul Kumar <rahul1.kumar@intel.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Jiaxin Wu <jiaxin.wu@intel.com>
Signed-off-by: Zhi Jin <zhi.jin@intel.com>
For scene of
HandOffToDxeCore()->SwitchStack(DxeCoreEntryPoint)->
InternalSwitchStack()->LongJump(),Variable HobList.Raw
will be passed (from *Context1 to register a0) to
DxeMain() in parameter *HobStart.
However, meanwhile the function LongJump() overrides
register a0 with a1 (-1) due to commit (ea628f28e5 "RISCV: Fix
InternalLongJump to return correct value"), then cause hang.
Replacing calling LongJump() with new InternalSwitchStackAsm() to pass
addres data in register s0 to register a0 could fix this issue (just
like the solution in MdePkg/Library/BaseLib/AArch64/SwitchStack.S)
Signed-off-by: Yang Wang <wangyang@bosc.ac.cn>
Cc: Bamvor Jian ZHANG <zhangjian@bosc.ac.cn>
Cc: Andrei Warkentin <andrei.warkentin@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Sunil V L <sunilvl@ventanamicro.com>
Cc: Zhiguang Liu <zhiguang.liu@intel.com>
Reviewed-by: Ran Wang <wangran@bosc.ac.cn>
Reviewed-by: Andrei Warkentin <andrei.warkentin@intel.com>
Implement EDKII_HTTP_CALLBACK_PROTOCOL that listens to
HttpEventTlsConfigured event for reconfiguring TLS configuration
data.
Signed-off-by: Abner Chang <abner.chang@amd.com>
Cc: Nickle Wang <nicklew@nvidia.com>
Cc: Igor Kulchytskyy <igork@ami.com>
Reviewed-by: Nickle Wang <nicklew@nvidia.com>
We still return EFI_SUCCESS to the caller when TlsConfigCertificate
returns error, for the use case the platform doesn't require
certificate for the specific HTTP session. This ensures
HttpInitSession function still initiated and returns EFI_SUCCESS to
the caller. The failure is pushed back to TLS DXE driver if the
HTTP communication actually requires certificate.
Signed-off-by: Abner Chang <abner.chang@amd.com>
Cc: Saloni Kasbekar <saloni.kasbekar@intel.com>
Cc: Zachary Clark-williams <zachary.clark-williams@intel.com>
Cc: Michael Brown <mcb30@ipxe.org>
Cc: Nickle Wang <nicklew@nvidia.com>
Cc: Igor Kulchytskyy <igork@ami.com>
Reviewed-by: Michael Brown <mcb30@ipxe.org>
Reviewed-by: Saloni Kasbekar <saloni.kasbekar@intel.com>
Extend the ValidateFvHeader function, additionally to the header checks
walk over the list of variables and sanity check them.
In case we find inconsistencies indicating variable store corruption
return EFI_NOT_FOUND so the variable store will be re-initialized.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Message-Id: <20240109112902.30002-4-kraxel@redhat.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
[lersek@redhat.com: fix StartId initialization/assignment coding style]
Only accept gEfiAuthenticatedVariableGuid when checking the variable
store header in ValidateFvHeader().
The edk2 code base has been switched to use the authenticated varstore
format unconditionally (even in case secure boot is not used or
supported) a few years ago.
Suggested-by: László Érsek <lersek@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20240109112902.30002-3-kraxel@redhat.com>
Set EXTENDED_PROCESSOR_INFORMATION to 0 in API
MpInitLibGetProcessorInfo() of MpInitLibUp. This
commit use ZeroMem() to set all fileds in output
EFI_PROCESSOR_INFORMATION to 0 before StatusFlag
field is reassigned.
Previously EXTENDED_PROCESSOR_INFORMATION in the API
MpInitLibGetProcessorInfo() of MpInitLibUp is ignored.
In PEI/DXE MpInitLib, EXTENDED_PROCESSOR_INFORMATION
will be retrived when BIT24 of input ProcessorNumber
is set. This commit can avoid garbage in the output
structure in MpInitLibGetProcessorInfo() of MpInitLibUp.
Signed-off-by: Dun Tan <dun.tan@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Rahul Kumar <rahul1.kumar@intel.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Min Xu <min.m.xu@intel.com>
Message-Id: <20240108050804.1718-2-dun.tan@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
There is an inconsistency between the UNIX and Windows
implementations of EMU_THUNK_PROTOCOL.SetTime(). The Windows
version returns an EFI_STATUS value whereas the the UNIX
implementation is VOID. However, the UNIX implementation is an
unimplemented stub whereas the Windows version is implementated.
The current EMU_THUNK_PROTOCOL function pointer definition
specifies a VOID return type. However, EMU_THUNK_PROTOCOL.SetTime()
is close to the spec defined gRT->SetTime() except for missing the
EFI_STATUS return type.
Therefore, I conclude that the most sensible reconciliation is to
add the EFI_STATUS return type to the protocol definition.
Cc: Andrew Fish <afish@apple.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Chasel Chiu <chasel.chiu@intel.com>
Signed-off-by: Nate DeSimone <nathaniel.l.desimone@intel.com>
In the early 2000s as part of the x64 transition the definition
for LPTIMECALLBACK changed from (UINT, UINT, DWORD, DWORD, DWORD)
to (UINT, UINT, DWORD_PTR, DWORD_PTR, DWORD_PTR). However,
the MMTimerThread() function was never updated to the new
signature. Since the implementation does not use the last three
parameters, this issue has not been caught until now.
Cc: Andrew Fish <afish@apple.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Signed-off-by: Nate DeSimone <nathaniel.l.desimone@intel.com>
Add the support for X64 compilation to the CI.
- Fix the signed and unsigned variable comparision.
warning C4018: '>': signed/unsigned mismatch
- Fix the NOOPT build error for IA32 by replacing
64bit shift operator with LShiftU64.
Cc: Pierre Gondois <pierre.gondois@arm.com>
Cc: Sami Mujawar <sami.mujawar@arm.com>
Signed-off-by: Abdul Lateef Attar <AbdulLateef.Attar@amd.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Add implementation of ReallocatePool which is defined in the
MemoryAllocationLib header file to allow components to not
need special handling for PrePi module types.
Signed-off-by: Jeff Brasen <jbrasen@nvidia.com>
URI is generated based on the RedfishLocation containing an ASCII string
representing the IP address. So, in the case of IPv4 the canonical
representation of an IPv4 address was inserted into the resulting Unicode
string i.e: "http{,s}://X.X.X.X/".
In the case of IPv6, to access resources, the IP address must be specified
in brackets, i.e. the resulting string should look like:
"http{,s}://[X::X:X:X:X]/".
Cc: Nickle Wang <nicklew@nvidia.com>
Cc: Igor Kulchytskyy <igork@ami.com>
Signed-off-by: Mike Maslenkin <mike.maslenkin@gmail.com>
Reviewed-by: Abner Chang <abner.chang@amd.com>
This patch adds a handy helper function deallocating resources from the
EFI_REDFISH_DISCOVERED_INFORMATION structure instance.
Cc: Nickle Wang <nicklew@nvidia.com>
Cc: Igor Kulchytskyy <igork@ami.com>
Signed-off-by: Mike Maslenkin <mike.maslenkin@gmail.com>
Reviewed-by: Abner Chang <abner.chang@amd.com>
Currently there is no description for RedfishConfigHandler driver.
This leads to <null string> in the "DRIVER NAME" column of a `drivers`
command for example.
Cc: Nickle Wang <nicklew@nvidia.com>
Cc: Igor Kulchytskyy <igork@ami.com>
Signed-off-by: Mike Maslenkin <mike.maslenkin@gmail.com>
Reviewed-by: Abner Chang <abner.chang@amd.com>
It's unclear why the new string is allocated as copy of the original
string if its pointer is stored in an array and the original string
is released immediately after the copy is created. All data allocated
in the same pool.
Cc: Nickle Wang <nicklew@nvidia.com>
Cc: Igor Kulchytskyy <igork@ami.com>
Signed-off-by: Mike Maslenkin <mike.maslenkin@gmail.com>
Reviewed-by: Abner Chang <abner.chang@amd.com>
It seems that initial implementation of this header file is based on
CrtLibSupport.h from CryptoPkg. But uid, euid, gid, egid and sa_family_t
sre not used in RedfishPkg. So remove them.
Also take "true" and "false" definition from MdePkg's LibFdtSupport.h
header file, that also seems based on a header mentioned above.
Cc: Nickle Wang <nicklew@nvidia.com>
Cc: Igor Kulchytskyy <igork@ami.com>
Signed-off-by: Mike Maslenkin <mike.maslenkin@gmail.com>
Reviewed-by: Abner Chang <abner.chang@amd.com>
After BSP returned from SmmCoreEntry, there are several rounds BSP
and AP sync in BSP handler:
1 .ReleaseAllAPs(); /// Notify all APs to exit.
if (SmmCpuFeaturesNeedConfigureMtrrs()) {
2. SmmCpuSyncWaitForAPs(); /// Wait for all APs to program MTRRs.
3. ReleaseAllAPs(); /// Signal APs to restore MTRRs.
}
4. SmmCpuSyncWaitForAPs(); /// Wait for all APs to complete pending
tasks including MTRR.
5. ReleaseAllAPs(); /// Signal APs to Reset states.
6. SmmCpuSyncWaitForAPs(); /// Gather APs to exit SMM synchronously.
Before step 6 and after step 5, BSP performs below items:
A. InitializeDebugAgent() /// Stop source level debug.
B. SmmCpuUpdate() /// Perform pending operations for hot-plug.
C. Present = FALSE; /// Clear the Present flag of BSP.
For InitializeDebugAgent(), BSP needs to wait all APs complete
pending tasks and then notify all APs to stop source level debug.
So, above step 4 & step 5 are required for InitializeDebugAgent().
For SmmCpuUpdate(), it's to perform pending operations for
hot-plug CPUs take effect in next SMI. Existing APs in SMI do not
reply on the CPU switch & hot-add & hot-remove operations. So, no
need step 4 and step 5 for additional one round BSP & AP sync.
Step 6 can make sure all APs are ready to exit SMM, then hot-plug
operation can take effect in next SMI.
For BSP "Present" flag, AP does not reply on it. No need step 4
and step 5 for additional one round BSP & AP sync.
Based on above analysis, step 4 and step 5 are only required if
need configure MTRR and support SMM source level debug. So, we can
reduce one round BSP and AP sync if both are unsupported. With
this change, SMI performance can be improved.
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Zeng Star <star.zeng@intel.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Rahul Kumar <rahul1.kumar@intel.com>
Signed-off-by: Jiaxin Wu <jiaxin.wu@intel.com>
Reviewed-by: Ray Ni <ray.ni@Intel.com>
Existing BSP handler stops source level debug, then call ReleaseAllAPs
to tell all APs can reset the Present flag to FALSE:
InitializeDebugAgent (); /// Stop source level debug
ReleaseAllAPs (); /// Tell APs can reset "Present" flag.
This patch is to invert ReleaseAllAPs & InitializeDebugAgent:
ReleaseAllAPs (); /// Tell APs can reset "Present" flag.
InitializeDebugAgent (); /// Stop source level debug
After this change, there is no negative impact since SMM source level
debug feature doesn't depend on AP's "Present" flag, no impact to the
SMM source level debug capability.
Instead, the change will benefit the AP source level debug capability
to trace its "Present" flag change for SMI exit since the source
level debug feature will be stopped after each AP has the chance to
reset the state.
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Zeng Star <star.zeng@intel.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Rahul Kumar <rahul1.kumar@intel.com>
Signed-off-by: Jiaxin Wu <jiaxin.wu@intel.com>
Reviewed-by: Ray Ni <ray.ni@Intel.com>
Below piece of code is the BSP and AP sync logic for SMI exit.
1. AP after finish the scheduled procedure:
if (SmmCpuFeaturesNeedConfigureMtrrs ()) {
SmmCpuSyncReleaseBsp ();
SmmCpuSyncWaitForBsp ();
...
}
SmmCpuSyncReleaseBsp ();
SmmCpuSyncWaitForBsp ();
SmmCpuSyncReleaseBsp ();
2. BSP after return from SmmCoreEntry:
SmmCpuSyncWaitForAPs ();
if (SmmCpuFeaturesNeedConfigureMtrrs ()) {
ReleaseAllAPs ();
...
SmmCpuSyncWaitForAPs ();
}
ReleaseAllAPs ();
SmmCpuSyncWaitForAPs();
This patch is to make BSP same as AP sync logic:
if (SmmCpuFeaturesNeedConfigureMtrrs ()) {
SmmCpuSyncWaitForAPs ();
ReleaseAllAPs ();
...
}
SmmCpuSyncWaitForAPs ();
ReleaseAllAPs ();
SmmCpuSyncWaitForAPs();
With the change, it will be easy to understand the sync flow as
below:
BSP: SmmCpuSyncWaitForAPs <-- AP: SmmCpuSyncReleaseBsp
BSP: ReleaseAllAPs --> AP: SmmCpuSyncWaitForBsp
This patch doesn't have function impact.
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Zeng Star <star.zeng@intel.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Rahul Kumar <rahul1.kumar@intel.com>
Signed-off-by: Jiaxin Wu <jiaxin.wu@intel.com>
Reviewed-by: Ray Ni <ray.ni@Intel.com>
This patch is to use the Context to indicate SMM Debug Agent support or
not if InitFlag is DEBUG_AGENT_INIT_SMM. Context must point to a
BOOLEAN if it's not NULL.
Cc: Ray Ni <ray.ni@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Signed-off-by: Jiaxin Wu <jiaxin.wu@intel.com>
Reviewed-by: Ray Ni <ray.ni@Intel.com>
This patch is to use the Context to indicate SMM Debug Agent support
or not if InitFlag is DEBUG_AGENT_INIT_SMM. Context must point to a
BOOLEAN if it's not NULL.
Cc: Ray Ni <ray.ni@intel.com>
Signed-off-by: Jiaxin Wu <jiaxin.wu@intel.com>
Reviewed-by: Ray Ni <ray.ni@Intel.com>
Load-module-at-fixed-address feature does not work in standalone MM core.
The patch removes the 2 dead functions and related global variables
that are related to the feature.
Signed-off-by: Ray Ni <ray.ni@intel.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Cc: Sami Mujawar <sami.mujawar@arm.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4533
There are use cases which not all FVs need be migrated from TempRam to
permanent memory before TempRam tears down. This new guid is introduced
to avoid unnecessary FV migration to improve boot performance. Platform
can publish MigrationInfo hob with this guid to customize FV migration
info, and PeiCore will only migrate FVs indicated by this Hob info.
This is a backwards compatible change, PeiCore will check MigrationInfo
hob before migration. If MigrationInfo hobs exists, only migrate FVs
recorded by hobs. If MigrationInfo hobs not exists, migrate all FVs to
permanent memory.
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Guomin Jiang <guomin.jiang@intel.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Signed-off-by: Cheng Sun <chengx.sun@intel.com>
When converting ELF to PE/COFF for the AArch64 target, we may encounter
an R_AARCH64_ADR_GOT_PAGE relocation that refers to an ADR instruction
instead of an ADRP instruction. This can happen when the toolchain is
working around Cortex-A53 erratum #843419. If that's the case, be sure
to calculate the offset appropriately.
This resolves an issue experienced when building a StandaloneMm image
(which is built with -fpie) with stack protection enabled on GCC
compiled with "--enable-fix-cortex-a53-843419". In this case, the linker
may convert an ADRP instruction appearing at an offset of 0xff8 or 0xffc
modulo 4KiB into an ADR instruction, but will leave the original
R_AARCH64_ADR_GOT_PAGE relocation in place. (This is not a bug in the
linker, given that there is no other relocation type that it could
reasonably convert it into)
In this scenario, the following code is being generated by the
toolchain:
# Load to set the stack canary
2ffc: 10028020 adr x0, 8000 <mErrorString+0x1bc>
3008: f940d400 ldr x0, [x0, #424]
# Load to check the stack canary
30cc: b0000020 adrp x0, 8000 <mErrorString+0x1bc>
30d0: f940d400 ldr x0, [x0, #424]
GenFw rewrote that to:
# Load to set the stack canary
2ffc: 10000480 adr x0, 0x308c
3008: 912ec000 add x0, x0, #0xbb0
# Load to check the stack canary
30cc: f0000460 adrp x0, 0x92000
30d0: 912ec000 add x0, x0, #0xbb0
Note that we're now setting the stack canary from the wrong address,
resulting in an erroneous stack fault.
After this fix, the offset will be calculated correctly for an ADR and
the stack canary is set correctly. Note that there is a corner case
where this may cause the conversion to fail: if the original GOT entry
is just within -/+ 1 MiB of the reference, but the actual variable it
refers to is not, the resulting offset cannot be represented by the
immediate offset field in a ADR instruction. Given that this issue only
affects PIE executables, which are rare and usually tiny, this is
unlikely to cause problems in practice.
Ref: https://edk2.groups.io/g/devel/topic/102202314
[ardb: expand commit log, add reference]
Signed-off-by: Jake Garver <jake@nvidia.com>
Reviewed-by: Rebecca Cran <rebecca@bsdio.com>
There is the SmmCpuSyncLib Library class define the SMM CPU sync
flow, which is aligned with existing SMM CPU driver sync behavior.
This patch is to consume SmmCpuSyncLib instance directly.
With this change, SMM CPU Sync flow/logic can be customized
with different implementation no matter for any purpose, e.g.
performance tuning, handle specific register, etc.
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Zeng Star <star.zeng@intel.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Rahul Kumar <rahul1.kumar@intel.com>
Signed-off-by: Jiaxin Wu <jiaxin.wu@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Implements SmmCpuSyncLib Library instance. The instance refers the
existing SMM CPU driver (PiSmmCpuDxeSmm) sync implementation
and behavior:
1.Abstract Counter and Run semaphores into SmmCpuSyncCtx.
2.Abstract CPU arrival count operation to
SmmCpuSyncGetArrivedCpuCount(), SmmCpuSyncCheckInCpu(),
SmmCpuSyncCheckOutCpu(), SmmCpuSyncLockDoor().
Implementation is aligned with existing SMM CPU driver.
3. Abstract SMM CPU Sync flow to:
BSP: SmmCpuSyncReleaseOneAp --> AP: SmmCpuSyncWaitForBsp
BSP: SmmCpuSyncWaitForAPs <-- AP: SmmCpuSyncReleaseBsp
Semaphores release & wait during sync flow is same as existing SMM
CPU driver.
4.Same operation to Counter and Run semaphores by leverage the atomic
compare exchange.
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Zeng Star <star.zeng@intel.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Rahul Kumar <rahul1.kumar@intel.com>
Signed-off-by: Jiaxin Wu <jiaxin.wu@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Intel is planning to provide different SMM CPU Sync implementation
along with some specific registers to improve the SMI performance,
hence need SmmCpuSyncLib Library for Intel.
This patch is to:
1.Adds SmmCpuSyncLib Library class in UefiCpuPkg.dec.
2.Adds SmmCpuSyncLib.h function declaration header file.
For the new SmmCpuSyncLib, it provides 3 sets of APIs:
1. ContextInit/ContextDeinit/ContextReset:
ContextInit() is called in driver's entrypoint to allocate and
initialize the SMM CPU Sync context. ContextDeinit() is called in
driver's unload function to deinitialize SMM CPU Sync context.
ContextReset() is called before CPU exist SMI, which allows CPU to
check into the next SMI from this point.
2. GetArrivedCpuCount/CheckInCpu/CheckOutCpu/LockDoor:
When SMI happens, all processors including BSP enter to SMM mode by
calling CheckInCpu(). The elected BSP calls LockDoor() so that
CheckInCpu() will return the error code after that. CheckOutCpu() can
be called in error handling flow for the CPU who calls CheckInCpu()
earlier. GetArrivedCpuCount() returns the number of checked-in CPUs.
3. WaitForAPs/ReleaseOneAp/WaitForBsp/ReleaseBsp
WaitForAPs() & ReleaseOneAp() are called from BSP to wait the number
of APs and release one specific AP. WaitForBsp() & ReleaseBsp() are
called from APs to wait and release BSP. The 4 APIs are used to
synchronize the running flow among BSP and APs. BSP and AP Sync flow
can be easy understand as below:
BSP: ReleaseOneAp --> AP: WaitForBsp
BSP: WaitForAPs <-- AP: ReleaseBsp
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Zeng Star <star.zeng@intel.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Rahul Kumar <rahul1.kumar@intel.com>
Signed-off-by: Jiaxin Wu <jiaxin.wu@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Currently, the ReadyToBoot event is only signaled when a formal Boot
Manager option is executed (in BmBoot.c -> EfiBootManagerBoot ()).
However, the introduction of Platform Recovery in UEFI 2.5 makes it
necessary to signal ReadyToBoot when a Platform Recovery boot loader
runs because otherwise it may lead to the execution of a boot loader
that has similar requirements to a regular one that is not launched
as a Boot Manager option.
This is especially critical to ensuring that the graphical console is
actually usable during platform recovery, as some platforms do rely on
the ConsolePrefDxe driver, which only performs console initialization
after ReadyToBoot is triggered.
This patch fixes that behavior by calling EfiSignalEventReadyToBoot ()
in EfiBootManagerProcessLoadOption () when invoking platform recovery,
which is the function that sets up the platform recovery boot process.
The expected behavior has been clarified in the UEFI 2.10 specification
to explicitly indicate this behavior is required for correct operation.
This is a rebased version of the patch originally written by Pete Batard.
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2831
Co-authored-by: Pete Batard <pete@akeo.ie>
Signed-off-by: Neal Gompa <ngompa@fedoraproject.org>
Reviewed-by: Jeremy Linton <jeremy.linton@arm.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Leif Lindholm <quic_llindhol@quicinc.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Implement Cache Management Operations (CMO) defined by
RISC-V spec https://github.com/riscv/riscv-CMOs.
Notes:
1. CMO only supports block based Operations. Meaning cache
flush/invd/clean Operations are not available for the entire
range. In that case we fallback on fence.i instructions.
2. Operations are implemented using Opcodes to make them compiler
independent. binutils 2.39+ compilers support CMO instructions.
Test:
1. Ensured correct instructions are refelecting in asm
2. Qemu implements basic support for CMO operations in that it allwos
instructions without exceptions. Verified it works properly in
that sense.
3. SG2042Pkg implements CMO-like instructions. It was verified that
CpuFlushCpuDataCache works fine. This more of less
confirms that framework is alright.
4. TODO: Once Silicon is available with exact instructions, we will
further verify this.
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Zhiguang Liu <zhiguang.liu@intel.com>
Cc: Sunil V L <sunilvl@ventanamicro.com>
Cc: Daniel Schaefer <git@danielschaefer.me>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Pedro Falcato <pedro.falcato@gmail.com>
Signed-off-by: Dhaval Sharma <dhaval@rivosinc.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Sunil V L <sunilvl@...>
Reviewed-by: Jingyu Li <jingyu.li01@...>
The MmCoreFfsFindMmDriver only checks for encapsulated compressed FVs.
When an inner FV is uncompressed, StandaloneMmCore will miss the FV and
all the MM drivers in the FV will not be dispatched.
Add checks for uncompressed inner FV to fix this issue.
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Sami Mujawar <sami.mujawar@arm.com>
Cc: Ray Ni <ray.ni@intel.com>
Signed-off-by: Wei6 Xu <wei6.xu@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
MmCoreFfsFindMmDriver() assumes FileHeader is EFI_FFS_FILE_HEADER.
If FileHeader is an EFI_FFS_FILE_HEADER2, 'FileHeader + 1' will get a
wrong section address. Use FfsFindSection to get the section directly,
instead of 'FileHeader + 1' to avoid this issue.
MmCoreFfsFindMmDriver() also assumes section is EFI_COMMON_SECTION_HEADER.
If Section is EFI_COMMON_SECTION_HEADER2, 'Section + 1' will get a wrong
wrong InnerFvHeader adress. Add section head detection and calculate the
address accordingly.
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Sami Mujawar <sami.mujawar@arm.com>
Cc: Ray Ni <ray.ni@intel.com>
Signed-off-by: Wei6 Xu <wei6.xu@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
In MmCoreFfsFindMmDriver(),
- ScratchBuffer is not freed in the error return path that DstBuffer page
allocation fails. Free ScratchBuffer before return with error.
- If the decoded buffer is identical to the data in InputSection,
ExtractGuidedSectionDecode() will change the value of DstBuffer rather
than changing the contents of the buffer that DstBuffer points at, in
which case freeing DstBuffer is wrong. Introduce a local variable
AllocatedDstBuffer for buffer free, free AllocatedDstBuffer immediately
if it is not used.
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Sami Mujawar <sami.mujawar@arm.com>
Cc: Ray Ni <ray.ni@intel.com>
Signed-off-by: Wei6 Xu <wei6.xu@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
MmCoreFfsFindMmDriver() is called recursively for encapsulation sections.
Currently this recursion is not limited. Introduce a new PCD
(fixed-at-build, or patchable-in-module), and make MmCoreFfsFindMmDriver()
track the section nesting depth against that PCD.
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Sami Mujawar <sami.mujawar@arm.com>
Cc: Ray Ni <ray.ni@intel.com>
Signed-off-by: Wei6 Xu <wei6.xu@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
The DebugPeCoffExtraActionLib implemention in ArmPkg contains some cruft
that dates back to the original RVCT based ARM port, and support for
RVCT was dropped a while ago.
Also drop the handling of Cygwin specific paths, which is highly
unlikely to be still depended upon by anyone.
Tweak the logic so that only two versions of the DEBUG() invocations
remain: one for __GNUC__ when PdbPointer is set, and the fallback that
just prints the image address and the address of the entrypoint.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Leif Lindholm <quic_llindhol@quicinc.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Add the long lost CI for CloudHv on AArch64.
As CloudHv CI works nearly the same way with other VMMs like KvmTool,
thus we can easily create its CI configuration based on KvmTool.
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Jianyong Wu <jianyong.wu@arm.com>
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Remedy Redfish service discovery flow changes made
in commit 8736b8fd.
The above fix creates the dependency with SMBIOS 42h record,
which has a problem as SMBIOS 42h may not be created when
RedfishDiscovery.Supported() is invoked even all of the
required protocols are ready on the ControllerHandle. We can’t
guarantee SMBIOS 42 structure will be always created before
ConnectController(). USB NIC maybe detected late and it means
PlatformHostInterfaceBmcUsbNicLib can populate SMBIOS 42h
information late as well. Calling to
RedfishServiceGetNetworkInterface with the previous fix may
result in no network interface for BMC-exposed NIC as SMBIOS
42h is not ready yet.This is the first issue.
Second, to skip the network interface when
NetworkInterfaceGetSubnetInfo() returns a failure also has
problem, as the NIC may be configured via RestEx->Configure().
This happens after the Host interface is discovered, as at this
moment we have the sufficient network information to configure
BMC-exposed NIC.
Base on Redfish spec in 31.1.5.2, “EFI Redfish Client may provide
selection UI of network interfaces for Redfish service discovery.",
This means edk2 Redfish client gets all network interfaces
through RedfishServiceGetNetworkInterface and choose the desired
network interface at its discretion for Redfish service.
So the fix here is:
1. In BuildNetworkInterface(), we don’t skip any network
interface. In RedfishServiceGetNetworkInterface, we don’t
skip any network interface even the subnet information is not
retrieved. We will still return all of network interfaces to
client.
2. In RedfishServiceAcquireService for
EFI_REDFISH_RISCOVER_HOST_INTERFACE case, we don’t skip any
network interface even the subnet information is not
retrieved.
3. Added some more debug information.
Note: The subnet information is used for the scenario the system
is managed by a centralized Redfish service (not on BMC), says
the multiple Redfish computer system instances. As it mentions
in 31.1.5.2, Redfish client they may have to know the subnet
information so they can know the network domain the NIC is
connected. There may have multiple subnets in the corporation
network environment. So the subnet information provides client
an idea when they choose the network interface, so does VLAN ID.
Signed-off-by: Abner Chang <abner.chang@amd.com>
Cc: Nickle Wang <nicklew@nvidia.com>
Cc: Igor Kulchytskyy <igork@ami.com>
Cc: Mike Maslenkin <mike.maslenkin@gmail.com>
Reviewed-by: Igor Kulchytskyy <igork@ami.com>
Acked-by: Mike Maslenkin <mike.maslenkin@gmail.com>
Shim's PE loader uses the EFI memory attributes protocol in a way that
results in an immediate crash when invoking the loaded image, unless the
base and size of its executable segment are both aligned to 4k.
If this is not the case, it will strip the memory allocation of its
executable permissions, but fail to add them back for the executable
region, resulting in non-executable code. Unfortunately, the PE loader
does not even bother invoking the protocol in this case (as it notices
the misalignment), making it very hard for system firmware to work
around this by attempting to infer the intent of the caller.
So let's introduce a QEMU command line option to indicate that the
protocol should not be exposed at all, and a PCD to set the default for
this option when it is omitted.
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Gerd Hoffmann <kraxel@redhat.com>
Link: https://gitlab.com/qemu-project/qemu/-/issues/1990
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Modify the gSmmBaseHobGuid consumption code to
remove the asuumption that there is only one
gSmmBaseHobGuid. If the CPU number is big enough,
there will be more than one SmmBaseHob in the
HOB list.
Signed-off-by: Dun Tan <dun.tan@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Cc: Rahul Kumar <rahul1.kumar@intel.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Consume MpInfo2Hob in PiSmmCpuDxe driver to get
NumberOfProcessors, MaxNumberOfCpus and
EFI_PROCESSOR_INFORMATION for all CPU from the
MpInformation2 HOB.
This can avoid calling MP service.
Signed-off-by: Dun Tan <dun.tan@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Cc: Rahul Kumar <rahul1.kumar@intel.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Build MpInfo2HOB in CpuMpPei module so that later
PiSmmCpuDxe or other StandaloneMm module can consume
the HOB.
Since there might be more one gMpInformationHobGuid2
in HOB list, CpuMpPei create a gMpInformationHobGuid2
with 0 value NumberOfProcessors field in the end of the
process to indicate it's the last MP_INFORMATION2_HOB.
Signed-off-by: Dun Tan <dun.tan@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Cc: Rahul Kumar <rahul1.kumar@intel.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Create gMpInformationHobGuid2 in UefiCpuPkg.
Currently, there is a gMpInformationHobGuid defined,
created and consumed only in StandaloneMmPkg. The HOB
contains the EFI_PROCESSOR_INFORMATION structure for
each CPU and the number of processors. This is the same
as the information that PiSmmCpuDxeSmm uses MpService
Protocol to get.
This new gMpInformationHobGuid2 also contains the
NumberOfProcessors and the EFI_PROCESSOR_INFORMATION
for each CPU. Also the HOB is extended to support the
case that the maximum HOB length is not enough for all
CPU. So there might be more than one HOB instance in the
HOB list. Each HOB describes the corresponding CPU index
range.
The plan is to create gMpInformationHob2Guid in CpuMpPei
module(implemented in next commit). Then PiSmmCpuDxeSmm
and other MM_STANDALONE modules can consume the hob. This
can avoid calling MpService Protocol in PiSmmCpuDxeSmm.
Also the issue that one gMpInformationHobGuid might be not
enough when CPU number is 1~2000 or bigger can be solved.
Signed-off-by: Dun Tan <dun.tan@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Cc: Rahul Kumar <rahul1.kumar@intel.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
The struct used for GHCB-based page-state change requests uses a 40-bit
bit-field for the GFN, which is shifted by PAGE_SHIFT to generate a
64-bit address. However, anything beyond 40-bits simply gets shifted off
when doing this, which will cause issues when dealing with 1TB+
addresses. Fix this by casting the 40-bit GFN values to 64-bit ones
prior to shifting it by PAGE_SHIFT.
Fixes: ade62c18f4 ("OvmfPkg/MemEncryptSevLib: add support to validate system RAM")
Signed-off-by: Michael Roth <michael.roth@amd.com>
Message-Id: <20231115175153.813213-1-michael.roth@amd.com>
Reviewed-by: Gerd Hoffmann <kraxel@redhat.com>
This patch is to complete 170d4ce8, sync the change to BaseXApicLib.
Checking the max cpuid leaf is not enough to figure whenever
CPUID_V2_EXTENDED_TOPOLOGY is supported. Intel SDM says:
Software must detect the presence of CPUID leaf 1FH by verifying
(a) the highest leaf index supported by CPUID is >= 1FH, and
(b) CPUID.1FH:EBX[15:0] reports a non-zero value.
The same is true for CPUID leaf 0BH.
This patch adds the EBX check to GetProcessorLocation2ByApicId(). The
patch also fixes the existing check in GetProcessorLocationByApicId() to
be in line with the spec by looking at bits 15:0. The comments are
updated with a quote from the Intel SDM.
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Rahul Kumar <rahul1.kumar@intel.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Star Zeng <star.zeng@intel.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Jiaxin Wu <jiaxin.wu@intel.com>
Message-Id: <20231115111553.6592-2-jiaxin.wu@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
8259InterruptControllerDxe is not used by any platforms at this point,
remove it.
This patch removes mentions of the following CSM resources from the source
code:
- GUIDs (protocols or otherwise):
- gEfiLegacy8259ProtocolGuid
- headers:
- Protocol/Legacy8259.h
- PCDs:
- Pcd8259LegacyModeEdgeLevel
- Pcd8259LegacyModeMask
which extends the list of resources scheduled for removal to:
- GUIDs (protocols or otherwise):
- gEfiLegacy8259ProtocolGuid
- headers:
- Protocol/Legacy8259.h
- PCDs:
- Pcd8259LegacyModeEdgeLevel
- Pcd8259LegacyModeMask
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=4588
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20231110235820.644381-35-lersek@redhat.com>
Reviewed-by: Jiewen Yao <Jiewen.yao@intel.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Acked-by: Corvin Köhne <corvink@FreeBSD.org>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
The <FrameworkDxe.h> header is not used by any source file at this point,
remove it.
<FrameworkDxe.h> is a thin wrapper for including all header files under
the "OvmfPkg/Csm/Include/Framework" directory. Remove that directory at
the same time (nothing else references contents in that directory
directly).
Consequently, the "OvmfPkg/Csm/Include" directory becomes empty, and git
automatically deletes it; remove that include path from
"OvmfPkg/OvmfPkg.dec".
This shrinks the list of resources scheduled for removal to:
- GUIDs (protocols or otherwise):
- SYSTEM_ROM_FILE_GUID (1547B4F3-3E8A-4FEF-81C8-328ED647AB1A)
- gEfiLegacy8259ProtocolGuid
- headers:
- Protocol/Legacy8259.h
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=4588
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20231110235820.644381-28-lersek@redhat.com>
Reviewed-by: Jiewen Yao <Jiewen.yao@intel.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Acked-by: Corvin Köhne <corvink@FreeBSD.org>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
CsmSupportLib is not used by any platform at this point, remove it.
This patch removes mentions of the following CSM resources from the source
code [*]:
- GUIDs (protocols or otherwise):
- SYSTEM_ROM_FILE_GUID (1547B4F3-3E8A-4FEF-81C8-328ED647AB1A)
- gEfiFirmwareVolumeProtocolGuid (by cutting the
<Protocol/FirmwareVolume.h> link)
- gEfiLegacyBiosPlatformProtocolGuid
- gEfiLegacyBiosProtocolGuid
- gEfiLegacyInterruptProtocolGuid
- headers:
- FrameworkDxe.h
- Protocol/FirmwareVolume.h
- Protocol/LegacyBiosPlatform.h
- Protocol/LegacyInterrupt.h
which extends the list of resources scheduled for removal to:
- GUIDs (protocols or otherwise):
- SYSTEM_ROM_FILE_GUID (1547B4F3-3E8A-4FEF-81C8-328ED647AB1A)
- gEfiFirmwareVolumeProtocolGuid
- gEfiLegacy8259ProtocolGuid
- gEfiLegacyBiosPlatformProtocolGuid
- gEfiLegacyBiosProtocolGuid
- gEfiLegacyInterruptProtocolGuid
- headers:
- FrameworkDxe.h
- Protocol/FirmwareVolume.h
- Protocol/Legacy8259.h
- Protocol/LegacyBios.h
- Protocol/LegacyBiosPlatform.h
- Protocol/LegacyInterrupt.h
[*] Note that gEfiLegacyRegion2ProtocolGuid, while a CSM-related protocol,
cannot be scheduled for removal, because the protocol GUID is defined in
"MdePkg.dec", and it's not only "OvmfPkg/Csm/CsmSupportLib" that produces
it in all of edk2, but also "MdeModulePkg/Universal/LegacyRegion2Dxe" (not
used by OVMF). For the same reason, the "Protocol/LegacyRegion2.h" header
(from MdePkg) cannot be scheduled for removal.
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=4588
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20231110235820.644381-23-lersek@redhat.com>
Reviewed-by: Jiewen Yao <Jiewen.yao@intel.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Acked-by: Corvin Köhne <corvink@FreeBSD.org>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
CsmSupportLib is effectively a hack. It produces the following protocols:
- Legacy Bios Platform,
- Legacy Interrupt,
- Legacy Region2.
(Note that the "OvmfPkg/Csm/CsmSupportLib/CsmSupportLib.inf" file contains
an error where it claims that "Legacy Bios Platform" is "consumed" -- it
is not; the lib instance produces that protocol).
At the same time, the library instance consumes
gEfiLegacyBiosProtocolGuid.
This *seemingly* creates a circular dependency with LegacyBiosDxe, because
that driver has the exact opposite protocol usage patterns. The solution
is that LegacyBiosDxe has a DEPEX on the protocols produced by
CsmSupportLib, while CsmSupportLib consumes the Legacy Bios Protocol from
LegacyBiosDxe only in the member functions of the protocols it produces.
Therefore, once BdsDxe is dispatched, and the CsmSupportLib constructor
exposes those three protocols, LegacyBiosDxe can also be started by the
DXE dispatcher, and then the protocols from CsmSupportLib become
functional.
But the main reason why CsmSupportLib is a hack is that it should be a
normal platform DXE driver (called e.g. "CsmSupportDxe"), and not a NULL
class library that's randomly hooked into BdsDxe.
Given that we have removed LegacyBiosDxe earlier (so there is no DEPEX we
need to satisfy now, conceptually), unhook CsmSupportLib from BdsDxe.
--*--
Note that in the BhyveX64 platform, the pathname
"OvmfPkg/Bhyve/Csm/CsmSupportLib/CsmSupportLib.inf" is bogus, and has
always been, since commit 656419f922 ("Add BhyvePkg, to support the
bhyve hypervisor", 2020-07-31).
Cc: Anthony Perard <anthony.perard@citrix.com>
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Corvin Köhne <corvink@freebsd.org>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Rebecca Cran <rebecca@bsdio.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=4588
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20231110235820.644381-22-lersek@redhat.com>
Reviewed-by: Jiewen Yao <Jiewen.yao@intel.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Acked-by: Corvin Köhne <corvink@FreeBSD.org>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
LegacyBiosDxe is not used by any platform at this point, remove it.
This patch removes mentions of the following CSM resources from the source
code [*] [**]:
- GUIDs (protocols or otherwise):
- gEfiIsaIoProtocolGuid
- gEfiLegacy8259ProtocolGuid
- gEfiLegacyBiosGuid
- gEfiLegacyBiosPlatformProtocolGuid
- gEfiLegacyBiosProtocolGuid
- gEfiLegacyInterruptProtocolGuid
- headers:
- FrameworkDxe.h
- Guid/LegacyBios.h
- Protocol/IsaIo.h
- Protocol/Legacy8259.h
- Protocol/LegacyBios.h
- Protocol/LegacyBiosPlatform.h
- Protocol/LegacyInterrupt.h
- PCDs:
- PcdEbdaReservedMemorySize
- PcdEndOpromShadowAddress
- PcdHighPmmMemorySize
- PcdLegacyBiosCacheLegacyRegion
- PcdLowPmmMemorySize
- PcdOpromReservedMemoryBase
- PcdOpromReservedMemorySize
which extends the list of resources scheduled for removal to:
- GUIDs (protocols or otherwise):
- gEfiIsaIoProtocolGuid
- gEfiLegacy8259ProtocolGuid
- gEfiLegacyBiosGuid
- gEfiLegacyBiosPlatformProtocolGuid
- gEfiLegacyBiosProtocolGuid
- gEfiLegacyInterruptProtocolGuid
- headers:
- FrameworkDxe.h
- Guid/LegacyBios.h
- Protocol/IsaIo.h
- Protocol/Legacy8259.h
- Protocol/LegacyBios.h
- Protocol/LegacyBiosPlatform.h
- Protocol/LegacyInterrupt.h
- PCDs:
- PcdEbdaReservedMemorySize
- PcdEndOpromShadowAddress
- PcdHighPmmMemorySize
- PcdLegacyBiosCacheLegacyRegion
- PcdLowPmmMemorySize
- PcdOpromReservedMemoryBase
- PcdOpromReservedMemorySize
[*] Note that gEfiGenericMemTestProtocolGuid, while not a CSM-related
protocol, also becomes useless in the OVMF platforms, so we'll deal with
that later in the series as well.
[**] Note that gEfiLegacyRegion2ProtocolGuid, while a CSM-related
protocol, cannot be scheduled for removal, because the protocol GUID is
defined in "MdePkg.dec", and it's not only "OvmfPkg/Csm/CsmSupportLib"
that produces it in all of edk2, but also
"MdeModulePkg/Universal/LegacyRegion2Dxe" (not used by OVMF). For the same
reason, the "Protocol/LegacyRegion2.h" header (from MdePkg) cannot be
scheduled for removal.
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=4588
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20231110235820.644381-16-lersek@redhat.com>
Reviewed-by: Jiewen Yao <Jiewen.yao@intel.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Acked-by: Corvin Köhne <corvink@FreeBSD.org>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
The UEFI protocol database cannot contain gEfiLegacyBiosProtocolGuid any
longer, after excluding LegacyBiosDxe from the OVMF platforms. Therefore,
instruct PciBusDxe from IncompatiblePciDeviceSupportDxe to allocate 64-bit
BARs above 4 GB regardless of a CSM.
Regression test: in commit 855743f717 ("OvmfPkg: prevent 64-bit MMIO BAR
degradation if there is no CSM", 2016-05-25), where we introduced
IncompatiblePciDeviceSupportDxe, we said, "By default, the PCI Bus driver
considers an option ROM reason enough for allocating the 64-bit MMIO BARs
in 32-bit address space". Therefore it suffices to verify the 64-bit BARs
of a device for which QEMU provides an option ROM. The simplest case is
the virtio-net-pci device. And indeed, with this patch applied, the log
contains:
> PciBus: Discovered PCI @ [04|00|00] [VID = 0x1AF4, DID = 0x1041]
> BAR[1]: Type = Mem32; Alignment = 0xFFF; Length = 0x1000; Offset = 0x14
> BAR[4]: Type = PMem64; Alignment = 0x3FFF; Length = 0x4000; Offset = 0x20
This portion shows that Bus|Device|Function 04|00|00 is a (modern)
virito-net-pci device [VID = 0x1AF4, DID = 0x1041].
> PciBus: Resource Map for Bridge [00|01|03]
> Type = Mem32; Base = 0x81200000; Length = 0x200000; Alignment = 0x1FFFFF
> Base = Padding; Length = 0x200000; Alignment = 0x1FFFFF
> Base = 0x81200000; Length = 0x1000; Alignment = 0xFFF; Owner = PCI [04|00|00:14]
> Type = Mem32; Base = 0x81A43000; Length = 0x1000; Alignment = 0xFFF
> Type = PMem64; Base = 0x800200000; Length = 0x100000; Alignment = 0xFFFFF
> Base = 0x800200000; Length = 0x4000; Alignment = 0x3FFF; Owner = PCI [04|00|00:20]
This quote shows that 04|00|00 has a BAR at 0x8_0020_0000.
(It also shows that the device is behind a bridge (PCIe root port) whose
own BDF is 00|01|03.)
> [Security] 3rd party image[7CEEB418] can be loaded after EndOfDxe: PciRoot(0x0)/Pci(0x1,0x3)/Pci(0x0,0x0)/Offset(0x10E00,0x273FF).
> None of Tcg2Protocol/CcMeasurementProtocol is installed.
> InstallProtocolInterface: [EfiLoadedImageProtocol] 7D2E5140
> Loading driver at 0x0007CA9F000 EntryPoint=0x0007CAA5447 1af41000.efi
> InstallProtocolInterface: [EfiLoadedImageDevicePathProtocol] 7D5B2198
And this part finally shows that the iPXE option ROM for the device
(1af41000.efi) was detected and is loaded. (Same PCIe root port, and PCIe
root ports can only host a single device.)
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=4588
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20231110235820.644381-14-lersek@redhat.com>
Reviewed-by: Jiewen Yao <Jiewen.yao@intel.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Acked-by: Corvin Köhne <corvink@FreeBSD.org>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
The CSM-based VideoDxe driver is a special UEFI_DRIVER module that both
follows and doesn't follow the UEFI driver model.
Namely, in the Supported and Start members of its Driver Binding Protocol
instance, it consumes the Legacy Bios Protocol directly from the UEFI
protocol database, as opposed to (only) opening protocols on the handle
that it is supposed to bind.
Furthermore, the driver "marks" its own image handle with the
NULL-interface "Legacy Bios" (pseudo-protocol) GUID, in order to "inform
back" the provider of the Legacy Bios Protocol, i.e., LegacyBiosDxe, that
VideoDxe is a "BIOS Thunk Driver" in the system.
Quoting "OvmfPkg/Csm/Include/Guid/LegacyBios.h", such a driver follows the
UEFI Driver Model, but still uses the Int86() or FarCall() services of the
Legacy Bios Protocol as the basis for the UEFI protocol it produces.
In a sense, there is a circular dependency between VideoDxe and
LegacyBiosDxe; each knows about the other. However, VideoDxe is a
UEFI_DRIVER, while LegacyBiosDxe is a platform DXE_DRIVER with a very long
DEPEX. Therefore, for keeping dependencies conceptually intact, first
exclude VideoDxe from the OVMF platforms. Always include the
hypervisor-specific real UEFI video driver.
--*--
Note that the pathname
"IntelFrameworkModulePkg/Csm/BiosThunk/VideoDxe/VideoDxe.inf" in the bhyve
platform DSC and FDF files is bogus anyway.
Cc: Anthony Perard <anthony.perard@citrix.com>
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Corvin Köhne <corvink@freebsd.org>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Rebecca Cran <rebecca@bsdio.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=4588
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20231110235820.644381-9-lersek@redhat.com>
Reviewed-by: Jiewen Yao <Jiewen.yao@intel.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Acked-by: Corvin Köhne <corvink@FreeBSD.org>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
LegacyBootMaintUiLib is not used by any platform at this point, remove it.
This patch removes mentions of the following CSM resources from the source
code:
- GUIDs (protocols or otherwise):
- gEfiLegacyBiosProtocolGuid
- gEfiLegacyDevOrderVariableGuid
- headers:
- Guid/LegacyDevOrder.h
- Protocol/LegacyBios.h
which extends the list of resources scheduled for removal to:
- GUIDs (protocols or otherwise):
- gEfiLegacyBiosProtocolGuid
- gEfiLegacyDevOrderVariableGuid
- headers:
- Guid/LegacyDevOrder.h
- Protocol/LegacyBios.h
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=4588
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20231110235820.644381-7-lersek@redhat.com>
Reviewed-by: Jiewen Yao <Jiewen.yao@intel.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Acked-by: Corvin Köhne <corvink@FreeBSD.org>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
LegacyBootManagerLib is not used by any platform at this point, remove it.
This patch removes mentions of the following CSM resources from the source
code:
- GUIDs (protocols or otherwise):
- gEfiLegacyBiosProtocolGuid
- gEfiLegacyDevOrderVariableGuid
- headers:
- Guid/LegacyDevOrder.h
- Protocol/LegacyBios.h
which extends the list of resources scheduled for removal to:
- GUIDs (protocols or otherwise):
- gEfiLegacyBiosProtocolGuid
- gEfiLegacyDevOrderVariableGuid
- headers:
- Guid/LegacyDevOrder.h
- Protocol/LegacyBios.h
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=4588
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20231110235820.644381-5-lersek@redhat.com>
Reviewed-by: Jiewen Yao <Jiewen.yao@intel.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Acked-by: Corvin Köhne <corvink@FreeBSD.org>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
OS may enable CET-IBT feature by set MSR IA32_U_CET.bit2.
If IA32_U_CET.bit2 is set, CPU is in WAIT_FOR_ENDBRANCH state and
the next assemble code is not ENDBR, it will trigger #CP exception
when set CR4.CET bit.
SMI handler needs to backup MSR IA32_U_CET and clear MSR IA32_U_CET
before set CR4.CET bit,
And SMI handler needs to restore MSR IA32_U_CET when exit SMI handler.
Signed-off-by: Sheng Wei <w.sheng@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Wu Jiaxin <jiaxin.wu@intel.com>
Cc: Tan Dun <dun.tan@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
The DXE & MM standalone variant of AcpiTimerLib defines a global
named mPerformanceCounterFrequency. A global with an identical
name is also present in MdeModulePkg/Bus/Pci/XhciDxe/Xhci.c
Since XhciDxe has a dependency on TimerLib, this can cause link
errors due to the same symbol being defined twice if the platform
DSC chooses to use AcpiTimerLib as the TimerLib implementation for
any given platform.
To resolve this, I noted that some of the globals in Xhci.c are not
used outside of the Xhci.c compilation unit:
- mPerformanceCounterStartValue
- mPerformanceCounterEndValue
- mPerformanceCounterFrequency
- mPerformanceCounterValuesCached
I have changed the definition for all of these to static and added
an Xhci prefix. Since they are not used outside of the Xhci.c
compilation unit, there is no reason to have them exported as
globals.
Reviewed-by: Ray Ni <ray.ni@intel.com>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Signed-off-by: Nate DeSimone <nathaniel.l.desimone@intel.com>
The DXE & MM standalone variant of AcpiTimerLib defines a global
named mPerformanceCounterFrequency. A global with an identical
name is also present in MdeModulePkg/Bus/Pci/XhciDxe/Xhci.c
Since XhciDxe has a dependency on TimerLib, this can cause link
errors due to the same symbol being defined twice if the platform
DSC chooses to use AcpiTimerLib as the TimerLib implementation for
any given platform.
To resolve this, I have changed made the definition of
mPerformanceCounterFrequency to static and renamed it to
mAcpiTimerLibTscFrequency. Since this variable is not used outside
of the DxeStandaloneMmAcpiTimerLib.c compilation unit, there is no
reason to have it exported as a global.
Reviewed-by: Ray Ni <ray.ni@intel.com>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Signed-off-by: Nate DeSimone <nathaniel.l.desimone@intel.com>
__builtin_return_address returns a pointer, not a string. Fix
the STACK FAULT message in BaseStackCheckLib appropriately.
Signed-off-by: Jake Garver <jake@nvidia.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Currently, there are code to set memory attribute in CpuMpPei module.
However, the code doesn't handle the case of 5 level paging.
Use the CpuPageTableLib to set memory attribute for two purpose:
1. Add 5 level paging support
2. Clean up code
Reviewed-by: Ray Ni <ray.ni@intel.com>
Cc: Rahul Kumar <rahul1.kumar@intel.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Zhiguang Liu <zhiguang.liu@intel.com>
The local variable OneOfPagingEntry is used before initialized, this
may cause reserved bit in page table entry is set especially in PAE
paging mode. The bug is random because it depends on the value in
stack.
Reviewed-by: Ray Ni <ray.ni@intel.com>
Cc: Rahul Kumar <rahul1.kumar@intel.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Zhiguang Liu <zhiguang.liu@intel.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4609
The current CalculateCrc16Ansi implementation does the following:
1) Invert the passed checksum
2) Calculate the new checksum by going through data and using the
lookup table
3) Invert it back again
This emulated my design for CalculateCrc32c, where 0 is
passed as the initial checksum, and it inverts in the end.
However, CRC16 does not invert the checksum on input and output.
So this is incorrect.
Fix the problem by not inverting input checksums nor output checksums.
Callers should now pass CRC16ANSI_INIT as the initial value instead of
"0". This is a breaking change.
This problem was found out-of-list when older ext4 filesystems
(that use crc16 checksums) failed to mount with "corruption".
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Zhiguang Liu <zhiguang.liu@intel.com>
Signed-off-by: Pedro Falcato <pedro.falcato@gmail.com>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4610
Google Test hides test registration in global constructors on global
objects. Global constructors are traditionally implemented by placing
references to the global constructor's symbol in special sections
(traditionally named .ctors or .init_array). These sections are not
explicitly referenced by the linker, and libc only looks at special
start and end symbols (and calls them).
This works fine if you're linking a program manually using
gcc a.o b.o c.o -o test_suite
but fails miserably when using static libraries (such as what EDK2
does), because traditional static archive symbol resolution rules don't
allow for object files to be pulled in to the link if there isn't an
undefined symbol reference to that .o elsewhere.
Fix it by passing --whole-archive (GCC) and /WHOLEARCHIVE (MSVC). These
options force the linker to pull in the entire static library, thus
including previously-unreferenced constructors and making sure
multi-file gtest EDK2 components work.
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Michael Kubacki <mikuback@linux.microsoft.com>
Cc: Sean Brogan <sean.brogan@microsoft.com>
Signed-off-by: Pedro Falcato <pedro.falcato@gmail.com>
Reviewed-by: Cc: Michael D Kinney <michael.d.kinney@intel.com>
CoreLocateDevicePath is used in CoreInstallMultipleProtocolInterfaces to
check if a Device Path Protocol instance with the same device path is
alreay installed.
CoreLocateDevicePath is a generic API, and would introduce some
unnecessary overhead for such usage.
The optimization is:
1. Implement IsDevicePathInstalled to loop all the Device Path
Protocols installed and check if any of them matchs the given device
path.
2. Replace CoreLocateDevicePath with IsDevicePathInstalled in
CoreInstallMultipleProtocolInterfaces.
This optimization could save several seconds in PCI enumeration on a
system with many PCI devices.
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Dandan Bi <dandan.bi@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Signed-off-by: Zhi Jin <zhi.jin@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Ancient GCC 4.8.5 warned about variable may be unitialied.
And it doesn't look like false alarm.
The warning is:
edk2/RedfishPkg/Library/HiiUtilityLib/HiiUtilityInternal.c: In function 'GetQuestionDefault':
edk2/RedfishPkg/Library/HiiUtilityLib/HiiUtilityInternal.c:5519:6: error: 'ConfigAccess' may be used uninitialized in this function [-Werror=maybe-uninitialized]
if (ConfigAccess != NULL) {
Cc: Abner Chang <abner.chang@amd.com>
Cc: Igor Kulchytskyy <igork@ami.com>
Reviewed-by: Nickle Wang <nicklew@nvidia.com>
Signed-off-by: Mike Maslenkin <mike.maslenkin@gmail.com>
AndroidBootImgLib allows for platforms to append to kernel command
line but does not allow for the overall kernel command line to go
beyond the limit set by the image header. Address this limitation
by adding a pcd where platform can tell how many extra characters
they expect on their platform in addition to what the image header
specifies.
Signed-off-by: Ashish Singhal <ashishsingha@nvidia.com>
Reviewed-by: Abner Chang <abner.chang@amd.com>
Curently, AndroidBootImgLib expects input kernel command line
to never exceed 256 unicode characters where the image header
allows for 512 ascii characters. If image header allows 512
ascii characters, similar number of unicode characters should be
allowed at the minimum.
Signed-off-by: Ashish Singhal <ashishsingha@nvidia.com>
Reviewed-by: Abner Chang <abner.chang@amd.com>
Currently, if BSP election is not enabled, will use Core0 as SMM BSP.
However, Core0 does not always have the highest performance.
So, we can used NonSmm BSP as default BSP.
This will take effect in normal SMM init flow and S3 boot flow.
In normal SMM flow, the code is executed before first SMI.
In S3 flow, the code is executed in Non-SMM BSP's first SMI, where the
gSmmCpuPrivate keeps the data from last boot.
Reviewed-by: Ray Ni <ray.ni@intel.com>
Cc: Rahul Kumar <rahul1.kumar@intel.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Zhiguang Liu <zhiguang.liu@intel.com>
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=4597
When creating a new variable, skip marking VAR_HEADER_VALID_ONLY so that
variable header + data update can be merged into one flash write. This
will greatly reduce the time taken for updating a variable and thus
increase performance. Removing VAR_HEADER_VALID_ONLY marking doesn't
have any function impact since it's not used by current code to detect
variable header + data corruption.
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Signed-off-by: Gao Cheng <gao.cheng@intel.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
If the SetVirtualAddressMap() is not called, mIsVirtualAddrConverted
is FALSE and the kernel crash occurs in IsNestedFmpCapsule() when
executing gBS->LocateProtocol () in the else case.
To serve the omitted SetVirtualAddressMap() call, we could just check
mEsrtTable presence instead of relying on mIsVirtualAddrConverted.
Signed-off-by: Nhi Pham <nhi@os.amperecomputing.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
GetNextEntryAttribute() is currently applying a 64-bit mask
(TT_ATTRIBUTES_MASK) to a 32-bit descriptor value (EntryType).
The original descriptor was 64 bits containing the upper and
lower attributes which are included in TT_ATTRIBUTES_MASK.
The PrevEntryAttribute parameter is also a UINT32, but passed to
PageAttributeToGcdAttribute() for a UINT64 parameter where the
function checks masks in the upper 32 bits of the integer value:
PageAttributeToGcdAttribute (*PrevEntryAttribute)
...
STATIC
UINT64
PageAttributeToGcdAttribute (
IN UINT64 PageAttributes
)
...
if ((PageAttributes & (TT_PXN_MASK | TT_UXN_MASK)) != 0) {
GcdAttributes |= EFI_MEMORY_XP;
}
...
#define TT_PXN_MASK BIT53
#define TT_UXN_MASK BIT54 // EL1&0
This change removes UINT32 intermediary values. For EntryType,
eliminating an unncessary cast. For EntryAttribute, preserving the
upper and lower attributes for evaluation in
PageAttributeToGcdAttribute().
This also resolves the following compiler warning previously present
on Visual Studio for the assignment to the previously 32-bit local
variables.
'=': conversion from 'UINT64' to 'UINT32', possible loss of data
Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
In order to allow the VMM (such as QEMU) to add a page with hashes of
kernel/initrd/cmdline for measured direct boot on SNP, add it explicitly
to the SNP metadata list report to the VMM.
In such case, VMM should fill the page with the hashes content, or
explicitly update it as a zero page (if kernel hashes are not used).
Note that for SNP, the launch secret part of the page (lower 3KB) are
not relevant and will remain zero. The last 1KB is used for the hashes.
This should have no effect on OvmfPkgX64 targets (which don't define
PcdSevLaunchSecretBase).
Signed-off-by: Dov Murik <dovmurik@linux.ibm.com>
Acked-by: Tom Lendacky <thomas.lendacky@amd.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Resize the MEMFD section of AmdSevX64.fdf and reorder its pages so that
it matches the same size and order used in OvmfPkgX64.fdf.
After this change, this is the difference in the MEMFD of the two
targets:
$ diff -u \
<(sed -ne '/FD.MEMFD/,/FV.SECFV/p' OvmfPkg/OvmfPkgX64.fdf) \
<(sed -ne '/FD.MEMFD/,/FV.SECFV/p' OvmfPkg/AmdSev/AmdSevX64.fdf)
--- /dev/fd/63 2023-02-16 07:06:15.365308683 +0000
+++ /dev/fd/62 2023-02-16 07:06:15.365308683 +0000
@@ -32,6 +32,12 @@
0x00E000|0x001000
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfCpuidBase|gUefiOvmfPkgTokenSpaceGuid.PcdOvmfCpuidSize
+0x00F000|0x000C00
+gUefiOvmfPkgTokenSpaceGuid.PcdSevLaunchSecretBase|gUefiOvmfPkgTokenSpaceGuid.PcdSevLaunchSecretSize
+
+0x00FC00|0x000400
+gUefiOvmfPkgTokenSpaceGuid.PcdQemuHashTableBase|gUefiOvmfPkgTokenSpaceGuid.PcdQemuHashTableSize
+
0x010000|0x010000
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPeiTempRamBase|gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPeiTempRamSize
Signed-off-by: Dov Murik <dovmurik@linux.ibm.com>
Acked-by: Tom Lendacky <thomas.lendacky@amd.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
With SEV-SNP, the SEV-ES save area for a vCPU should be unique to that
vCPU. After commit 3323359a81, the VMSA allocation was re-used, but when
sorting the CPUs by APIC ID, the save area was not updated to follow the
original CPU. Similar to the StartupApSignal address, the SevEsSaveArea
address should be updated when sorting the CPUs.
This does not cause an issue at this time because all APs are in HLT state
and then are (re)started at the same time, with the same VMSA contents.
However, this should be fixed to account for any change in future
behavior.
Fixes: 3323359a81 ("UefiCpuPkg/MpInitLib: Reuse VMSA allocation to ...")
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
The CPUID_EXTENDED_TOPOLOGY CPUID leaf takes a subleaf as input when
returning CPUID information. However, the AsmCpuid() function does not
zero out ECX before the CPUID instruction, so the input leaf is used as
the sub-leaf for the CPUID request and returns erroneous/invalid CPUID
data, since the intent of the request was to get data related to sub-leaf
0. Instead, use AsmCpuidEx() for the CPUID_EXTENDED_TOPOLOGY leaf.
Fixes: d4d7c9ad5f ("UefiCpuPkg/MpInitLib: use BSP to do extended ...")
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
mReplaceLiveEntryFunc is a function pointer but assigned as a VOID*
pointer:
mReplaceLiveEntryFunc = *(VOID **)GET_GUID_HOB_DATA (Hob);
This leads to the Visual Studio warning:
nonstandard extension, function/data pointer conversion in
expression
This change updates the assignment to avoid using a data pointer and
defines a type for the function pointer to succinctly and accurately
refer to the type when it is used in the library code.
Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
PiSmmCore fetches the EFI memory map and calls SplitTable() to
split each loaded image section into its own descriptor with
EFI_MEMORY_XP marking data sections and EFI_MEMORY_RO marking
code sections.
The SMM MAT logic is almost identical to the DXE MAT logic but goes
a step further and also updates the memory map descriptors which describe
image code and data sections to be of type EfiRuntimeServicesCode and
EfiRuntimeServicesData respectively. The consolidated MAT logic
(present in the new ImagePropertiesRecordLib) more closely follows
the DXE MAT logic which identifies image code sections by the presence
of the attribute EFI_MEMORY_RO in the descriptor and image data
sections by the presence of the attribute EFI_MEMORY_XP. Because of
the flow choice of the consolidated MAT logic, the SMM MAT logic should
just use the attributes from the table returned by SplitTable().
Additionally, the function EnforceMemoryMapAttribute() in the SMM MAT
logic will ensure that the CODE and DATA memory types have the desired
attributes so bisecting this patch series at this commit will still
function as before.
Cc: Eric Dong <eric.dong@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Rahul Kumar <rahul1.kumar@intel.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Taylor Beebe <taylor.d.beebe@gmail.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Update function headers to clarify the contract of each function and
improve readability. Add NULL checks to all functions that take a
pointer as an argument. Add return status to functions that
may need to return early due to invalid input.
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Dandan Bi <dandan.bi@intel.com>
Signed-off-by: Taylor Beebe <taylor.d.beebe@gmail.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
SplitRecord() does not handle the case where a memory descriptor
describes an image region plus extra pages before or after the
image region. This patch fixes this case by carving off the
unrelated regions into their own descriptors.
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Dandan Bi <dandan.bi@intel.com>
Signed-off-by: Taylor Beebe <taylor.d.beebe@gmail.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
|4K PAGE|DATA|CODE|DATA|CODE|DATA|4K PAGE|
Say the above memory region is currently one memory map descriptor.
The above image memory layout example contains two code sections
oriented in a way that maximizes the number of descriptors which
would be required to describe each section.
NOTE: It's unlikely that a data section would ever be between
two code sections, but it's still handled by the below formula
for correctness.
There are two code sections (let's say CodeSegmentMax == 2),
three data sections, and two unrelated memory regions flanking the
image. The number of required descriptors to describe this layout
will be 2 * 2 + 3 == 7. This patch updates the calculations to account
for the worst-case scenario.
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Dandan Bi <dandan.bi@intel.com>
Signed-off-by: Taylor Beebe <taylor.d.beebe@gmail.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Create a host-based unit test for the ImagePropertiesRecordLib
SplitTable() logic. This test has 4 cases which tests different
potential image and memory map layouts. 3/4 of these tests fail
with the logic in its current state to provide proof of the bugs
in the current MAT logic.
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Dandan Bi <dandan.bi@intel.com>
Signed-off-by: Taylor Beebe <taylor.d.beebe@gmail.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
No functional changes in this patch.
Updates the comments of _CPU_MP_DATA to delcared that duplications in
CpuMpData are present to avoid to be direct accessed and comprehended
in assembly code. CpuMpData: Intended for use in C code while
ExchangeInfo are used in assembly code in this module.
This patch deletes the unnecessary comments in CpuMpData, since
CpuMpData is no longer responsible for passing information from PEI to
DXE.
Signed-off-by: Yuanhao Xie <yuanhao.xie@intel.com>
Cc: Laszlo Ersek lersek@redhat.com
Cc: Eric Dong <eric.dong@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Rahul Kumar <rahul1.kumar@intel.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
This patch synchronizes the No-Execute bit in the IA32_EFER
register for the APs before the RestoreVolatileRegisters operation.
The commit 964a4f0, titled "Eliminate the second INIT-SIPI-SIPI
sequence," replaces the second INIT-SIPI-SIPI sequence with the BSP
calling the SwitchApContext function to initiate a specialized start-up
signal, waking up APs in the DXE instead of using INIT-SIPI-SIPI.
Due to this change, the logic for "Enable execute disable bit" in
MpFuncs.nasm is no longer executed. However, to ensure the proper setup
of the page table, it is necessary to synchronize the IA32_EFER.NXE for
APs before executing RestoreVolatileRegisters .
Based on SDM:
If IA32_EFER.NXE is set to 1, it signifies execute-disable, meaning
instruction fetches are not allowed from the 4-KByte page controlled by
this entry. Conversely, if it is set to 0, it is reserved.
Signed-off-by: Yuanhao Xie <yuanhao.xie@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Cc: Laszlo Ersek lersek@redhat.com
Cc: Eric Dong <eric.dong@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Rahul Kumar <rahul1.kumar@intel.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
2023-11-27 05:21:45 +00:00
584 changed files with 22841 additions and 33386 deletions
DEBUG((DEBUG_LOAD|DEBUG_INFO,"Loading driver at 0x%11p EntryPoint=0x%11p\n",(VOID*)(UINTN)ImageContext->ImageAddress,FUNCTION_ENTRY_POINT(ImageContext->EntryPoint)));
#endif
}else{
DEBUG((DEBUG_LOAD|DEBUG_INFO,"Loading driver at 0x%11p EntryPoint=0x%11p\n",(VOID*)(UINTN)ImageContext->ImageAddress,FUNCTION_ENTRY_POINT(ImageContext->EntryPoint)));
('ELF_ST_Shndx',c_uint16),# Elf32_Half /* Section index of symbol. */
]
# Structures used by Sun & GNU symbol versioning.
classELF_VERDEF(Structure):
_pack_=1
_fields_=[
('ELF_VD_Version',c_uint16),# Elf32_Half
('ELF_VD_Flags',c_uint16),# Elf32_Half
('ELF_VD_Ndx',c_uint16),# Elf32_Half
('ELF_VD_Cnt',c_uint16),# Elf32_Half
('ELF_VD_Hash',c_uint32),# Elf32_Word
('ELF_VD_Aux',c_uint32),# Elf32_Word
('ELF_VD_Next',c_uint32),# Elf32_Word
]
classELF_VERDAUX(Structure):
_pack_=1
_fields_=[
('ELF_VDA_Name',c_uint32),# Elf32_Word
('ELF_VDA_Next',c_uint32),# Elf32_Word
]
classELF_VERNEED(Structure):
_pack_=1
_fields_=[
('ELF_VN_Version',c_uint16),# Elf32_Half
('ELF_VN_Cnt',c_uint16),# Elf32_Half
('ELF_VN_File',c_uint32),# Elf32_Word
('ELF_VN_Aux',c_uint32),# Elf32_Word
('ELF_VN_Next',c_uint32),# Elf32_Word
]
classELF_VERNAUX(Structure):
_pack_=1
_fields_=[
('ELF_VNA_Hash',c_uint32),# Elf32_Word
('ELF_VNA_Flags',c_uint16),# Elf32_Half
('ELF_VNA_Other',c_uint16),# Elf32_Half
('ELF_VNA_Name',c_uint32),# Elf32_Word
('ELF_VNA_Next',c_uint32),# Elf32_Word
]
classELF_SYMINFO(Structure):
_pack_=1
_fields_=[
('ELF_SI_BoundTo',c_uint16),# Elf32_Half /* direct bindings - symbol bound to */
('ELF_SI_Flags',c_uint16),# Elf32_Half /* per symbol flags */
]
classUNIVERSAL_PAYLOAD_INFO(Structure):
_pack_=1
_fields_=[
('Identifier',c_uint32),# ?PLDH? Identifier for the unverial payload info. 0x504c4448
('HeaderLength',c_uint32),# Length of the structure in bytes.
('SpecRevision',c_uint16),# Indicates compliance with a revision of this specification in the BCD format. 7 : 0 - Minor Version / 15 : 8 - Major Version For revision v0.75 the value will be 0x0075.
('Reserved',c_uint16),# Reserved for future use.
('Revision',c_uint32),# Revision of the Payload binary. Major.Minor .Revision.Build . The ImageRevision can be decoded as follows: 7 : 0 - Build Number / 15 :8 - Revision / 23 :16 - Minor Version / 31 :24 - Major Version
('Attribute',c_uint32),# Length of the structure in bytes.
('Capability',c_uint32),# Length of the structure in bytes.
('ProducerId',ARRAY(c_uint8,16)),# Length of the structure in bytes.
('ImageId',ARRAY(c_uint8,16)),# Length of the structure in bytes.
@retval EFI_SUCCESS The operation completed successfully.
@retval EFI_INVALID_PARAMETER Time is NULL.
@retval EFI_DEVICE_ERROR The time could not be retrieved due to hardware error.
@retval EFI_UNSUPPORTED This call is not supported by this platform at the time the call is made.
The platform should describe this runtime service as unsupported at runtime
via an EFI_RT_PROPERTIES_TABLE configuration table.
**/
EFI_STATUS
@ -75,6 +78,9 @@ GetTime (
@retval EFI_SUCCESS The operation completed successfully.
@retval EFI_INVALID_PARAMETER A time field is out of range.
@retval EFI_DEVICE_ERROR The time could not be set due to hardware error.
@retval EFI_UNSUPPORTED This call is not supported by this platform at the time the call is made.
The platform should describe this runtime service as unsupported at runtime
via an EFI_RT_PROPERTIES_TABLE configuration table.
**/
EFI_STATUS
@ -132,6 +138,9 @@ SetTime (
@retval EFI_SUCCESS The alarm settings were returned.
@retval EFI_INVALID_PARAMETER Any parameter is NULL.
@retval EFI_DEVICE_ERROR The wakeup time could not be retrieved due to a hardware error.
@retval EFI_UNSUPPORTED This call is not supported by this platform at the time the call is made.
The platform should describe this runtime service as unsupported at runtime
via an EFI_RT_PROPERTIES_TABLE configuration table.
**/
EFI_STATUS
@ -166,7 +175,9 @@ GetWakeupTime (
Enable is FALSE, then the wakeup alarm was disabled.
@retval EFI_INVALID_PARAMETER A time field is out of range.
@retval EFI_DEVICE_ERROR The wakeup time could not be set due to a hardware error.
@retval EFI_UNSUPPORTED A wakeup timer is not supported on this platform.
@retval EFI_UNSUPPORTED This call is not supported by this platform at the time the call is made.
The platform should describe this runtime service as unsupported at runtime
via an EFI_RT_PROPERTIES_TABLE configuration table.
**/
EFI_STATUS
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
