[edk2-devel] [PATCH v1 0/1] Correct spelling error in SctPkg
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 Cc: Barton Gao Cc: Carolyn Gjertsen Cc: Samer El-Haj-Mahmoud Cc: Eric Jin Cc: Arvin Chen Cc: Supreeth Venkatesh Sam Kaynor (1): uefi-sct/SctPkg: Incorrect instances of RANDOM_NAME_PROTOCOL uefi-sct/SctPkg/TestCase/UEFI/EFI/Protocol/RandomNumber/BlackBoxTest/RandomNumberBBTestConformance.c | 4 ++-- uefi-sct/SctPkg/TestCase/UEFI/EFI/Protocol/RandomNumber/BlackBoxTest/RandomNumberBBTestFunction.c | 4 ++-- 2 files changed, 4 insertions(+), 4 deletions(-) -- 2.34.1 -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#94693): https://edk2.groups.io/g/devel/message/94693 Mute This Topic: https://groups.io/mt/94106840/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[edk2-devel] [PATCH v1 1/1] uefi-sct/SctPkg: Incorrect instances of RANDOM_NAME_PROTOCOL
Changed 4 incorrect instances of "RANDOM_NAME_PROTOCOL" in RandomNumberBBTestConformance and RandomNumberBBTestFunction to "RANDOM_NUMBER_PROTOCOL". Cc: G Edhaya Chandran Cc: Barton Gao Cc: Carolyn Gjertsen Cc: Samer El-Haj-Mahmoud Cc: Eric Jin Cc: Arvin Chen Cc: Supreeth Venkatesh Signed-off-by: Sam Kaynor --- uefi-sct/SctPkg/TestCase/UEFI/EFI/Protocol/RandomNumber/BlackBoxTest/RandomNumberBBTestConformance.c | 4 ++-- uefi-sct/SctPkg/TestCase/UEFI/EFI/Protocol/RandomNumber/BlackBoxTest/RandomNumberBBTestFunction.c | 4 ++-- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/uefi-sct/SctPkg/TestCase/UEFI/EFI/Protocol/RandomNumber/BlackBoxTest/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/BlackBoxTest/RandomNumberBBTestConformance.c +++ b/uefi-sct/SctPkg/TestCase/UEFI/EFI/Protocol/RandomNumber/BlackBoxTest/RandomNumberBBTestConformance.c @@ -160,7 +160,7 @@ BBTestGetInfoConformanceTestCheckpoint1 ( StandardLib, EFI_TEST_ASSERTION_WARNING, gConformanceTestAssertionGuid001, - L"RANDOM_NAME_PROTOCOL.GetInfo - GetInfo() is not supported or EFI_DEVICE_ERROR", + L"RANDOM_NUMBER_PROTOCOL.GetInfo - GetInfo() is not supported 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 EFI_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/BlackBoxTest/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/BlackBoxTest/RandomNumberBBTestFunction.c +++ b/uefi-sct/SctPkg/TestCase/UEFI/EFI/Protocol/RandomNumber/BlackBoxTest/RandomNumberBBTestFunction.c @@ -188,7 +188,7 @@ BBTestGetInfoFunctionTestCheckpoint1 ( StandardLib, EFI_TEST_ASSERTION_FAILED, gTestGenericFailureGuid, - L"RANDOM_NAME_PROTOCOL.GetInfo - GetInfo() is not supported or EFI_DEVICE_ERROR", + L"RANDOM_NUMBER_PROTOCOL.GetInfo - GetInfo() is not supported 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 not return the correct RNGAlgorithmListSize", L"%a:%d: Status - %r", __FILE__, (UINTN)__LINE__, -- 2.34.1 -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#94694): https://edk2.groups.io/g/devel/message/94694 Mute This Topic: https://groups.io/mt/94106841/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [PATCH v1 1/1] DynamicTablesPkg: Add SMBIOS String table helper library
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
The Section 6.1.3, SMBIOS specification version 3.6.0 describes the
handling of test strings in SMBIOS tables.
Test strings are added at the end of the formatted portion of the SMBIOS
structure and are referenced by index in the SMBIOS structure.
Therefore, introduce a SmbiosStringTableLib to simplify the publishing
of the string set.
SmbiosStringTableLib introduces a concept of string table which records
the references to the SMBIOS strings as they are added and returns an
string reference which is then assigned to the string field in the
formatted portion of the SMBIOS structure. Once all strings are added,
the library provides an interface to get the required size for the string
set. This allows sufficient memory to be allocated for the SMBIOS table.
The library also provides an interface to publish the string set in
accordance with the SMBIOS specification.
Example:
EFI_STATUS
BuildSmbiosType17Table () {
STRING_TABLE StrTable;
UINT8DevLocatorRef;
UINT8BankLocatorRef;
SMBIOS_TABLE_TYPE17 *SmbiosRecord;
CHAR8*StringSet;
...
// Initialize string table for 7 strings
StringTableInitialize (&StrTable, 7);
StringTableAddString (&StrTable, "SIMM 3", &DevLocatorRef);
StringTableAddString (&StrTable, "Bank 0", &BankLocatorRef);
...
SmbiosRecord = AllocateZeroPool (
sizeof (SMBIOS_TABLE_TYPE17) +
StringTableGetStringSetSize (&StrTable)
);
...
SmbiosRecord->DeviceLocator = DevLocatorRef;
SmbiosRecord->BankLocator = BankLocatorRef;
...
// get the string set area
StringSet = (CHAR8*)(SmbiosRecord + 1);
// publish the string set
StringTablePublishStringSet (
&StrTable,
StringSet,
StringTableGetStringSetSize (&StrTable)
);
// free string table
StringTableFree (&StrTable);
return EFI_SUCCESS;
}
Signed-off-by: Sami Mujawar
Cc: Alexei Fedorov
Cc: Pierre Gondois
Cc: Girish Mahadevan
Cc: Jeff Brasen
Cc: Ashish Singhal
Cc: Nick Ramirez
Cc: William Watson
Cc: Samer El-Haj-Mahmoud
---
The changes can be seen at:
https://github.com/samimujawar/edk2/tree/2370_smbios_stringlib_v1
DynamicTablesPkg/DynamicTables.dsc.inc
| 3 +-
DynamicTablesPkg/DynamicTablesPkg.dec
| 5 +-
DynamicTablesPkg/DynamicTablesPkg.dsc
| 3 +-
DynamicTablesPkg/Include/Library/SmbiosStringTableLib.h
| 119 ++
DynamicTablesPkg/Library/Common/SmbiosStringTableLib/SmbiosStringTableLib.c
| 227
DynamicTablesPkg/Library/Common/SmbiosStringTableLib/SmbiosStringTableLib.inf
| 25 +++
6 files changed, 379 insertions(+), 3 deletions(-)
diff --git a/DynamicTablesPkg/DynamicTables.dsc.inc
b/DynamicTablesPkg/DynamicTables.dsc.inc
index
3d4fa0c4c4b67d6770aee8705c80cc18d20c823a..d35acc1788f2ddc5e2b5fc3e4bedfd48251f7ec8
100644
--- a/DynamicTablesPkg/DynamicTables.dsc.inc
+++ b/DynamicTablesPkg/DynamicTables.dsc.inc
@@ -1,7 +1,7 @@
## @file
# Dsc include file for Dynamic Tables Framework.
#
-# Copyright (c) 2017 - 2021, Arm Limited. All rights reserved.
+# Copyright (c) 2017 - 2022, Arm Limited. All rights reserved.
#
# SPDX-License-Identifier: BSD-2-Clause-Patent
#
@@ -18,6 +18,7 @@ [LibraryClasses.common]
SsdtPcieSupportLib|DynamicTablesPkg/Library/Common/SsdtPcieSupportLib/SsdtPcieSupportLib.inf
SsdtSerialPortFixupLib|DynamicTablesPkg/Library/Common/SsdtSerialPortFixupLib/SsdtSerialPortFixupLib.inf
TableHelperLib|DynamicTablesPkg/Library/Common/TableHelperLib/TableHelperLib.inf
+
SmbiosStringTableLib|DynamicTablesPkg/Library/Common/SmbiosStringTableLib/SmbiosStringTableLib.inf
[Components.common]
#
diff --git a/DynamicTablesPkg/DynamicTablesPkg.dec
b/DynamicTablesPkg/DynamicTablesPkg.dec
index
cc34c2bdd6ff9b5ca508961b3d0fe85ffbb73c12..2a79cfd4edebbdff05bee66fa01a17d68252e8a7
100644
--- a/DynamicTablesPkg/DynamicTablesPkg.dec
+++ b/DynamicTablesPkg/DynamicTablesPkg.dec
@@ -1,7 +1,7 @@
## @file
# dec file for Dynamic Tables Framework.
#
-# Copyright (c) 2017 - 2021, Arm Limited. All rights reserved.
+# Copyright (c) 2017 - 2022, Arm Limited. All rights reserved.
#
# SPDX-License-Identifier: BSD-2-Clause-Patent
#
@@ -39,6 +39,9 @@ [LibraryClasses]
## @libraryclass Defines a set of helper methods.
TableHelperLib|Include/Library/TableHelperLib.h
+ ## @libraryclass Defines a set of SMBIOS string helper methods.
+ SmbiosStringTableLib|Include/Library/SmbiosStringTableLib.h
+
[Protocols]
# Configuration Manager Protocol GUID
gEdkiiConfigurationManage
[edk2-devel] [PATCH v3] remove GCC build warning
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
Cc: Liming Gao
Cc: Yuwei Chen
Signed-off-by: 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 @@
"$(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)
--
2.37.3.windows.1
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#94691): https://edk2.groups.io/g/devel/message/94691
Mute This Topic: https://groups.io/mt/94106021/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[edk2-devel] Now: Tools, CI, Code base construction meeting series - 10/03/2022 #cal-notice
*Tools, CI, Code base construction meeting series* *When:* 10/03/2022 4:30pm to 5:30pm (UTC-07:00) America/Los Angeles *Where:* https://github.com/tianocore/edk2/discussions/2614 View Event ( https://edk2.groups.io/g/devel/viewevent?eventid=1610030 ) *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. * tianocore/edk2: EDK II (github.com) * tianocore/edk2-basetools: EDK II BaseTools Python tools as a PIP module (github.com) https://github.com/tianocore/edk2-basetools * tianocore/edk2-pytool-extensions: Extensions to the edk2 build system allowing for a more robust and plugin based build system and tool execution environment (github.com) https://github.com/tianocore/edk2-pytool-extensions * tianocore/edk2-pytool-library: Python library package that supports UEFI development (github.com) https://github.com/tianocore/edk2-pytool-library MS Teams Browser Clients * https://docs.microsoft.com/en-us/microsoftteams/get-clients?tabs=Windows#browser-client -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#94690): https://edk2.groups.io/g/devel/message/94690 Mute This Topic: https://groups.io/mt/94103515/21656 Mute #cal-notice:https://edk2.groups.io/g/devel/mutehashtag/cal-notice Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[edk2-devel] Event: Tools, CI, Code base construction meeting series - 10/03/2022 #cal-reminder
*Reminder: Tools, CI, Code base construction meeting series* *When:* 10/03/2022 4:30pm to 5:30pm (UTC-07:00) America/Los Angeles *Where:* https://github.com/tianocore/edk2/discussions/2614 View Event ( https://edk2.groups.io/g/devel/viewevent?eventid=1610030 ) *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. * tianocore/edk2: EDK II (github.com) * tianocore/edk2-basetools: EDK II BaseTools Python tools as a PIP module (github.com) https://github.com/tianocore/edk2-basetools * tianocore/edk2-pytool-extensions: Extensions to the edk2 build system allowing for a more robust and plugin based build system and tool execution environment (github.com) https://github.com/tianocore/edk2-pytool-extensions * tianocore/edk2-pytool-library: Python library package that supports UEFI development (github.com) https://github.com/tianocore/edk2-pytool-library MS Teams Browser Clients * https://docs.microsoft.com/en-us/microsoftteams/get-clients?tabs=Windows#browser-client -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#94689): https://edk2.groups.io/g/devel/message/94689 Mute This Topic: https://groups.io/mt/94080747/21656 Mute #cal-reminder:https://edk2.groups.io/g/devel/mutehashtag/cal-reminder Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [edk2-platforms PATCH 0/2] Platform/RaspberryPi: SyncPcie() fixes
Hi, On 9/30/22 13:47, Adrien Thierry wrote: Hi Jeremy, If you just add the range tweak, does that fix the XHCI config in your setup too? I tested applying the range tweak in your patch, unfortunately it doesn't seem to work on my setup. I'm still getting "usb 1-1: device descriptor > read/64, error -71" errors. That is unfortunate. Which revision/how much RAM? Can you paste the before/after kernel/pci output like: ] brcm-pcie fd50.pcie: host bridge /scb/pcie@7d50 ranges: ] brcm-pcie fd50.pcie: No bus range found for /scb/pcie@7d50, using [bus 00-ff] ] brcm-pcie fd50.pcie: MEM 0x06..0x0603ff -> 0x00f800 ] brcm-pcie fd50.pcie: IB MEM 0x00..0x00bfff -> 0x00 ] brcm-pcie fd50.pcie: PCI host bridge to bus :00 ] pci_bus :00: root bus resource [bus 00-ff] ] pci_bus :00: root bus resource [mem 0x6-0x603ff] (bus address [0xf800-0xfbff]) 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] I'm running upstream linux 6.0-rc6 with the downstream device tree provided in [2] Thank you, Adrien [1] http://pastebin.test.redhat.com/1075875 [2] https://github.com/pftf/RPi4/releases/tag/v1.33 -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#94688): https://edk2.groups.io/g/devel/message/94688 Mute This Topic: https://groups.io/mt/94002759/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[edk2-devel] [PATCH v6 7/7] OvmfPkg/PlatformPei: SEV-SNP make >=4GB unaccepted
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
Cc: "Min M. Xu"
Cc: Gerd Hoffmann
Cc: James Bottomley
Cc: Tom Lendacky
Cc: Jiewen Yao
Cc: Erdem Aktas
Signed-off-by: Dionna Glaze
---
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
#include
#include
+#include
#include
#include
#include
@@ -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
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#94687): https://edk2.groups.io/g/devel/message/94687
Mute This Topic: https://groups.io/mt/94098177/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[edk2-devel] [PATCH v6 6/7] OvmfPkg: Implement AcceptAllUnacceptedMemory in CocoDxe
This protocol implementation disables the accept-all-memory behavior
of the ExitBootServicesCallback instance thise driver adds.
Cc: Gerd Hoffmann
Cc: James Bottomley
Cc: Jiewen Yao
Cc: Tom Lendacky
Cc: Ard Biesheuvel
Cc: "Min M. Xu"
Cc: Andrew Fish
Cc: "Michael D. Kinney"
Signed-off-by: Dionna Glaze
---
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
#include
#include
+#include
#include
#include
@@ -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
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#94686): https://edk2.groups.io/g/devel/message/94686
Mute This Topic: https://groups.io/mt/94098176/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[edk2-devel] [PATCH v6 5/7] MdePkg: Introduce the AcceptAllUnacceptedMemory protocol
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
Cc: James Bottomley
Cc: Jiewen Yao
Cc: Tom Lendacky
Cc: Ard Biesheuvel
Cc: "Min M. Xu"
Cc: Andrew Fish
Cc: "Michael D. Kinney"
Signed-off-by: Dionna Glaze
---
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 00..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.
+ 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
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#94685): https://edk2.groups.io/g/devel/message/94685
Mute This Topic: https://groups.io/mt/94098173/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[edk2-devel] [PATCH v6 4/7] OvmfPkg: Introduce CocoDxe driver
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
Cc: James Bottomley
Cc: Jiewen Yao
Cc: Tom Lendacky
Cc: Ard Biesheuvel
Cc: "Min M. Xu"
Cc: Andrew Fish
Cc: "Michael D. Kinney"
Signed-off-by: Dionna Glaze
---
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 @@
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 00..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.
+
+ SPDX-License-Identifier: BSD-2-Clause-Patent
+
+**/
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+STATIC EFI_HANDLE mCocoDxeHandle = NULL;
+
+STATIC
+EFI_STATUS
+AcceptAllUnacceptedMemory (
+ IN EFI_MEMORY_ACCEPT_PROTOCOL *AcceptMemory
+ )
+{
+ EFI_GCD_MEMORY_SPACE_DESCRIPTOR *AllDescMap;
+ UINTNNumEntries;
+ UINTNIndex;
+ 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_HANDLEImageHandle,
+ IN EFI_SYSTEM_TABLE *SystemTable
+ )
+{
+ EFI_STATUS Status;
+
+ //
+ // Do nothing when confidential compute technologies that require memory
+ // acceptance are not enabled.
+ //
+
[edk2-devel] [PATCH v6 3/7] MdeModulePkg: Invoke all ExitBootServicesCallback instances at ExitBootServices
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
Cc: James Bottomley
Cc: Jiewen Yao
Cc: Tom Lendacky
Cc: Ard Biesheuvel
Cc: "Min M. Xu"
Cc: Andrew Fish
Cc: "Michael D. Kinney"
Cc: Ray Ni
Signed-off-by: Dionna Glaze
---
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
#include
#include
+#include
#include
#include
#include
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
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#94683): https://edk2.groups.io/g/devel/message/94683
Mute This Topic: https://groups.io/mt/94098170/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[edk2-devel] [PATCH v6 2/7] MdeModulePkg: Introduce ExitBootServicesCallbackProtocol
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
Cc: "Min M. Xu"
Cc: James Bottomley
Cc: Jiewen Yao
Cc: Tom Lendacky
Cc: Ard Biesheuvel
Cc: Andrew Fish
Cc: "Michael D. Kinney"
Signed-off-by: Dionna Glaze
---
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 00..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.
+ 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.
# TRUE - Supports update capsule across a system reset.
--
2.38.0.rc1.362.ged0d419d3c-goog
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#94682): https://edk2.groups.io/g/devel/message/94682
Mute This Topic: https://groups.io/mt/94098169/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[edk2-devel] [PATCH v6 0/7] Add safe unaccepted memory behavior
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 Cc: "Min M. Xu" Cc: Gerd Hoffmann Cc: James Bottomley Cc: Tom Lendacky Cc: Jiewen Yao Cc: Erdem Aktas Cc: Andrew Fish Cc: "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
[edk2-devel] [PATCH v6 1/7] OvmfPkg: Realize EfiMemoryAcceptProtocol in AmdSevDxe
From: Sophia Wolf
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
Cc: James Bottomley
Cc: Jiewen Yao
Cc: Tom Lendacky
Signed-off-by: Dionna Glaze
---
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
#include
#include
+#include
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..5abc32 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
#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
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links:
Re: [edk2-devel] [PATCH v2 3/6] IntelFsp2Pkg: Add CI YAML file
+Other IntelFsp2Pkg & IntelFsp2WrapperPkg maintainers to To line
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.
On 9/22/2022 9:07 PM, Michael Kubacki wrote:
Review reminder
On 9/15/2022 3:41 PM, Michael Kubacki wrote:
Hi Chasel,
Your CI YAML file feedback in v1 is addressed now in v2.
Can you please provide your review on this patch and [PATCH v2 5/6]?
Note that I updated the commit message for this patch to remove the
info about the build being broken since that was recently fixed. That
update is in the branch:
https://github.com/makubacki/edk2/commit/c37e6dfa482ed075cd4ab6712e6d17b3cf17786a
With these reviews, the series will be covered.
Thanks,
Michael
On 9/15/2022 2:55 PM, Michael Kubacki wrote:
From: Michael Kubacki
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=4048
Adds IntelFsp2Pkg to the list of supported build packages for edk2
CI and defines an initial set of CI configuration options.
The compiler plugin is disabled as the package currently does not
build due to some changes in the FSP 2.4 interface addition.
Specifically, in commit df25a54 "Fsp24SecCore.inf" files were
added to IntelFspPkg.dsc but the actual files were not added.
Simply removing these files from the DSC exposes a linker failure.
Recommendation:
1. Enable package CI (accept this change)
2. Add IntelFsp2Pkg.dsc to the "CompilerPlugin" "DscPath" in
IntelFsp2Pkg/IntelFsp2Pkg.ci.yaml to enable compilation
3. Verify compilation and all currently enabled package CI checks
pass
4. Check-in fixes in (3) with change in (2)
Cc: Chasel Chiu
Cc: Nate DeSimone
Cc: Star Zeng
Signed-off-by: Michael Kubacki
---
.pytool/CISettings.py | 1 +
IntelFsp2Pkg/IntelFsp2Pkg.ci.yaml | 90
2 files changed, 91 insertions(+)
diff --git a/.pytool/CISettings.py b/.pytool/CISettings.py
index cf9e0d77b19b..0205c26a58f8 100644
--- a/.pytool/CISettings.py
+++ b/.pytool/CISettings.py
@@ -54,6 +54,7 @@ class Settings(CiBuildSettingsManager,
UpdateSettingsManager, SetupSettingsManag
"ArmVirtPkg",
"DynamicTablesPkg",
"EmulatorPkg",
+ "IntelFsp2Pkg",
"MdePkg",
"MdeModulePkg",
"NetworkPkg",
diff --git a/IntelFsp2Pkg/IntelFsp2Pkg.ci.yaml
b/IntelFsp2Pkg/IntelFsp2Pkg.ci.yaml
new file mode 100644
index ..9ce401b20164
--- /dev/null
+++ b/IntelFsp2Pkg/IntelFsp2Pkg.ci.yaml
@@ -0,0 +1,90 @@
+## @file
+# Core CI configuration for IntelFsp2Pkg
+#
+# Copyright (c) Microsoft Corporation
+#
+# SPDX-License-Identifier: BSD-2-Clause-Patent
+##
+{
+ ## options defined .pytool/Plugin/LicenseCheck
+ "LicenseCheck": {
+ "IgnoreFiles": []
+ },
+
+ "EccCheck": {
+ ## Exception sample looks like below:
+ ## "ExceptionList": [
+ ## "", ""
+ ## ]
+ "ExceptionList": [
+ ],
+ ## Both file path and directory path are accepted.
+ "IgnoreFiles": []
+ },
+
+ ## options defined .pytool/Plugin/CompilerPlugin
+ "CompilerPlugin": {
+ "DscPath": "IntelFsp2Pkg.dsc"
+ },
+
+ ## options defined .pytool/Plugin/HostUnitTestCompilerPlugin
+ "HostUnitTestCompilerPlugin": {
+ "DscPath": "" # Don't support this test
+ },
+
+ ## options defined .pytool/Plugin/CharEncodingCheck
+ "CharEncodingCheck": {
+ "IgnoreFiles": []
+ },
+
+ ## options defined .pytool/Plugin/DependencyCheck
+ "DependencyCheck": {
+ "AcceptableDependencies": [
+ "IntelFsp2Pkg/IntelFsp2Pkg.dec",
+ "MdeModulePkg/MdeModulePkg.dec",
+ "MdePkg/MdePkg.dec",
+ "UefiCpuPkg/UefiCpuPkg.dec"
+ ],
+ # For host based unit tests
+ "AcceptableDependencies-HOST_APPLICATION":[
+ "UnitTestFrameworkPkg/UnitTestFrameworkPkg.dec"
+ ],
+ # For UEFI shell based apps
+ "AcceptableDependencies-UEFI_APPLICATION":[],
+ "IgnoreInf": []
+ },
+
+ ## options defined .pytool/Plugin/DscCompleteCheck
+ "DscCompleteCheck": {
+ "IgnoreInf": [""],
+ "DscPath": "IntelFsp2Pkg.dsc"
+ },
+
+ ## options defined .pytool/Plugin/HostUnitTestDscCompleteCheck
+ "HostUnitTestDscCompleteCheck": {
+ "IgnoreInf": [""],
+ "DscPath": "" # Don't support this test
+ },
+
+ ## options defined .pytool/Plugin/GuidCheck
+ "GuidCheck": {
+ "IgnoreGuidName": [],
+ "IgnoreGuidValue": [],
+ "IgnoreFoldersAndFiles": [],
+ "IgnoreDuplicates": [],
+ },
+
+ ## options defined .pytool/Plugin/LibraryClassCheck
+ "LibraryClassCheck": {
+ "IgnoreHeaderFile": []
+ },
+
+ ## options defined .pytool/Plugin/SpellCheck
+ "SpellCheck": {
+ "AuditOnly": True, # Fails right now with over
270 errors
+
Re: [edk2-devel] Can NULL pointer be a valid event?
Hi Ayush, 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- > From: devel@edk2.groups.io On Behalf Of Dionna Glaze > via groups.io > Sent: Monday, October 3, 2022 10:16 AM > To: devel@edk2.groups.io; ayushdevel1...@gmail.com > Subject: Re: [edk2-devel] Can NULL pointer be a valid event? > > CreateEvent returns an EFI_STATUS. It expects the OUT parameter, a > pointer to an EFI_EVENT, to be non-NULL. A null pointer results in > EFI_INVALID_PARAMETER. If the CreateEvent is successful, then `event` > points to the newly created event. It's the caller's responsibility to > pass a pointer to valid writable memory. > > On Mon, Oct 3, 2022 at 8:08 AM Ayush Singh wrote: > > > > Hello everyone, > > > > I wanted to ask if a NULL pointer can be returned as a valid event from > > `EFI_BOOT_SERVICES.CreateEvent()` or > `EFI_BOOT_SERVICES.CreateEventEx()`? Or does the specification state that a > valid event pointer has to be non-NULL? > > > > Yours Sincerely, > > Ayush Singh > > > > > > -- > -Dionna Glaze, PhD (she/her) > > > > -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#94678): https://edk2.groups.io/g/devel/message/94678 Mute This Topic: https://groups.io/mt/94092613/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [PATCH v5 2/7] MdePkg: Introduce ExitBootServicesCallbackProtocol
> > What Ray is getting to (I think) is that that means that it should be > defined in MdeModulePkg not MdePkg. Oh, MemoryAcceptProtocol is also not specified AFAICT, so I thought this is where it would go. I can move it. -- -Dionna Glaze, PhD (she/her) -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#94677): https://edk2.groups.io/g/devel/message/94677 Mute This Topic: https://groups.io/mt/94028459/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] Can NULL pointer be a valid event?
CreateEvent returns an EFI_STATUS. It expects the OUT parameter, a pointer to an EFI_EVENT, to be non-NULL. A null pointer results in EFI_INVALID_PARAMETER. If the CreateEvent is successful, then `event` points to the newly created event. It's the caller's responsibility to pass a pointer to valid writable memory. On Mon, Oct 3, 2022 at 8:08 AM Ayush Singh wrote: > > Hello everyone, > > I wanted to ask if a NULL pointer can be returned as a valid event from > `EFI_BOOT_SERVICES.CreateEvent()` or `EFI_BOOT_SERVICES.CreateEventEx()`? Or > does the specification state that a valid event pointer has to be non-NULL? > > Yours Sincerely, > Ayush Singh > -- -Dionna Glaze, PhD (she/her) -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#94676): https://edk2.groups.io/g/devel/message/94676 Mute This Topic: https://groups.io/mt/94092613/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] The principles of EDK2 module reconstruction for archs
Hi Abner, responses below. Mike > -Original Message- > From: devel@edk2.groups.io On Behalf Of Chang, Abner > via groups.io > Sent: Sunday, October 2, 2022 10:37 PM > To: Kinney, Michael D ; devel@edk2.groups.io; > quic_llind...@quicinc.com; Ni, Ray ; > Attar, AbdulLateef (Abdul Lateef) ; Sunil V L > > Cc: lichao ; Kirkendall, Garrett > ; Grimes, Paul ; He, > Jiangang ; Andrew Fish > Subject: Re: [edk2-devel] The principles of EDK2 module reconstruction for > archs > > [AMD Official Use Only - General] > > Mike, > Agree. This can be mentioned on the Wiki page. Also, this would require the > discussion between maintainer and contributor. I would > say maintainer has the responsibility to make sure an arch folder is only > created when necessary. Agreed > > Do you agree with the arch concatenate solution for arch folder? That means > IA32_X64 instead of X86 (I am fine with this)? Yes > However, there is one scenario. Assume there were two arch folders IA32_X64 > and RISCV64. Then ARM shares the code with IA32_X64, > we may rename IA32_X64 to IA32_X64_ARM. > Although the directory naming is not real a problem to the build, a separate > ARM folder seems easier? Or we can just allow this > kind of folder naming structure, however we let maintainer to make the > decision? I would let the maintainer make the decision. For your example, another approach may be to move the IA32_X64 content up a level so it is common and is used by IA32, X64, ARM. And leave RISCV64 folder for an arch that has special requirements. I think having some flexibility in the guidelines is very beneficial. The main goal is for consistency when a specific guideline is followed. > > Abner > > > > -Original Message- > > From: Kinney, Michael D > > Sent: Monday, October 3, 2022 1:18 PM > > To: Chang, Abner ; devel@edk2.groups.io; > > quic_llind...@quicinc.com; Ni, Ray ; Attar, AbdulLateef > > (Abdul Lateef) ; Sunil V L > > ; Kinney, Michael D > > > > Cc: lichao ; Kirkendall, Garrett > > ; Grimes, Paul ; He, > > Jiangang ; Andrew Fish > > Subject: RE: [edk2-devel] The principles of EDK2 module reconstruction for > > archs > > > > Caution: This message originated from an External Source. Use proper > > caution when opening attachments, clicking links, or responding. > > > > > > Abner, > > > > I think another guideline is to minimize the number of subdirectories. > > > > Only create them if it helps with the organization and long term maintenance > > of the component. > > > > Mike > > > > > > > -Original Message- > > > From: Chang, Abner > > > Sent: Sunday, October 2, 2022 8:13 PM > > > To: Kinney, Michael D ; > > > devel@edk2.groups.io; quic_llind...@quicinc.com; Ni, Ray > > > ; Attar, AbdulLateef (Abdul Lateef) > > > ; Sunil V L > > > Cc: lichao ; Kirkendall, Garrett > > > ; Grimes, Paul ; > > He, > > > Jiangang ; Andrew Fish > > > Subject: RE: [edk2-devel] The principles of EDK2 module reconstruction > > > for archs > > > > > > [AMD Official Use Only - General] > > > > > > Hi Mike and Leif, > > > First of all, we don't use arch folder if the module is mainly for a > > > specific arch in obviously. So we will have both common and arch-specific > > files constructed under module/library root. > > > > > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fedk > > 2 > > > .groups.io%2Fg%2Fdevel%2Fmessage%2F94567&data=05%7C01%7CA > > bner.Chan > > > > > g%40amd.com%7Cd49cbbe6d3d942bd69a308daa4fea41b%7C3dd8961fe4884 > > e608e11a > > > > > 82d994e183d%7C0%7C0%7C638003710850252776%7CUnknown%7CTWFpbGZ > > sb3d8eyJWI > > > > > joiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3 > > 000%7 > > > > > C%7C%7C&sdata=eiLOC0G9WZWKqm2ALcAiKr7SPBP5AgDdAxogHlv5pI > > M%3D&r > > > eserved=0 > > > SmmCpuFeatureLib\Ia32 > > > SmmCpuFeatureLib\X64 > > > SmmCpuFeatureLib\SmmCpuFeatureLib.c > > > SmmCpuFeatureLib\SmmCpuFeatureLibCommon.c > > > SmmCpuFeatureLib\IntelSmmCPuFeaturesLib > > > SmmCpuFeatureLib\AmdlSmmCPuFeaturesLib > > > > > > > > > > > Could we concatenate architectures? > > > > > I.e. AARCH64_ARM, IA32_X64, AARCH64_RISCV64... ? > > > Looks like below? > > > > > > CpuDxe\IA32_X64\IA32\abc.nasm > > > CpuDxe\IA32_X64\X64\abc.nasm > > > CpuDxe\IA32_X64\CpuDxe.c > > > CpuDxe\IA32_X64\AmdCpuDxe.c > > > CpuDxe\IA32_X64\IntelCpuDxe.c > > > CpuDxe\RiscV64\CpuDxe.c > > > CpuDxe\ARM\CpuDxe.c > > > CpuDxe\ > > >CpuDxeCommon.c // If required. > > > CpuDxe.inf // Use INF section arch modifier > > > for X86, RISC-V > > and ARM. > > > CpuDxeAmd.inf// Separate INF for AMD. > > > > > > Seems ok, but is AARCH64_RISCV64 a real case? Or it means we can > > > create a folder "AARCH64_RISCV64" when there are some common files > > shared by AARCH64 and RISCV64? > > > > > > For the 32/64 bit support, it can still stay under module root and > > > don't need to assign a folder for them unless the arch has the differen
[edk2-devel] Can NULL pointer be a valid event?
Hello everyone, I wanted to ask if a NULL pointer can be returned as a valid event from `EFI_BOOT_SERVICES.CreateEvent()` or `EFI_BOOT_SERVICES.CreateEventEx()`? Or does the specification state that a valid event pointer has to be non-NULL? Yours Sincerely, Ayush Singh -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#94674): https://edk2.groups.io/g/devel/message/94674 Mute This Topic: https://groups.io/mt/94092613/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [PATCH v5 1/7] OvmfPkg: Realize EfiMemoryAcceptProtocol in AmdSevDxe
On 9/30/22 18:06, Dionna Glaze wrote:
From: Sophia Wolf
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
Cc: James Bottomley
Cc: Jiewen Yao
Cc: Tom Lendacky
Signed-off-by: Dionna Glaze
Just some formatting suggestions and one area of cleanup from previous
version of the patch below. Assuming you take care of those:
Reviewed-by: Tom Lendacky
---
OvmfPkg/AmdSevDxe/AmdSevDxe.c | 57
++--
OvmfPkg/AmdSevDxe/AmdSevDxe.inf| 3 ++
OvmfPkg/Library/BaseMemEncryptSevLib/X64/DxeSnpSystemRamValidate.c | 24
+++--
3 files changed, 76 insertions(+), 8 deletions(-)
diff --git a/OvmfPkg/AmdSevDxe/AmdSevDxe.c b/OvmfPkg/AmdSevDxe/AmdSevDxe.c
index 662d3c4ccb..77d3caa833 100644
--- a/OvmfPkg/AmdSevDxe/AmdSevDxe.c
+++ b/OvmfPkg/AmdSevDxe/AmdSevDxe.c
@@ -20,6 +20,7 @@
#include
#include
#include
+#include
STATIC CONFIDENTIAL_COMPUTING_SNP_BLOB_LOCATION mSnpBootDxeTable = {
SIGNATURE_32 ('A','M', 'D', 'E'),
@@ -31,6 +32,38 @@ STATIC CONFIDENTIAL_COMPUTING_SNP_BLOB_LOCATION
mSnpBootDxeTable = {
FixedPcdGet32 (PcdOvmfCpuidSize),
};
+STATIC EFI_HANDLE mAmdSevDxeHandle = NULL;
+
+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 (((StartAddress & ~(SIZE_4KB - 1)) == 0) &&
+ ((Size & ~(SIZE_4KB - 1)) == 0) &&
+ (Size != 0));
Create a generic alignment check macro?
#define IS_ALIGNED(x, y) (((x) & ((y) - 1)) == 0)
Maybe keep the ASSERTs separate so they better identify which condition
caused the assert, e.g.:
ASSERT (IS_ALIGNED (StartAddress, SIZE_4KB));
ASSERT (IS_ALIGNED (Size, SIZE_4KB));
ASSERT (Size != 0);
?
Not sure if those are worth it or not, though.
+
+ MemEncryptSevSnpPreValidateSystemRam (
+StartAddress,
+EFI_SIZE_TO_PAGES (Size)
+);
+
+ return EFI_SUCCESS;
+}
+
+STATIC EFI_MEMORY_ACCEPT_PROTOCOL mMemoryAcceptProtocol = {
+ AmdSevMemoryAccept
+};
+
EFI_STATUS
EFIAPI
AmdSevDxeEntryPoint (
@@ -147,11 +180,27 @@ 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 (EFI_ERROR (Status)) {
+DEBUG ((DEBUG_ERROR, "Install EfiMemoryAcceptProtocol failed.\n"));
+ }
Looks like this shouldn't be here.
+
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
+ );
Need to indent these two more spaces to align with the "s" in Install.
Thanks,
Tom
+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..5abc32 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
#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;
}
- //
- // Al
Re: [edk2-devel] [PATCH v1 1/2] SignedCapsulePkg: Add package CI YAML file
Another reminder.
On 9/22/2022 9:06 PM, Michael Kubacki wrote:
Review reminder
On 9/15/2022 3:36 PM, Michael Kubacki wrote:
Hi Jian,
Can you please provide a review for this patch?
Mike Kinney has already given an R-b for [PATCH v1 2/2] so the series
will be ready once this patch is reviewed.
Thanks,
Michael
On 9/7/2022 1:05 AM, Michael Kubacki wrote:
From: Michael Kubacki
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=4050
Adds the package as a supported package to .pytool/CISettings.py
and adds a CI YAML for the package so it can be run in CI.
Cc: Jian J Wang
Signed-off-by: Michael Kubacki
---
.pytool/CISettings.py | 1 +
SignedCapsulePkg/SignedCapsulePkg.ci.yaml | 90
2 files changed, 91 insertions(+)
diff --git a/.pytool/CISettings.py b/.pytool/CISettings.py
index cf9e0d77b19b..306e27893e58 100644
--- a/.pytool/CISettings.py
+++ b/.pytool/CISettings.py
@@ -62,6 +62,7 @@ class Settings(CiBuildSettingsManager,
UpdateSettingsManager, SetupSettingsManag
"UefiCpuPkg",
"FmpDevicePkg",
"ShellPkg",
+ "SignedCapsulePkg",
"StandaloneMmPkg",
"FatPkg",
"CryptoPkg",
diff --git a/SignedCapsulePkg/SignedCapsulePkg.ci.yaml
b/SignedCapsulePkg/SignedCapsulePkg.ci.yaml
new file mode 100644
index ..5f48613bd79f
--- /dev/null
+++ b/SignedCapsulePkg/SignedCapsulePkg.ci.yaml
@@ -0,0 +1,90 @@
+## @file
+# Core CI configuration for SignedCapsulePkg
+#
+# Copyright (c) Microsoft Corporation
+#
+# SPDX-License-Identifier: BSD-2-Clause-Patent
+##
+{
+ ## options defined .pytool/Plugin/LicenseCheck
+ "LicenseCheck": {
+ "IgnoreFiles": []
+ },
+
+ "EccCheck": {
+ ## Exception sample looks like below:
+ ## "ExceptionList": [
+ ## "", ""
+ ## ]
+ "ExceptionList": [
+ ],
+ ## Both file path and directory path are accepted.
+ "IgnoreFiles": []
+ },
+
+ ## options defined .pytool/Plugin/CompilerPlugin
+ "CompilerPlugin": {
+ "DscPath": "SignedCapsulePkg.dsc"
+ },
+
+ ## options defined .pytool/Plugin/HostUnitTestCompilerPlugin
+ "HostUnitTestCompilerPlugin": {
+ "DscPath": "" # Don't support this test
+ },
+
+ ## options defined .pytool/Plugin/CharEncodingCheck
+ "CharEncodingCheck": {
+ "IgnoreFiles": []
+ },
+
+ ## options defined .pytool/Plugin/DependencyCheck
+ "DependencyCheck": {
+ "AcceptableDependencies": [
+ "MdeModulePkg/MdeModulePkg.dec",
+ "MdePkg/MdePkg.dec",
+ "SecurityPkg/SecurityPkg.dec",
+ "SignedCapsulePkg/SignedCapsulePkg.dec"
+ ],
+ # For host based unit tests
+ "AcceptableDependencies-HOST_APPLICATION":[
+ "UnitTestFrameworkPkg/UnitTestFrameworkPkg.dec"
+ ],
+ # For UEFI shell based apps
+ "AcceptableDependencies-UEFI_APPLICATION":[],
+ "IgnoreInf": []
+ },
+
+ ## options defined .pytool/Plugin/DscCompleteCheck
+ "DscCompleteCheck": {
+ "IgnoreInf": [""],
+ "DscPath": "SignedCapsulePkg.dsc"
+ },
+
+ ## options defined .pytool/Plugin/HostUnitTestDscCompleteCheck
+ "HostUnitTestDscCompleteCheck": {
+ "IgnoreInf": [""],
+ "DscPath": "" # Don't support this test
+ },
+
+ ## options defined .pytool/Plugin/GuidCheck
+ "GuidCheck": {
+ "IgnoreGuidName": [],
+ "IgnoreGuidValue": [],
+ "IgnoreFoldersAndFiles": [],
+ "IgnoreDuplicates": [],
+ },
+
+ ## options defined .pytool/Plugin/LibraryClassCheck
+ "LibraryClassCheck": {
+ "IgnoreHeaderFile": []
+ },
+
+ ## options defined .pytool/Plugin/SpellCheck
+ "SpellCheck": {
+ "AuditOnly": True, # Failures need to be reviewed
and resolved in the future
+ "IgnoreFiles": [], # use gitignore syntax to
ignore errors in matching files
+ "ExtendWords": [], # words to extend to the
dictionary for this package
+ "IgnoreStandardPaths": [], # Standard Plugin defined paths
that should be ignore
+ "AdditionalIncludePaths": [] # Additional paths to spell
check (wildcards supported)
+ }
+}
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#94672): https://edk2.groups.io/g/devel/message/94672
Mute This Topic: https://groups.io/mt/93519142/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [PATCH v2 3/6] IntelFsp2Pkg: Add CI YAML file
Another reminder.
On 9/22/2022 9:07 PM, Michael Kubacki wrote:
Review reminder
On 9/15/2022 3:41 PM, Michael Kubacki wrote:
Hi Chasel,
Your CI YAML file feedback in v1 is addressed now in v2.
Can you please provide your review on this patch and [PATCH v2 5/6]?
Note that I updated the commit message for this patch to remove the
info about the build being broken since that was recently fixed. That
update is in the branch:
https://github.com/makubacki/edk2/commit/c37e6dfa482ed075cd4ab6712e6d17b3cf17786a
With these reviews, the series will be covered.
Thanks,
Michael
On 9/15/2022 2:55 PM, Michael Kubacki wrote:
From: Michael Kubacki
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=4048
Adds IntelFsp2Pkg to the list of supported build packages for edk2
CI and defines an initial set of CI configuration options.
The compiler plugin is disabled as the package currently does not
build due to some changes in the FSP 2.4 interface addition.
Specifically, in commit df25a54 "Fsp24SecCore.inf" files were
added to IntelFspPkg.dsc but the actual files were not added.
Simply removing these files from the DSC exposes a linker failure.
Recommendation:
1. Enable package CI (accept this change)
2. Add IntelFsp2Pkg.dsc to the "CompilerPlugin" "DscPath" in
IntelFsp2Pkg/IntelFsp2Pkg.ci.yaml to enable compilation
3. Verify compilation and all currently enabled package CI checks
pass
4. Check-in fixes in (3) with change in (2)
Cc: Chasel Chiu
Cc: Nate DeSimone
Cc: Star Zeng
Signed-off-by: Michael Kubacki
---
.pytool/CISettings.py | 1 +
IntelFsp2Pkg/IntelFsp2Pkg.ci.yaml | 90
2 files changed, 91 insertions(+)
diff --git a/.pytool/CISettings.py b/.pytool/CISettings.py
index cf9e0d77b19b..0205c26a58f8 100644
--- a/.pytool/CISettings.py
+++ b/.pytool/CISettings.py
@@ -54,6 +54,7 @@ class Settings(CiBuildSettingsManager,
UpdateSettingsManager, SetupSettingsManag
"ArmVirtPkg",
"DynamicTablesPkg",
"EmulatorPkg",
+ "IntelFsp2Pkg",
"MdePkg",
"MdeModulePkg",
"NetworkPkg",
diff --git a/IntelFsp2Pkg/IntelFsp2Pkg.ci.yaml
b/IntelFsp2Pkg/IntelFsp2Pkg.ci.yaml
new file mode 100644
index ..9ce401b20164
--- /dev/null
+++ b/IntelFsp2Pkg/IntelFsp2Pkg.ci.yaml
@@ -0,0 +1,90 @@
+## @file
+# Core CI configuration for IntelFsp2Pkg
+#
+# Copyright (c) Microsoft Corporation
+#
+# SPDX-License-Identifier: BSD-2-Clause-Patent
+##
+{
+ ## options defined .pytool/Plugin/LicenseCheck
+ "LicenseCheck": {
+ "IgnoreFiles": []
+ },
+
+ "EccCheck": {
+ ## Exception sample looks like below:
+ ## "ExceptionList": [
+ ## "", ""
+ ## ]
+ "ExceptionList": [
+ ],
+ ## Both file path and directory path are accepted.
+ "IgnoreFiles": []
+ },
+
+ ## options defined .pytool/Plugin/CompilerPlugin
+ "CompilerPlugin": {
+ "DscPath": "IntelFsp2Pkg.dsc"
+ },
+
+ ## options defined .pytool/Plugin/HostUnitTestCompilerPlugin
+ "HostUnitTestCompilerPlugin": {
+ "DscPath": "" # Don't support this test
+ },
+
+ ## options defined .pytool/Plugin/CharEncodingCheck
+ "CharEncodingCheck": {
+ "IgnoreFiles": []
+ },
+
+ ## options defined .pytool/Plugin/DependencyCheck
+ "DependencyCheck": {
+ "AcceptableDependencies": [
+ "IntelFsp2Pkg/IntelFsp2Pkg.dec",
+ "MdeModulePkg/MdeModulePkg.dec",
+ "MdePkg/MdePkg.dec",
+ "UefiCpuPkg/UefiCpuPkg.dec"
+ ],
+ # For host based unit tests
+ "AcceptableDependencies-HOST_APPLICATION":[
+ "UnitTestFrameworkPkg/UnitTestFrameworkPkg.dec"
+ ],
+ # For UEFI shell based apps
+ "AcceptableDependencies-UEFI_APPLICATION":[],
+ "IgnoreInf": []
+ },
+
+ ## options defined .pytool/Plugin/DscCompleteCheck
+ "DscCompleteCheck": {
+ "IgnoreInf": [""],
+ "DscPath": "IntelFsp2Pkg.dsc"
+ },
+
+ ## options defined .pytool/Plugin/HostUnitTestDscCompleteCheck
+ "HostUnitTestDscCompleteCheck": {
+ "IgnoreInf": [""],
+ "DscPath": "" # Don't support this test
+ },
+
+ ## options defined .pytool/Plugin/GuidCheck
+ "GuidCheck": {
+ "IgnoreGuidName": [],
+ "IgnoreGuidValue": [],
+ "IgnoreFoldersAndFiles": [],
+ "IgnoreDuplicates": [],
+ },
+
+ ## options defined .pytool/Plugin/LibraryClassCheck
+ "LibraryClassCheck": {
+ "IgnoreHeaderFile": []
+ },
+
+ ## options defined .pytool/Plugin/SpellCheck
+ "SpellCheck": {
+ "AuditOnly": True, # Fails right now with over 270
errors
+ "IgnoreFiles": [], # use gitignore syntax to
ignore errors in matching files
+ "ExtendWords": [], # words to extend to the
dictionary for this package
+ "IgnoreStandardPaths": [], # Standard Plugin
Re: [edk2-devel] [PATCH 1/2] MdePkg: Support for MPAM ACPI Table
Hi Swatisri, Rohit pointed me to this patch series, which I believe is v2. I happened to have missed this as the subject line was not clear. However, I believe my feedback (or some parts) for the v1 series would still apply. Regards, Sami Mujawar -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#94668): https://edk2.groups.io/g/devel/message/94668 Mute This Topic: https://groups.io/mt/93824432/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [PATCH v5 3/7] MdeModulePkg: Invoke all ExitBootServicesCallback instances at ExitBootServices
(cc Ray)
On Sat, 1 Oct 2022 at 01:06, Dionna Glaze wrote:
>
> 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
> Cc: James Bottomley
> Cc: Jiewen Yao
> Cc: Tom Lendacky
> Cc: Ard Biesheuvel
> Cc: "Min M. Xu"
> Cc: Andrew Fish
> Cc: "Michael D. Kinney"
>
> Signed-off-by: Dionna Glaze
> ---
> MdeModulePkg/Core/Dxe/DxeMain.inf | 1 +
> MdeModulePkg/Core/Dxe/DxeMain/DxeMain.c | 62
> 2 files changed, 63 insertions(+)
>
> 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..8cf7d6bcbf 100644
> --- a/MdeModulePkg/Core/Dxe/DxeMain/DxeMain.c
> +++ b/MdeModulePkg/Core/Dxe/DxeMain/DxeMain.c
> @@ -6,6 +6,7 @@ SPDX-License-Identifier: BSD-2-Clause-Patent
>
> **/
>
> +#include
This include belongs in DxeMain.h
> #include "DxeMain.h"
>
> //
> @@ -744,6 +745,54 @@ CalculateEfiHdrCrc (
>Hdr->CRC32 = Crc;
> }
>
> +/**
> + Invokes TerminateMemoryMapPrehook from every instance of the
> + EdkiiExitBootServicesProtocol.
> +**/
> +STATIC
> +EFI_STATUS
> +InvokeTerminateMemoryMapPrehooks (
> + VOID
> + )
We should decide whether or not we want to support a multitude of
these callback protocols. Some protocols in EFI are simply considered
singleton protocols, and I think we might want to stick with that
approach for the time being, as it makes the code much simpler,
especially because most users of this code are not confidential
compute.
> +{
> + UINTN NoHandles;
> + UINTN Index;
> + EFI_HANDLE *HandleBuffer;
> + EFI_STATUS Status;
> + EDKII_EXIT_BOOT_SERVICES_CALLBACK_PROTOCOL *Callback;
> +
> + Status = gBS->LocateHandleBuffer (
> + ByProtocol,
> + &gEdkiiExitBootServicesCallbackProtocolGuid,
> + NULL,
> + &NoHandles,
> + &HandleBuffer
> + );
> + if (EFI_ERROR (Status) && NoHandles == 0) {
> +return Status;
> + }
> +
> + for (Index = 0; Index < NoHandles; Index++) {
> +Status = gBS->HandleProtocol (
> +HandleBuffer[Index],
> +&gEdkiiExitBootServicesCallbackProtocolGuid,
> +(VOID **)&Callback
> +);
> +if (EFI_ERROR (Status)) {
> + continue;
> +}
> +
> +Status = Callback->TerminateMemoryMapPrehook(Callback);
> +if (EFI_ERROR (Status) || Status == EFI_WARN_STALE_DATA) {
EFI_WARN_STALE_DATA is not an error, so this routine might return a
non-error, which we fail to check for below.
Also, if multiple protocols exist, shouldn't we invoke all of them,
and collate the return codes in some way?
(Another reason to stick with a singleton protocol)
> + goto done;
> +}
> + }
> +
> +done:
> + FreePool(HandleBuffer);
> + return Status;
> +}
> +
> /**
>Terminates all boot services.
>
> @@ -768,6 +817,19 @@ CoreExitBootServices (
>//
>gTimer->SetTimerPeriod (gTimer, 0);
>
> + //
> + // Invoke all protocols installed for ExitBootServices prior to
> + // CoreTerminateMemoryMap.
> + //
> + Status = InvokeTerminateMemoryMapPrehooks();
> + if (EFI_ERROR (Status)) {
This condition does not hold for EFI_WARN_STALE_DATA, nor is
EFI_WARN_STALE_DATA documented as a valid return value for
ExitBootServices().
> +//
> +// Notify other drivers that ExitBootServices failed
> +//
> +CoreNotifySignalList (&gEventExitBootServicesFailedGuid);
> +return Status;
> + }
> +
>//
>// Terminate memory services if the MapKey matches
>//
> --
> 2.38.0.rc1.362.ged0d419d3c-goog
>
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#94667): https://edk2.groups.io/g/devel/message/94667
Mute This Topic: https://groups.io/mt/94028462/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [PATCH v5 2/7] MdePkg: Introduce ExitBootServicesCallbackProtocol
On Mon, 3 Oct 2022 at 03:16, Dionna Amalie Glaze wrote: > > > > > Is it defined by UEFI Spec? > > > > It is not. This is Ard's suggested solution > https://patchew.org/EDK2/20220928153323.2583389-1-dionnagl...@google.com/20220928153323.2583389-5-dionnagl...@google.com/#camj1kxfwbu9oiulufxsrqhag1pf+yu2dl4jbuz2lo0k9uue...@mail.gmail.com > It is not in the spec, which is why we called it gEdkiiExitBootServicesCallbackProtocolGuid What Ray is getting to (I think) is that that means that it should be defined in MdeModulePkg not MdePkg. -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#94666): https://edk2.groups.io/g/devel/message/94666 Mute This Topic: https://groups.io/mt/94028459/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [PATCH 1/2] Mde Pkg: Support for MPAM ACPI Table
Hi Swatisri,
Apologies for the delay in feedback.
There is a new version of "ACPI for Memory System Resource Partitioning
and Monitoring 2.0, Platform Design Document" published on 2022/Sep/30
at https://developer.arm.com/documentation/den0065/latest.
The version 2.0 of ACPI MPAM table has a few errata fixes and some new
additions. Therefore, the version 1.0 of the ACPI MPAM table stands
deprecated and must not be used.
I would therefore suggest that this patch is updated to reflect ACPI
MPAM table version 2.0. I also have some feedback below that would still
apply.
Regards,
Sami Mujawar
On 16/08/2022 09:18 pm, Name wrote:
From: Swatisri Kantamsetti
Added MPAM table header, MSC and Resource Node
info structures
Signed-off-by: Swatisri Kantamsetti
---
MdePkg/Include/IndustryStandard/Acpi64.h | 5 ++
MdePkg/Include/IndustryStandard/Mpam.h | 69
2 files changed, 74 insertions(+)
create mode 100644 MdePkg/Include/IndustryStandard/Mpam.h
diff --git a/MdePkg/Include/IndustryStandard/Acpi64.h
b/MdePkg/Include/IndustryStandard/Acpi64.h
index fe5ebfac2b..e54f631186 100644
--- a/MdePkg/Include/IndustryStandard/Acpi64.h
+++ b/MdePkg/Include/IndustryStandard/Acpi64.h
@@ -2952,6 +2952,11 @@ typedef struct {
///
#define EFI_ACPI_6_4_PROCESSOR_PROPERTIES_TOPOLOGY_TABLE_STRUCTURE_SIGNATURE
SIGNATURE_32('P', 'P', 'T', 'T')
+///
+/// "MPAM" Memory System Resource Partitioning And Monitoring Table
+///
+#define
EFI_ACPI_6_4_MEMORY_SYSTEM_RESOURCE_PARTITIONING_MONITORING_TABLE_STRUCTURE_SIGNATURE
SIGNATURE_32('M', 'P', 'A', 'M')
+
///
/// "PSDT" Persistent System Description Table
///
diff --git a/MdePkg/Include/IndustryStandard/Mpam.h
b/MdePkg/Include/IndustryStandard/Mpam.h
new file mode 100644
index 00..e0f75f0114
--- /dev/null
+++ b/MdePkg/Include/IndustryStandard/Mpam.h
@@ -0,0 +1,69 @@
+/** @file
+ ACPI Memory System Resource Partitioning And Monitoring (MPAM)
+ as specified in ARM spec DEN0065
+
+ Copyright (c) 2022, NVIDIA CORPORATION. All rights reserved.
+ Copyright (c) 2022, ARM Limited. All rights reserved.
+ SPDX-License-Identifier: BSD-2-Clause-Patent
[SAMI] Please add a '@par Specification Reference:' section as shown in
https://edk2-docs.gitbook.io/edk-ii-c-coding-standards-specification/5_source_files/53_include_files#5.3.7-include-files-shall-not-generate-code-or-define-data-variables.
e.g.
@par Specification Reference:
- [1] ACPI for Memory System Resource Partitioning and Monitoring 2.0,
Platform Design Document
(https://developer.arm.com/documentation/den0065/latest)
[/SAMI]
+**/
+
+#ifndef _MPAM_H_
+#define _MPAM_H_
[SAMI] I think the leading underscore should not be present, see
https://edk2-docs.gitbook.io/edk-ii-c-coding-standards-specification/4_naming_conventions/43_identifiers#4.3.5.4-the-names-of-guard-macros-shall-end-with-an-underscore-character.
+
+#pragma pack(1)
+
+///
+/// Memory System Resource Partitioning and Monitoring Table (MPAM)
+///
+typedef struct {
+ EFI_ACPI_DESCRIPTION_HEADERHeader;
+ UINT32 NumNodes;
+ UINT32 NodeOffset;
+ UINT32 Reserved;
[SAMI] I do not see the NumNodes, NodeOffset and the Reserved filed in
the specification. Can you check, please?
+} EFI_ACPI_6_4_MEMORY_SYSTEM_RESOURCE_PARTITIONING_MONITORING_TABLE_HEADER;
[SAMI] I think the infix '_6_4_' is not going to work, as the ACPI MPAM
table specification is not going to be in sync with the ACPI
specification revision. So, this can be dropped.
Also, it may be better to add a @glossary section in the file header
describing the MPAM acronym and abbreviate the structure names to
EFI_ACPI_MPAM_TABLE_HEADER. The macro describing the table revision can
also follow a similar approach.
[/SAMI]
+
+///
+/// MPAM Revision (as defined in ACPI 6.4 spec.)
[SAMI] I believe this should be (a defined by the 'ACPI for Memory
System Resource Partitioning and Monitoring, Platform Design Document').
Or simply refer it as '(as defined by [1])'.
+///
+#define
EFI_ACPI_6_4_MEMORY_SYSTEM_RESOURCE_PARTITIONING_MONITORING_TABLE_REVISION 0x01
[SAMI] Please move this definition before the definition of
EFI_ACPI_6_4_MEMORY_SYSTEM_RESOURCE_PARTITIONING_MONITORING_TABLE_HEADER.
The ACPI MPAM 1.0 table revision was 0. But for ACPI MPAM table 2.0 the
revision is 1, so there is no need to change.
+
+///
+/// Memory System Controller Node Structure
+///
+
+typedef struct {
+ UINT16Length;
+ UINT16Reserved;
[SAMI] ACPI MPAM 2.0 introduces splits the Reserved field to introduce
'Interface type'.
+ UINT32Identifier;
+ UINT64BaseAddress;
+ UINT32MmioSize;
+ UINT32OverflowInterrupt;
+ UINT32OverflowInterruptFlags;
+ UINT32Reserved1;
+ UINT32OverflowInterruptAff;
+ UINT32ErrorInterrupt;
+ UINT32ErrorInterruptFlags;
+ UINT32Reserved2;
+ UINT32ErrorInterruptAff;
+ UINT32MaxNRdy
Re: [edk2-devel] [PATCH 1/1] Maintainers.txt: Add 'Pierre Gondois' as DynamicTablesPkg reviewer
Reviewed-by: Alexei Fedorov -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#94664): https://edk2.groups.io/g/devel/message/94664 Mute This Topic: https://groups.io/mt/93869929/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [PATCH] MdeModulePkg/FaultTolerantWriteDxe: Don't check for address alignment
Hi Wu Hao/ Zeng Star, Any update on this? :) -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#94663): https://edk2.groups.io/g/devel/message/94663 Mute This Topic: https://groups.io/mt/91134149/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[edk2-devel] [PATCH 3/3] UsbNetworkPkg/UsbCdcNcm: Add USB Cdc NCM devices support
This driver provides UEFI driver for USB CDC NCM device
Signed-off-by: Richard Ho
Cc: Andrew Fish
Cc: Leif Lindholm
Cc: Michael D Kinney
Cc: Michael Kubacki
Cc: Zhiguang Liu
Cc: Liming Gao
Reviewed-by: Tony Lo
---
UsbNetworkPkg/UsbCdcNcm/ComponentName.c | 170
UsbNetworkPkg/UsbCdcNcm/UsbCdcNcm.c | 506
UsbNetworkPkg/UsbCdcNcm/UsbCdcNcm.h | 245 ++
UsbNetworkPkg/UsbCdcNcm/UsbCdcNcm.inf| 42 +
UsbNetworkPkg/UsbCdcNcm/UsbNcmFunction.c | 950 +++
5 files changed, 1913 insertions(+)
create mode 100644 UsbNetworkPkg/UsbCdcNcm/ComponentName.c
create mode 100644 UsbNetworkPkg/UsbCdcNcm/UsbCdcNcm.c
create mode 100644 UsbNetworkPkg/UsbCdcNcm/UsbCdcNcm.h
create mode 100644 UsbNetworkPkg/UsbCdcNcm/UsbCdcNcm.inf
create mode 100644 UsbNetworkPkg/UsbCdcNcm/UsbNcmFunction.c
diff --git a/UsbNetworkPkg/UsbCdcNcm/ComponentName.c
b/UsbNetworkPkg/UsbCdcNcm/ComponentName.c
new file mode 100644
index 00..3db1dc6933
--- /dev/null
+++ b/UsbNetworkPkg/UsbCdcNcm/ComponentName.c
@@ -0,0 +1,170 @@
+/** @file
+ This file contains code for USB Ncm Driver Component Name definitions
+
+ Copyright (c) 2022, American Megatrends International LLC. All rights
reserved.
+ SPDX-License-Identifier: BSD-2-Clause-Patent
+**/
+#include "UsbCdcNcm.h"
+
+GLOBAL_REMOVE_IF_UNREFERENCED EFI_UNICODE_STRING_TABLE
gUsbNcmDriverNameTable[] = {
+ {
+"eng;en",
+L"USB NCM Driver"
+ },
+ {
+NULL,
+NULL
+ }
+};
+
+EFI_STATUS
+EFIAPI
+UsbNcmComponentNameGetDriverName (
+ IN EFI_COMPONENT_NAME_PROTOCOL *This,
+ IN CHAR8*Language,
+ OUT CHAR16 **DriverName
+ );
+
+EFI_STATUS
+EFIAPI
+UsbNcmComponentNameGetControllerName (
+ IN EFI_COMPONENT_NAME_PROTOCOL *This,
+ IN EFI_HANDLE Controller,
+ IN EFI_HANDLE ChildHandleOPTIONAL,
+ IN CHAR8*Language,
+ OUT CHAR16 **ControllerName
+ );
+
+GLOBAL_REMOVE_IF_UNREFERENCED EFI_COMPONENT_NAME_PROTOCOL
gUsbNcmComponentName = {
+ UsbNcmComponentNameGetDriverName,
+ UsbNcmComponentNameGetControllerName,
+ "eng"
+};
+
+GLOBAL_REMOVE_IF_UNREFERENCED EFI_COMPONENT_NAME2_PROTOCOL
gUsbNcmComponentName2 = {
+ (EFI_COMPONENT_NAME2_GET_DRIVER_NAME)UsbNcmComponentNameGetDriverName,
+
(EFI_COMPONENT_NAME2_GET_CONTROLLER_NAME)UsbNcmComponentNameGetControllerName,
+ "en"
+};
+
+/**
+ Retrieves a Unicode string that is the user readable name of the driver.
+
+ This function retrieves the user readable name of a driver in the form of a
+ Unicode string. If the driver specified by This has a user readable name in
+ the language specified by Language, then a pointer to the driver name is
+ returned in DriverName, and EFI_SUCCESS is returned. If the driver specified
+ by This does not support the language specified by Language,
+ then EFI_UNSUPPORTED is returned.
+
+ @param[in] This A pointer to the EFI_COMPONENT_NAME2_PROTOCOL
or
+EFI_COMPONENT_NAME_PROTOCOL instance.
+ @param[in] Language A pointer to a Null-terminated ASCII string
+array indicating the language. This is the
+language of the driver name that the caller is
+requesting, and it must match one of the
+languages specified in SupportedLanguages. The
+number of languages supported by a driver is up
+to the driver writer. Language is specified
+in RFC 4646 or ISO 639-2 language code format.
+ @param[out] DriverNameA pointer to the Unicode string to return.
+This Unicode string is the name of the
+driver specified by This in the language
+specified by Language.
+
+ @retval EFI_SUCCESS The Unicode string for the Driver specified by
+This and the language specified by Language was
+returned in DriverName.
+ @retval EFI_INVALID_PARAMETER Language is NULL.
+ @retval EFI_INVALID_PARAMETER DriverName is NULL.
+ @retval EFI_UNSUPPORTED The driver specified by This does not support
+the language specified by Language.
+
+**/
+EFI_STATUS
+EFIAPI
+UsbNcmComponentNameGetDriverName (
+ IN EFI_COMPONENT_NAME_PROTOCOL *This,
+ IN CHAR8*Language,
+ OUT CHAR16 **DriverName
+ )
+{
+ return LookupUnicodeString2 (
+ Language,
+ This->SupportedLanguages,
+ gUsbNcmDriverNameTable,
+ DriverName,
+ (BOOLEAN)(This == &gUsbNcmComponentName)
+ );
+}
+
+/**
+ Retrieves a Unicode string that is the user readable name of the controller
+
[edk2-devel] [PATCH 2/3] UsbNetworkPkg/UsbCdcEcm: Add USB Cdc ECM devices support
This driver provides UEFI driver for USB CDC ECM device
Signed-off-by: Richard Ho
Cc: Andrew Fish
Cc: Leif Lindholm
Cc: Michael D Kinney
Cc: Michael Kubacki
Cc: Zhiguang Liu
Cc: Liming Gao
Reviewed-by: Tony Lo
---
UsbNetworkPkg/UsbCdcEcm/ComponentName.c | 170 +
UsbNetworkPkg/UsbCdcEcm/UsbCdcEcm.c | 502 +
UsbNetworkPkg/UsbCdcEcm/UsbCdcEcm.h | 211 ++
UsbNetworkPkg/UsbCdcEcm/UsbCdcEcm.inf| 42 ++
UsbNetworkPkg/UsbCdcEcm/UsbEcmFunction.c | 865 +++
5 files changed, 1790 insertions(+)
create mode 100644 UsbNetworkPkg/UsbCdcEcm/ComponentName.c
create mode 100644 UsbNetworkPkg/UsbCdcEcm/UsbCdcEcm.c
create mode 100644 UsbNetworkPkg/UsbCdcEcm/UsbCdcEcm.h
create mode 100644 UsbNetworkPkg/UsbCdcEcm/UsbCdcEcm.inf
create mode 100644 UsbNetworkPkg/UsbCdcEcm/UsbEcmFunction.c
diff --git a/UsbNetworkPkg/UsbCdcEcm/ComponentName.c
b/UsbNetworkPkg/UsbCdcEcm/ComponentName.c
new file mode 100644
index 00..684a08730a
--- /dev/null
+++ b/UsbNetworkPkg/UsbCdcEcm/ComponentName.c
@@ -0,0 +1,170 @@
+/** @file
+ This file contains code for USB Ecm Driver Component Name definitions
+
+ Copyright (c) 2022, American Megatrends International LLC. All rights
reserved.
+ SPDX-License-Identifier: BSD-2-Clause-Patent
+**/
+#include "UsbCdcEcm.h"
+
+GLOBAL_REMOVE_IF_UNREFERENCED EFI_UNICODE_STRING_TABLE
gUsbEcmDriverNameTable[] = {
+ {
+"eng;en",
+L"USB ECM Driver"
+ },
+ {
+NULL,
+NULL
+ }
+};
+
+EFI_STATUS
+EFIAPI
+UsbEcmComponentNameGetDriverName (
+ IN EFI_COMPONENT_NAME_PROTOCOL *This,
+ IN CHAR8*Language,
+ OUT CHAR16 **DriverName
+ );
+
+EFI_STATUS
+EFIAPI
+UsbEcmComponentNameGetControllerName (
+ IN EFI_COMPONENT_NAME_PROTOCOL *This,
+ IN EFI_HANDLE Controller,
+ IN EFI_HANDLE ChildHandleOPTIONAL,
+ IN CHAR8*Language,
+ OUT CHAR16 **ControllerName
+ );
+
+GLOBAL_REMOVE_IF_UNREFERENCED EFI_COMPONENT_NAME_PROTOCOL
gUsbEcmComponentName = {
+ UsbEcmComponentNameGetDriverName,
+ UsbEcmComponentNameGetControllerName,
+ "eng"
+};
+
+GLOBAL_REMOVE_IF_UNREFERENCED EFI_COMPONENT_NAME2_PROTOCOL
gUsbEcmComponentName2 = {
+ (EFI_COMPONENT_NAME2_GET_DRIVER_NAME)UsbEcmComponentNameGetDriverName,
+
(EFI_COMPONENT_NAME2_GET_CONTROLLER_NAME)UsbEcmComponentNameGetControllerName,
+ "en"
+};
+
+/**
+ Retrieves a Unicode string that is the user readable name of the driver.
+
+ This function retrieves the user readable name of a driver in the form of a
+ Unicode string. If the driver specified by This has a user readable name in
+ the language specified by Language, then a pointer to the driver name is
+ returned in DriverName, and EFI_SUCCESS is returned. If the driver specified
+ by This does not support the language specified by Language,
+ then EFI_UNSUPPORTED is returned.
+
+ @param[in] This A pointer to the EFI_COMPONENT_NAME2_PROTOCOL
or
+EFI_COMPONENT_NAME_PROTOCOL instance.
+ @param[in] Language A pointer to a Null-terminated ASCII string
+array indicating the language. This is the
+language of the driver name that the caller is
+requesting, and it must match one of the
+languages specified in SupportedLanguages. The
+number of languages supported by a driver is up
+to the driver writer. Language is specified
+in RFC 4646 or ISO 639-2 language code format.
+ @param[out] DriverNameA pointer to the Unicode string to return.
+This Unicode string is the name of the
+driver specified by This in the language
+specified by Language.
+
+ @retval EFI_SUCCESS The Unicode string for the Driver specified by
+This and the language specified by Language was
+returned in DriverName.
+ @retval EFI_INVALID_PARAMETER Language is NULL.
+ @retval EFI_INVALID_PARAMETER DriverName is NULL.
+ @retval EFI_UNSUPPORTED The driver specified by This does not support
+the language specified by Language.
+
+**/
+EFI_STATUS
+EFIAPI
+UsbEcmComponentNameGetDriverName (
+ IN EFI_COMPONENT_NAME_PROTOCOL *This,
+ IN CHAR8*Language,
+ OUT CHAR16 **DriverName
+ )
+{
+ return LookupUnicodeString2 (
+ Language,
+ This->SupportedLanguages,
+ gUsbEcmDriverNameTable,
+ DriverName,
+ (BOOLEAN)(This == &gUsbEcmComponentName)
+ );
+}
+
+/**
+ Retrieves a Unicode string that is the user readable name of the controlle
Re: [edk2-devel] [PATCH 1/3] MdeModulePkg/BootLogoLib: Add option to follow Microsoft Recommendations
Hi Liming,
Mind to help to take a look at these 2 patches? Sean has updated the initial
patches per your recommendation:
https://edk2.groups.io/g/devel/message/94318?p=%2C%2C%2C20%2C0%2C0%2C0%3A%3ACreated%2C%2Cboot+logo+sean%2C20%2C2%2C0%2C93922542
https://edk2.groups.io/g/devel/message/94320?p=%2C%2C%2C20%2C0%2C0%2C0%3A%3ACreated%2C%2Cboot+logo+sean%2C20%2C2%2C0%2C93922544
Previous feedback:
https://edk2.groups.io/g/devel/message/92385?p=%2C%2C%2C20%2C0%2C0%2C0%3A%3ACreated%2C%2Cboot+logo+sean%2C20%2C2%2C0%2C92974182
https://edk2.groups.io/g/devel/message/92146?p=%2C%2C%2C20%2C0%2C0%2C0%3A%3ACreated%2C%2Cboot+logo+sean%2C20%2C2%2C0%2C92830014
Thanks,
Sheng
From: devel@edk2.groups.io on behalf of Sean Rhodes
Date: Monday, 26. September 2022 at 10:10
To: devel@edk2.groups.io
Cc: Sean Rhodes , Zhichao Gao ,
Ray Ni , Jian J Wang , Liming Gao
Subject: [edk2-devel] [PATCH 1/3] MdeModulePkg/BootLogoLib: Add option to
follow Microsoft Recommendations
Add an option to position the logo 38.2% from the top of the screen,
which follows the recommendations from Microsoft. These can be found
here:
https://docs.microsoft.com/en-us/windows-hardware/drivers/bringup/boot-screen-components
Cc: Zhichao Gao
Cc: Ray Ni
Cc: Jian J Wang
Cc: Liming Gao
Signed-off-by: Sean Rhodes
---
MdeModulePkg/Include/Protocol/PlatformLogo.h | 3 ++-
MdeModulePkg/Library/BootLogoLib/BootLogoLib.c | 7 ---
2 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/MdeModulePkg/Include/Protocol/PlatformLogo.h
b/MdeModulePkg/Include/Protocol/PlatformLogo.h
index 08e1dc35a4..b24d7d5b79 100644
--- a/MdeModulePkg/Include/Protocol/PlatformLogo.h
+++ b/MdeModulePkg/Include/Protocol/PlatformLogo.h
@@ -29,7 +29,8 @@ typedef enum {
EdkiiPlatformLogoDisplayAttributeCenterBottom,
EdkiiPlatformLogoDisplayAttributeLeftBottom,
EdkiiPlatformLogoDisplayAttributeCenterLeft,
- EdkiiPlatformLogoDisplayAttributeCenter
+ EdkiiPlatformLogoDisplayAttributeCenter,
+ EdkiiPlatformLogoDisplayAttributeMicrosoftRecommended
} EDKII_PLATFORM_LOGO_DISPLAY_ATTRIBUTE;
/**
diff --git a/MdeModulePkg/Library/BootLogoLib/BootLogoLib.c
b/MdeModulePkg/Library/BootLogoLib/BootLogoLib.c
index 478ec2d40e..9065e5281b 100644
--- a/MdeModulePkg/Library/BootLogoLib/BootLogoLib.c
+++ b/MdeModulePkg/Library/BootLogoLib/BootLogoLib.c
@@ -169,7 +169,6 @@ BootLogoEnableLogo (
DestX = SizeOfX - Image.Width;
DestY = 0;
break;
-
case EdkiiPlatformLogoDisplayAttributeCenterLeft:
DestX = 0;
DestY = (SizeOfY - Image.Height) / 2;
@@ -182,7 +181,6 @@ BootLogoEnableLogo (
DestX = SizeOfX - Image.Width;
DestY = (SizeOfY - Image.Height) / 2;
break;
-
case EdkiiPlatformLogoDisplayAttributeLeftBottom:
DestX = 0;
DestY = SizeOfY - Image.Height;
@@ -195,7 +193,10 @@ BootLogoEnableLogo (
DestX = SizeOfX - Image.Width;
DestY = SizeOfY - Image.Height;
break;
-
+ case EdkiiPlatformLogoDisplayAttributeMicrosoftRecommended:
+DestX = (SizeOfX - Image.Width) / 2;
+DestY = (SizeOfY * 382) / 1000 - Image.Height / 2;
+break;
default:
ASSERT (FALSE);
continue;
--
2.34.1
-=-=-=-=-=-=
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#94318): https://edk2.groups.io/g/devel/message/94318
Mute This Topic: https://groups.io/mt/93922542/6757431
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [sheng@9elements.com]
-=-=-=-=-=-=
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#94659): https://edk2.groups.io/g/devel/message/94659
Mute This Topic: https://groups.io/mt/93922542/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [PATCH v2 02/17] BaseTools: Remove duplicated words
Hello Bob,
Thanks for the review. Other patches in the serie received a Reviewed-by:
- [PATCH v2 04/17] DynamicTablesPkg: Remove duplicated words
- [PATCH v2 09/17] NetworkPkg: Remove duplicated words
- [PATCH v2 11/17] RedfishPkg: Remove duplicated words
- [PATCH v2 13/17] ShellPkg: Remove duplicated words
- [PATCH v2 14/17] SourceLevelDebugPkg: Remove duplicated words
- [PATCH v2 17/17] UnitTestFrameworkPkg: Remove duplicated words
Would it be possible to take them aswell ? I'm not sure who should take them as
they are accross multiple packages,
Regards,
Pierre
On 10/1/22 17:08, Feng, Bob C wrote:
Reviewed-by: Bob Feng
-Original Message-
From: devel@edk2.groups.io On Behalf Of PierreGondois
Sent: Tuesday, September 6, 2022 4:29 PM
To: devel@edk2.groups.io
Cc: Pierre Gondois ; Feng, Bob C ; Gao,
Liming
Subject: [edk2-devel] [PATCH v2 02/17] BaseTools: Remove duplicated words
From: Pierre Gondois
In an effort to clean the documentation of the above package, remove duplicated
words.
Cc: Bob Feng
Cc: Liming Gao
Signed-off-by: Pierre Gondois
---
BaseTools/Source/C/Common/FirmwareVolumeBuffer.c| 6 +++---
BaseTools/Source/C/DevicePath/DevicePathUtilities.c | 2 +-
BaseTools/Source/C/GenFv/GenFv.c| 2 +-
BaseTools/Source/C/VfrCompile/Pccts/antlr/mrhoist.c | 4 ++--
BaseTools/Source/Python/Ecc/EccToolError.py | 2 +-
BaseTools/Source/Python/build/build.py | 2 +-
6 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/BaseTools/Source/C/Common/FirmwareVolumeBuffer.c
b/BaseTools/Source/C/Common/FirmwareVolumeBuffer.c
index 70741c8afcb5..ace26eb71c6b 100644
--- a/BaseTools/Source/C/Common/FirmwareVolumeBuffer.c
+++ b/BaseTools/Source/C/Common/FirmwareVolumeBuffer.c
@@ -91,7 +91,7 @@ Routine Description:
Arguments:
- SourceFv - Address of the Fv in memory, this firmware volume volume will
+ SourceFv - Address of the Fv in memory, this firmware volume will
be modified, if SourceFfsFile exists
SourceFfsFile - Input FFS file to replace
@@ -141,7 +141,7 @@ Routine Description:
Arguments:
- SourceFv - Address of the Fv in memory, this firmware volume volume will
+ SourceFv - Address of the Fv in memory, this firmware volume will
be modified, if SourceFfsFile exists
SourceFfsFile - Input FFS file to replace
@@ -285,7 +285,7 @@ Routine Description:
Arguments:
- SourceFv - Address of the Fv in memory, this firmware volume volume will
+ SourceFv - Address of the Fv in memory, this firmware volume will
be modified, if SourceFfsFile exists
SourceFfsFile - Input FFS file to replace
diff --git a/BaseTools/Source/C/DevicePath/DevicePathUtilities.c b/BaseTools/Source/C/DevicePath/DevicePathUtilities.c
index 2ffefa8ceeef..49078aac8caf 100644
--- a/BaseTools/Source/C/DevicePath/DevicePathUtilities.c
+++ b/BaseTools/Source/C/DevicePath/DevicePathUtilities.c
@@ -37,7 +37,7 @@ CONST EFI_DEVICE_PATH_PROTOCOL
mUefiDevicePathLibEndDevicePath = {
@retval TRUEDevicePath is valid.
@retval FALSE DevicePath is NULL.
@retval FALSE Maxsize is less than sizeof(EFI_DEVICE_PATH_PROTOCOL).
- @retval FALSE The length of any node node in the DevicePath is less
+ @retval FALSE The length of any node in the DevicePath is less
than sizeof (EFI_DEVICE_PATH_PROTOCOL).
@retval FALSE If MaxSize is not zero, the size of the DevicePath
exceeds MaxSize.
diff --git a/BaseTools/Source/C/GenFv/GenFv.c b/BaseTools/Source/C/GenFv/GenFv.c
index 43cc5cd3fe82..a742d55e5270 100644
--- a/BaseTools/Source/C/GenFv/GenFv.c
+++ b/BaseTools/Source/C/GenFv/GenFv.c
@@ -299,7 +299,7 @@ Returns:
return STATUS_ERROR;
}
if (TempNumber == 0) {
-Error (NULL, 0, 1003, "Invalid option value", "Fv block size can't be be
set to zero");
+Error (NULL, 0, 1003, "Invalid option value", "Fv block size
+ can't be set to zero");
return STATUS_ERROR;
}
mFvDataInfo.FvBlocks[0].Length = (UINT32) TempNumber; diff --git
a/BaseTools/Source/C/VfrCompile/Pccts/antlr/mrhoist.c
b/BaseTools/Source/C/VfrCompile/Pccts/antlr/mrhoist.c
index b57f5ded846c..bf3dd18eaf6f 100644
--- a/BaseTools/Source/C/VfrCompile/Pccts/antlr/mrhoist.c
+++ b/BaseTools/Source/C/VfrCompile/Pccts/antlr/mrhoist.c
@@ -714,7 +714,7 @@ Tree *MR_compute_pred_tree_ctxXX(p)
if (p == NULL) return NULL;
/* this appears strange: why do we OR the context
- of and AND predicate ? It is because of the way
+ of an AND predicate ? It is because of the way
that predicates are evaluated: if the context is
wrong then it's the same as if the predicate was
true. That means that even when one leg of an @@ -1531,7 +1531,7 @@
Predicate * MR_find_in_aSubBlk(alt)
* 1. if lookahead for alt i is contained in the lookahead for any
* alt j then ig
[edk2-devel] [PATCH 2/2] BaseTools: Remove duplicated words in Python tools
From: Pierre Gondois
In an effort to clean the documentation of the above
package, remove duplicated words.
Cc: Bob Feng
Cc: Liming Gao
Reviewed-by: Bob Feng
Signed-off-by: Pierre Gondois
---
BaseTools/Source/Python/Ecc/EccToolError.py | 2 +-
BaseTools/Source/Python/build/build.py | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/BaseTools/Source/Python/Ecc/EccToolError.py
b/BaseTools/Source/Python/Ecc/EccToolError.py
index d97bf7948ce8..2ff36c8329cc 100644
--- a/BaseTools/Source/Python/Ecc/EccToolError.py
+++ b/BaseTools/Source/Python/Ecc/EccToolError.py
@@ -186,7 +186,7 @@ gEccErrorMessage = {
ERROR_META_DATA_FILE_CHECK_BINARY_INF_IN_FDF : "An INF file is specified
in the FDF file, but not in the DSC file, therefore the INF file must be for a
Binary module only",
ERROR_META_DATA_FILE_CHECK_PCD_DUPLICATE : "Duplicate PCDs found",
ERROR_META_DATA_FILE_CHECK_PCD_FLASH : "PCD settings in the FDF file
should only be related to flash",
-ERROR_META_DATA_FILE_CHECK_PCD_NO_USE : "There should be no PCDs declared
in INF files that are not specified in in either a DSC or FDF file",
+ERROR_META_DATA_FILE_CHECK_PCD_NO_USE : "There should be no PCDs declared
in INF files that are not specified in either a DSC or FDF file",
ERROR_META_DATA_FILE_CHECK_DUPLICATE_GUID : "Duplicate GUID found",
ERROR_META_DATA_FILE_CHECK_DUPLICATE_PROTOCOL : "Duplicate PROTOCOL found",
ERROR_META_DATA_FILE_CHECK_DUPLICATE_PPI : "Duplicate PPI found",
diff --git a/BaseTools/Source/Python/build/build.py
b/BaseTools/Source/Python/build/build.py
index 07187c03618a..51fb1f433eb7 100755
--- a/BaseTools/Source/Python/build/build.py
+++ b/BaseTools/Source/Python/build/build.py
@@ -205,7 +205,7 @@ class MakeSubProc(Popen):
#
# This method will call subprocess.Popen to execute an external program with
# given options in specified directory. Because of the dead-lock issue during
-# redirecting output of the external program, threads are used to to do the
+# redirecting output of the external program, threads are used to do the
# redirection work.
#
# @param Command A list or string containing the call of the
program
--
2.25.1
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#94657): https://edk2.groups.io/g/devel/message/94657
Mute This Topic: https://groups.io/mt/94085944/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[edk2-devel] [PATCH 0/2] BaseTools: Remove duplicated words
From: Pierre Gondois As requestid in: https://edk2.groups.io/g/devel/message/94625 split the initial patch in 2 pieces, one for the C tools, and one for the Python tools. Pierre Gondois (2): BaseTools: Remove duplicated words in C tools BaseTools: Remove duplicated words in Python tools BaseTools/Source/C/Common/FirmwareVolumeBuffer.c| 6 +++--- BaseTools/Source/C/DevicePath/DevicePathUtilities.c | 2 +- BaseTools/Source/C/GenFv/GenFv.c| 2 +- BaseTools/Source/C/VfrCompile/Pccts/antlr/mrhoist.c | 4 ++-- BaseTools/Source/Python/Ecc/EccToolError.py | 2 +- BaseTools/Source/Python/build/build.py | 2 +- 6 files changed, 9 insertions(+), 9 deletions(-) -- 2.25.1 -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#94655): https://edk2.groups.io/g/devel/message/94655 Mute This Topic: https://groups.io/mt/94085941/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[edk2-devel] [PATCH 1/2] BaseTools: Remove duplicated words in C tools
From: Pierre Gondois
In an effort to clean the documentation of the above
package, remove duplicated words.
Cc: Bob Feng
Cc: Liming Gao
Reviewed-by: Bob Feng
Signed-off-by: Pierre Gondois
---
BaseTools/Source/C/Common/FirmwareVolumeBuffer.c| 6 +++---
BaseTools/Source/C/DevicePath/DevicePathUtilities.c | 2 +-
BaseTools/Source/C/GenFv/GenFv.c| 2 +-
BaseTools/Source/C/VfrCompile/Pccts/antlr/mrhoist.c | 4 ++--
4 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/BaseTools/Source/C/Common/FirmwareVolumeBuffer.c
b/BaseTools/Source/C/Common/FirmwareVolumeBuffer.c
index 70741c8afcb5..ace26eb71c6b 100644
--- a/BaseTools/Source/C/Common/FirmwareVolumeBuffer.c
+++ b/BaseTools/Source/C/Common/FirmwareVolumeBuffer.c
@@ -91,7 +91,7 @@ Routine Description:
Arguments:
- SourceFv - Address of the Fv in memory, this firmware volume volume will
+ SourceFv - Address of the Fv in memory, this firmware volume will
be modified, if SourceFfsFile exists
SourceFfsFile - Input FFS file to replace
@@ -141,7 +141,7 @@ Routine Description:
Arguments:
- SourceFv - Address of the Fv in memory, this firmware volume volume will
+ SourceFv - Address of the Fv in memory, this firmware volume will
be modified, if SourceFfsFile exists
SourceFfsFile - Input FFS file to replace
@@ -285,7 +285,7 @@ Routine Description:
Arguments:
- SourceFv - Address of the Fv in memory, this firmware volume volume will
+ SourceFv - Address of the Fv in memory, this firmware volume will
be modified, if SourceFfsFile exists
SourceFfsFile - Input FFS file to replace
diff --git a/BaseTools/Source/C/DevicePath/DevicePathUtilities.c
b/BaseTools/Source/C/DevicePath/DevicePathUtilities.c
index 2ffefa8ceeef..49078aac8caf 100644
--- a/BaseTools/Source/C/DevicePath/DevicePathUtilities.c
+++ b/BaseTools/Source/C/DevicePath/DevicePathUtilities.c
@@ -37,7 +37,7 @@ CONST EFI_DEVICE_PATH_PROTOCOL
mUefiDevicePathLibEndDevicePath = {
@retval TRUEDevicePath is valid.
@retval FALSE DevicePath is NULL.
@retval FALSE Maxsize is less than sizeof(EFI_DEVICE_PATH_PROTOCOL).
- @retval FALSE The length of any node node in the DevicePath is less
+ @retval FALSE The length of any node in the DevicePath is less
than sizeof (EFI_DEVICE_PATH_PROTOCOL).
@retval FALSE If MaxSize is not zero, the size of the DevicePath
exceeds MaxSize.
diff --git a/BaseTools/Source/C/GenFv/GenFv.c b/BaseTools/Source/C/GenFv/GenFv.c
index 43cc5cd3fe82..a742d55e5270 100644
--- a/BaseTools/Source/C/GenFv/GenFv.c
+++ b/BaseTools/Source/C/GenFv/GenFv.c
@@ -299,7 +299,7 @@ Returns:
return STATUS_ERROR;
}
if (TempNumber == 0) {
-Error (NULL, 0, 1003, "Invalid option value", "Fv block size can't be
be set to zero");
+Error (NULL, 0, 1003, "Invalid option value", "Fv block size can't be
set to zero");
return STATUS_ERROR;
}
mFvDataInfo.FvBlocks[0].Length = (UINT32) TempNumber;
diff --git a/BaseTools/Source/C/VfrCompile/Pccts/antlr/mrhoist.c
b/BaseTools/Source/C/VfrCompile/Pccts/antlr/mrhoist.c
index b57f5ded846c..bf3dd18eaf6f 100644
--- a/BaseTools/Source/C/VfrCompile/Pccts/antlr/mrhoist.c
+++ b/BaseTools/Source/C/VfrCompile/Pccts/antlr/mrhoist.c
@@ -714,7 +714,7 @@ Tree *MR_compute_pred_tree_ctxXX(p)
if (p == NULL) return NULL;
/* this appears strange: why do we OR the context
- of and AND predicate ? It is because of the way
+ of an AND predicate ? It is because of the way
that predicates are evaluated: if the context is
wrong then it's the same as if the predicate was
true. That means that even when one leg of an
@@ -1531,7 +1531,7 @@ Predicate * MR_find_in_aSubBlk(alt)
* 1. if lookahead for alt i is contained in the lookahead for any
* alt j then ignore semantic predicate of alt i
* 2. if lookahead for alt i is not contained in the lookahead for
- * any alt j then add add predicate i to the OR list to be hoisted
+ * any alt j then add predicate i to the OR list to be hoisted
* 3. if lookahead for alt i overlaps the lookahead for some alt j then
* add a dummy semantic predicate for alt j
*
--
2.25.1
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#94656): https://edk2.groups.io/g/devel/message/94656
Mute This Topic: https://groups.io/mt/94085942/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[edk2-devel] [PATCH v7 19/19] ArmVirtPkg: Kvmtool: Add RNG support using FW-TRNG interface
From: Sami Mujawar Bugzilla: 3668 (https://bugzilla.tianocore.org/show_bug.cgi?id=3668) The EFI_RNG_PROTOCOL published by RngDxe has been updated to implement the EFI_RNG_ALGORITHM_RAW using the Arm FW-TRNG interface to provide access to entropy. Therefore, enable EFI_RNG_PROTOCOL for the Kvmtool guest/virtual firmware. Signed-off-by: Pierre Gondois --- ArmVirtPkg/ArmVirtKvmTool.dsc | 10 ++ ArmVirtPkg/ArmVirtKvmTool.fdf | 5 + 2 files changed, 15 insertions(+) diff --git a/ArmVirtPkg/ArmVirtKvmTool.dsc b/ArmVirtPkg/ArmVirtKvmTool.dsc index 3bd3ebd6e0b3..847dbdd2af2b 100644 --- a/ArmVirtPkg/ArmVirtKvmTool.dsc +++ b/ArmVirtPkg/ArmVirtKvmTool.dsc @@ -81,6 +81,9 @@ [LibraryClasses.common] HwInfoParserLib|DynamicTablesPkg/Library/FdtHwInfoParserLib/FdtHwInfoParserLib.inf DynamicPlatRepoLib|DynamicTablesPkg/Library/Common/DynamicPlatRepoLib/DynamicPlatRepoLib.inf + ArmMonitorLib|ArmPkg/Library/ArmMonitorLib/ArmMonitorLib.inf + TrngLib|ArmPkg/Library/ArmFwTrngLib/ArmFwTrngLib.inf + [LibraryClasses.common.SEC, LibraryClasses.common.PEI_CORE, LibraryClasses.common.PEIM] PciExpressLib|MdePkg/Library/BasePciExpressLib/BasePciExpressLib.inf PlatformHookLib|ArmVirtPkg/Library/Fdt16550SerialPortHookLib/EarlyFdt16550SerialPortHookLib.inf @@ -112,6 +115,8 @@ [PcdsFeatureFlag.common] # Use MMIO for accessing RTC controller registers. gPcAtChipsetPkgTokenSpaceGuid.PcdRtcUseMmio|TRUE + gArmTokenSpaceGuid.PcdMonitorConduitHvc|TRUE + [PcdsFixedAtBuild.common] gEfiMdePkgTokenSpaceGuid.PcdDebugPrintErrorLevel|0x800F @@ -362,6 +367,11 @@ [Components.common] OvmfPkg/VirtioPciDeviceDxe/VirtioPciDeviceDxe.inf OvmfPkg/Virtio10Dxe/Virtio10.inf + # + # Rng Support + # + SecurityPkg/RandomNumberGenerator/RngDxe/RngDxe.inf + !if $(ARCH) == AARCH64 # # ACPI Support diff --git a/ArmVirtPkg/ArmVirtKvmTool.fdf b/ArmVirtPkg/ArmVirtKvmTool.fdf index 9e006e83ee5c..4b5c99ef6700 100644 --- a/ArmVirtPkg/ArmVirtKvmTool.fdf +++ b/ArmVirtPkg/ArmVirtKvmTool.fdf @@ -224,6 +224,11 @@ [FV.FvMain] # INF MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskDxe.inf + # + # Rng Support + # + INF SecurityPkg/RandomNumberGenerator/RngDxe/RngDxe.inf + [FV.FVMAIN_COMPACT] FvAlignment= 16 ERASE_POLARITY = 1 -- 2.25.1 -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#94654): https://edk2.groups.io/g/devel/message/94654 Mute This Topic: https://groups.io/mt/94085863/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[edk2-devel] [PATCH v7 18/19] SecurityPkg/RngDxe: Add Arm support of RngDxe
From: Pierre Gondois
Bugzilla: 3668 (https://bugzilla.tianocore.org/show_bug.cgi?id=3668)
Add RngDxe support for Arm. This implementation uses the TrngLib
to support the RawAlgorithm and doens't support the RNDR instruction.
To re-use the RngGetRNG(), RngGetInfo() and FreeAvailableAlgorithms()
functions, create Arm/AArch64 files which implement the arch specific
function GetAvailableAlgorithms(). Indeed, FEAT_RNG instruction is not
supported on Arm.
Signed-off-by: Pierre Gondois
---
Notes:
v4:
- Add AArch64/AArch64Algo.c and Arm/ArmAlgo.c that hold an arch
specific implementation of GetAvailableAlgorithms().
.../RngDxe/AArch64/AArch64Algo.c | 72 +++
.../RngDxe/Arm/ArmAlgo.c | 51 +
.../RandomNumberGenerator/RngDxe/ArmRngDxe.c | 60
.../RandomNumberGenerator/RngDxe/RngDxe.inf | 12 +++-
SecurityPkg/SecurityPkg.dsc | 2 +-
5 files changed, 133 insertions(+), 64 deletions(-)
create mode 100644
SecurityPkg/RandomNumberGenerator/RngDxe/AArch64/AArch64Algo.c
create mode 100644 SecurityPkg/RandomNumberGenerator/RngDxe/Arm/ArmAlgo.c
diff --git a/SecurityPkg/RandomNumberGenerator/RngDxe/AArch64/AArch64Algo.c
b/SecurityPkg/RandomNumberGenerator/RngDxe/AArch64/AArch64Algo.c
new file mode 100644
index ..d7e80a0d0d0d
--- /dev/null
+++ b/SecurityPkg/RandomNumberGenerator/RngDxe/AArch64/AArch64Algo.c
@@ -0,0 +1,72 @@
+/** @file
+ Aarch64 specific code.
+
+ Copyright (c) 2022, Arm Limited. All rights reserved.
+ SPDX-License-Identifier: BSD-2-Clause-Patent
+**/
+
+#include
+#include
+#include
+#include
+#include
+
+#include "RngDxeInternals.h"
+
+// Maximum number of Rng algorithms.
+#define RNG_AVAILABLE_ALGO_MAX 2
+
+/** Allocate and initialize mAvailableAlgoArray with the available
+Rng algorithms. Also update mAvailableAlgoArrayCount.
+
+ @retval EFI_SUCCESS The function completed successfully.
+ @retval EFI_OUT_OF_RESOURCESCould not allocate memory.
+**/
+EFI_STATUS
+EFIAPI
+GetAvailableAlgorithms (
+ VOID
+ )
+{
+ UINT64 DummyRand;
+ UINT16 MajorRevision;
+ UINT16 MinorRevision;
+
+ // Rng algorithms 2 times, one for the allocation, one to populate.
+ mAvailableAlgoArray = AllocateZeroPool (RNG_AVAILABLE_ALGO_MAX);
+ if (mAvailableAlgoArray == NULL) {
+return EFI_OUT_OF_RESOURCES;
+ }
+
+ // Check RngGetBytes() before advertising PcdCpuRngSupportedAlgorithm.
+ if (!EFI_ERROR (RngGetBytes (sizeof (DummyRand), (UINT8 *)&DummyRand))) {
+CopyMem (
+ &mAvailableAlgoArray[mAvailableAlgoArrayCount],
+ PcdGetPtr (PcdCpuRngSupportedAlgorithm),
+ sizeof (EFI_RNG_ALGORITHM)
+ );
+mAvailableAlgoArrayCount++;
+
+DEBUG_CODE_BEGIN ();
+if (IsZeroGuid (PcdGetPtr (PcdCpuRngSupportedAlgorithm))) {
+ DEBUG ((
+DEBUG_WARN,
+"PcdCpuRngSupportedAlgorithm should be a non-zero GUID\n"
+));
+}
+
+DEBUG_CODE_END ();
+ }
+
+ // Raw algorithm (Trng)
+ if (!EFI_ERROR (GetTrngVersion (&MajorRevision, &MinorRevision))) {
+CopyMem (
+ &mAvailableAlgoArray[mAvailableAlgoArrayCount],
+ &gEfiRngAlgorithmRaw,
+ sizeof (EFI_RNG_ALGORITHM)
+ );
+mAvailableAlgoArrayCount++;
+ }
+
+ return EFI_SUCCESS;
+}
diff --git a/SecurityPkg/RandomNumberGenerator/RngDxe/Arm/ArmAlgo.c
b/SecurityPkg/RandomNumberGenerator/RngDxe/Arm/ArmAlgo.c
new file mode 100644
index ..5acef91fe3b2
--- /dev/null
+++ b/SecurityPkg/RandomNumberGenerator/RngDxe/Arm/ArmAlgo.c
@@ -0,0 +1,51 @@
+/** @file
+ Arm specific code.
+
+ Copyright (c) 2022, Arm Limited. All rights reserved.
+ SPDX-License-Identifier: BSD-2-Clause-Patent
+**/
+
+#include
+#include
+#include
+#include
+#include
+
+#include "RngDxeInternals.h"
+
+// Maximum number of Rng algorithms.
+#define RNG_AVAILABLE_ALGO_MAX 1
+
+/** Allocate and initialize mAvailableAlgoArray with the available
+Rng algorithms. Also update mAvailableAlgoArrayCount.
+
+ @retval EFI_SUCCESS The function completed successfully.
+ @retval EFI_OUT_OF_RESOURCESCould not allocate memory.
+**/
+EFI_STATUS
+EFIAPI
+GetAvailableAlgorithms (
+ VOID
+ )
+{
+ UINT16 MajorRevision;
+ UINT16 MinorRevision;
+
+ // Rng algorithms 2 times, one for the allocation, one to populate.
+ mAvailableAlgoArray = AllocateZeroPool (RNG_AVAILABLE_ALGO_MAX);
+ if (mAvailableAlgoArray == NULL) {
+return EFI_OUT_OF_RESOURCES;
+ }
+
+ // Raw algorithm (Trng)
+ if (!EFI_ERROR (GetTrngVersion (&MajorRevision, &MinorRevision))) {
+CopyMem (
+ &mAvailableAlgoArray[mAvailableAlgoArrayCount],
+ &gEfiRngAlgorithmRaw,
+ sizeof (EFI_RNG_ALGORITHM)
+ );
+mAvailableAlgoArrayCount++;
+ }
+
+ return EFI_SUCCESS;
+}
diff --git a/SecurityPkg/RandomNumberGenerator/RngDxe/ArmRngDxe.c
b/SecurityPkg/RandomNumberGenerator/RngDxe/ArmRngDxe.c
index 0d853720ecb1..5ba319899ce9 100644
--- a/SecurityPkg/RandomNumberGenerat
[edk2-devel] [PATCH v7 17/19] SecurityPkg/RngDxe: Rename AArch64/RngDxe.c
From: Pierre Gondois
To re-use the AArch64/RngDxe.c for an Arm implementation,
rename AArch64/RngDxe.c to ArmRngDxe.c.
Signed-off-by: Pierre Gondois
---
.../RngDxe/{AArch64/RngDxe.c => ArmRngDxe.c}| 0
SecurityPkg/RandomNumberGenerator/RngDxe/RngDxe.inf | 2 +-
2 files changed, 1 insertion(+), 1 deletion(-)
rename SecurityPkg/RandomNumberGenerator/RngDxe/{AArch64/RngDxe.c =>
ArmRngDxe.c} (100%)
diff --git a/SecurityPkg/RandomNumberGenerator/RngDxe/AArch64/RngDxe.c
b/SecurityPkg/RandomNumberGenerator/RngDxe/ArmRngDxe.c
similarity index 100%
rename from SecurityPkg/RandomNumberGenerator/RngDxe/AArch64/RngDxe.c
rename to SecurityPkg/RandomNumberGenerator/RngDxe/ArmRngDxe.c
diff --git a/SecurityPkg/RandomNumberGenerator/RngDxe/RngDxe.inf
b/SecurityPkg/RandomNumberGenerator/RngDxe/RngDxe.inf
index f6e08da96140..337becf5224f 100644
--- a/SecurityPkg/RandomNumberGenerator/RngDxe/RngDxe.inf
+++ b/SecurityPkg/RandomNumberGenerator/RngDxe/RngDxe.inf
@@ -42,7 +42,7 @@ [Sources.IA32, Sources.X64]
Rand/AesCore.h
[Sources.AARCH64]
- AArch64/RngDxe.c
+ ArmRngDxe.c
ArmTrng.c
[Packages]
--
2.25.1
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#94652): https://edk2.groups.io/g/devel/message/94652
Mute This Topic: https://groups.io/mt/94085861/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[edk2-devel] [PATCH v7 16/19] SecurityPkg/RngDxe: Add debug warning for NULL PcdCpuRngSupportedAlgorithm
From: Pierre Gondois
PcdCpuRngSupportedAlgorithm should allow to identify the the algorithm
used by the RNDR CPU instruction to generate a random number.
Add a debug warning if the Pcd is not set.
Signed-off-by: Pierre Gondois
---
.../RandomNumberGenerator/RngDxe/AArch64/RngDxe.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/SecurityPkg/RandomNumberGenerator/RngDxe/AArch64/RngDxe.c
b/SecurityPkg/RandomNumberGenerator/RngDxe/AArch64/RngDxe.c
index f5910e3b999f..0d853720ecb1 100644
--- a/SecurityPkg/RandomNumberGenerator/RngDxe/AArch64/RngDxe.c
+++ b/SecurityPkg/RandomNumberGenerator/RngDxe/AArch64/RngDxe.c
@@ -67,6 +67,16 @@ GetAvailableAlgorithms (
sizeof (EFI_RNG_ALGORITHM)
);
mAvailableAlgoArrayCount++;
+
+DEBUG_CODE_BEGIN ();
+if (IsZeroGuid (PcdGetPtr (PcdCpuRngSupportedAlgorithm))) {
+ DEBUG ((
+DEBUG_WARN,
+"PcdCpuRngSupportedAlgorithm should be a non-zero GUID\n"
+));
+}
+
+DEBUG_CODE_END ();
}
// Raw algorithm (Trng)
--
2.25.1
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#94651): https://edk2.groups.io/g/devel/message/94651
Mute This Topic: https://groups.io/mt/94085860/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[edk2-devel] [PATCH v7 15/19] SecurityPkg/RngDxe: Add AArch64 RawAlgorithm support through TrngLib
From: Sami Mujawar
Bugzilla: 3668 (https://bugzilla.tianocore.org/show_bug.cgi?id=3668)
RawAlgorithm is used to provide access to entropy that is suitable
for cryptographic applications. Therefore, add RawAlgorithm support
that provides access to entropy using the TrngLib.
Also remove unused UefiBootServicesTableLib library inclusion
and Status variable.
Signed-off-by: Pierre Gondois
---
Notes:
v4:
- Use TrngLib from MdePkg instead of ArmPkg. This also
allows to not build ArmMonitorLib, ArmSmcLib and
ArmHvcLib. [Jiewen, Pierre]
.../RngDxe/AArch64/RngDxe.c | 28 ++--
.../RandomNumberGenerator/RngDxe/ArmTrng.c| 71 +++
.../RandomNumberGenerator/RngDxe/RngDxe.inf | 5 ++
SecurityPkg/SecurityPkg.dsc | 3 +
4 files changed, 103 insertions(+), 4 deletions(-)
create mode 100644 SecurityPkg/RandomNumberGenerator/RngDxe/ArmTrng.c
diff --git a/SecurityPkg/RandomNumberGenerator/RngDxe/AArch64/RngDxe.c
b/SecurityPkg/RandomNumberGenerator/RngDxe/AArch64/RngDxe.c
index 09a5924a699b..f5910e3b999f 100644
--- a/SecurityPkg/RandomNumberGenerator/RngDxe/AArch64/RngDxe.c
+++ b/SecurityPkg/RandomNumberGenerator/RngDxe/AArch64/RngDxe.c
@@ -1,11 +1,13 @@
/** @file
RNG Driver to produce the UEFI Random Number Generator protocol.
- The driver will use the RNDR instruction to produce random numbers.
+ The driver can use RNDR instruction (through the RngLib and if FEAT_RNG is
+ present) to produce random numbers. It also uses the Arm FW-TRNG interface
+ to implement EFI_RNG_ALGORITHM_RAW.
RNG Algorithms defined in UEFI 2.4:
- EFI_RNG_ALGORITHM_SP800_90_CTR_256_GUID
- - EFI_RNG_ALGORITHM_RAW- Unsupported
+ - EFI_RNG_ALGORITHM_RAW
- EFI_RNG_ALGORITHM_SP800_90_HMAC_256_GUID
- EFI_RNG_ALGORITHM_SP800_90_HASH_256_GUID
- EFI_RNG_ALGORITHM_X9_31_3DES_GUID- Unsupported
@@ -26,12 +28,14 @@
#include
#include
#include
+#include
+#include
#include
#include "RngDxeInternals.h"
// Maximum number of Rng algorithms.
-#define RNG_AVAILABLE_ALGO_MAX 1
+#define RNG_AVAILABLE_ALGO_MAX 2
/** Allocate and initialize mAvailableAlgoArray with the available
Rng algorithms. Also update mAvailableAlgoArrayCount.
@@ -46,8 +50,9 @@ GetAvailableAlgorithms (
)
{
UINT64 DummyRand;
+ UINT16 MajorRevision;
+ UINT16 MinorRevision;
- // Allocate RNG_AVAILABLE_ALGO_MAX entries to avoid evaluating
// Rng algorithms 2 times, one for the allocation, one to populate.
mAvailableAlgoArray = AllocateZeroPool (RNG_AVAILABLE_ALGO_MAX);
if (mAvailableAlgoArray == NULL) {
@@ -64,6 +69,16 @@ GetAvailableAlgorithms (
mAvailableAlgoArrayCount++;
}
+ // Raw algorithm (Trng)
+ if (!EFI_ERROR (GetTrngVersion (&MajorRevision, &MinorRevision))) {
+CopyMem (
+ &mAvailableAlgoArray[mAvailableAlgoArrayCount],
+ &gEfiRngAlgorithmRaw,
+ sizeof (EFI_RNG_ALGORITHM)
+ );
+mAvailableAlgoArrayCount++;
+ }
+
return EFI_SUCCESS;
}
@@ -141,6 +156,11 @@ FoundAlgo:
return Status;
}
+ // Raw algorithm (Trng)
+ if (CompareGuid (RNGAlgorithm, &gEfiRngAlgorithmRaw)) {
+return GenerateEntropy (RNGValueLength, RNGValue);
+ }
+
//
// Other algorithms are unsupported by this driver.
//
diff --git a/SecurityPkg/RandomNumberGenerator/RngDxe/ArmTrng.c
b/SecurityPkg/RandomNumberGenerator/RngDxe/ArmTrng.c
new file mode 100644
index ..6100e02b32b0
--- /dev/null
+++ b/SecurityPkg/RandomNumberGenerator/RngDxe/ArmTrng.c
@@ -0,0 +1,71 @@
+/** @file
+ RNG Driver to produce the UEFI Random Number Generator protocol.
+
+ The driver implements the EFI_RNG_ALGORITHM_RAW using the FW-TRNG
+ interface to provide entropy.
+
+ Copyright (c) 2021 - 2022, Arm Limited. All rights reserved.
+
+ SPDX-License-Identifier: BSD-2-Clause-Patent
+
+**/
+
+#include
+#include
+#include
+#include
+#include
+
+#include "RngDxeInternals.h"
+
+/**
+ Generate high-quality entropy source using a TRNG or through RDRAND.
+
+ @param[in] LengthSize of the buffer, in bytes, to fill with.
+ @param[out] Entropy Pointer to the buffer to store the entropy data.
+
+ @retval RETURN_SUCCESSThe function completed successfully.
+ @retval RETURN_INVALID_PARAMETER Invalid parameter.
+ @retval RETURN_UNSUPPORTEDFunction not implemented.
+ @retval RETURN_BAD_BUFFER_SIZEBuffer size is too small.
+ @retval RETURN_NOT_READY No Entropy available.
+**/
+EFI_STATUS
+EFIAPI
+GenerateEntropy (
+ IN UINTN Length,
+ OUT UINT8 *Entropy
+ )
+{
+ EFI_STATUS Status;
+ UINTN CollectedEntropyBits;
+ UINTN RequiredEntropyBits;
+ UINTN EntropyBits;
+ UINTN Index;
+ UINTN MaxBits;
+
+ ZeroMem (Entropy, Length);
+
+ RequiredEntropyBits = (Length << 3);
+ Index= 0;
+ CollectedEntropyBits = 0;
+ MaxBits = GetTrngMaxSupportedEntropyBits ();
+ wh
[edk2-devel] [PATCH v7 14/19] SecurityPkg/RngDxe: Check before advertising Cpu Rng algo
From: Pierre Gondois
RngGetBytes() relies on the RngLib. The RngLib might use the RNDR
instruction if the FEAT_RNG feature is present. RngGetInfo and
RngGetRNG both must check that RngGetBytes() is working before
advertising/using it.
To do so, allocate an array storing the available algorithms.
The Rng algorithm at the lowest index will be the default Rng
algorithm. The array is shared between RngGetInfo and RngGetRNG.
This array is allocated when the driver is loaded, and freed
when unloaded.
This patch also prevents from having PcdCpuRngSupportedAlgorithm
let to a zero GUID, but let the possibility to have no valid Rng
algorithm in such case.
Signed-off-by: Pierre Gondois
---
Notes:
v4:
- Replace RngInitAvailableAlgoArray() with
GetAvailableAlgorithms() and FreeAvailableAlgorithms() and
add an implementation of these functions for all archs.
- Make mAvailableAlgoArrayCount and mAvailableAlgoArray
global variable and dynamically allocated instead of static.
- Add UNLOAD_IMAGE function to free mAvailableAlgoArray.
- All of this was done in order to remove the:
'#ifdef MDE_CPU_AARCH64'
statement in the v3 of:
SecurityPkg/RngDxe: Add Arm support of RngDxe
.../RngDxe/AArch64/RngDxe.c | 87 +--
.../RngDxe/Rand/RngDxe.c | 26 ++
.../RandomNumberGenerator/RngDxe/RngDxe.c | 40 -
.../RandomNumberGenerator/RngDxe/RngDxe.inf | 1 +
.../RngDxe/RngDxeInternals.h | 27 ++
5 files changed, 172 insertions(+), 9 deletions(-)
diff --git a/SecurityPkg/RandomNumberGenerator/RngDxe/AArch64/RngDxe.c
b/SecurityPkg/RandomNumberGenerator/RngDxe/AArch64/RngDxe.c
index f9c740d761ff..09a5924a699b 100644
--- a/SecurityPkg/RandomNumberGenerator/RngDxe/AArch64/RngDxe.c
+++ b/SecurityPkg/RandomNumberGenerator/RngDxe/AArch64/RngDxe.c
@@ -22,11 +22,63 @@
#include
#include
+#include
+#include
#include
+#include
#include
#include "RngDxeInternals.h"
+// Maximum number of Rng algorithms.
+#define RNG_AVAILABLE_ALGO_MAX 1
+
+/** Allocate and initialize mAvailableAlgoArray with the available
+Rng algorithms. Also update mAvailableAlgoArrayCount.
+
+ @retval EFI_SUCCESS The function completed successfully.
+ @retval EFI_OUT_OF_RESOURCESCould not allocate memory.
+**/
+EFI_STATUS
+EFIAPI
+GetAvailableAlgorithms (
+ VOID
+ )
+{
+ UINT64 DummyRand;
+
+ // Allocate RNG_AVAILABLE_ALGO_MAX entries to avoid evaluating
+ // Rng algorithms 2 times, one for the allocation, one to populate.
+ mAvailableAlgoArray = AllocateZeroPool (RNG_AVAILABLE_ALGO_MAX);
+ if (mAvailableAlgoArray == NULL) {
+return EFI_OUT_OF_RESOURCES;
+ }
+
+ // Check RngGetBytes() before advertising PcdCpuRngSupportedAlgorithm.
+ if (!EFI_ERROR (RngGetBytes (sizeof (DummyRand), (UINT8 *)&DummyRand))) {
+CopyMem (
+ &mAvailableAlgoArray[mAvailableAlgoArrayCount],
+ PcdGetPtr (PcdCpuRngSupportedAlgorithm),
+ sizeof (EFI_RNG_ALGORITHM)
+ );
+mAvailableAlgoArrayCount++;
+ }
+
+ return EFI_SUCCESS;
+}
+
+/** Free mAvailableAlgoArray.
+**/
+VOID
+EFIAPI
+FreeAvailableAlgorithms (
+ VOID
+ )
+{
+ FreePool (mAvailableAlgoArray);
+ return;
+}
+
/**
Produces and returns an RNG value using either the default or specified RNG
algorithm.
@@ -59,6 +111,7 @@ RngGetRNG (
)
{
EFI_STATUS Status;
+ UINTN Index;
if ((This == NULL) || (RNGValueLength == 0) || (RNGValue == NULL)) {
return EFI_INVALID_PARAMETER;
@@ -68,9 +121,21 @@ RngGetRNG (
//
// Use the default RNG algorithm if RNGAlgorithm is NULL.
//
-RNGAlgorithm = PcdGetPtr (PcdCpuRngSupportedAlgorithm);
+for (Index = 0; Index < mAvailableAlgoArrayCount; Index++) {
+ if (!IsZeroGuid (&mAvailableAlgoArray[Index])) {
+RNGAlgorithm = &mAvailableAlgoArray[Index];
+goto FoundAlgo;
+ }
+}
+
+if (Index == mAvailableAlgoArrayCount) {
+ // No algorithm available.
+ ASSERT (Index != mAvailableAlgoArrayCount);
+ return EFI_DEVICE_ERROR;
+}
}
+FoundAlgo:
if (CompareGuid (RNGAlgorithm, PcdGetPtr (PcdCpuRngSupportedAlgorithm))) {
Status = RngGetBytes (RNGValueLength, RNGValue);
return Status;
@@ -113,24 +178,30 @@ RngGetInfo (
OUT EFI_RNG_ALGORITHM *RNGAlgorithmList
)
{
- UINTN RequiredSize;
- EFI_RNG_ALGORITHM *CpuRngSupportedAlgorithm;
-
- RequiredSize = sizeof (EFI_RNG_ALGORITHM);
+ UINTN RequiredSize;
if ((This == NULL) || (RNGAlgorithmListSize == NULL)) {
return EFI_INVALID_PARAMETER;
}
+ RequiredSize = mAvailableAlgoArrayCount * sizeof (EFI_RNG_ALGORITHM);
+
+ if (RequiredSize == 0) {
+// No supported algorithms found.
+return EFI_UNSUPPORTED;
+ }
+
if (*RNGAlgorithmListSize < RequiredSize) {
*RNGAlgorithmListSize = RequiredSize;
return EFI_BUFFER_TOO_SMALL;
}
- CpuRngSupportedAlgorithm = PcdGetPtr (PcdCpuRn
[edk2-devel] [PATCH v7 13/19] SecurityPkg/RngDxe: Documentation/include/parameter cleanup
From: Pierre Gondois
This patch:
-Update RngGetBytes() documentation to align the function
definition and declaration.
-Improve input parameter checking. Even though 'This'
it is not used, the parameter should always point to the
current EFI_RNG_PROTOCOL.
-Removes TimerLib inclusion as unused.
Signed-off-by: Pierre Gondois
---
SecurityPkg/RandomNumberGenerator/RngDxe/AArch64/RngDxe.c | 3 +--
SecurityPkg/RandomNumberGenerator/RngDxe/Rand/RngDxe.c| 2 +-
SecurityPkg/RandomNumberGenerator/RngDxe/RngDxe.c | 3 +--
3 files changed, 3 insertions(+), 5 deletions(-)
diff --git a/SecurityPkg/RandomNumberGenerator/RngDxe/AArch64/RngDxe.c
b/SecurityPkg/RandomNumberGenerator/RngDxe/AArch64/RngDxe.c
index 6d989f7ea376..f9c740d761ff 100644
--- a/SecurityPkg/RandomNumberGenerator/RngDxe/AArch64/RngDxe.c
+++ b/SecurityPkg/RandomNumberGenerator/RngDxe/AArch64/RngDxe.c
@@ -23,7 +23,6 @@
#include
#include
#include
-#include
#include
#include "RngDxeInternals.h"
@@ -61,7 +60,7 @@ RngGetRNG (
{
EFI_STATUS Status;
- if ((RNGValueLength == 0) || (RNGValue == NULL)) {
+ if ((This == NULL) || (RNGValueLength == 0) || (RNGValue == NULL)) {
return EFI_INVALID_PARAMETER;
}
diff --git a/SecurityPkg/RandomNumberGenerator/RngDxe/Rand/RngDxe.c
b/SecurityPkg/RandomNumberGenerator/RngDxe/Rand/RngDxe.c
index b2d2236380fd..8f5d8e740f5e 100644
--- a/SecurityPkg/RandomNumberGenerator/RngDxe/Rand/RngDxe.c
+++ b/SecurityPkg/RandomNumberGenerator/RngDxe/Rand/RngDxe.c
@@ -59,7 +59,7 @@ RngGetRNG (
{
EFI_STATUS Status;
- if ((RNGValueLength == 0) || (RNGValue == NULL)) {
+ if ((This == NULL) || (RNGValueLength == 0) || (RNGValue == NULL)) {
return EFI_INVALID_PARAMETER;
}
diff --git a/SecurityPkg/RandomNumberGenerator/RngDxe/RngDxe.c
b/SecurityPkg/RandomNumberGenerator/RngDxe/RngDxe.c
index 6608ca8804a5..d7905a7f4d72 100644
--- a/SecurityPkg/RandomNumberGenerator/RngDxe/RngDxe.c
+++ b/SecurityPkg/RandomNumberGenerator/RngDxe/RngDxe.c
@@ -23,7 +23,6 @@ SPDX-License-Identifier: BSD-2-Clause-Patent
#include
#include
#include
-#include
#include
#include "RngDxeInternals.h"
@@ -72,7 +71,7 @@ RngDriverEntry (
}
/**
- Calls RDRAND to fill a buffer of arbitrary size with random bytes.
+ Runs CPU RNG instruction to fill a buffer of arbitrary size with random
bytes.
@param[in] LengthSize of the buffer, in bytes, to fill with.
@param[out] RandBufferPointer to the buffer to store the random result.
--
2.25.1
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#94648): https://edk2.groups.io/g/devel/message/94648
Mute This Topic: https://groups.io/mt/94085857/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[edk2-devel] [PATCH v7 12/19] SecurityPkg/RngDxe: Remove ArchGetSupportedRngAlgorithms()
From: Pierre Gondois
RngGetInfo() is one of the 2 functions of the EFI_RNG_PROTOCOL.
RngGetInfo() is currently a mere wrapper around
ArchGetSupportedRngAlgorithms() which is implemented differently
depending on the architecture used.
RngGetInfo() does nothing more than calling
ArchGetSupportedRngAlgorithms(). So remove it, and let RngGetInfo()
be implemented differently according to the architecture.
This follows the implementation of the other function of the
EFI_RNG_PROTOCOL, RngGetRNG().
Signed-off-by: Pierre Gondois
---
.../RngDxe/AArch64/RngDxe.c | 19 +--
.../RngDxe/Rand/RngDxe.c | 22 +++--
.../RandomNumberGenerator/RngDxe/RngDxe.c | 49 ---
.../RngDxe/RngDxeInternals.h | 25 --
4 files changed, 33 insertions(+), 82 deletions(-)
diff --git a/SecurityPkg/RandomNumberGenerator/RngDxe/AArch64/RngDxe.c
b/SecurityPkg/RandomNumberGenerator/RngDxe/AArch64/RngDxe.c
index 3daf847d46d3..6d989f7ea376 100644
--- a/SecurityPkg/RandomNumberGenerator/RngDxe/AArch64/RngDxe.c
+++ b/SecurityPkg/RandomNumberGenerator/RngDxe/AArch64/RngDxe.c
@@ -14,6 +14,7 @@
Copyright (c) 2021, NUVIA Inc. All rights reserved.
Copyright (c) 2013 - 2018, Intel Corporation. All rights reserved.
(C) Copyright 2015 Hewlett Packard Enterprise Development LP
+ Copyright (c) 2021 - 2022, Arm Limited. All rights reserved.
SPDX-License-Identifier: BSD-2-Clause-Patent
@@ -85,6 +86,7 @@ RngGetRNG (
/**
Returns information about the random number generation implementation.
+ @param[in] This A pointer to the EFI_RNG_PROTOCOL
instance.
@param[in,out] RNGAlgorithmListSize On input, the size in bytes of
RNGAlgorithmList.
On output with a return code of
EFI_SUCCESS, the size
in bytes of the data returned in
RNGAlgorithmList. On output
@@ -97,14 +99,19 @@ RngGetRNG (
is the default algorithm for the driver.
@retval EFI_SUCCESS The RNG algorithm list was returned
successfully.
+ @retval EFI_UNSUPPORTED The services is not supported by this
driver.
+ @retval EFI_DEVICE_ERRORThe list of algorithms could not be
retrieved due to a
+ hardware or firmware error.
+ @retval EFI_INVALID_PARAMETER One or more of the parameters are
incorrect.
@retval EFI_BUFFER_TOO_SMALLThe buffer RNGAlgorithmList is too small
to hold the result.
**/
-UINTN
+EFI_STATUS
EFIAPI
-ArchGetSupportedRngAlgorithms (
- IN OUT UINTN *RNGAlgorithmListSize,
- OUTEFI_RNG_ALGORITHM *RNGAlgorithmList
+RngGetInfo (
+ IN EFI_RNG_PROTOCOL*This,
+ IN OUT UINTN *RNGAlgorithmListSize,
+ OUT EFI_RNG_ALGORITHM *RNGAlgorithmList
)
{
UINTN RequiredSize;
@@ -112,6 +119,10 @@ ArchGetSupportedRngAlgorithms (
RequiredSize = sizeof (EFI_RNG_ALGORITHM);
+ if ((This == NULL) || (RNGAlgorithmListSize == NULL)) {
+return EFI_INVALID_PARAMETER;
+ }
+
if (*RNGAlgorithmListSize < RequiredSize) {
*RNGAlgorithmListSize = RequiredSize;
return EFI_BUFFER_TOO_SMALL;
diff --git a/SecurityPkg/RandomNumberGenerator/RngDxe/Rand/RngDxe.c
b/SecurityPkg/RandomNumberGenerator/RngDxe/Rand/RngDxe.c
index df7db12b771c..b2d2236380fd 100644
--- a/SecurityPkg/RandomNumberGenerator/RngDxe/Rand/RngDxe.c
+++ b/SecurityPkg/RandomNumberGenerator/RngDxe/Rand/RngDxe.c
@@ -104,6 +104,7 @@ RngGetRNG (
/**
Returns information about the random number generation implementation.
+ @param[in] This A pointer to the EFI_RNG_PROTOCOL
instance.
@param[in,out] RNGAlgorithmListSize On input, the size in bytes of
RNGAlgorithmList.
On output with a return code of
EFI_SUCCESS, the size
in bytes of the data returned in
RNGAlgorithmList. On output
@@ -116,18 +117,27 @@ RngGetRNG (
is the default algorithm for the driver.
@retval EFI_SUCCESS The RNG algorithm list was returned
successfully.
+ @retval EFI_UNSUPPORTED No supported algorithms found.
+ @retval EFI_DEVICE_ERRORThe list of algorithms could not be
retrieved due to a
+ hardware or firmware error.
+ @retval EFI_INVALID_PARAMETER One or more of the parameters are
incorrect.
@retval EFI_BUFFER_TOO_SMALLThe buffer RNGAlgorithmList is too small
to hold the result.
**/
-UINTN
+EFI_STATUS
EFIAPI
-ArchGetSupportedRngAlgorithms (
- IN OUT UINTN *RNGAlgorithmListSize,
- OUTEFI_RNG_ALGORITHM *RNGAlgorithmList
+RngGetInfo (
+ IN EFI_RNG_PROTOCOL*This,
+ IN OUT UINTN *RNGAlgorithmListSize,
+ OUT EFI_RNG_ALGORITHM *RNGAlgorithmList
)
{
UINTN RequiredSize;
+
[edk2-devel] [PATCH v7 11/19] SecurityPkg/RngDxe: Replace Pcd with Sp80090Ctr256Guid
From: Pierre Gondois
gEfiRngAlgorithmSp80090Ctr256Guid was used as the default algorithm
in RngGetRNG(). The commit below set the default algorithm to
PcdCpuRngSupportedAlgorithm, which is a zero GUID by default.
As the Pcd value is not defined for any platform in the edk2-platfoms
repository, assume it was an error and go back to the first version,
using gEfiRngAlgorithmSp80090Ctr256Guid.
Fixes 4e5ecdbac8bd ("SecurityPkg: Add support for RngDxe on AARCH64")
Signed-off-by: Pierre Gondois
---
Notes:
v4:
- Fix: Correctly reference gEfiRngAlgorithmSp80090Ctr256Guid
Guid by copying its address (add missing '&'). [Jiewen]
SecurityPkg/RandomNumberGenerator/RngDxe/Rand/RngDxe.c | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/SecurityPkg/RandomNumberGenerator/RngDxe/Rand/RngDxe.c
b/SecurityPkg/RandomNumberGenerator/RngDxe/Rand/RngDxe.c
index 8d44f0636c3d..df7db12b771c 100644
--- a/SecurityPkg/RandomNumberGenerator/RngDxe/Rand/RngDxe.c
+++ b/SecurityPkg/RandomNumberGenerator/RngDxe/Rand/RngDxe.c
@@ -126,8 +126,7 @@ ArchGetSupportedRngAlgorithms (
OUTEFI_RNG_ALGORITHM *RNGAlgorithmList
)
{
- UINTN RequiredSize;
- EFI_RNG_ALGORITHM *CpuRngSupportedAlgorithm;
+ UINTN RequiredSize;
RequiredSize = 2 * sizeof (EFI_RNG_ALGORITHM);
@@ -136,9 +135,7 @@ ArchGetSupportedRngAlgorithms (
return EFI_BUFFER_TOO_SMALL;
}
- CpuRngSupportedAlgorithm = PcdGetPtr (PcdCpuRngSupportedAlgorithm);
-
- CopyMem (&RNGAlgorithmList[0], CpuRngSupportedAlgorithm, sizeof
(EFI_RNG_ALGORITHM));
+ CopyMem (&RNGAlgorithmList[0], &gEfiRngAlgorithmSp80090Ctr256Guid, sizeof
(EFI_RNG_ALGORITHM));
// x86 platforms also support EFI_RNG_ALGORITHM_RAW via RDSEED
CopyMem (&RNGAlgorithmList[1], &gEfiRngAlgorithmRaw, sizeof
(EFI_RNG_ALGORITHM));
--
2.25.1
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#94646): https://edk2.groups.io/g/devel/message/94646
Mute This Topic: https://groups.io/mt/94085855/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[edk2-devel] [PATCH v7 10/19] SecurityPkg/RngDxe: Rename RdRandGenerateEntropy to generic name
From: Sami Mujawar Bugzilla: 3668 (https://bugzilla.tianocore.org/show_bug.cgi?id=3668) Rename RdRandGenerateEntropy() to GenerateEntropy() to provide a common interface to generate entropy on other architectures. GenerateEntropy() is intended to generate high quality entropy. Also move the definition to RngDxeInternals.h Signed-off-by: Pierre Gondois --- .../RngDxe/Rand/RdRand.c | 14 -- .../RngDxe/Rand/RdRand.h | 43 --- .../RngDxe/Rand/RngDxe.c | 7 ++- .../RandomNumberGenerator/RngDxe/RngDxe.inf | 2 +- .../RngDxe/RngDxeInternals.h | 19 5 files changed, 36 insertions(+), 49 deletions(-) delete mode 100644 SecurityPkg/RandomNumberGenerator/RngDxe/Rand/RdRand.h diff --git a/SecurityPkg/RandomNumberGenerator/RngDxe/Rand/RdRand.c b/SecurityPkg/RandomNumberGenerator/RngDxe/Rand/RdRand.c index 5b6644138231..4b011c7e8e49 100644 --- a/SecurityPkg/RandomNumberGenerator/RngDxe/Rand/RdRand.c +++ b/SecurityPkg/RandomNumberGenerator/RngDxe/Rand/RdRand.c @@ -1,15 +1,23 @@ /** @file - Support routines for RDRAND instruction access. + Support routines for RDRAND instruction access, which will leverage + Intel Secure Key technology to provide high-quality random numbers for use + in applications, or entropy for seeding other random number generators. + Refer to http://software.intel.com/en-us/articles/intel-digital-random-number + -generator-drng-software-implementation-guide/ for more information about Intel + Secure Key technology. +Copyright (c) 2021 - 2022, Arm Limited. All rights reserved. Copyright (c) 2013 - 2018, Intel Corporation. All rights reserved. (C) Copyright 2015 Hewlett Packard Enterprise Development LP SPDX-License-Identifier: BSD-2-Clause-Patent **/ +#include +#include #include +#include #include "AesCore.h" -#include "RdRand.h" #include "RngDxeInternals.h" /** @@ -87,7 +95,7 @@ RdRandGetSeed128 ( **/ EFI_STATUS EFIAPI -RdRandGenerateEntropy ( +GenerateEntropy ( IN UINTN Length, OUT UINT8 *Entropy ) diff --git a/SecurityPkg/RandomNumberGenerator/RngDxe/Rand/RdRand.h b/SecurityPkg/RandomNumberGenerator/RngDxe/Rand/RdRand.h deleted file mode 100644 index 7fdb6891bd63.. --- a/SecurityPkg/RandomNumberGenerator/RngDxe/Rand/RdRand.h +++ /dev/null @@ -1,43 +0,0 @@ -/** @file - Header for the RDRAND APIs used by RNG DXE driver. - - Support API definitions for RDRAND instruction access, which will leverage - Intel Secure Key technology to provide high-quality random numbers for use - in applications, or entropy for seeding other random number generators. - Refer to http://software.intel.com/en-us/articles/intel-digital-random-number - -generator-drng-software-implementation-guide/ for more information about Intel - Secure Key technology. - -Copyright (c) 2013, Intel Corporation. All rights reserved. -(C) Copyright 2015 Hewlett Packard Enterprise Development LP -SPDX-License-Identifier: BSD-2-Clause-Patent - -**/ - -#ifndef __RD_RAND_H__ -#define __RD_RAND_H__ - -#include -#include -#include -#include -#include - -/** - Generate high-quality entropy source through RDRAND. - - @param[in] LengthSize of the buffer, in bytes, to fill with. - @param[out] Entropy Pointer to the buffer to store the entropy data. - - @retval EFI_SUCCESSEntropy generation succeeded. - @retval EFI_NOT_READY Failed to request random data. - -**/ -EFI_STATUS -EFIAPI -RdRandGenerateEntropy ( - IN UINTN Length, - OUT UINT8 *Entropy - ); - -#endif // __RD_RAND_H__ diff --git a/SecurityPkg/RandomNumberGenerator/RngDxe/Rand/RngDxe.c b/SecurityPkg/RandomNumberGenerator/RngDxe/Rand/RngDxe.c index 2df4ed44329a..8d44f0636c3d 100644 --- a/SecurityPkg/RandomNumberGenerator/RngDxe/Rand/RngDxe.c +++ b/SecurityPkg/RandomNumberGenerator/RngDxe/Rand/RngDxe.c @@ -14,13 +14,16 @@ - EFI_RNG_ALGORITHM_X9_31_3DES_GUID- Unsupported - EFI_RNG_ALGORITHM_X9_31_AES_GUID - Unsupported + Copyright (c) 2021 - 2022, Arm Limited. All rights reserved. Copyright (c) 2013 - 2018, Intel Corporation. All rights reserved. (C) Copyright 2015 Hewlett Packard Enterprise Development LP SPDX-License-Identifier: BSD-2-Clause-Patent **/ -#include "RdRand.h" +#include +#include + #include "RngDxeInternals.h" /** @@ -88,7 +91,7 @@ RngGetRNG ( return EFI_INVALID_PARAMETER; } -Status = RdRandGenerateEntropy (RNGValueLength, RNGValue); +Status = GenerateEntropy (RNGValueLength, RNGValue); return Status; } diff --git a/SecurityPkg/RandomNumberGenerator/RngDxe/RngDxe.inf b/SecurityPkg/RandomNumberGenerator/RngDxe/RngDxe.inf index f3300971993f..60efb5562ee0 100644 --- a/SecurityPkg/RandomNumberGenerator/RngDxe/RngDxe.inf +++ b/SecurityPkg/RandomNumberGenerator/RngDxe/RngDxe.inf @@ -10,6 +10,7 @@ # # Copyright (c) 2013 - 2018, Intel Corporation. All rights reserved. # (C) Cop
[edk2-devel] [PATCH v7 09/19] ArmPkg/TrngLib: Add Arm Firmware TRNG library
From: Sami Mujawar
Bugzilla: 3668 (https://bugzilla.tianocore.org/show_bug.cgi?id=3668)
The Arm True Random Number Generator Firmware, Interface 1.0,
Platform Design Document
(https://developer.arm.com/documentation/den0098/latest/)
defines an interface between an Operating System (OS) executing
at EL1 and Firmware (FW) exposing a conditioned entropy source
that is provided by a TRNG back end.
The conditioned entropy, that is provided by the TRNG FW interface,
is commonly used to seed deterministic random number generators.
This patch adds a TrngLib library that implements the Arm TRNG
firmware interface.
Signed-off-by: Pierre Gondois
---
ArmPkg/ArmPkg.dsc| 1 +
ArmPkg/Library/ArmFwTrngLib/ArmFwTrngDefs.h | 50 +++
ArmPkg/Library/ArmFwTrngLib/ArmFwTrngLib.c | 388 +++
ArmPkg/Library/ArmFwTrngLib/ArmFwTrngLib.inf | 29 ++
4 files changed, 468 insertions(+)
create mode 100644 ArmPkg/Library/ArmFwTrngLib/ArmFwTrngDefs.h
create mode 100644 ArmPkg/Library/ArmFwTrngLib/ArmFwTrngLib.c
create mode 100644 ArmPkg/Library/ArmFwTrngLib/ArmFwTrngLib.inf
diff --git a/ArmPkg/ArmPkg.dsc b/ArmPkg/ArmPkg.dsc
index 11b473974463..8726989bc73d 100644
--- a/ArmPkg/ArmPkg.dsc
+++ b/ArmPkg/ArmPkg.dsc
@@ -131,6 +131,7 @@ [Components.common]
ArmPkg/Library/ArmGenericTimerPhyCounterLib/ArmGenericTimerPhyCounterLib.inf
ArmPkg/Library/ArmGenericTimerVirtCounterLib/ArmGenericTimerVirtCounterLib.inf
+ ArmPkg/Library/ArmFwTrngLib/ArmFwTrngLib.inf
ArmPkg/Library/ArmHvcLib/ArmHvcLib.inf
ArmPkg/Library/ArmHvcLibNull/ArmHvcLibNull.inf
ArmPkg/Library/ArmMonitorLib/ArmMonitorLib.inf
diff --git a/ArmPkg/Library/ArmFwTrngLib/ArmFwTrngDefs.h
b/ArmPkg/Library/ArmFwTrngLib/ArmFwTrngDefs.h
new file mode 100644
index ..150c89fe7969
--- /dev/null
+++ b/ArmPkg/Library/ArmFwTrngLib/ArmFwTrngDefs.h
@@ -0,0 +1,50 @@
+/** @file
+ Arm Firmware TRNG definitions.
+
+ Copyright (c) 2021 - 2022, Arm Limited. All rights reserved.
+
+ SPDX-License-Identifier: BSD-2-Clause-Patent
+
+ @par Reference(s):
+ - [1] Arm True Random Number Generator Firmware, Interface 1.0,
+Platform Design Document.
+(https://developer.arm.com/documentation/den0098/latest/)
+
+ @par Glossary:
+- TRNG - True Random Number Generator
+- FID - Function ID
+**/
+
+#ifndef ARM_FW_TRNG_DEFS_H_
+#define ARM_FW_TRNG_DEFS_H_
+
+#include
+
+// Firmware TRNG revision mask and shift
+#define TRNG_REV_MAJOR_MASK 0x7FFF
+#define TRNG_REV_MINOR_MASK 0x
+#define TRNG_REV_MAJOR_SHIFT 16
+
+#if defined (MDE_CPU_ARM)
+
+/** FID to use on AArch32 platform to request entropy.
+*/
+#define FID_TRNG_RND FID_TRNG_RND_AARCH32
+
+/** Maximum bits of entropy supported on AArch32.
+*/
+#define MAX_ENTROPY_BITS 96
+#elif defined (MDE_CPU_AARCH64)
+
+/** FID to use on AArch64 platform to request entropy.
+*/
+#define FID_TRNG_RND FID_TRNG_RND_AARCH64
+
+/** Maximum bits of entropy supported on AArch64.
+*/
+#define MAX_ENTROPY_BITS 192
+#else
+ #error "Firmware TRNG not supported. Unknown chipset."
+#endif
+
+#endif // ARM_FW_TRNG_DEFS_H_
diff --git a/ArmPkg/Library/ArmFwTrngLib/ArmFwTrngLib.c
b/ArmPkg/Library/ArmFwTrngLib/ArmFwTrngLib.c
new file mode 100644
index ..df4c59ce7736
--- /dev/null
+++ b/ArmPkg/Library/ArmFwTrngLib/ArmFwTrngLib.c
@@ -0,0 +1,388 @@
+/** @file
+ Arm Firmware TRNG interface library.
+
+ Copyright (c) 2021 - 2022, Arm Limited. All rights reserved.
+
+ SPDX-License-Identifier: BSD-2-Clause-Patent
+
+ @par Reference(s):
+ - [1] NIST Special Publication 800-90B, Recommendation for the Entropy
+Sources Used for Random Bit Generation.
+(https://csrc.nist.gov/publications/detail/sp/800-90b/final)
+ - [2] Arm True Random Number Generator Firmware, Interface 1.0,
+Platform Design Document.
+(https://developer.arm.com/documentation/den0098/latest/)
+
+ @par Glossary:
+- TRNG - True Random Number Generator
+- FID - Function ID
+**/
+
+#include
+#include
+#include
+#include
+#include
+
+#include "ArmFwTrngDefs.h"
+
+/** Convert TRNG status codes to RETURN status codes.
+
+ @param [in] TrngStatusTRNG status code.
+
+ @retval RETURN_SUCCESSSuccess.
+ @retval RETURN_UNSUPPORTEDFunction not implemented or
+ negative return code.
+ @retval RETURN_INVALID_PARAMETER A parameter is invalid.
+ @retval RETURN_NOT_READY No Entropy available.
+**/
+STATIC
+RETURN_STATUS
+TrngStatusToReturnStatus (
+ IN INT32 TrngStatus
+ )
+{
+ switch (TrngStatus) {
+case TRNG_STATUS_NOT_SUPPORTED:
+ return RETURN_UNSUPPORTED;
+
+case TRNG_STATUS_INVALID_PARAMETER:
+ return RETURN_INVALID_PARAMETER;
+
+case TRNG_STATUS_NO_ENTROPY:
+ return RETURN_NOT_READY;
+
+case TRNG_STATUS_SUCCESS:
+ return RETURN_SUCCESS;
+
+default:
+ if (TrngStatus < 0) {
+return RETURN_UNSUPPORTED;
+ }
+
+ ret
[edk2-devel] [PATCH v7 08/19] ArmPkg: Add FID definitions for Firmware TRNG
From: Sami Mujawar Bugzilla: 3668 (https://bugzilla.tianocore.org/show_bug.cgi?id=3668) The Arm True Random Number Generator Firmware, Interface 1.0, Platform Design Document (https://developer.arm.com/documentation/den0098/latest/) defines an interface between an Operating System (OS) executing at EL1 and Firmware (FW) exposing a conditioned entropy source that is provided by a TRNG back end. New function IDs have been defined by the specification for accessing the TRNG services. Therefore, add these definitions to the Arm standard SMC header. Signed-off-by: Pierre Gondois --- ArmPkg/Include/IndustryStandard/ArmStdSmc.h | 109 +++- 1 file changed, 107 insertions(+), 2 deletions(-) diff --git a/ArmPkg/Include/IndustryStandard/ArmStdSmc.h b/ArmPkg/Include/IndustryStandard/ArmStdSmc.h index 78ce77cd734d..fa977a03a7ab 100644 --- a/ArmPkg/Include/IndustryStandard/ArmStdSmc.h +++ b/ArmPkg/Include/IndustryStandard/ArmStdSmc.h @@ -1,13 +1,20 @@ /** @file * * Copyright (c) 2020, NUVIA Inc. All rights reserved. -* Copyright (c) 2012-2017, ARM Limited. All rights reserved. +* Copyright (c) 2012 - 2022, Arm Limited. All rights reserved. * * SPDX-License-Identifier: BSD-2-Clause-Patent * * @par Revision Reference: -* - SMC Calling Convention version 1.2 +* - [1] SMC Calling Convention version 1.2 *(https://developer.arm.com/documentation/den0028/c/?lang=en) +* - [2] Arm True Random Number Generator Firmware, Interface 1.0, +*Platform Design Document. +*(https://developer.arm.com/documentation/den0098/latest/) +* +* @par Glossary: +*- TRNG - True Random Number Generator +* **/ #ifndef ARM_STD_SMC_H_ @@ -139,4 +146,102 @@ /*0xbf00ff02 is reserved */ #define ARM_SMC_ID_TOS_REVISION 0xbf00ff03 +// Firmware TRNG interface Function IDs + +/* + SMC/HVC call to get the version of the TRNG backend, + Cf. [2], 2.1 TRNG_VERSION + Input values: +W00x8400_0050 +W1-W7 Reserved (MBZ) + Return values: +Success (W0 > 0) W0[31] MBZ + W0[30:16] Major revision + W0[15:0] Minor revision + W1 - W3 Reserved (MBZ) +Error (W0 < 0) + NOT_SUPPORTED Function not implemented +*/ +#define FID_TRNG_VERSION 0x8450 + +/* + SMC/HVC call to check if a TRNG function ID is implemented by the backend, + Cf. [2], Section 2.2 TRNG_FEATURES + Input Values +W00x8400_0051 +W1trng_func_id +W2-W7 Reserved (MBZ) + Return values: +Success (W0 >= 0): + SUCCESS Function is implemented. +> 0 Function is implemented and +has specific capabilities, +see function definition. +Error (W0 < 0) + NOT_SUPPORTED Function with FID=trng_func_id + is not implemented +*/ +#define FID_TRNG_FEATURES 0x8451 + +/* + SMC/HVC call to get the UUID of the TRNG backend, + Cf. [2], Section 2.3 TRNG_GET_UUID + Input Values: +W00x8400_0052 +W1-W7 Reserved (MBZ) + Return Values: +Success (W0 != -1) +W0 UUID[31:0] +W1 UUID[63:32] +W2 UUID[95:64] +W3 UUID[127:96] +Error (W0 = -1) +W0 NOT_SUPPORTED +*/ +#define FID_TRNG_GET_UUID 0x8452 + +/* + AARCH32 SMC/HVC call to get entropy bits, Cf. [2], Section 2.4 TRNG_RND. + Input values: +W00x8400_0053 +W2-W7 Reserved (MBZ) + Return values: +Success (W0 = 0): + W0 MBZ + W1 Entropy[95:64] + W2 Entropy[63:32] + W3 Entropy[31:0] +Error (W0 < 0) + W0 NOT_SUPPORTED + NO_ENTROPY + INVALID_PARAMETERS + W1 - W3 Reserved (MBZ) +*/ +#define FID_TRNG_RND_AARCH32 0x8453 + +/* + AARCH64 SMC/HVC call to get entropy bits, Cf. [2], Section 2.4 TRNG_RND. + Input values: + X00xC400_0053 + X2-X7 Reserved (MBZ) + Return values: +Success (X0 = 0): + X0 MBZ + X1 Entropy[191:128] + X2 Entropy[127:64] + X3 Entropy[63:0] +Error (X0 < 0) + X0 NOT_SUPPORTED + NO_ENTROPY + INVALID_PARAMETERS + X1 - X3 Reserved (MBZ) +*/ +#define FID_TRNG_RND_AARCH64 0xC453 + +// Firmware TRNG status codes +#define TRNG_STATUS_SUCCESS(INT32)(0) +#define TRNG_STATUS_NOT_SUPPORTED (INT32)(-1) +#define TRNG_STATUS_INVALID_PARAMETER (INT32)(-2) +#define TRNG_STATUS_NO_ENTROPY (INT32)(-3) + #endif // ARM_STD_SMC_H_ -- 2.25.1 -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#94643): https://edk2.groups.io/g/devel/message/94643 Mute This Topic: https://groups.io/mt/94085852/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[edk2-devel] [PATCH v7 07/19] MdePkg/TrngLib: Add NULL instance of TRNG Library
From: Sami Mujawar
Bugzilla: 3668 (https://bugzilla.tianocore.org/show_bug.cgi?id=3668)
The True Random Number Generator (TRNG) library defines an
interface to access the entropy source on a platform. On
platforms that do not have access to an entropy source, a
NULL instance of the TRNG library may be useful to satisfy
the build dependency.
Therefore, add a NULL instance of the TRNG library.
Signed-off-by: Pierre Gondois
---
.../Library/BaseTrngLibNull/BaseTrngLibNull.c | 117 ++
.../BaseTrngLibNull/BaseTrngLibNull.inf | 30 +
.../BaseTrngLibNull/BaseTrngLibNull.uni | 12 ++
MdePkg/MdePkg.dsc | 1 +
4 files changed, 160 insertions(+)
create mode 100644 MdePkg/Library/BaseTrngLibNull/BaseTrngLibNull.c
create mode 100644 MdePkg/Library/BaseTrngLibNull/BaseTrngLibNull.inf
create mode 100644 MdePkg/Library/BaseTrngLibNull/BaseTrngLibNull.uni
diff --git a/MdePkg/Library/BaseTrngLibNull/BaseTrngLibNull.c
b/MdePkg/Library/BaseTrngLibNull/BaseTrngLibNull.c
new file mode 100644
index ..60774b33dd58
--- /dev/null
+++ b/MdePkg/Library/BaseTrngLibNull/BaseTrngLibNull.c
@@ -0,0 +1,117 @@
+/** @file
+ Null version of TRNG (True Random Number Generator) services.
+
+ Copyright (c) 2021 - 2022, Arm Limited. All rights reserved.
+
+ SPDX-License-Identifier: BSD-2-Clause-Patent
+
+ @par Reference(s):
+ - [1] NIST Special Publication 800-90B, Recommendation for the Entropy
+Sources Used for Random Bit Generation.
+(https://csrc.nist.gov/publications/detail/sp/800-90b/final)
+
+ @par Glossary:
+- TRNG - True Random Number Generator
+**/
+
+#include
+#include
+
+/** Get the version of the TRNG backend.
+
+ A TRNG may be implemented by the system firmware, in which case this
+ function shall return the version of the TRNG backend.
+ The implementation must return NOT_SUPPORTED if a Back end is not present.
+
+ @param [out] MajorRevision Major revision.
+ @param [out] MinorRevision Minor revision.
+
+ @retval RETURN_SUCCESSThe function completed successfully.
+ @retval RETURN_INVALID_PARAMETER Invalid parameter.
+ @retval RETURN_UNSUPPORTEDBackend not present.
+**/
+RETURN_STATUS
+EFIAPI
+GetTrngVersion (
+ OUT UINT16 *MajorRevision,
+ OUT UINT16 *MinorRevision
+ )
+{
+ ASSERT (FALSE);
+ return RETURN_UNSUPPORTED;
+}
+
+/** Get the UUID of the TRNG backend.
+
+ A TRNG may be implemented by the system firmware, in which case this
+ function shall return the UUID of the TRNG backend.
+ Returning the TRNG UUID is optional and if not implemented,
RETURN_UNSUPPORTED
+ shall be returned.
+
+ Note: The caller must not rely on the returned UUID as a trustworthy TRNG
+Back end identity
+
+ @param [out] Guid UUID of the TRNG backend.
+
+ @retval RETURN_SUCCESSThe function completed successfully.
+ @retval RETURN_INVALID_PARAMETER Invalid parameter.
+ @retval RETURN_UNSUPPORTEDFunction not implemented.
+**/
+RETURN_STATUS
+EFIAPI
+GetTrngUuid (
+ OUT GUID *Guid
+ )
+{
+ ASSERT (FALSE);
+ return RETURN_UNSUPPORTED;
+}
+
+/** Returns maximum number of entropy bits that can be returned in a single
+call.
+
+ @return Returns the maximum number of Entropy bits that can be returned
+ in a single call to GetTrngEntropy().
+**/
+UINTN
+EFIAPI
+GetTrngMaxSupportedEntropyBits (
+ VOID
+ )
+{
+ ASSERT (FALSE);
+ return 0;
+}
+
+/** Returns N bits of conditioned entropy.
+
+ See [1] Section 2.3.1 GetEntropy: An Interface to the Entropy Source
+GetEntropy
+ Input:
+bits_of_entropy: the requested amount of entropy
+ Output:
+entropy_bitstring: The string that provides the requested entropy.
+ status: A Boolean value that is TRUE if the request has been satisfied,
+ and is FALSE otherwise.
+
+ @param [in] EntropyBits Number of entropy bits requested.
+ @param [in] BufferSize Size of the Buffer in bytes.
+ @param [out] Buffer Buffer to return the entropy bits.
+
+ @retval RETURN_SUCCESSThe function completed successfully.
+ @retval RETURN_INVALID_PARAMETER Invalid parameter.
+ @retval RETURN_UNSUPPORTEDFunction not implemented.
+ @retval RETURN_BAD_BUFFER_SIZEBuffer size is too small.
+ @retval RETURN_NOT_READY No Entropy available.
+**/
+RETURN_STATUS
+EFIAPI
+GetTrngEntropy (
+ IN UINTN EntropyBits,
+ IN UINTN BufferSize,
+ OUT UINT8 *Buffer
+ )
+{
+ ASSERT (FALSE);
+ return RETURN_UNSUPPORTED;
+}
diff --git a/MdePkg/Library/BaseTrngLibNull/BaseTrngLibNull.inf
b/MdePkg/Library/BaseTrngLibNull/BaseTrngLibNull.inf
new file mode 100644
index ..54a4fd3db8cd
--- /dev/null
+++ b/MdePkg/Library/BaseTrngLibNull/BaseTrngLibNull.inf
@@ -0,0 +1,30 @@
+## @file
+# Null instance of TRNG (True Random Number Generator) Library.
+#
+# Copyright (c) 2021 - 2022, Arm Limited. All rights reserved
[edk2-devel] [PATCH v7 06/19] MdePkg/TrngLib: Definition for TRNG library class interface
From: Sami Mujawar Bugzilla: 3668 (https://bugzilla.tianocore.org/show_bug.cgi?id=3668) The NIST Special Publications 800-90A, 800-90B and 800-90C provide recommendations for random number generation. The NIST 800-90C, Recommendation for Random Bit Generator (RBG) Constructions, defines the GetEntropy() interface that is used to access the entropy source. The GetEntropy() interface is further used by Deterministic Random Bit Generators (DRBG) to generate random numbers. The True Random Number Generator (TRNG) library defines an interface to access the entropy source on a platform. Some platforms/architectures may provide access to the entropy using a firmware interface. In such cases the TRNG library shall be used to provide an abstraction. Signed-off-by: Pierre Gondois --- MdePkg/Include/Library/TrngLib.h | 103 +++ MdePkg/MdePkg.dec| 5 ++ 2 files changed, 108 insertions(+) create mode 100644 MdePkg/Include/Library/TrngLib.h diff --git a/MdePkg/Include/Library/TrngLib.h b/MdePkg/Include/Library/TrngLib.h new file mode 100644 index ..535fd53f4305 --- /dev/null +++ b/MdePkg/Include/Library/TrngLib.h @@ -0,0 +1,103 @@ +/** @file + TRNG interface library definitions. + + Copyright (c) 2021 - 2022, Arm Limited. All rights reserved. + + SPDX-License-Identifier: BSD-2-Clause-Patent + + @par Reference(s): + - [1] NIST Special Publication 800-90B, Recommendation for the Entropy +Sources Used for Random Bit Generation. +(https://csrc.nist.gov/publications/detail/sp/800-90b/final) + + @par Glossary: +- TRNG - True Random Number Generator +**/ + +#ifndef TRNG_LIB_H_ +#define TRNG_LIB_H_ + +/** Get the version of the TRNG backend. + + A TRNG may be implemented by the system firmware, in which case this + function shall return the version of the TRNG backend. + The implementation must return NOT_SUPPORTED if a Back end is not present. + + @param [out] MajorRevision Major revision. + @param [out] MinorRevision Minor revision. + + @retval RETURN_SUCCESSThe function completed successfully. + @retval RETURN_INVALID_PARAMETER Invalid parameter. + @retval RETURN_UNSUPPORTEDBackend not present. +**/ +RETURN_STATUS +EFIAPI +GetTrngVersion ( + OUT UINT16 *MajorRevision, + OUT UINT16 *MinorRevision + ); + +/** Get the UUID of the TRNG backend. + + A TRNG may be implemented by the system firmware, in which case this + function shall return the UUID of the TRNG backend. + Returning the TRNG UUID is optional and if not implemented, RETURN_UNSUPPORTED + shall be returned. + + Note: The caller must not rely on the returned UUID as a trustworthy TRNG +Back end identity + + @param [out] Guid UUID of the TRNG backend. + + @retval RETURN_SUCCESSThe function completed successfully. + @retval RETURN_INVALID_PARAMETER Invalid parameter. + @retval RETURN_UNSUPPORTEDFunction not implemented. +**/ +RETURN_STATUS +EFIAPI +GetTrngUuid ( + OUT GUID *Guid + ); + +/** Returns maximum number of entropy bits that can be returned in a single +call. + + @return Returns the maximum number of Entropy bits that can be returned + in a single call to GetTrngEntropy(). +**/ +UINTN +EFIAPI +GetTrngMaxSupportedEntropyBits ( + VOID + ); + +/** Returns N bits of conditioned entropy. + + See [1] Section 2.3.1 GetEntropy: An Interface to the Entropy Source +GetEntropy + Input: +bits_of_entropy: the requested amount of entropy + Output: +entropy_bitstring: The string that provides the requested entropy. + status: A Boolean value that is TRUE if the request has been satisfied, + and is FALSE otherwise. + + @param [in] EntropyBits Number of entropy bits requested. + @param [in] BufferSize Size of the Buffer in bytes. + @param [out] Buffer Buffer to return the entropy bits. + + @retval RETURN_SUCCESSThe function completed successfully. + @retval RETURN_INVALID_PARAMETER Invalid parameter. + @retval RETURN_UNSUPPORTEDFunction not implemented. + @retval RETURN_BAD_BUFFER_SIZEBuffer size is too small. + @retval RETURN_NOT_READY No Entropy available. +**/ +RETURN_STATUS +EFIAPI +GetTrngEntropy ( + IN UINTN EntropyBits, + IN UINTN BufferSize, + OUT UINT8 *Buffer + ); + +#endif // TRNG_LIB_H_ diff --git a/MdePkg/MdePkg.dec b/MdePkg/MdePkg.dec index f1ebf9e251c1..7ff26e22f915 100644 --- a/MdePkg/MdePkg.dec +++ b/MdePkg/MdePkg.dec @@ -7,6 +7,7 @@ # Copyright (c) 2007 - 2022, Intel Corporation. All rights reserved. # Portions copyright (c) 2008 - 2009, Apple Inc. All rights reserved. # (C) Copyright 2016 - 2021 Hewlett Packard Enterprise Development LP +# Copyright (c) 2021 - 2022, Arm Limited. All rights reserved. # # SPDX-License-Identifier: BSD-2-Clause-Patent # @@ -275,6 +276,10 @@ [LibraryClasses] ## @libraryclass Provides functi
[edk2-devel] [PATCH v7 05/19] ArmPkg/ArmHvcLibNull: Add NULL instance of ArmHvcLib
From: Pierre Gondois
Add a Null instance of ArmHvcLib in case of library dependencies.
Signed-off-by: Pierre Gondois
---
ArmPkg/ArmPkg.dsc | 1 +
ArmPkg/Library/ArmHvcLibNull/ArmHvcLibNull.c | 29 +++
.../Library/ArmHvcLibNull/ArmHvcLibNull.inf | 22 ++
3 files changed, 52 insertions(+)
create mode 100644 ArmPkg/Library/ArmHvcLibNull/ArmHvcLibNull.c
create mode 100644 ArmPkg/Library/ArmHvcLibNull/ArmHvcLibNull.inf
diff --git a/ArmPkg/ArmPkg.dsc b/ArmPkg/ArmPkg.dsc
index 13e20a258e9e..11b473974463 100644
--- a/ArmPkg/ArmPkg.dsc
+++ b/ArmPkg/ArmPkg.dsc
@@ -132,6 +132,7 @@ [Components.common]
ArmPkg/Library/ArmGenericTimerVirtCounterLib/ArmGenericTimerVirtCounterLib.inf
ArmPkg/Library/ArmHvcLib/ArmHvcLib.inf
+ ArmPkg/Library/ArmHvcLibNull/ArmHvcLibNull.inf
ArmPkg/Library/ArmMonitorLib/ArmMonitorLib.inf
ArmPkg/Library/ArmSmcLib/ArmSmcLib.inf
ArmPkg/Library/ArmSmcLibNull/ArmSmcLibNull.inf
diff --git a/ArmPkg/Library/ArmHvcLibNull/ArmHvcLibNull.c
b/ArmPkg/Library/ArmHvcLibNull/ArmHvcLibNull.c
new file mode 100644
index ..8edda01a7f0a
--- /dev/null
+++ b/ArmPkg/Library/ArmHvcLibNull/ArmHvcLibNull.c
@@ -0,0 +1,29 @@
+/** @file
+ Arm HyperVisor Call (HVC) Null Library.
+
+ Copyright (c) 2022, Arm Limited. All rights reserved.
+
+ SPDX-License-Identifier: BSD-2-Clause-Patent
+
+**/
+
+#include
+#include
+
+/**
+ Trigger an HVC call
+
+ HVC calls can take up to 8 arguments and return up to 4 return values.
+ Therefore, the 4 first fields in the ARM_HVC_ARGS structure are used
+ for both input and output values.
+
+ @param [in,out] ArgsArguments for the HVC call.
+**/
+VOID
+ArmCallHvc (
+ IN OUT ARM_HVC_ARGS *Args
+ )
+{
+ ASSERT (FALSE);
+ return;
+}
diff --git a/ArmPkg/Library/ArmHvcLibNull/ArmHvcLibNull.inf
b/ArmPkg/Library/ArmHvcLibNull/ArmHvcLibNull.inf
new file mode 100644
index ..e390a5fbbe21
--- /dev/null
+++ b/ArmPkg/Library/ArmHvcLibNull/ArmHvcLibNull.inf
@@ -0,0 +1,22 @@
+## @file
+# Arm Hvc Null Library
+#
+# Copyright (c) 2022, Arm Limited. All rights reserved.
+#
+# SPDX-License-Identifier: BSD-2-Clause-Patent
+##
+
+[Defines]
+ INF_VERSION= 1.29
+ BASE_NAME = ArmHvcLibNull
+ FILE_GUID = 02076A46-D6DB-48DD-8E5F-153172DD73A1
+ MODULE_TYPE= BASE
+ VERSION_STRING = 1.0
+ LIBRARY_CLASS = ArmHvcLib
+
+[Sources]
+ ArmHvcLibNull.c
+
+[Packages]
+ ArmPkg/ArmPkg.dec
+ MdePkg/MdePkg.dec
--
2.25.1
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#94640): https://edk2.groups.io/g/devel/message/94640
Mute This Topic: https://groups.io/mt/94085849/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[edk2-devel] [PATCH v7 04/19] ArmPkg: Sort HVC/SMC section alphbetically in ArmPkg.dsc
From: Pierre Gondois Sort the section containing HVC/SMC libraries prior to adding new libraries in this specific section. Signed-off-by: Pierre Gondois --- ArmPkg/ArmPkg.dsc | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/ArmPkg/ArmPkg.dsc b/ArmPkg/ArmPkg.dsc index 3afd212f472b..13e20a258e9e 100644 --- a/ArmPkg/ArmPkg.dsc +++ b/ArmPkg/ArmPkg.dsc @@ -131,11 +131,11 @@ [Components.common] ArmPkg/Library/ArmGenericTimerPhyCounterLib/ArmGenericTimerPhyCounterLib.inf ArmPkg/Library/ArmGenericTimerVirtCounterLib/ArmGenericTimerVirtCounterLib.inf + ArmPkg/Library/ArmHvcLib/ArmHvcLib.inf + ArmPkg/Library/ArmMonitorLib/ArmMonitorLib.inf ArmPkg/Library/ArmSmcLib/ArmSmcLib.inf ArmPkg/Library/ArmSmcLibNull/ArmSmcLibNull.inf - ArmPkg/Library/ArmHvcLib/ArmHvcLib.inf ArmPkg/Library/ArmSvcLib/ArmSvcLib.inf - ArmPkg/Library/ArmMonitorLib/ArmMonitorLib.inf ArmPkg/Library/OpteeLib/OpteeLib.inf ArmPkg/Filesystem/SemihostFs/SemihostFs.inf -- 2.25.1 -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#94639): https://edk2.groups.io/g/devel/message/94639 Mute This Topic: https://groups.io/mt/94085848/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[edk2-devel] [PATCH v7 03/19] ArmPkg/ArmMonitorLib: Add ArmMonitorLib
From: Pierre Gondois
The ArmMonitorLib provides an abstract interface to issue
an HyperVisor Call (HVC) or System Monitor Call (SMC) depending
on the default conduit.
The PcdMonitorConduitHvc PCD allows to select the default conduit.
Signed-off-by: Pierre Gondois
---
ArmPkg/ArmPkg.dsc | 1 +
ArmPkg/Library/ArmMonitorLib/ArmMonitorLib.c | 34 +++
.../Library/ArmMonitorLib/ArmMonitorLib.inf | 29
3 files changed, 64 insertions(+)
create mode 100644 ArmPkg/Library/ArmMonitorLib/ArmMonitorLib.c
create mode 100644 ArmPkg/Library/ArmMonitorLib/ArmMonitorLib.inf
diff --git a/ArmPkg/ArmPkg.dsc b/ArmPkg/ArmPkg.dsc
index 59fd8f295d4f..3afd212f472b 100644
--- a/ArmPkg/ArmPkg.dsc
+++ b/ArmPkg/ArmPkg.dsc
@@ -135,6 +135,7 @@ [Components.common]
ArmPkg/Library/ArmSmcLibNull/ArmSmcLibNull.inf
ArmPkg/Library/ArmHvcLib/ArmHvcLib.inf
ArmPkg/Library/ArmSvcLib/ArmSvcLib.inf
+ ArmPkg/Library/ArmMonitorLib/ArmMonitorLib.inf
ArmPkg/Library/OpteeLib/OpteeLib.inf
ArmPkg/Filesystem/SemihostFs/SemihostFs.inf
diff --git a/ArmPkg/Library/ArmMonitorLib/ArmMonitorLib.c
b/ArmPkg/Library/ArmMonitorLib/ArmMonitorLib.c
new file mode 100644
index ..741f5c615744
--- /dev/null
+++ b/ArmPkg/Library/ArmMonitorLib/ArmMonitorLib.c
@@ -0,0 +1,34 @@
+/** @file
+ Arm Monitor Library.
+
+ Copyright (c) 2022, Arm Limited. All rights reserved.
+
+ SPDX-License-Identifier: BSD-2-Clause-Patent
+
+**/
+
+#include
+#include
+#include
+#include
+
+/** Monitor call.
+
+ An HyperVisor Call (HVC) or System Monitor Call (SMC) will be issued
+ depending on the default conduit. PcdMonitorConduitHvc determines the type
+ of the call: if true, do an HVC.
+
+ @param [in,out] ArgsArguments for the HVC/SMC.
+**/
+VOID
+EFIAPI
+ArmMonitorCall (
+ IN OUT ARM_MONITOR_ARGS *Args
+ )
+{
+ if (FeaturePcdGet (PcdMonitorConduitHvc)) {
+ArmCallHvc ((ARM_HVC_ARGS *)Args);
+ } else {
+ArmCallSmc ((ARM_SMC_ARGS *)Args);
+ }
+}
diff --git a/ArmPkg/Library/ArmMonitorLib/ArmMonitorLib.inf
b/ArmPkg/Library/ArmMonitorLib/ArmMonitorLib.inf
new file mode 100644
index ..f504cb80f1fc
--- /dev/null
+++ b/ArmPkg/Library/ArmMonitorLib/ArmMonitorLib.inf
@@ -0,0 +1,29 @@
+## @file
+# Arm Monitor Library
+#
+# Copyright (c) 2022, Arm Limited. All rights reserved.
+#
+# SPDX-License-Identifier: BSD-2-Clause-Patent
+##
+
+[Defines]
+ INF_VERSION= 1.29
+ BASE_NAME = ArmMonitorLib
+ FILE_GUID = F918DACB-FBB8-4CB6-A61D-08E75AF0E7CD
+ MODULE_TYPE= BASE
+ VERSION_STRING = 1.0
+ LIBRARY_CLASS = ArmMonitorLib
+
+[Sources]
+ ArmMonitorLib.c
+
+[Packages]
+ ArmPkg/ArmPkg.dec
+ MdePkg/MdePkg.dec
+
+[LibraryClasses]
+ ArmHvcLib
+ ArmSmcLib
+
+[Pcd]
+ gArmTokenSpaceGuid.PcdMonitorConduitHvc
--
2.25.1
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#94638): https://edk2.groups.io/g/devel/message/94638
Mute This Topic: https://groups.io/mt/94085847/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[edk2-devel] [PATCH v7 00/19] Add Raw algorithm support using Arm FW-TRNG interface
From: Pierre Gondois
Bugzilla: Bug 3668 (https://bugzilla.tianocore.org/show_bug.cgi?id=3668)
The Arm True Random Number Generator Firmware, Interface 1.0, specification
defines an interface between an Operating System (OS) executing at EL1 and
Firmware (FW) exposing a conditioned entropy source that is provided by a
TRNG back end.
This patch-set:
- defines a TRNG library class that provides an interface to access the
entropy source on a platform.
- implements a TRNG library instance that uses the Arm FW-TRNG interface.
- Adds RawAlgorithm support to RngDxe for Arm architecture using the Arm
FW-TRNG interface.
- Enables RNG support using FW-TRNG interface for Kvmtool Guest/Virtual
firmware.
This patch-set is based on the v2 from Sami Mujawar:
[PATCH v2 0/8] Add Raw algorithm support using Arm FW-TRNG interface
v2:
https://edk2.groups.io/g/devel/message/83775
v3:
https://edk2.groups.io/g/devel/message/90845
https://github.com/PierreARM/edk2/tree/Arm_Trng_v3
v4:
https://github.com/PierreARM/edk2/tree/Arm_Trng_v4
v5:
https://github.com/PierreARM/edk2/tree/Arm_Trng_v5
v6:
https://github.com/PierreARM/edk2/tree/Arm_Trng_v6
v7:
https://github.com/PierreARM/edk2/tree/Arm_Trng_v7
v7:
- Removed Reviewed-by from Leif.
- Remove Sami's Signed-off.
V6:
- Added my signed-off on patches authored by Sami. [Leif]
- New patch to make it easier to add new libraries in alphabetical
order: ArmPkg: Sort HVC/SMC section alphbetically in ArmPkg.dsc [Leif]
- Renmaed ArmHvcNullLib to ArmHvcLibNull. [Leif]
- Added RISCV64 to the list of VALID_ARCHITECTURES for BaseTrngLibNull. [Leif]
- Removed unnecessary space in function parameter documentation
('[in, out]'). [Rebecca]
- Updated INF_VERSION to latest spec (1.29) for new libraries. [Rebecca]
- Dropped the following patches [Leif]:
- ArmPkg/ArmLib: Add ArmHasRngExt()
- ArmPkg/ArmLib: Add ArmReadIdIsar0() helper
- MdePkg/BaseRngLib: Rename ArmReadIdIsar0() to ArmGetFeatRng()
V5:
- Removed references in Trnglib.h to 'Special Publication'
800-90A and 800-90C, and only reference 'Arm True Random
Number Generator Firmware, Interface 1.0' in the Arm
implementation of the TrngLib. [Jiewen]
V4:
- Removed dependencies on ArmPkg and dropped patch:
[PATCH v3 12/22] SecurityPkg: Update Securitypkg.ci.yaml
[Jiewen]
- Use a dynamically allocated array to hold available algorithms.
The array is freed in a new UNLOAD_IMAGE function and
allocated in arch specific implementations of
GetAvailableAlgorithms(), available in AArch64/AArch64Algo.c
and Arm/ArmAlgo.c.
- Correctly reference gEfiRngAlgorithmSp80090Ctr256Guid
Guid by copying its address (add missing '&'). [Jiewen]
V3:
- Address Leif's comment (moving definitions, optimizations, ...)
- Add ArmMonitorLib to choose Hvc/Smc conduit depending on a Pcd.
- Re-factor some parts of SecurityPkg/RngDxe/ to ease the addition
of new algorithms.
- Add ArmHasRngExt() function to check Arm's FEAT_RNG extension.
V2:
- Updates TrngLib definitions to use RETURN_STATUS as the return type
from the interface functions as TrngLib is base type library.
- Drops the patch "MdePkg: Add definition for NULL GUID" as there is
already an equivalent definition provided by gZeroGuid. Thus, the
use of gNullGuid has been replaced with gZeroGuid.
Pierre Gondois (11):
ArmPkg/ArmMonitorLib: Definition for ArmMonitorLib library class
ArmPkg/ArmMonitorLib: Add ArmMonitorLib
ArmPkg: Sort HVC/SMC section alphbetically in ArmPkg.dsc
ArmPkg/ArmHvcLibNull: Add NULL instance of ArmHvcLib
SecurityPkg/RngDxe: Replace Pcd with Sp80090Ctr256Guid
SecurityPkg/RngDxe: Remove ArchGetSupportedRngAlgorithms()
SecurityPkg/RngDxe: Documentation/include/parameter cleanup
SecurityPkg/RngDxe: Check before advertising Cpu Rng algo
SecurityPkg/RngDxe: Add debug warning for NULL
PcdCpuRngSupportedAlgorithm
SecurityPkg/RngDxe: Rename AArch64/RngDxe.c
SecurityPkg/RngDxe: Add Arm support of RngDxe
Sami Mujawar (8):
ArmPkg: PCD to select conduit for monitor calls
MdePkg/TrngLib: Definition for TRNG library class interface
MdePkg/TrngLib: Add NULL instance of TRNG Library
ArmPkg: Add FID definitions for Firmware TRNG
ArmPkg/TrngLib: Add Arm Firmware TRNG library
SecurityPkg/RngDxe: Rename RdRandGenerateEntropy to generic name
SecurityPkg/RngDxe: Add AArch64 RawAlgorithm support through TrngLib
ArmVirtPkg: Kvmtool: Add RNG support using FW-TRNG interface
ArmPkg/ArmPkg.dec | 12 +-
ArmPkg/ArmPkg.dsc | 5 +-
ArmPkg/Include/IndustryStandard/ArmStdSmc.h | 109 -
ArmPkg/Include/Library/ArmMonitorLib.h| 42 ++
ArmPkg/Library/ArmFwTrngLib/ArmFwTrngDefs.h | 50 +++
ArmPkg/Library/ArmFwTrngLib/ArmFwTrngLib.c| 388 ++
ArmPkg/Library/ArmFwTrngLib/ArmFwTrngLib.inf | 29 ++
ArmPkg/Library/ArmHvcLibNull/ArmHvcLibNull.c | 29 ++
.../Library/ArmHvcLibNull/ArmHvcLibNull.inf | 22 +
ArmPkg/Library/
[edk2-devel] [PATCH v7 02/19] ArmPkg/ArmMonitorLib: Definition for ArmMonitorLib library class
From: Pierre Gondois
The ArmMonitorLib provides an abstract interface to issue
an HyperVisor Call (HVC) or System Monitor Call (SMC) depending
on the default conduit.
The PcdMonitorConduitHvc PCD allows to select the default conduit.
The new library relies on the ArmHvcLib and ArmSmcLib libraries.
A Null instance of these libraries can be used for the unused conduit.
Signed-off-by: Pierre Gondois
---
ArmPkg/ArmPkg.dec | 5 +++
ArmPkg/Include/Library/ArmMonitorLib.h | 42 ++
2 files changed, 47 insertions(+)
create mode 100644 ArmPkg/Include/Library/ArmMonitorLib.h
diff --git a/ArmPkg/ArmPkg.dec b/ArmPkg/ArmPkg.dec
index bb5cbecbc228..653942ff63c3 100644
--- a/ArmPkg/ArmPkg.dec
+++ b/ArmPkg/ArmPkg.dec
@@ -71,6 +71,11 @@ [LibraryClasses.common]
#
ArmSvcLib|Include/Library/ArmSvcLib.h
+ ## @libraryclass Provides a Monitor Call interface that will use the
+ # default conduit (HVC or SMC).
+ #
+ ArmMonitorLib|Include/Library/ArmMonitorLib.h
+
## @libraryclass Provides a default exception handler.
#
DefaultExceptionHandlerLib|Include/Library/DefaultExceptionHandlerLib.h
diff --git a/ArmPkg/Include/Library/ArmMonitorLib.h
b/ArmPkg/Include/Library/ArmMonitorLib.h
new file mode 100644
index ..d6e13b61d63d
--- /dev/null
+++ b/ArmPkg/Include/Library/ArmMonitorLib.h
@@ -0,0 +1,42 @@
+/** @file
+
+ Copyright (c) 2022, Arm Limited. All rights reserved.
+
+ SPDX-License-Identifier: BSD-2-Clause-Patent
+
+**/
+
+#ifndef ARM_MONITOR_LIB_H_
+#define ARM_MONITOR_LIB_H_
+
+/** The size of the SMC arguments is different between AArch64 and AArch32.
+
+ The native size is used for the arguments.
+ It will be casted to either HVC or SMC args.
+*/
+typedef struct {
+ UINTNArg0;
+ UINTNArg1;
+ UINTNArg2;
+ UINTNArg3;
+ UINTNArg4;
+ UINTNArg5;
+ UINTNArg6;
+ UINTNArg7;
+} ARM_MONITOR_ARGS;
+
+/** Monitor call.
+
+ An HyperVisor Call (HVC) or System Monitor Call (SMC) will be issued
+ depending on the default conduit. PcdMonitorConduitHvc determines the type
+ of the call: if true, do an HVC.
+
+ @param [in,out] ArgsArguments for the HVC/SMC.
+**/
+VOID
+EFIAPI
+ArmMonitorCall (
+ IN OUT ARM_MONITOR_ARGS *Args
+ );
+
+#endif // ARM_MONITOR_LIB_H_
--
2.25.1
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#94637): https://edk2.groups.io/g/devel/message/94637
Mute This Topic: https://groups.io/mt/94085846/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[edk2-devel] [PATCH v7 01/19] ArmPkg: PCD to select conduit for monitor calls
From: Sami Mujawar Define a PCD 'PcdMonitorConduitHvc' to select the conduit to use for monitor calls. PcdMonitorConduitHvc is defined as FALSE by default, meaning the SMC conduit is enabled as default. Adding PcdMonitorConduitHvc allows selection of HVC conduit to be used by virtual firmware implementations. Signed-off-by: Pierre Gondois --- ArmPkg/ArmPkg.dec | 7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/ArmPkg/ArmPkg.dec b/ArmPkg/ArmPkg.dec index 9da1bbc9f216..bb5cbecbc228 100644 --- a/ArmPkg/ArmPkg.dec +++ b/ArmPkg/ArmPkg.dec @@ -2,7 +2,7 @@ # ARM processor package. # # Copyright (c) 2009 - 2010, Apple Inc. All rights reserved. -# Copyright (c) 2011 - 2021, ARM Limited. All rights reserved. +# Copyright (c) 2011 - 2022, ARM Limited. All rights reserved. # Copyright (c) 2021, Ampere Computing LLC. All rights reserved. # #SPDX-License-Identifier: BSD-2-Clause-Patent @@ -132,6 +132,11 @@ [PcdsFeatureFlag.common] # Define if the GICv3 controller should use the GICv2 legacy gArmTokenSpaceGuid.PcdArmGicV3WithV2Legacy|FALSE|BOOLEAN|0x0042 + ## Define the conduit to use for monitor calls. + # Default PcdMonitorConduitHvc = FALSE, conduit = SMC + # If PcdMonitorConduitHvc = TRUE, conduit = HVC + gArmTokenSpaceGuid.PcdMonitorConduitHvc|FALSE|BOOLEAN|0x0047 + [PcdsFeatureFlag.ARM] # Whether to map normal memory as non-shareable. FALSE is the safe choice, but # TRUE may be appropriate to fix performance problems if you don't care about -- 2.25.1 -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#94636): https://edk2.groups.io/g/devel/message/94636 Mute This Topic: https://groups.io/mt/94085844/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
