|
[PATCH 1/1] OvmfPkg: rename QemuBootOrderNNNN to VMMBootOrderNNNN
Gerd Hoffmann
While the actual implementation (using qemu fw_cfg) is qemu-specific,
the idea to store the boot order as configured by the VMM in EFI variables is not. So lets give the variables a more neutral name while we still can (i.e. no stable tag yet with the new feature). While being at it also fix the NNNN format (use %x instead of %d for consistency with BootNNNN). Signed-off-by: Gerd Hoffmann <kraxel@...> --- OvmfPkg/OvmfPkg.dec | 2 +- OvmfPkg/Library/QemuBootOrderLib/QemuBootOrderLib.inf | 2 +- OvmfPkg/Library/QemuBootOrderLib/QemuBootOrderLib.c | 6 +++--- 3 files changed, 5 insertions(+), 5 deletions(-) diff --git a/OvmfPkg/OvmfPkg.dec b/OvmfPkg/OvmfPkg.dec index 6d689ecc5d55..f13dd4a61f01 100644 --- a/OvmfPkg/OvmfPkg.dec +++ b/OvmfPkg/OvmfPkg.dec @@ -146,7 +146,7 @@ [Guids] gConfidentialComputingSecretGuid = {0xadf956ad, 0xe98c, 0x484c, {0xae, 0x11, 0xb5, 0x1c, 0x7d, 0x33, 0x64, 0x47}} gConfidentialComputingSevSnpBlobGuid = {0x067b1f5f, 0xcf26, 0x44c5, {0x85, 0x54, 0x93, 0xd7, 0x77, 0x91, 0x2d, 0x42}} gUefiOvmfPkgPlatformInfoGuid = {0xdec9b486, 0x1f16, 0x47c7, {0x8f, 0x68, 0xdf, 0x1a, 0x41, 0x88, 0x8b, 0xa5}} - gQemuBootOrderGuid = {0x668f4529, 0x63d0, 0x4bb5, {0xb6, 0x5d, 0x6f, 0xbb, 0x9d, 0x36, 0xa4, 0x4a}} + gVMMBootOrderGuid = {0x668f4529, 0x63d0, 0x4bb5, {0xb6, 0x5d, 0x6f, 0xbb, 0x9d, 0x36, 0xa4, 0x4a}} [Ppis] # PPI whose presence in the PPI database signals that the TPM base address diff --git a/OvmfPkg/Library/QemuBootOrderLib/QemuBootOrderLib.inf b/OvmfPkg/Library/QemuBootOrderLib/QemuBootOrderLib.inf index 211344fb0b89..6e320e3e8514 100644 --- a/OvmfPkg/Library/QemuBootOrderLib/QemuBootOrderLib.inf +++ b/OvmfPkg/Library/QemuBootOrderLib/QemuBootOrderLib.inf @@ -49,7 +49,7 @@ [LibraryClasses] [Guids] gEfiGlobalVariableGuid gVirtioMmioTransportGuid - gQemuBootOrderGuid + gVMMBootOrderGuid [FeaturePcd] gUefiOvmfPkgTokenSpaceGuid.PcdQemuBootOrderPciTranslation diff --git a/OvmfPkg/Library/QemuBootOrderLib/QemuBootOrderLib.c b/OvmfPkg/Library/QemuBootOrderLib/QemuBootOrderLib.c index 18646daa67e3..cea4b7a099e3 100644 --- a/OvmfPkg/Library/QemuBootOrderLib/QemuBootOrderLib.c +++ b/OvmfPkg/Library/QemuBootOrderLib/QemuBootOrderLib.c @@ -1709,7 +1709,7 @@ ConnectDevicesFromQemu ( Attempt to retrieve the "bootorder" fw_cfg file from QEMU. Translate the OpenFirmware device paths therein to UEFI device path fragments. - On Success store the device path in QemuBootOrderNNNN variables. + On Success store the device path in VMMBootOrderNNNN variables. **/ VOID EFIAPI @@ -1794,13 +1794,13 @@ StoreQemuBootOrder ( UnicodeSPrint ( VariableName, sizeof (VariableName), - L"QemuBootOrder%04d", + L"VMMBootOrder%04x", VariableIndex++ ); DEBUG ((DEBUG_INFO, "%a: %s = %s\n", __FUNCTION__, VariableName, Translated)); gRT->SetVariable ( VariableName, - &gQemuBootOrderGuid, + &gVMMBootOrderGuid, EFI_VARIABLE_BOOTSERVICE_ACCESS | EFI_VARIABLE_RUNTIME_ACCESS, GetDevicePathSize (DevicePath), DevicePath -- 2.37.3
|
|
|
|
Re: [PATCH v1 1/1] DynamicTablesPkg: Add SMBIOS String table helper library
PierreGondois
Hello Girish,
On 10/4/22 05:01, Girish Mahadevan wrote: Hello Sami,I didn't try to run the code, but it seems ok to me. Assuming the string has 9 chars: """ // Copy 9 chars + 1 NULL char AsciiStrCpyS (SmbiosString, BytesRemaining, StrElement->String); // We have copied 10 chars BytesCopied = StrElement->StringLen + 1; BytesRemaining -= BytesCopied; // Increment SmbiosString of 10 chars, so SmbiosString is pointing // to an un-initialized char now and we can continue. SmbiosString += BytesCopied; """ However, maybe we need to add an extra check/ASSERT for BytesRemaining before writing the last NULL char. + return EFI_SUCCESS;
|
|
|
|
Re: [PATCH v1 1/1] DynamicTablesPkg: Add SMBIOS String table helper library
Sami Mujawar
Hi Girish,
There are 2 cases that need handling. Please see my response inline marked [SAMI]. Regards, Sami Mujawar On 04/10/2022 04:01 am, Girish Mahadevan wrote: Hello Sami,[SAMI] SmbiosString points to the startof the sting storage area. [SAMI] Case 1: SmbiosString[0] is set to '\0' and the pointer is incremented. So now it points to SmbiosString[1] which will be updated with the String table null terminator before the function returns.+ [SAMI] Case 2: AsciiStrCpyS() copies the string including the terrminating null character and BytesCopied is incremented accordingly. SmbiosString is then incremented by BytesCopied. So, SmbiosString should point to the byte where the next string starts or will be updated with the String table null terminator before the function returns.+ } else { [SAMI] I don't think this increment is required for the reasons explained above in Case 1 & Case 2. However, please let me know if I have missed something.+ }[GM] Shouldn't you advance the SmbiosString pointer by one more ? After the loop isn't SmbiosString going to be at the NULL char of the last string ? And we're trying to add one more NULL character ? *SmbiosString = '\0';+ return EFI_SUCCESS;
|
|
|
|
[PATCH v1 1/1] uefi-sct/SctPkg: Incorrect instances of RANDOM_NAME_PROTOCOL
Sam Kaynor
Changed 4 incorrect instances of "RANDOM_NAME_PROTOCOL" in
RandomNumberBBTestConformance and RandomNumberBBTestFunction to "RANDOM_NUMBER_PROTOCOL". Cc: G Edhaya Chandran <Edhaya.Chandran@...> Cc: Barton Gao <gaojie@...> Cc: Carolyn Gjertsen <Carolyn.Gjertsen@...> Cc: Samer El-Haj-Mahmoud <Samer.El-Haj-Mahmoud@...> Cc: Eric Jin <eric.jin@...> Cc: Arvin Chen <arvinx.chen@...> Cc: Supreeth Venkatesh <Supreeth.Venkatesh@...> Signed-off-by: Sam Kaynor <sam.kaynor@...> --- uefi-sct/SctPkg/TestCase/UEFI/EFI/Protocol/RandomNumber/BlackBoxTest/Ran= domNumberBBTestConformance.c | 4 ++-- uefi-sct/SctPkg/TestCase/UEFI/EFI/Protocol/RandomNumber/BlackBoxTest/Ran= domNumberBBTestFunction.c | 4 ++-- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/uefi-sct/SctPkg/TestCase/UEFI/EFI/Protocol/RandomNumber/Blac= kBoxTest/RandomNumberBBTestConformance.c b/uefi-sct/SctPkg/TestCase/UEFI/= EFI/Protocol/RandomNumber/BlackBoxTest/RandomNumberBBTestConformance.c index 2738a4899457..364aaca925e0 100644 --- a/uefi-sct/SctPkg/TestCase/UEFI/EFI/Protocol/RandomNumber/BlackBoxTes= t/RandomNumberBBTestConformance.c +++ b/uefi-sct/SctPkg/TestCase/UEFI/EFI/Protocol/RandomNumber/BlackBoxTes= t/RandomNumberBBTestConformance.c @@ -160,7 +160,7 @@ BBTestGetInfoConformanceTestCheckpoint1 ( StandardLib, EFI_TEST_ASSERTION_WARNING, gConformanceTestAssertionGuid001, - L"RANDOM_NAME_PROTOCOL.GetInfo - GetInfo() is not sup= ported or EFI_DEVICE_ERROR", + L"RANDOM_NUMBER_PROTOCOL.GetInfo - GetInfo() is not s= upported or EFI_DEVICE_ERROR", L"%a:%d: Status - %r", __FILE__, (UINTN)__LINE__, @@ -180,7 +180,7 @@ BBTestGetInfoConformanceTestCheckpoint1 ( StandardLib, AssertionType, gConformanceTestAssertionGuid001, - L"RANDOM_NAME_PROTOCOL.GetInfo - GetInfo() returns EFI_= BUFFER_TOO_SMALL with small RNGAlgorithmListSize and returns valid size", + L"RANDOM_NUMBER_PROTOCOL.GetInfo - GetInfo() returns EF= I_BUFFER_TOO_SMALL with small RNGAlgorithmListSize and returns valid size= ", L"%a:%d: Status - %r, RNGAlgorithmListSize - %d", __FILE__, (UINTN)__LINE__, diff --git a/uefi-sct/SctPkg/TestCase/UEFI/EFI/Protocol/RandomNumber/Blac= kBoxTest/RandomNumberBBTestFunction.c b/uefi-sct/SctPkg/TestCase/UEFI/EFI= /Protocol/RandomNumber/BlackBoxTest/RandomNumberBBTestFunction.c index 3d41085d2243..0ba003449dc6 100644 --- a/uefi-sct/SctPkg/TestCase/UEFI/EFI/Protocol/RandomNumber/BlackBoxTes= t/RandomNumberBBTestFunction.c +++ b/uefi-sct/SctPkg/TestCase/UEFI/EFI/Protocol/RandomNumber/BlackBoxTes= t/RandomNumberBBTestFunction.c @@ -188,7 +188,7 @@ BBTestGetInfoFunctionTestCheckpoint1 ( StandardLib, EFI_TEST_ASSERTION_FAILED, gTestGenericFailureGuid, - L"RANDOM_NAME_PROTOCOL.GetInfo - GetInfo() is not sup= ported or EFI_DEVICE_ERROR", + L"RANDOM_NUMBER_PROTOCOL.GetInfo - GetInfo() is not s= upported or EFI_DEVICE_ERROR", L"%a:%d: Status - %r", __FILE__, (UINTN)__LINE__, @@ -201,7 +201,7 @@ BBTestGetInfoFunctionTestCheckpoint1 ( StandardLib, EFI_TEST_ASSERTION_FAILED, gTestGenericFailureGuid, - L"RANDOM_NAME_PROTOCOL.GetInfo - GetInfo() could not = return the correct RNGAlgorithmListSize", + L"RANDOM_NUMBER_PROTOCOL.GetInfo - GetInfo() could no= t return the correct RNGAlgorithmListSize", L"%a:%d: Status - %r", __FILE__, (UINTN)__LINE__, --=20 2.34.1
|
|
|
|
[PATCH v1 0/1] Correct spelling error in SctPkg
Sam Kaynor
4 incorrect instances of "RANDOM_NAME_PROTOCOL" corrected to
"RANDOM_NUMBER_PROTOCOL" https://github.com/skaynor/edk2-test/tree/fix_bug_4065 Cc: G Edhaya Chandran <Edhaya.Chandran@...> Cc: Barton Gao <gaojie@...> Cc: Carolyn Gjertsen <Carolyn.Gjertsen@...> Cc: Samer El-Haj-Mahmoud <Samer.El-Haj-Mahmoud@...> Cc: Eric Jin <eric.jin@...> Cc: Arvin Chen <arvinx.chen@...> Cc: Supreeth Venkatesh <Supreeth.Venkatesh@...> Sam Kaynor (1): uefi-sct/SctPkg: Incorrect instances of RANDOM_NAME_PROTOCOL uefi-sct/SctPkg/TestCase/UEFI/EFI/Protocol/RandomNumber/BlackBoxTest/Ran= domNumberBBTestConformance.c | 4 ++-- uefi-sct/SctPkg/TestCase/UEFI/EFI/Protocol/RandomNumber/BlackBoxTest/Ran= domNumberBBTestFunction.c | 4 ++-- 2 files changed, 4 insertions(+), 4 deletions(-) --=20 2.34.1
|
|
|
|
Re: [PATCH v1 1/1] DynamicTablesPkg: Add SMBIOS String table helper library
Girish Mahadevan
Hello Sami,
My apologies for the late response. I had one question/comment. Comment marked with [GM] inline. Best Regards Girish On 9/12/2022 8:18 AM, Sami Mujawar wrote: External email: Use caution opening links or attachments[GM] Shouldn't you advance the SmbiosString pointer by one more ? After the loop isn't SmbiosString going to be at the NULL char of the last string ? And we're trying to add one more NULL character ? Should it be: SmbiosString++; *SmbiosString = '\0'; + return EFI_SUCCESS;
|
|
|
|
[PATCH v3] remove GCC build warning
JessyX Wu
Fix gcc: warning:
-x c after last input file has no effect These kind of flag can only affect the source code after them. For the build command in build_rule.template, we have no other source code or object after these two flag. It seems we don't need them here. Cc: Bob Feng <bob.c.feng@...> Cc: Liming Gao <gaoliming@...> Cc: Yuwei Chen <yuwei.chen@...> Signed-off-by: JessyX Wu <jessyx.wu@...> --- BaseTools/Conf/build_rule.template | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/BaseTools/Conf/build_rule.template b/BaseTools/Conf/build_rule.template index 5895b48fd8..af4819de92 100755 --- a/BaseTools/Conf/build_rule.template +++ b/BaseTools/Conf/build_rule.template @@ -463,7 +463,7 @@ <Command.GCC> "$(ASLCC)" $(DEPS_FLAGS) -c -o $(OUTPUT_DIR)(+)${s_dir}(+)${s_base}.obj $(CC_FLAGS) $(ASLCC_FLAGS) $(DEPS_FLAGS) $(INC) ${src} - "$(ASLDLINK)" -o $(OUTPUT_DIR)(+)${s_dir}(+)${s_base}.dll $(ASLDLINK_FLAGS) $(OUTPUT_DIR)(+)${s_dir}(+)${s_base}.obj $(CC_FLAGS) $(ASLCC_FLAGS) + "$(ASLDLINK)" -o $(OUTPUT_DIR)(+)${s_dir}(+)${s_base}.dll $(ASLDLINK_FLAGS) $(OUTPUT_DIR)(+)${s_dir}(+)${s_base}.obj "$(GENFW)" -o ${dst} -c $(OUTPUT_DIR)(+)${s_dir}(+)${s_base}.dll $(GENFW_FLAGS) <Command.CLANGPDB> -- 2.37.3.windows.1
|
|
|
|
Now: Tools, CI, Code base construction meeting series - 10/03/2022
#cal-notice
Group Notification <noreply@...>
Tools, CI, Code base construction meeting series When: Where: Description: TianoCore community, Microsoft and Intel will be hosting a series of open meetings to discuss build, CI, tools, and other related topics. If you are interested, have ideas/opinions please join us. These meetings will be Monday 4:30pm Pacific Time on Microsoft Teams. MS Teams Link in following discussion: * https://github.com/tianocore/edk2/discussions/2614 Anyone is welcome to join.
MS Teams Browser Clients * https://docs.microsoft.com/en-us/microsoftteams/get-clients?tabs=Windows#browser-client
|
|
|
|
Event: Tools, CI, Code base construction meeting series - 10/03/2022
#cal-reminder
Group Notification <noreply@...>
Reminder: Tools, CI, Code base construction meeting series When: Where: Description: TianoCore community, Microsoft and Intel will be hosting a series of open meetings to discuss build, CI, tools, and other related topics. If you are interested, have ideas/opinions please join us. These meetings will be Monday 4:30pm Pacific Time on Microsoft Teams. MS Teams Link in following discussion: * https://github.com/tianocore/edk2/discussions/2614 Anyone is welcome to join.
MS Teams Browser Clients * https://docs.microsoft.com/en-us/microsoftteams/get-clients?tabs=Windows#browser-client
|
|
|
|
Re: [edk2-platforms PATCH 0/2] Platform/RaspberryPi: SyncPcie() fixes
Jeremy Linton
Hi,
On 9/30/22 13:47, Adrien Thierry wrote: Hi Jeremy,That is unfortunate. Which revision/how much RAM? Can you paste the before/after kernel/pci output like:If you just add the range tweak, does that fix the XHCI config in your setupI tested applying the range tweak in your patch, unfortunately it doesn't ] brcm-pcie fd500000.pcie: host bridge /scb/pcie@7d500000 ranges: ] brcm-pcie fd500000.pcie: No bus range found for /scb/pcie@7d500000, using [bus 00-ff] ] brcm-pcie fd500000.pcie: MEM 0x0600000000..0x0603ffffff -> 0x00f8000000 ] brcm-pcie fd500000.pcie: IB MEM 0x0000000000..0x00bfffffff -> 0x0000000000 ] brcm-pcie fd500000.pcie: PCI host bridge to bus 0000:00 ] pci_bus 0000:00: root bus resource [bus 00-ff] ] pci_bus 0000:00: root bus resource [mem 0x600000000-0x603ffffff] (bus address [0xf8000000-0xfbffffff]) I tested it on a C0 with 8G and a B0 with 4G, and it seems to work on both, although the C0 might have been misbehaving a bit (likely unrelated). In both cases I swapped in the latest Pi foundation DT (https://github.com/raspberrypi/firmware/blob/master/boot/bcm2711-rpi-4-b.dtb) which uses the address you suggest, and it still seems to work either way (with or without the reset). If we reroll the PFTF firmware it is usually with the latest pi foundation DTs. So the first patch makes sense, but I think it should probably be checking both DT property names (pci0,0 and pci1,0) since we probably want maximum compatibility with differing DT's the user might swap in, and the upstream linux change which changes the node from 1,0 to 0,0 is from august of last year, so not old at all.. The second one, I'm less sure about, since the primary thing your changing (AFAIK) is whether the XHCI BIOS handoff is being checked, and since EDK2 supports the hand-off and Linux doesn't throw the XHCI bios failure message I think we actually want to leave that in place. If you have debugging turned on, the XHCI/LegacyBios ownership control is the message you see during exit boot services that says "XhciClearBiosOwnership: called to clear BIOS ownership". I suspect the kernel patch is yet another case of "UBOOT and/or the pi foundation firmware is broken so we fixed the kernel" Do you see a difference with/without the second patch? Here's my SyncPcie function with the range tweak applied [1]
|
|
|
|
[PATCH v6 7/7] OvmfPkg/PlatformPei: SEV-SNP make >=4GB unaccepted
Dionna Glaze
Instead of eagerly accepting all memory in PEI, only accept memory under
the 4GB address. This allows a loaded image to use the ACCEPT_ALL_UNACCEPTED_MEMORY_PROTOCOL to disable the accept behavior and indicate that it can interpret the memory type accordingly. This classification is safe since ExitBootServices will accept and reclassify the memory as conventional if the disable protocol is not used. Cc: Ard Biescheuvel <ardb@...> Cc: "Min M. Xu" <min.m.xu@...> Cc: Gerd Hoffmann <kraxel@...> Cc: James Bottomley <jejb@...> Cc: Tom Lendacky <Thomas.Lendacky@...> Cc: Jiewen Yao <jiewen.yao@...> Cc: Erdem Aktas <erdemaktas@...> Signed-off-by: Dionna Glaze <dionnaglaze@...> --- OvmfPkg/PlatformPei/AmdSev.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/OvmfPkg/PlatformPei/AmdSev.c b/OvmfPkg/PlatformPei/AmdSev.c index 385562b44c..2a52d6f491 100644 --- a/OvmfPkg/PlatformPei/AmdSev.c +++ b/OvmfPkg/PlatformPei/AmdSev.c @@ -16,6 +16,7 @@ #include <Library/MemEncryptSevLib.h> #include <Library/MemoryAllocationLib.h> #include <Library/PcdLib.h> +#include <Pi/PrePiHob.h> #include <PiPei.h> #include <Register/Amd/Msr.h> #include <Register/Intel/SmramSaveStateMap.h> @@ -63,6 +64,10 @@ AmdSevSnpInitialize ( for (Hob.Raw = GetHobList (); !END_OF_HOB_LIST (Hob); Hob.Raw = GET_NEXT_HOB (Hob)) { if ((Hob.Raw != NULL) && (GET_HOB_TYPE (Hob) == EFI_HOB_TYPE_RESOURCE_DESCRIPTOR)) { ResourceHob = Hob.ResourceDescriptor; + if (ResourceHob->PhysicalStart >= SIZE_4GB) { + ResourceHob->ResourceType = EFI_RESOURCE_MEMORY_UNACCEPTED; + continue; + } if (ResourceHob->ResourceType == EFI_RESOURCE_SYSTEM_MEMORY) { MemEncryptSevSnpPreValidateSystemRam ( -- 2.38.0.rc1.362.ged0d419d3c-goog
|
|
|
|
[PATCH v6 6/7] OvmfPkg: Implement AcceptAllUnacceptedMemory in CocoDxe
Dionna Glaze
This protocol implementation disables the accept-all-memory behavior
of the ExitBootServicesCallback instance thise driver adds. Cc: Gerd Hoffmann <kraxel@...> Cc: James Bottomley <jejb@...> Cc: Jiewen Yao <jiewen.yao@...> Cc: Tom Lendacky <thomas.lendacky@...> Cc: Ard Biesheuvel <ardb@...> Cc: "Min M. Xu" <min.m.xu@...> Cc: Andrew Fish <afish@...> Cc: "Michael D. Kinney" <michael.d.kinney@...> Signed-off-by: Dionna Glaze <dionnaglaze@...> --- OvmfPkg/CocoDxe/CocoDxe.c | 25 ++++++++++++++++++++ OvmfPkg/CocoDxe/CocoDxe.inf | 1 + 2 files changed, 26 insertions(+) diff --git a/OvmfPkg/CocoDxe/CocoDxe.c b/OvmfPkg/CocoDxe/CocoDxe.c index 9e9a405af1..abf2d2b055 100644 --- a/OvmfPkg/CocoDxe/CocoDxe.c +++ b/OvmfPkg/CocoDxe/CocoDxe.c @@ -16,6 +16,7 @@ #include <Library/UefiBootServicesTableLib.h> #include <Library/MemEncryptSevLib.h> #include <Library/MemEncryptTdxLib.h> +#include <Protocol/Bz3987AcceptAllUnacceptedMemory.h> #include <Protocol/ExitBootServicesCallback.h> #include <Protocol/MemoryAccept.h> @@ -113,6 +114,21 @@ STATIC EDKII_EXIT_BOOT_SERVICES_CALLBACK_PROTOCOL mExitBootServicesCallbackProco FALSE, }; +STATIC +EFI_STATUS +EFIAPI +DisableAcceptAllUnacceptedMemory ( + IN BZ3987_ACCEPT_ALL_UNACCEPTED_MEMORY_PROTOCOL *This + ) +{ + mExitBootServicesCallbackProcotol.Disabled = TRUE; + return EFI_SUCCESS; +} + +STATIC +BZ3987_ACCEPT_ALL_UNACCEPTED_MEMORY_PROTOCOL +mAcceptAllUnacceptedMemoryProtocol = {DisableAcceptAllUnacceptedMemory}; + EFI_STATUS EFIAPI CocoDxeEntryPoint ( @@ -140,5 +156,14 @@ CocoDxeEntryPoint ( DEBUG ((DEBUG_ERROR, "Install EdkiiExitBootServicesCallbackProtocol failed.\n")); } + Status = gBS->InstallProtocolInterface (&mCocoDxeHandle, + &gBz3987AcceptAllUnacceptedMemoryProtocolGuid, + EFI_NATIVE_INTERFACE, + &mAcceptAllUnacceptedMemoryProtocol + ); + if (EFI_ERROR (Status)) { + DEBUG ((DEBUG_ERROR, "Install Bz3987AcceptAllUnacceptedMemoryProtocol failed.\n")); + } + return EFI_SUCCESS; } diff --git a/OvmfPkg/CocoDxe/CocoDxe.inf b/OvmfPkg/CocoDxe/CocoDxe.inf index 3ff2a6fade..96ab3e1c68 100644 --- a/OvmfPkg/CocoDxe/CocoDxe.inf +++ b/OvmfPkg/CocoDxe/CocoDxe.inf @@ -39,5 +39,6 @@ TRUE [Protocols] + gBz3987AcceptAllUnacceptedMemoryProtocolGuid gEdkiiExitBootServicesCallbackProtocolGuid gEfiMemoryAcceptProtocolGuid -- 2.38.0.rc1.362.ged0d419d3c-goog
|
|
|
|
[PATCH v6 5/7] MdePkg: Introduce the AcceptAllUnacceptedMemory protocol
Dionna Glaze
The default behavior for unaccepted memory is to accept all memory
when ExitBootServices is called. An OS loader can use this protocol to Disable this behavior to assume responsibility for memory acceptance and to affirm that the OS can handle the unaccepted memory type. This is a candidate for standardization. Cc: Gerd Hoffmann <kraxel@...> Cc: James Bottomley <jejb@...> Cc: Jiewen Yao <jiewen.yao@...> Cc: Tom Lendacky <thomas.lendacky@...> Cc: Ard Biesheuvel <ardb@...> Cc: "Min M. Xu" <min.m.xu@...> Cc: Andrew Fish <afish@...> Cc: "Michael D. Kinney" <michael.d.kinney@...> Signed-off-by: Dionna Glaze <dionnaglaze@...> --- MdePkg/Include/Protocol/Bz3987AcceptAllUnacceptedMemory.h | 40 ++++++++++++++++++++ MdePkg/MdePkg.dec | 3 ++ 2 files changed, 43 insertions(+) diff --git a/MdePkg/Include/Protocol/Bz3987AcceptAllUnacceptedMemory.h b/MdePkg/Include/Protocol/Bz3987AcceptAllUnacceptedMemory.h new file mode 100644 index 0000000000..e50831836c --- /dev/null +++ b/MdePkg/Include/Protocol/Bz3987AcceptAllUnacceptedMemory.h @@ -0,0 +1,40 @@ +/** @file + The file provides the protocol that disables the behavior that all memory + gets accepted at ExitBootServices(). This protocol is only meant to be called + by the OS loader, and not EDK2 itself. + + Copyright (c) 2022, Google LLC. All rights reserved.<BR> + SPDX-License-Identifier: BSD-2-Clause-Patent +**/ +#ifndef _ACCEPT_ALL_UNACCEPTED_MEMORY_H_ +#define _ACCEPT_ALL_UNACCEPTED_MEMORY_H_ + +#define BZ3987_ACCEPT_ALL_UNACCEPTED_MEMORY_PROTOCOL_GUID \ + {0xc5a010fe, \ + 0x38a7, \ + 0x4531, \ + {0x8a, 0x4a, 0x05, 0x00, 0xd2, 0xfd, 0x16, 0x49}} + +typedef struct _BZ3987_ACCEPT_ALL_UNACCEPTED_MEMORY_PROTOCOL + BZ3987_ACCEPT_ALL_UNACCEPTED_MEMORY_PROTOCOL; + +/** + @param This A pointer to a BZ3987_ACCEPT_ALL_UNACCEPTED_MEMORY_PROTOCOL. +**/ +typedef +EFI_STATUS +(EFIAPI *BZ3987_DISABLE_ACCEPT_ALL_UNACCEPTED_MEMORY)( + IN BZ3987_ACCEPT_ALL_UNACCEPTED_MEMORY_PROTOCOL *This + ); + +/// +/// The BZ3987_ACCEPT_ALL_UNACCEPTED_MEMORY_PROTOCOL allows the OS loader to +/// indicate to EDK2 that ExitBootServices should not accept all memory. +/// +struct _BZ3987_ACCEPT_ALL_UNACCEPTED_MEMORY_PROTOCOL { + BZ3987_DISABLE_ACCEPT_ALL_UNACCEPTED_MEMORY Disable; +}; + +extern EFI_GUID gBz3987AcceptAllUnacceptedMemoryProtocolGuid; + +#endif diff --git a/MdePkg/MdePkg.dec b/MdePkg/MdePkg.dec index de3c56758b..b6b108586e 100644 --- a/MdePkg/MdePkg.dec +++ b/MdePkg/MdePkg.dec @@ -1019,6 +1019,9 @@ gEfiPeiDelayedDispatchPpiGuid = { 0x869c711d, 0x649c, 0x44fe, { 0x8b, 0x9e, 0x2c, 0xbb, 0x29, 0x11, 0xc3, 0xe6 }} [Protocols] + ## Include/Protocol/Bz3987AcceptAllUnacceptedMemory.h + gBz3987AcceptAllUnacceptedMemoryProtocolGuid = { 0xc5a010fe, 0x38a7, 0x4531, {0x8a, 0x4a, 0x05, 0x00, 0xd2, 0xfd, 0x16, 0x49 }} + ## Include/Protocol/MemoryAccept.h gEfiMemoryAcceptProtocolGuid = { 0x38c74800, 0x5590, 0x4db4, { 0xa0, 0xf3, 0x67, 0x5d, 0x9b, 0x8e, 0x80, 0x26 }} -- 2.38.0.rc1.362.ged0d419d3c-goog
|
|
|
|
[PATCH v6 4/7] OvmfPkg: Introduce CocoDxe driver
Dionna Glaze
This driver is meant as a join point for all Confidential Compute
technologies to put shared behavior that doesn't belong anywhere else. The first behavior added here is to accept all unaccepted memory at ExitBootServices if the protocol is not disabled. This allows safe upgrades for OS loaders to affirm their support for the unaccepted memory type. Cc: Gerd Hoffmann <kraxel@...> Cc: James Bottomley <jejb@...> Cc: Jiewen Yao <jiewen.yao@...> Cc: Tom Lendacky <thomas.lendacky@...> Cc: Ard Biesheuvel <ardb@...> Cc: "Min M. Xu" <min.m.xu@...> Cc: Andrew Fish <afish@...> Cc: "Michael D. Kinney" <michael.d.kinney@...> Signed-off-by: Dionna Glaze <dionnaglaze@...> --- OvmfPkg/AmdSev/AmdSevX64.dsc | 1 + OvmfPkg/AmdSev/AmdSevX64.fdf | 1 + OvmfPkg/CocoDxe/CocoDxe.c | 144 ++++++++++++++++++++ OvmfPkg/CocoDxe/CocoDxe.inf | 43 ++++++ OvmfPkg/IntelTdx/IntelTdxX64.dsc | 1 + OvmfPkg/IntelTdx/IntelTdxX64.fdf | 1 + OvmfPkg/OvmfPkgIa32X64.dsc | 1 + OvmfPkg/OvmfPkgIa32X64.fdf | 1 + OvmfPkg/OvmfPkgX64.dsc | 1 + OvmfPkg/OvmfPkgX64.fdf | 1 + 10 files changed, 195 insertions(+) diff --git a/OvmfPkg/AmdSev/AmdSevX64.dsc b/OvmfPkg/AmdSev/AmdSevX64.dsc index 90e8a213ef..ad6b73ca4a 100644 --- a/OvmfPkg/AmdSev/AmdSevX64.dsc +++ b/OvmfPkg/AmdSev/AmdSevX64.dsc @@ -747,6 +747,7 @@ <LibraryClasses> PciLib|MdePkg/Library/BasePciLibCf8/BasePciLibCf8.inf } + OvmfPkg/CocoDxe/CocoDxe.inf OvmfPkg/IoMmuDxe/IoMmuDxe.inf # diff --git a/OvmfPkg/AmdSev/AmdSevX64.fdf b/OvmfPkg/AmdSev/AmdSevX64.fdf index 4658e1d30e..3717ec9094 100644 --- a/OvmfPkg/AmdSev/AmdSevX64.fdf +++ b/OvmfPkg/AmdSev/AmdSevX64.fdf @@ -302,6 +302,7 @@ INF OvmfPkg/QemuRamfbDxe/QemuRamfbDxe.inf INF OvmfPkg/VirtioGpuDxe/VirtioGpu.inf INF OvmfPkg/PlatformDxe/Platform.inf INF OvmfPkg/AmdSevDxe/AmdSevDxe.inf +INF OvmfPkg/CocoDxe/CocoDxe.inf INF OvmfPkg/IoMmuDxe/IoMmuDxe.inf diff --git a/OvmfPkg/CocoDxe/CocoDxe.c b/OvmfPkg/CocoDxe/CocoDxe.c new file mode 100644 index 0000000000..9e9a405af1 --- /dev/null +++ b/OvmfPkg/CocoDxe/CocoDxe.c @@ -0,0 +1,144 @@ +/** @file + + Confidential Compute Dxe driver. This driver installs protocols that are + generic over confidential compute techonology. + + Copyright (c) 2022, Google LLC. All rights reserved.<BR> + + SPDX-License-Identifier: BSD-2-Clause-Patent + +**/ + +#include <Library/BaseLib.h> +#include <Library/BaseMemoryLib.h> +#include <Library/DebugLib.h> +#include <Library/DxeServicesTableLib.h> +#include <Library/UefiBootServicesTableLib.h> +#include <Library/MemEncryptSevLib.h> +#include <Library/MemEncryptTdxLib.h> +#include <Protocol/ExitBootServicesCallback.h> +#include <Protocol/MemoryAccept.h> + +STATIC EFI_HANDLE mCocoDxeHandle = NULL; + +STATIC +EFI_STATUS +AcceptAllUnacceptedMemory ( + IN EFI_MEMORY_ACCEPT_PROTOCOL *AcceptMemory + ) +{ + EFI_GCD_MEMORY_SPACE_DESCRIPTOR *AllDescMap; + UINTN NumEntries; + UINTN Index; + EFI_STATUS Status; + BOOLEAN AcceptedAny; + + DEBUG ((DEBUG_INFO, "Accepting all memory\n")); + AcceptedAny = FALSE; + Status = EFI_SUCCESS; + /* + * Get a copy of the memory space map to iterate over while + * changing the map. + */ + Status = gDS->GetMemorySpaceMap (&NumEntries, &AllDescMap); + if (EFI_ERROR (Status)) { + return Status; + } + for (Index = 0; Index < NumEntries; Index++) { + CONST EFI_GCD_MEMORY_SPACE_DESCRIPTOR *Desc; + + Desc = &AllDescMap[Index]; + if (Desc->GcdMemoryType != EfiGcdMemoryTypeUnaccepted) { + continue; + } + + Status = AcceptMemory->AcceptMemory ( + AcceptMemory, + Desc->BaseAddress, + Desc->Length + ); + ASSERT_EFI_ERROR (Status); + + Status = gDS->RemoveMemorySpace(Desc->BaseAddress, Desc->Length); + ASSERT_EFI_ERROR (Status); + + Status = gDS->AddMemorySpace ( + EfiGcdMemoryTypeSystemMemory, + Desc->BaseAddress, + Desc->Length, + EFI_MEMORY_CPU_CRYPTO | EFI_MEMORY_XP | EFI_MEMORY_RO | EFI_MEMORY_RP + ); + ASSERT_EFI_ERROR (Status); + + AcceptedAny = TRUE; + } + + // If any memory is accepted, cause ExitBootServices to fail with + // EFI_INVALID_PARAMETER in order to force the caller to refresh + // their view of the MemoryMap. + if (AcceptedAny) { + Status = EFI_INVALID_PARAMETER; + } + +done: + gBS->FreePool (AllDescMap); + return Status; +} + +EFI_STATUS +EFIAPI +ResolveUnacceptedMemory ( + IN EDKII_EXIT_BOOT_SERVICES_CALLBACK_PROTOCOL *This + ) +{ + EFI_MEMORY_ACCEPT_PROTOCOL *AcceptMemory; + EFI_STATUS Status; + + if (This->Disabled) { + return EFI_SUCCESS; + } + + Status = gBS->LocateProtocol (&gEfiMemoryAcceptProtocolGuid, NULL, + (VOID **)&AcceptMemory); + if (Status == EFI_NOT_FOUND) { + return EFI_SUCCESS; + } + ASSERT_EFI_ERROR (Status); + + return AcceptAllUnacceptedMemory(AcceptMemory); +} + +STATIC EDKII_EXIT_BOOT_SERVICES_CALLBACK_PROTOCOL mExitBootServicesCallbackProcotol = { + ResolveUnacceptedMemory, + FALSE, +}; + +EFI_STATUS +EFIAPI +CocoDxeEntryPoint ( + IN EFI_HANDLE ImageHandle, + IN EFI_SYSTEM_TABLE *SystemTable + ) +{ + EFI_STATUS Status; + + // + // Do nothing when confidential compute technologies that require memory + // acceptance are not enabled. + // + if (!MemEncryptSevSnpIsEnabled () && + !MemEncryptTdxIsEnabled ()) { + return EFI_UNSUPPORTED; + } + + Status = gBS->InstallProtocolInterface (&mCocoDxeHandle, + &gEdkiiExitBootServicesCallbackProtocolGuid, + EFI_NATIVE_INTERFACE, + &mExitBootServicesCallbackProcotol + ); + if (EFI_ERROR (Status)) { + DEBUG ((DEBUG_ERROR, "Install EdkiiExitBootServicesCallbackProtocol failed.\n")); + } + + return EFI_SUCCESS; +} diff --git a/OvmfPkg/CocoDxe/CocoDxe.inf b/OvmfPkg/CocoDxe/CocoDxe.inf new file mode 100644 index 0000000000..3ff2a6fade --- /dev/null +++ b/OvmfPkg/CocoDxe/CocoDxe.inf @@ -0,0 +1,43 @@ +#/** @file +# +# Driver installs shared protocols needed for confidential compute +# technologies. +# +# Copyright (c) 2022, Google LLC. All rights reserved.<BR> +# +# SPDX-License-Identifier: BSD-2-Clause-Patent +# +#**/ + +[Defines] + INF_VERSION = 1.25 + BASE_NAME = CocoDxe + FILE_GUID = 08162f1e-5147-4d3e-b5a9-fa48c9808419 + MODULE_TYPE = DXE_DRIVER + VERSION_STRING = 1.0 + ENTRY_POINT = CocoDxeEntryPoint + +[Sources] + CocoDxe.c + +[Packages] + MdeModulePkg/MdeModulePkg.dec + MdePkg/MdePkg.dec + OvmfPkg/OvmfPkg.dec + +[LibraryClasses] + BaseLib + BaseMemoryLib + DebugLib + DxeServicesTableLib + MemEncryptSevLib + MemEncryptTdxLib + MemoryAllocationLib + UefiDriverEntryPoint + +[Depex] + TRUE + +[Protocols] + gEdkiiExitBootServicesCallbackProtocolGuid + gEfiMemoryAcceptProtocolGuid diff --git a/OvmfPkg/IntelTdx/IntelTdxX64.dsc b/OvmfPkg/IntelTdx/IntelTdxX64.dsc index c0c1a15b09..8136d50eb2 100644 --- a/OvmfPkg/IntelTdx/IntelTdxX64.dsc +++ b/OvmfPkg/IntelTdx/IntelTdxX64.dsc @@ -753,6 +753,7 @@ OvmfPkg/IoMmuDxe/IoMmuDxe.inf OvmfPkg/TdxDxe/TdxDxe.inf + OvmfPkg/CocoDxe/CocoDxe.inf # # Variable driver stack (non-SMM) diff --git a/OvmfPkg/IntelTdx/IntelTdxX64.fdf b/OvmfPkg/IntelTdx/IntelTdxX64.fdf index 6923eb8831..e612608c0c 100644 --- a/OvmfPkg/IntelTdx/IntelTdxX64.fdf +++ b/OvmfPkg/IntelTdx/IntelTdxX64.fdf @@ -269,6 +269,7 @@ INF ShellPkg/Application/Shell/Shell.inf INF MdeModulePkg/Logo/LogoDxe.inf INF OvmfPkg/TdxDxe/TdxDxe.inf +INF OvmfPkg/CocoDxe/CocoDxe.inf # # Usb Support diff --git a/OvmfPkg/OvmfPkgIa32X64.dsc b/OvmfPkg/OvmfPkgIa32X64.dsc index af566b953f..2cfb3fbc6b 100644 --- a/OvmfPkg/OvmfPkgIa32X64.dsc +++ b/OvmfPkg/OvmfPkgIa32X64.dsc @@ -965,6 +965,7 @@ <LibraryClasses> PciLib|MdePkg/Library/BasePciLibCf8/BasePciLibCf8.inf } + OvmfPkg/CocoDxe/CocoDxe.inf OvmfPkg/IoMmuDxe/IoMmuDxe.inf !if $(SMM_REQUIRE) == TRUE diff --git a/OvmfPkg/OvmfPkgIa32X64.fdf b/OvmfPkg/OvmfPkgIa32X64.fdf index 80de4fa2c0..2ab7f3b95b 100644 --- a/OvmfPkg/OvmfPkgIa32X64.fdf +++ b/OvmfPkg/OvmfPkgIa32X64.fdf @@ -343,6 +343,7 @@ INF OvmfPkg/QemuRamfbDxe/QemuRamfbDxe.inf INF OvmfPkg/VirtioGpuDxe/VirtioGpu.inf INF OvmfPkg/PlatformDxe/Platform.inf INF OvmfPkg/AmdSevDxe/AmdSevDxe.inf +INF OvmfPkg/CocoDxe/CocoDxe.inf INF OvmfPkg/IoMmuDxe/IoMmuDxe.inf !if $(SMM_REQUIRE) == TRUE diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc index f39d9cd117..3ead476b61 100644 --- a/OvmfPkg/OvmfPkgX64.dsc +++ b/OvmfPkg/OvmfPkgX64.dsc @@ -1036,6 +1036,7 @@ OvmfPkg/IoMmuDxe/IoMmuDxe.inf OvmfPkg/TdxDxe/TdxDxe.inf + OvmfPkg/CocoDxe/CocoDxe.inf !if $(SMM_REQUIRE) == TRUE OvmfPkg/SmmAccess/SmmAccess2Dxe.inf diff --git a/OvmfPkg/OvmfPkgX64.fdf b/OvmfPkg/OvmfPkgX64.fdf index c0f5a1ef3c..5dd452f42b 100644 --- a/OvmfPkg/OvmfPkgX64.fdf +++ b/OvmfPkg/OvmfPkgX64.fdf @@ -370,6 +370,7 @@ INF OvmfPkg/QemuRamfbDxe/QemuRamfbDxe.inf INF OvmfPkg/VirtioGpuDxe/VirtioGpu.inf INF OvmfPkg/PlatformDxe/Platform.inf INF OvmfPkg/AmdSevDxe/AmdSevDxe.inf +INF OvmfPkg/CocoDxe/CocoDxe.inf INF OvmfPkg/IoMmuDxe/IoMmuDxe.inf !if $(SMM_REQUIRE) == TRUE -- 2.38.0.rc1.362.ged0d419d3c-goog
|
|
|
|
[PATCH v6 3/7] MdeModulePkg: Invoke all ExitBootServicesCallback instances at ExitBootServices
Dionna Glaze
The protocol's intent is to allow drivers to install callbacks that can
modify the memory map at ExitBootServices time, so that any changes will lead to the EFI_INVALID_PARAMETER error. This error is specified to require the EBS caller to call GetMemoryMap again if it already had. Cc: Gerd Hoffmann <kraxel@...> Cc: James Bottomley <jejb@...> Cc: Jiewen Yao <jiewen.yao@...> Cc: Tom Lendacky <thomas.lendacky@...> Cc: Ard Biesheuvel <ardb@...> Cc: "Min M. Xu" <min.m.xu@...> Cc: Andrew Fish <afish@...> Cc: "Michael D. Kinney" <michael.d.kinney@...> Cc: Ray Ni <ray.ni@...> Signed-off-by: Dionna Glaze <dionnaglaze@...> --- MdeModulePkg/Core/Dxe/DxeMain.h | 1 + MdeModulePkg/Core/Dxe/DxeMain.inf | 1 + MdeModulePkg/Core/Dxe/DxeMain/DxeMain.c | 41 ++++++++++++++++++++ 3 files changed, 43 insertions(+) diff --git a/MdeModulePkg/Core/Dxe/DxeMain.h b/MdeModulePkg/Core/Dxe/DxeMain.h index 815a6b4bd8..185b9dc3d6 100644 --- a/MdeModulePkg/Core/Dxe/DxeMain.h +++ b/MdeModulePkg/Core/Dxe/DxeMain.h @@ -45,6 +45,7 @@ SPDX-License-Identifier: BSD-2-Clause-Patent #include <Protocol/HiiPackageList.h> #include <Protocol/SmmBase2.h> #include <Protocol/PeCoffImageEmulator.h> +#include <Protocol/ExitBootServicesCallback.h> #include <Guid/MemoryTypeInformation.h> #include <Guid/FirmwareFileSystem2.h> #include <Guid/FirmwareFileSystem3.h> diff --git a/MdeModulePkg/Core/Dxe/DxeMain.inf b/MdeModulePkg/Core/Dxe/DxeMain.inf index e4bca89577..bdd9cf8222 100644 --- a/MdeModulePkg/Core/Dxe/DxeMain.inf +++ b/MdeModulePkg/Core/Dxe/DxeMain.inf @@ -153,6 +153,7 @@ gEfiHiiPackageListProtocolGuid ## SOMETIMES_PRODUCES gEfiSmmBase2ProtocolGuid ## SOMETIMES_CONSUMES gEdkiiPeCoffImageEmulatorProtocolGuid ## SOMETIMES_CONSUMES + gEdkiiExitBootServicesCallbackProtocolGuid ## CONSUMES # Arch Protocols gEfiBdsArchProtocolGuid ## CONSUMES diff --git a/MdeModulePkg/Core/Dxe/DxeMain/DxeMain.c b/MdeModulePkg/Core/Dxe/DxeMain/DxeMain.c index 5733f0c8ec..3270f9858d 100644 --- a/MdeModulePkg/Core/Dxe/DxeMain/DxeMain.c +++ b/MdeModulePkg/Core/Dxe/DxeMain/DxeMain.c @@ -744,6 +744,34 @@ CalculateEfiHdrCrc ( Hdr->CRC32 = Crc; } +/** + Invokes TerminateMemoryMapPrehook from the first located instance of + EdkiiExitBootServicesProtocol. +**/ +STATIC +EFI_STATUS +InvokeTerminateMemoryMapPrehooks ( + VOID + ) +{ + EFI_STATUS Status; + EDKII_EXIT_BOOT_SERVICES_CALLBACK_PROTOCOL *Callback; + + Status = gBS->LocateHandle ( + &gEdkiiExitBootServicesCallbackProtocolGuid, + NULL, + (VOID**)Callback + ); + if (Status == EFI_NOT_FOUND) { + return EFI_SUCCESS; + } + if (EFI_ERROR (Status)) { + return Status; + } + + return Callback->TerminateMemoryMapPrehook(Callback); +} + /** Terminates all boot services. @@ -768,6 +796,19 @@ CoreExitBootServices ( // gTimer->SetTimerPeriod (gTimer, 0); + // + // Invoke all protocols installed for ExitBootServices prior to + // CoreTerminateMemoryMap. + // + Status = InvokeTerminateMemoryMapPrehooks(); + if (EFI_ERROR (Status)) { + // + // Notify other drivers that ExitBootServices failed + // + CoreNotifySignalList (&gEventExitBootServicesFailedGuid); + return Status; + } + // // Terminate memory services if the MapKey matches // -- 2.38.0.rc1.362.ged0d419d3c-goog
|
|
|
|
[PATCH v6 2/7] MdeModulePkg: Introduce ExitBootServicesCallbackProtocol
Dionna Glaze
This introduces a callback after the time that the timer is disabled and before
the MemoryMap is finalized. This callback is useful to make final changes to the memory map due to protocols initiated (or not initiated) by the OS loader. Cc: Gerd Hoffmann <kraxel@...> Cc: "Min M. Xu" <min.m.xu@...> Cc: James Bottomley <jejb@...> Cc: Jiewen Yao <jiewen.yao@...> Cc: Tom Lendacky <thomas.lendacky@...> Cc: Ard Biesheuvel <ardb@...> Cc: Andrew Fish <afish@...> Cc: "Michael D. Kinney" <michael.d.kinney@...> Signed-off-by: Dionna Glaze <dionnaglaze@...> --- MdeModulePkg/Include/Protocol/ExitBootServicesCallback.h | 40 ++++++++++++++++++++ MdeModulePkg/MdeModulePkg.dec | 3 ++ 2 files changed, 43 insertions(+) diff --git a/MdeModulePkg/Include/Protocol/ExitBootServicesCallback.h b/MdeModulePkg/Include/Protocol/ExitBootServicesCallback.h new file mode 100644 index 0000000000..5c9f973b79 --- /dev/null +++ b/MdeModulePkg/Include/Protocol/ExitBootServicesCallback.h @@ -0,0 +1,40 @@ +/** @file + The file provides the protocol that allows callbacks in ExitBootServices + immediately before TerminateMemoryMap. + + Copyright (c) 2022, Google LLC. All rights reserved.<BR> + SPDX-License-Identifier: BSD-2-Clause-Patent +**/ +#ifndef EXIT_BOOT_SERVICES_CALLBACK_H_ +#define EXIT_BOOT_SERVICES_CALLBACK_H_ + +/* This protocol is internal to EDK2 only */ + +#define EDKII_EXIT_BOOT_SERVICES_CALLBACK_PROTOCOL_GUID {0xf5684799, 0x9a33, 0x40f7, {0xa1, 0x5c, 0x10, 0x8e, 0x0e, 0x6b, 0x45, 0x25}} + +typedef struct _EDKII_EXIT_BOOT_SERVICES_CALLBACK_PROTOCOL + EDKII_EXIT_BOOT_SERVICES_CALLBACK_PROTOCOL; + +/** + @param This A pointer to a EDKII_EXIT_BOOT_SERVICES_CALLBACK_PROTOCOL. + + The returned status may only be EFI_SUCCESS or EFI_INVALID_PARAMETER. +**/ +typedef +EFI_STATUS +(EFIAPI *EDKII_TERMINATE_MEMORY_MAP_PREHOOK)( + IN EDKII_EXIT_BOOT_SERVICES_CALLBACK_PROTOCOL *This + ); + +/// +/// The EDKII_EXIT_BOOT_SERVICES_CALLBACK_PROTOCOL allows callbacks in +/// ExitBootServices immediately before TerminateMemoryMap. +/// +struct _EDKII_EXIT_BOOT_SERVICES_CALLBACK_PROTOCOL { + EDKII_TERMINATE_MEMORY_MAP_PREHOOK TerminateMemoryMapPrehook; + BOOLEAN Disabled; +}; + +extern EFI_GUID gEdkiiExitBootServicesCallbackProtocolGuid; + +#endif diff --git a/MdeModulePkg/MdeModulePkg.dec b/MdeModulePkg/MdeModulePkg.dec index 58e6ab0048..add4e304ca 100644 --- a/MdeModulePkg/MdeModulePkg.dec +++ b/MdeModulePkg/MdeModulePkg.dec @@ -677,6 +677,9 @@ ## Include/Protocol/VariablePolicy.h gEdkiiVariablePolicyProtocolGuid = { 0x81D1675C, 0x86F6, 0x48DF, { 0xBD, 0x95, 0x9A, 0x6E, 0x4F, 0x09, 0x25, 0xC3 } } + ## Include/Protocol/ExitBootServicesCallback.h + gEdkiiExitBootServicesCallbackProtocolGuid = { 0xf5684799, 0x9a33, 0x40f7, {0xa1, 0x5c, 0x10, 0x8e, 0x0e, 0x6b, 0x45, 0x25 }} + [PcdsFeatureFlag] ## Indicates if the platform can support update capsule across a system reset.<BR><BR> # TRUE - Supports update capsule across a system reset.<BR> -- 2.38.0.rc1.362.ged0d419d3c-goog
|
|
|
|
[PATCH v6 1/7] OvmfPkg: Realize EfiMemoryAcceptProtocol in AmdSevDxe
Dionna Glaze
From: Sophia Wolf <phiawolf@...>
When a guest OS does not support unaccepted memory, the unaccepted memory must be accepted before returning a memory map to the caller. EfiMemoryAcceptProtocol is defined in MdePkg and is implemented / Installed in AmdSevDxe for AMD SEV-SNP memory acceptance. Cc: Gerd Hoffmann <kraxel@...> Cc: James Bottomley <jejb@...> Cc: Jiewen Yao <jiewen.yao@...> Cc: Tom Lendacky <thomas.lendacky@...> Signed-off-by: Dionna Glaze <dionnaglaze@...> --- OvmfPkg/AmdSevDxe/AmdSevDxe.c | 55 ++++++++++++++++++-- OvmfPkg/AmdSevDxe/AmdSevDxe.inf | 3 ++ OvmfPkg/Library/BaseMemEncryptSevLib/X64/DxeSnpSystemRamValidate.c | 24 +++++++-- 3 files changed, 74 insertions(+), 8 deletions(-) diff --git a/OvmfPkg/AmdSevDxe/AmdSevDxe.c b/OvmfPkg/AmdSevDxe/AmdSevDxe.c index 662d3c4ccb..13fb58cc02 100644 --- a/OvmfPkg/AmdSevDxe/AmdSevDxe.c +++ b/OvmfPkg/AmdSevDxe/AmdSevDxe.c @@ -20,6 +20,7 @@ #include <Library/UefiBootServicesTableLib.h> #include <Guid/ConfidentialComputingSevSnpBlob.h> #include <Library/PcdLib.h> +#include <Protocol/MemoryAccept.h> STATIC CONFIDENTIAL_COMPUTING_SNP_BLOB_LOCATION mSnpBootDxeTable = { SIGNATURE_32 ('A', 'M', 'D', 'E'), @@ -31,6 +32,40 @@ STATIC CONFIDENTIAL_COMPUTING_SNP_BLOB_LOCATION mSnpBootDxeTable = { FixedPcdGet32 (PcdOvmfCpuidSize), }; +STATIC EFI_HANDLE mAmdSevDxeHandle = NULL; + +#define IS_ALIGNED(x, y) ((((x) & (y - 1)) == 0)) + +STATIC +EFI_STATUS +EFIAPI +AmdSevMemoryAccept ( + IN EFI_MEMORY_ACCEPT_PROTOCOL *This, + IN EFI_PHYSICAL_ADDRESS StartAddress, + IN UINTN Size +) +{ + // + // The StartAddress must be page-aligned, and the Size must be a positive + // multiple of SIZE_4KB. Use an assert instead of returning an erros since + // this is an EDK2-internal protocol. + // + ASSERT (IS_ALIGNED (StartAddress, SIZE_4KB)); + ASSERT (IS_ALIGNED (Size, SIZE_4KB)); + ASSERT (Size != 0); + + MemEncryptSevSnpPreValidateSystemRam ( + StartAddress, + EFI_SIZE_TO_PAGES (Size) + ); + + return EFI_SUCCESS; +} + +STATIC EFI_MEMORY_ACCEPT_PROTOCOL mMemoryAcceptProtocol = { + AmdSevMemoryAccept +}; + EFI_STATUS EFIAPI AmdSevDxeEntryPoint ( @@ -147,11 +182,23 @@ AmdSevDxeEntryPoint ( } } - // - // If its SEV-SNP active guest then install the CONFIDENTIAL_COMPUTING_SEV_SNP_BLOB. - // It contains the location for both the Secrets and CPUID page. - // if (MemEncryptSevSnpIsEnabled ()) { + // + // Memory acceptance began being required in SEV-SNP, so install the + // memory accept protocol implementation for a SEV-SNP active guest. + // + Status = gBS->InstallProtocolInterface ( + &mAmdSevDxeHandle, + &gEfiMemoryAcceptProtocolGuid, + EFI_NATIVE_INTERFACE, + &mMemoryAcceptProtocol + ); + ASSERT_EFI_ERROR (Status); + + // + // If its SEV-SNP active guest then install the CONFIDENTIAL_COMPUTING_SEV_SNP_BLOB. + // It contains the location for both the Secrets and CPUID page. + // return gBS->InstallConfigurationTable ( &gConfidentialComputingSevSnpBlobGuid, &mSnpBootDxeTable diff --git a/OvmfPkg/AmdSevDxe/AmdSevDxe.inf b/OvmfPkg/AmdSevDxe/AmdSevDxe.inf index 9acf860cf2..5ddddabc32 100644 --- a/OvmfPkg/AmdSevDxe/AmdSevDxe.inf +++ b/OvmfPkg/AmdSevDxe/AmdSevDxe.inf @@ -47,6 +47,9 @@ gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSnpSecretsBase gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSnpSecretsSize +[Protocols] + gEfiMemoryAcceptProtocolGuid + [Guids] gConfidentialComputingSevSnpBlobGuid diff --git a/OvmfPkg/Library/BaseMemEncryptSevLib/X64/DxeSnpSystemRamValidate.c b/OvmfPkg/Library/BaseMemEncryptSevLib/X64/DxeSnpSystemRamValidate.c index d3a95e4913..ee3710f7b3 100644 --- a/OvmfPkg/Library/BaseMemEncryptSevLib/X64/DxeSnpSystemRamValidate.c +++ b/OvmfPkg/Library/BaseMemEncryptSevLib/X64/DxeSnpSystemRamValidate.c @@ -14,6 +14,7 @@ #include <Library/MemEncryptSevLib.h> #include "SnpPageStateChange.h" +#include "VirtualMemory.h" /** Pre-validate the system RAM when SEV-SNP is enabled in the guest VM. @@ -29,12 +30,27 @@ MemEncryptSevSnpPreValidateSystemRam ( IN UINTN NumPages ) { + EFI_STATUS Status; + if (!MemEncryptSevSnpIsEnabled ()) { return; } - // - // All the pre-validation must be completed in the PEI phase. - // - ASSERT (FALSE); + // DXE pre-validation may happen with the memory accept protocol. + // The protocol should only be called outside the prevalidated ranges + // that the PEI stage code explicitly skips. Specifically, only memory + // ranges that are classified as unaccepted. + if (BaseAddress >= SIZE_4GB) { + Status = InternalMemEncryptSevCreateIdentityMap1G ( + 0, + BaseAddress, + EFI_PAGES_TO_SIZE (NumPages) + ); + if (EFI_ERROR (Status)) { + ASSERT (FALSE); + CpuDeadLoop (); + } + } + + InternalSetPageState (BaseAddress, NumPages, SevSnpPagePrivate, TRUE); } -- 2.38.0.rc1.362.ged0d419d3c-goog
|
|
|
|
[PATCH v6 0/7] Add safe unaccepted memory behavior
Dionna Glaze
These seven patches build on the lazy-accept patch series
"Introduce Lazy-accept for Tdx guest" by adding SEV-SNP support for the MemoryAccept protocol, and importantly making eager memory acceptance the default behavior. We add a new protocol, ExitBootServicesCallbackProtocol, with a single interface: TerminateMemoryMapPrehook(). We invoke all prehooks in CoreExitBootServices after disabling the timer and before TerminateMemoryMap. This gives hooks the chance to change the memory map and cause ExitBootServices to fail with EFI_INVALID_PARAMETER. The failure is specified to require the caller to update their view of the MemoryMap and call ExitBootServices again. To make use of this new protocol, we add a new driver that is meant to carry behavior that is needed for all confidential compute technologies, not just specific platforms, CocoDxe. In CocoDxe we implement the default safe behavior to accept all unaccepted memory and invalidate the MemoryMap on ExitBootServices. To allow the OS loader to prevent the eager acceptance, add another protocol, up for standardization, AcceptAllUnacceptedMemoryProtocol. This protocol has one interface, Disable(). The OS loader can inform the UEFI that it supports the unaccepted memory type and accepts the responsibility to accept it. All images that support unaccepted memory must now locate and call this new BZ3987_ACCEPT_ALL_UNACCEPTED_MEMORY_PROTOCOL and call the Disable function. Changes since v5: - Generic callback protocol moved to MdeModulePkg - Removed use of EFI_WARN_STALE_DATA and added comment that the callback should only return EFI_SUCCESS or EFI_INVALID_PARAMETER. - Removed errant log statement and fixed formatting. Changes since v4: - Commit message wording - Replaced direct change to DxeMain with a more generic callback protocol. - Implemented the direct change as an instance of the callback protocol from a new CocoDxe driver. - Replaced "enable" protocol with a "disable" protocol, since the name was confusing. The AcceptAllUnacceptedMemory protocol directly names the behavior that is disabling. Changes since v3: - "DxeMain accepts all memory" patch split into 3 to make each patch affect only one package at a time. Changes since v2: - Removed the redundant memory accept interface and added the accept behavior to the DXE implementation of MemEncryptSevSnpPreValidateSystemRam. - Fixed missing #include in >=4GB patch. Changes since v1: - Added a patch to classify SEV-SNP memory above 4GB unaccepted. - Fixed style problems in EfiMemoryAcceptProtocol implementation. Cc: Ard Biescheuvel <ardb@...> Cc: "Min M. Xu" <min.m.xu@...> Cc: Gerd Hoffmann <kraxel@...> Cc: James Bottomley <jejb@...> Cc: Tom Lendacky <Thomas.Lendacky@...> Cc: Jiewen Yao <jiewen.yao@...> Cc: Erdem Aktas <erdemaktas@...> Cc: Andrew Fish <afish@...> Cc: "Michael D. Kinney" <michael.d.kinney@...> Dionna Glaze (7): OvmfPkg: Realize EfiMemoryAcceptProtocol in AmdSevDxe MdeModulePkg: Introduce ExitBootServicesCallbackProtocol MdeModulePkg: Invoke all ExitBootServicesCallback instances at ExitBootServices OvmfPkg: Introduce CocoDxe driver MdePkg: Introduce the AcceptAllUnacceptedMemory protocol OvmfPkg: Implement AcceptAllUnacceptedMemory in CocoDxe OvmfPkg/PlatformPei: SEV-SNP make >=4GB unaccepted MdeModulePkg/Core/Dxe/DxeMain.h | 1 + MdeModulePkg/Core/Dxe/DxeMain.inf | 1 + MdeModulePkg/Core/Dxe/DxeMain/DxeMain.c | 41 +++++ MdeModulePkg/Include/Protocol/ExitBootServicesCallback.h | 40 +++++ MdeModulePkg/MdeModulePkg.dec | 3 + MdePkg/Include/Protocol/Bz3987AcceptAllUnacceptedMemory.h | 40 +++++ MdePkg/MdePkg.dec | 3 + OvmfPkg/AmdSev/AmdSevX64.dsc | 1 + OvmfPkg/AmdSev/AmdSevX64.fdf | 1 + OvmfPkg/AmdSevDxe/AmdSevDxe.c | 55 ++++++- OvmfPkg/AmdSevDxe/AmdSevDxe.inf | 3 + OvmfPkg/CocoDxe/CocoDxe.c | 169 ++++++++++++++++++++ OvmfPkg/CocoDxe/CocoDxe.inf | 44 +++++ OvmfPkg/IntelTdx/IntelTdxX64.dsc | 1 + OvmfPkg/IntelTdx/IntelTdxX64.fdf | 1 + OvmfPkg/Library/BaseMemEncryptSevLib/X64/DxeSnpSystemRamValidate.c | 24 ++- OvmfPkg/OvmfPkgIa32X64.dsc | 1 + OvmfPkg/OvmfPkgIa32X64.fdf | 1 + OvmfPkg/OvmfPkgX64.dsc | 1 + OvmfPkg/OvmfPkgX64.fdf | 1 + OvmfPkg/PlatformPei/AmdSev.c | 5 + 21 files changed, 429 insertions(+), 8 deletions(-) create mode 100644 MdeModulePkg/Include/Protocol/ExitBootServicesCallback.h create mode 100644 MdePkg/Include/Protocol/Bz3987AcceptAllUnacceptedMemory.h create mode 100644 OvmfPkg/CocoDxe/CocoDxe.c create mode 100644 OvmfPkg/CocoDxe/CocoDxe.inf -- 2.38.0.rc1.362.ged0d419d3c-goog
|
|
|
|
Re: [PATCH v2 3/6] IntelFsp2Pkg: Add CI YAML file
Michael Kubacki
+Other IntelFsp2Pkg & IntelFsp2WrapperPkg maintainers to To line
toggle quoted messageShow quoted text
Please review the remaining patches in this patch series: https://edk2.groups.io/g/devel/message/93859 Thanks, Michael
On 10/3/2022 10:44 AM, Michael Kubacki wrote:
Another reminder.
|
|
|
|
Re: Can NULL pointer be a valid event?
Michael D Kinney
Hi Ayush,
toggle quoted messageShow quoted text
Quick answer is that the UEFI Spec may not explicitly disallow NULLL, but in practice, it will never return NULL. =================================== EFI_EVENT is same as VOID*. typedef VOID *EFI_EVENT CreateEvent() returns a pointer to an Event, so it is really a double pointer. CreateEvent() returns EFI_INVALID_PARAMETER if Event (pointer to EFI_EVENT structure) is NULL. But CreateEvent/Ex() do not explicitly state that the pointer to the EFI_EVENT structure returned cannot be address 0. Internally to the EDK II, EFI_EVENT is a structure so it must be a valid pointer. Though I would point out that even this is an implementation choice. An implementation could treat the pointer to the EFI_EVENT as a handle number and could internally convert a handle number to a structure pointer to further hide details of the event structure and prevent the reuse of the same pointer value for different events across allocates/frees. The EDK II implementation choice to use pointers instead of handles is for the smallest/fastest implementation. It is possible to have a pointer to a structure at address 0. However, the EDK II implementations of the UEFI services do not allow the use of memory at 0 for normal memory allocations. I am aware of one use case of memory at 0 for an x86 IDT structure for 16-bit code. So it is not possible for the EDK II implementation of an UEFI service that returns pointers to structures to return a pointer value of 0. In fact, there are guard page features in EDK II that check if there is any access to the first page of memory in the address range 0x0..0xFFF. So the real restriction EDK II imposes is to never allocate a data structure in the first page of memory (0x0..0xFFF). Given it would be possible to implement many UEFI services using handle numbers instead of pointers. I would recommend those implementations do not use a handle value of 0. And instead start at a handle value of at least 1. Best regards, Mike
-----Original Message-----
|
|
|