Re: [edk2-devel] [PATCH] BaseTools: Correct BPDG tool error prints

[Bob Feng]

Reviewed-by: Bob Feng 

-Original Message-
From: Konstantin Aladyshev  
Sent: Monday, September 5, 2022 5:19 PM
To: devel@edk2.groups.io
Cc: Feng, Bob C ; Gao, Liming ; 
Chen, Christine ; Konstantin Aladyshev 

Subject: [PATCH] BaseTools: Correct BPDG tool error prints

Popen communication returns bytestrings. It is necessary to perform decode on 
these strings before passing them to the EdkLogger that works with ordinary 
strings.

Signed-off-by: Konstantin Aladyshev 
---
 BaseTools/Source/Python/Common/VpdInfoFile.py | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/BaseTools/Source/Python/Common/VpdInfoFile.py 
b/BaseTools/Source/Python/Common/VpdInfoFile.py
index 4249b9f899..1e0c3dfe76 100644
--- a/BaseTools/Source/Python/Common/VpdInfoFile.py
+++ b/BaseTools/Source/Python/Common/VpdInfoFile.py
@@ -248,8 +248,8 @@ def CallExtenalBPDGTool(ToolPath, VpdFileName):
 PopenObject.wait()  if PopenObject.returncode != 0:-
EdkLogger.debug(EdkLogger.DEBUG_1, "Fail to call BPDG tool", str(error))+   
 EdkLogger.debug(EdkLogger.DEBUG_1, "Fail to call BPDG tool", 
str(error.decode())) EdkLogger.error("BPDG", 
BuildToolError.COMMAND_FAILURE, "Fail to execute BPDG tool with exit code: %d, 
the error message is: \n %s" % \-
(PopenObject.returncode, str(error)))+
(PopenObject.returncode, str(error.decode(  return 
PopenObject.returncode-- 
2.25.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#94610): https://edk2.groups.io/g/devel/message/94610
Mute This Topic: https://groups.io/mt/93474930/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v3 00/34] Add a new architecture called LoongArch in EDK II

[Chao Li]

Hi All,
Today, all of LoongArch patches have been approved, a big thank you to all the 
maintainers!

I have updated the LoongArch code repo to the EDK2 latest commit, applied the 
LoongArch patches based on it, and CI passed.

LoongArch repo URL: https://github.com/loongson/edk2/tree/LoongArch
CI results: 
https://dev.azure.com/kilaterlee/LoongArch_edk2/_build/results?buildId=75&view=results

I think the LoongArch port is ready to merge into the EDK2 master branch, if so 
please help me merge them. Please let me know if something should I do next.


--
Thanks,
Chao

> -原始邮件-
> 发件人: "Chao Li" 
> 发送时间:2022-09-27 19:13:20 (星期二)
> 收件人: devel@edk2.groups.io
> 抄送: "Ray Ni" , "Liming Gao" , 
> "Michael D Kinney" , "Guomin Jiang" 
> , "Wei6 Xu" , "Maciej Rabeda" 
> , "Jiaxin Wu" , "Siyuan 
> Fu" , "Jiewen Yao" , "Jian J Wang" 
> , "Xiaoyu Lu" , "Zhiguang Liu" 
> , "Zhichao Gao" , "Bob Feng" 
> , "Yuwei Chen" 
> 主题: [edk2-devel] [PATCH v3 00/34] Add a new architecture called LoongArch in 
> EDK II
> 
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4053
> 
> UEFI Spec V2.10 already supports LoongArch and all changes of this
> commit passwed Azure CI testing, so let's enable it in EDK2. This commit
> contains 35 patches, with patch 0 is the cover and the rest being the
> LoongArch base code.
> 
> Changes from v1 to v2:
> 1. For patch 0008, added IANA website link in the commit message and
> Dhcp.h.
> 2. Added IANA, Microsft and UEFI specification links in every patch
> commit message that uses them.
> 3. For patch 0023, LoongArch64 supports unaligned access operations, so
> use the unaligned read/write generic implementation. Added Barrier.S
> file to provide barrier operations for LoongArch.
> 4. For patch 0024, convert inline assembly code to ASM code.
> 5. Added the BZ link in every patch commit message.
> 
> Changes from v2 to v3:
> 1. Added all reviewer in the correspondings patches.
> 2. For patch 0029, converted LoongArch synchronization operations from
> inline assembly code to ASM code.
> 3. For patch 0015, 0016, 0017, changed the commit message for more
> clarity.
> 4. For patch 0034, move it to patch 0018, as it also changes the BaseTools.
> 
> Please refer to this URL for the code repo of LoongArch64:
> https://github.com/loongson/edk2/tree/LoongArch
> 
> Fore more documents of LoongArch please refer to following URL:
> https://loongson.github.io/LoongArch-Documentation/README-EN.html
> 
> Modified modules: FatPkg, FmpDevicePkg, NetworkPkg,
> NetworkPkg/HttpBootDxe, CryptoPkg, MdePkg/Include, SecurityPkg,
> ShellPkg, UnitTestFrameworkPkg, MdePkg/DxeServicesLib, MdeModulePkg,
> .python/SpellCheck, BaseTools, .azurepipelines, .pytool, MdePkg,
> MdeModulePkg and MdePkg/MdePkg.ci.yaml.
> 
> Cc: Ray Ni 
> Cc: Liming Gao 
> Cc: Michael D Kinney 
> Cc: Guomin Jiang 
> Cc: Wei6 Xu 
> Cc: Maciej Rabeda 
> Cc: Jiaxin Wu 
> Cc: Siyuan Fu 
> Cc: Jiewen Yao 
> Cc: Jian J Wang 
> Cc: Xiaoyu Lu 
> Cc: Zhiguang Liu 
> Cc: Zhichao Gao 
> Cc: Bob Feng 
> Cc: Yuwei Chen 
> 
> Chao Li (34):
>   MdePkg: Added file of DebugSupport.h to MdePkg.ci.yaml
>   MdePkg: Added LoongArch jump buffer register definition to
> MdePkg.ci.yaml
>   FatPkg: Add LOONGARCH64 architecture for EDK2 CI.
>   FmpDevicePkg: Add LOONGARCH64 architecture for EDK2 CI.
>   NetworkPkg: Add LOONGARCH64 architecture for EDK2 CI.
>   NetworkPkg/HttpBootDxe: Add LOONGARCH64 architecture for EDK2 CI.
>   CryptoPkg: Add LOONGARCH64 architecture for EDK2 CI.
>   MdePkg/Include: Add LOONGARCH related definitions EDK2 CI.
>   SecurityPkg: Add LOONGARCH64 architecture for EDK2 CI.
>   ShellPkg: Add LOONGARCH64 architecture for EDK2 CI.
>   UnitTestFrameworkPkg: Add LOONGARCH64 architecture for EDK2 CI.
>   MdePkg/DxeServicesLib: Add LOONGARCH64 architecture
>   MdeModulePkg: Use LockBoxNullLib for LOONGARCH64
>   .python/SpellCheck: Add "Loongson" and "LOONGARCH" to "words" section
>   BaseTools: Update GenFw/GenFv to support LoongArch platform.
>   BaseTools: Updated for GCC5 tool chain for LoongArch platfrom.
>   BaseTools: Updated build tools to support new LoongArch.
>   BaseTools: Add LoongArch64 binding.
>   BaseTools: Enable LoongArch64 architecture for LoongArch64 EDK2 CI.
>   .azurepipelines: Add LoongArch64 architecture on LoongArch64 EDK2 CI.
>   .pytool: Add LoongArch64 architecture on LoongArch64 EDK2 CI.
>   MdePkg: Add LoongArch LOONGARCH64 binding
>   MdePkg/Include: LoongArch definitions.
>   MdePkg/BaseLib: BaseLib for LOONGARCH64 architecture.
>   MdePkg/BaseCacheMaintenanceLib: LoongArch cache maintenance
> implementation.
>   MdePkg/BaseIoLibIntrinsic: IoLibNoIo for LoongArch architecture.
>   MdePkg/BasePeCoff: Add LoongArch PE/Coff related code.
>   MdePkg/BaseCpuLib: LoongArch Base CPU library implementation.
>   MdePkg/BaseSynchronizationLib: LoongArch cache related code.
>   MdePkg/BaseSafeIntLib: Add LoongArch64 architecture for
> BaseSafeIntLib.
>   MdeModulePkg/Logo: Add LoongArch64 architecture.
>   MdeModuleP

Re: [edk2-devel] [PATCH v5 2/7] MdePkg: Introduce ExitBootServicesCallbackProtocol

[Ni, Ray]

Is it defined by UEFI Spec?


From: devel@edk2.groups.io  on behalf of Dionna Glaze via 
groups.io 
Sent: Saturday, October 1, 2022 7:06
To: devel@edk2.groups.io
Cc: Dionna Glaze; Gerd Hoffmann; Xu, Min M; James Bottomley; Yao, Jiewen; Tom 
Lendacky; Ard Biesheuvel; Andrew Fish; Kinney, Michael D
Subject: [edk2-devel] [PATCH v5 2/7] MdePkg: 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 
---
 MdePkg/Include/Protocol/ExitBootServicesCallback.h | 38 
 MdePkg/MdePkg.dec  |  3 ++
 2 files changed, 41 insertions(+)

diff --git a/MdePkg/Include/Protocol/ExitBootServicesCallback.h 
b/MdePkg/Include/Protocol/ExitBootServicesCallback.h
new file mode 100644
index 00..d21d7700f7
--- /dev/null
+++ b/MdePkg/Include/Protocol/ExitBootServicesCallback.h
@@ -0,0 +1,38 @@
+/** @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.
+**/
+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/MdePkg/MdePkg.dec b/MdePkg/MdePkg.dec
index de3c56758b..43b099b396 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/ExitBootServicesCallback.h
+  gEdkiiExitBootServicesCallbackProtocolGuid = { 0xf5684799, 0x9a33, 0x40f7, 
{0xa1, 0x5c, 0x10, 0x8e, 0x0e, 0x6b, 0x45, 0x25 }}
+
   ## 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 (#94608): https://edk2.groups.io/g/devel/message/94608
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]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH v5 7/7] OvmfPkg/PlatformPei: SEV-SNP make >=4GB unaccepted

[Dionna Glaze via groups.io]

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 (#94607): https://edk2.groups.io/g/devel/message/94607
Mute This Topic: https://groups.io/mt/94028467/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH v5 6/7] OvmfPkg: Implement AcceptAllUnacceptedMemory in CocoDxe

[Dionna Glaze via groups.io]

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 dc37c292f4..d7478603f7 100644
--- a/OvmfPkg/CocoDxe/CocoDxe.c
+++ b/OvmfPkg/CocoDxe/CocoDxe.c
@@ -16,6 +16,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -118,6 +119,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 (
@@ -145,5 +161,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 (#94606): https://edk2.groups.io/g/devel/message/94606
Mute This Topic: https://groups.io/mt/94028466/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH v5 5/7] MdePkg: Introduce the AcceptAllUnacceptedMemory protocol

[Dionna Glaze via groups.io]

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/AcceptAllUnacceptedMemory.h | 40 
 MdePkg/MdePkg.dec   |  5 ++-
 2 files changed, 44 insertions(+), 1 deletion(-)

diff --git a/MdePkg/Include/Protocol/AcceptAllUnacceptedMemory.h 
b/MdePkg/Include/Protocol/AcceptAllUnacceptedMemory.h
new file mode 100644
index 00..e50831836c
--- /dev/null
+++ b/MdePkg/Include/Protocol/AcceptAllUnacceptedMemory.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 43b099b396..452c40683e 100644
--- a/MdePkg/MdePkg.dec
+++ b/MdePkg/MdePkg.dec
@@ -1019,8 +1019,11 @@
   gEfiPeiDelayedDispatchPpiGuid  = { 0x869c711d, 0x649c, 0x44fe, { 0x8b, 0x9e, 
0x2c, 0xbb, 0x29, 0x11, 0xc3, 0xe6 }}
 
 [Protocols]
+  ## Include/Protocol/AcceptAllUnacceptedMemory.h
+  gBz3987AcceptAllUnacceptedMemoryProtocolGuid = { 0xc5a010fe, 0x38a7, 0x4531, 
{0x8a, 0x4a, 0x05, 0x00, 0xd2, 0xfd, 0x16, 0x49 }}
+
   ## Include/Protocol/ExitBootServicesCallback.h
-  gEdkiiExitBootServicesCallbackProtocolGuid = { 0xf5684799, 0x9a33, 0x40f7, 
{0xa1, 0x5c, 0x10, 0x8e, 0x0e, 0x6b, 0x45, 0x25 }}
+  gEdkiiExitBootServicesCallbackProtocolGuid   = { 0xf5684799, 0x9a33, 0x40f7, 
{0xa1, 0x5c, 0x10, 0x8e, 0x0e, 0x6b, 0x45, 0x25 }}
 
   ## 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 (#94605): https://edk2.groups.io/g/devel/message/94605
Mute This Topic: https://groups.io/mt/94028465/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH v5 3/7] MdeModulePkg: Invoke all ExitBootServicesCallback instances at ExitBootServices

[Dionna Glaze via groups.io]

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 
 #include "DxeMain.h"
 
 //
@@ -744,6 +745,54 @@ CalculateEfiHdrCrc (
   Hdr->CRC32 = Crc;
 }
 
+/**
+  Invokes TerminateMemoryMapPrehook from every instance of the
+  EdkiiExitBootServicesProtocol.
+**/
+STATIC
+EFI_STATUS
+InvokeTerminateMemoryMapPrehooks (
+  VOID
+  )
+{
+  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) {
+  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)) {
+//
+// 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 (#94603): https://edk2.groups.io/g/devel/message/94603
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]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH v5 4/7] OvmfPkg: Introduce CocoDxe driver

[Dionna Glaze via groups.io]

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| 149 
 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, 200 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..dc37c292f4
--- /dev/null
+++ b/OvmfPkg/CocoDxe/CocoDxe.c
@@ -0,0 +1,149 @@
+/** @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;
+  /*
+   * 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
+  );
+if (EFI_ERROR(Status)) {
+  goto done;
+}
+
+Status = gDS->RemoveMemorySpace(Desc->BaseAddress, Desc->Length);
+if (EFI_ERROR(Status)) {
+  goto done;
+}
+
+Status = gDS->AddMemorySpace (
+  EfiGcdMemoryTypeSystemMemory,
+  Desc->BaseAddress,
+  Desc->Length,
+  EFI_MEMORY_CPU_CRYPTO | EFI_MEMORY_XP | EFI_MEMORY_RO | EFI_MEMORY_RP
+  );
+if (EFI_ERROR(Status)) {
+  goto done;
+}
+
+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 memor

[edk2-devel] [PATCH v5 2/7] MdePkg: Introduce ExitBootServicesCallbackProtocol

[Dionna Glaze via groups.io]

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 
---
 MdePkg/Include/Protocol/ExitBootServicesCallback.h | 38 
 MdePkg/MdePkg.dec  |  3 ++
 2 files changed, 41 insertions(+)

diff --git a/MdePkg/Include/Protocol/ExitBootServicesCallback.h 
b/MdePkg/Include/Protocol/ExitBootServicesCallback.h
new file mode 100644
index 00..d21d7700f7
--- /dev/null
+++ b/MdePkg/Include/Protocol/ExitBootServicesCallback.h
@@ -0,0 +1,38 @@
+/** @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.
+**/
+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/MdePkg/MdePkg.dec b/MdePkg/MdePkg.dec
index de3c56758b..43b099b396 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/ExitBootServicesCallback.h
+  gEdkiiExitBootServicesCallbackProtocolGuid = { 0xf5684799, 0x9a33, 0x40f7, 
{0xa1, 0x5c, 0x10, 0x8e, 0x0e, 0x6b, 0x45, 0x25 }}
+
   ## 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 (#94602): https://edk2.groups.io/g/devel/message/94602
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]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH v5 1/7] OvmfPkg: Realize EfiMemoryAcceptProtocol in AmdSevDxe

[Dionna Glaze via groups.io]

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  | 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));
+
+  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"));
+  }
+
   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.ged0

[edk2-devel] [PATCH v5 0/7] Add safe unaccepted memory behavior

[Dionna Glaze via groups.io]

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 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
  MdePkg: 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.inf  |   1 +
 MdeModulePkg/Core/Dxe/DxeMain/DxeMain.c|  62 
+++
 MdePkg/Include/Protocol/AcceptAllUnacceptedMemory.h|  40 +
 MdePkg/Include/Protocol/ExitBootServicesCallback.h |  38 +
 MdePkg/MdePkg.dec  |   6 +
 OvmfPkg/AmdSev/AmdSevX64.dsc   |   1 +
 OvmfPkg/AmdSev/AmdSevX64.fdf   |   1 +
 OvmfPkg/AmdSevDxe/AmdSevDxe.c  |  57 
++-
 OvmfPkg/AmdSevDxe/AmdSevDxe.inf|   3 +
 OvmfPkg/CocoDxe/CocoDxe.c  | 174 

 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 +
 19 files changed, 454 insertions(+), 8 deletions(-)
 create mode 100644 MdePkg/Include/Protocol/AcceptAllUnacceptedMemory.h
 create mode 100644 MdePkg/Include/Protocol/ExitBootServicesCallback.h
 create mode 100644 OvmfPkg/CocoDxe/CocoDxe.c
 create mode 100644 OvmfPkg/CocoDxe/CocoDxe.inf

-- 
2.38.0.rc1.362.ged0d419d3c-goog



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#94600): https://edk2.groups.io/g/devel/message/94600
Mute This Topic: https://groups.io/mt/94028457/21656
Group Owner: devel+ow...@ed

Re: [edk2-devel] The principles of EDK2 module reconstruction for archs

[Michael D Kinney]

Hi Leif,

Concatenation is a good idea.  Makes it more obvious and can be easily
adopted for new CPU archs.

There is an additional case where an implementation does not have 
differences based on CPU Arch or Vendor, but it does have differences
based on the bit-width of the CPU.  Take BaseSafeIntLib as an example.
It has source files for 32-bit CPUs, 64-bit CPUs, and CPU arch
specific file for Ebc because Ebc adapts to 32-bit or 64-bit depending
on the CPU type the EBC Interpreter is running.

MdePkg/Library/BaseSafeIntLib/
  BaseSafeIntLib.inf
  SafeIntLib.c
  SafeIntLib32.c
  SafeIntLib64.c
  SafeIntLibEbc.c

Should we add "32" and "64" as supported suffices in file names?

If we wanted to put type content into a subdirectory, what would 
be the suggested directory name for "32" and "64".  Or do we want
to require this type of difference to always be files in top
level directory of the modules/library?

Best regards,

Mike


> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Leif Lindholm
> Sent: Friday, September 30, 2022 9:09 AM
> To: devel@edk2.groups.io; Kinney, Michael D ; 
> Chang, Abner ; 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
> 
> I agree similar things will certainly happen for ARM/AARCH64, which will
> probably be noticeable when I start eradicating ArmPkg and putting the
> arch-standard bits into (mostly) MdePkg.
> 
> But I like the ability to see already at the filesystem level which
> files belong to the architecture I'm currently working on and which don't.
> 
> Could we concatenate architectures?
> I.e. AARCH64_ARM, IA32_X64, AARCH64_RISCV64... ?
> 
> /
>  Leif
> 
> On 2022-09-30 08:28, Michael D Kinney wrote:
> > Hi Abner,
> >
> > One comment is on adding a new CPU type dir name of 'X86' for
> > content that is common for IA32/X64.
> >
> > I can imagine a similar case for ARM/AARCH64 and for the
> > RISCV (32, 64, 128) cases.
> >
> > I think I would prefer to drop X86 and if there are files
> > that are common to multiple CPU architectures then they
> > are considered common and are in top directory of module
> > and the file header and INF file can clearly document
> > which CPU archs the file applies.
> >
> > Mike
> >
> >> -Original Message-
> >> From: Chang, Abner 
> >> Sent: Friday, September 30, 2022 12:11 AM
> >> To: Ni, Ray ; Attar, AbdulLateef (Abdul Lateef) 
> >> ; Sunil V L
> >> ; devel@edk2.groups.io; Kinney, Michael D 
> >> 
> >> Cc: lichao ; Kirkendall, Garrett 
> >> ; Grimes, Paul ; He,
> >> Jiangang ; Leif Lindholm ; 
> >> Andrew Fish 
> >> Subject: RE: [edk2-devel] The principles of EDK2 module reconstruction for 
> >> archs
> >>
> >> [AMD Official Use Only - General]
> >>
> >> Thanks Ray, here are my responses.
> >> https://github.com/tianocore-docs/edk2-CCodingStandardsSpecification/pull/2
> >>
> >> @Kinney, Michael D we may also need your clarification on the comments.
> >>
> >>
> >>> -Original Message-
> >>> From: Ni, Ray 
> >>> Sent: Thursday, September 29, 2022 3:42 PM
> >>> To: Attar, AbdulLateef (Abdul Lateef) ; Chang,
> >>> Abner ; Sunil V L ;
> >>> devel@edk2.groups.io
> >>> Cc: Kinney, Michael D ; lichao
> >>> ; Kirkendall, Garrett ;
> >>> Grimes, Paul ; He, Jiangang
> >>> ; Leif Lindholm ;
> >>> 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,
> >>> Comments in
> >>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
> >>> ub.com%2Ftianocore-docs%2Fedk2-
> >>> CCodingStandardsSpecification%2Fpull%2F2%23pullrequestreview-
> >>> 1124763311&data=05%7C01%7CAbner.Chang%40amd.com%7Cd825e24
> >>> 8625541e3f43e08daa1ee2883%7C3dd8961fe4884e608e11a82d994e183d%7C0
> >>> %7C0%7C638000341502885565%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC
> >>> 4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%
> >>> 7C%7C%7C&sdata=RXxgpbEr6ivbqP1R6%2B3Rxl%2ByJAnaUJuaYYKdfCH
> >>> 8jo8%3D&reserved=0
> >>>
> >>> We can discuss more in tomorrow's meeting.
> >>>
> >>>
>  -Original Message-
>  From: Attar, AbdulLateef (Abdul Lateef) 
>  Sent: Thursday, September 29, 2022 3:11 PM
>  To: Chang, Abner ; Sunil V L
>  ; devel@edk2.groups.io; Ni, Ray
>  
>  Cc: Kinney, Michael D ; lichao
>  ; Kirkendall, Garrett
>  ; Grimes, Paul ;
> >>> He,
>  Jiangang ; Leif Lindholm
>  ; Andrew Fish 
>  Subject: RE: [edk2-devel] The principles of EDK2 module reconstruction
>  for archs
> 
>  Hi Abner,
>   Looks good to me.
>  Reviewed-by:  Abdul Lateef Attar 
> 
>  Thanks
>  AbduL
> 
>  -Original Message-
>  From: Ch

Re: [edk2-devel] [edk2-platforms PATCH 0/2] Platform/RaspberryPi: SyncPcie() fixes

[Adrien Thierry]

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.

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 (#94598): https://edk2.groups.io/g/devel/message/94598
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]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v4 1/6] OvmfPkg: Realize EfiMemoryAcceptProtocol in AmdSevDxe

[Dionna Glaze via groups.io]

> > +{
> > +  MemEncryptSevSnpPreValidateSystemRam (
> > +StartAddress,
> > +EFI_SIZE_TO_PAGES (Size)
>
> Sorry, I forgot to ask this earlier in the series, but is StartAddress
> guaranteed to be page-aligned and Size a multiple of 4KB? Should there be
> any asserts for those just in case?
>
> Also, can Size be 0? In which case MemEncryptSevSnpPreValidateSystemRam()
> shouldn't be called?
>

It shouldn't happen, but I'll return EFI_INVALID_PARAMETER on those conditions.


> > +  Status = gBS->InstallProtocolInterface (
> > +  &mAmdSevDxeHandle,
> > +  &gEfiMemoryAcceptProtocolGuid,
> > +  EFI_NATIVE_INTERFACE,
> > +  &mMemoryAcceptProtocol
> > +  );
>
> Should this only be installed for an SNP guest, e.g. put within the
> "if (MemEncryptSevSnpIsEnabled ()) {" check?
>
> Maybe use ASSERT_EFI_ERROR (Status)?
>

Will do, thanks for your review.

-- 
-Dionna Glaze, PhD (she/her)


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#94597): https://edk2.groups.io/g/devel/message/94597
Mute This Topic: https://groups.io/mt/93975245/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

[Leif Lindholm]

I agree similar things will certainly happen for ARM/AARCH64, which will 
probably be noticeable when I start eradicating ArmPkg and putting the 
arch-standard bits into (mostly) MdePkg.


But I like the ability to see already at the filesystem level which 
files belong to the architecture I'm currently working on and which don't.


Could we concatenate architectures?
I.e. AARCH64_ARM, IA32_X64, AARCH64_RISCV64... ?

/
Leif

On 2022-09-30 08:28, Michael D Kinney wrote:

Hi Abner,

One comment is on adding a new CPU type dir name of 'X86' for
content that is common for IA32/X64.

I can imagine a similar case for ARM/AARCH64 and for the
RISCV (32, 64, 128) cases.

I think I would prefer to drop X86 and if there are files
that are common to multiple CPU architectures then they
are considered common and are in top directory of module
and the file header and INF file can clearly document
which CPU archs the file applies.

Mike


-Original Message-
From: Chang, Abner 
Sent: Friday, September 30, 2022 12:11 AM
To: Ni, Ray ; Attar, AbdulLateef (Abdul Lateef) 
; Sunil V L
; devel@edk2.groups.io; Kinney, Michael D 

Cc: lichao ; Kirkendall, Garrett ; 
Grimes, Paul ; He,
Jiangang ; Leif Lindholm ; Andrew 
Fish 
Subject: RE: [edk2-devel] The principles of EDK2 module reconstruction for archs

[AMD Official Use Only - General]

Thanks Ray, here are my responses.
https://github.com/tianocore-docs/edk2-CCodingStandardsSpecification/pull/2

@Kinney, Michael D we may also need your clarification on the comments.



-Original Message-
From: Ni, Ray 
Sent: Thursday, September 29, 2022 3:42 PM
To: Attar, AbdulLateef (Abdul Lateef) ; Chang,
Abner ; Sunil V L ;
devel@edk2.groups.io
Cc: Kinney, Michael D ; lichao
; Kirkendall, Garrett ;
Grimes, Paul ; He, Jiangang
; Leif Lindholm ;
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,
Comments in
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
ub.com%2Ftianocore-docs%2Fedk2-
CCodingStandardsSpecification%2Fpull%2F2%23pullrequestreview-
1124763311&data=05%7C01%7CAbner.Chang%40amd.com%7Cd825e24
8625541e3f43e08daa1ee2883%7C3dd8961fe4884e608e11a82d994e183d%7C0
%7C0%7C638000341502885565%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC
4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%
7C%7C%7C&sdata=RXxgpbEr6ivbqP1R6%2B3Rxl%2ByJAnaUJuaYYKdfCH
8jo8%3D&reserved=0

We can discuss more in tomorrow's meeting.



-Original Message-
From: Attar, AbdulLateef (Abdul Lateef) 
Sent: Thursday, September 29, 2022 3:11 PM
To: Chang, Abner ; Sunil V L
; devel@edk2.groups.io; Ni, Ray

Cc: Kinney, Michael D ; lichao
; Kirkendall, Garrett
; Grimes, Paul ;

He,

Jiangang ; Leif Lindholm
; Andrew Fish 
Subject: RE: [edk2-devel] The principles of EDK2 module reconstruction
for archs

Hi Abner,
 Looks good to me.
Reviewed-by:  Abdul Lateef Attar 

Thanks
AbduL

-Original Message-
From: Chang, Abner 
Sent: 28 September 2022 20:31
To: Sunil V L ; devel@edk2.groups.io;
ray...@intel.com
Cc: Kinney, Michael D ; lichao
; Kirkendall, Garrett
; Grimes, Paul ;

He,

Jiangang ; Attar, AbdulLateef (Abdul Lateef)
; Leif Lindholm
; Andrew Fish 
Subject: RE: [edk2-devel] The principles of EDK2 module reconstruction
for archs

[AMD Official Use Only - General]

I just had created PR to update edkII C coding standard spec for the
file and directory naming. We can review and confirm this update first
and then go back to the principles of EDK2 module reconstruction for archs.
Here is the PR:


https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith

ub.com%2Ftianocore-docs%2Fedk2-

&data=05%7C01%7CAbner.Chang%40amd.c



om%7Cd825e248625541e3f43e08daa1ee2883%7C3dd8961fe4884e608e11a82
d994e18



3d%7C0%7C0%7C638000341502885565%7CUnknown%7CTWFpbGZsb3d8eyJ
WIjoiMC4wLj



AwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%
7C%7C&a



mp;sdata=X4z9puj81nIGTqtMxC9igDZyBPOT6OTWSU%2BjoIowo%2BE%3D&a
mp;reserv

ed=0
CCodingStandardsSpecification/pull/2

The naming rule is mainly for the new module or new file IMO. Some
existing module may not meet the guidelines mentioned in this spec.
Thus we need the principles of EDK2 module reconstruction on the
existing module to support other processor archs and not impacting the

existing platforms (e.g.

rename the INF file or directory to meet the guidelines).

Sunil, seems RISC-V CpuDxe meet the guideline. Please check it.
Just feel that having  CpuDxe.c to Riscv64 folder is not quite a best
solution. I think at least we can abstract the protocol structure and
protocol installation under CpuDxe\ and have the arch implementation
under arch folder. We can discuss this later after we confirming the

guideline and principles.


Thanks
Abner


-Original Message-
From: Sunil V L 
Sent: Wednesday, September 28, 2022 3:34

[edk2-devel] [PATCH v6 18/19] SecurityPkg/RngDxe: Add Arm support of RngDxe

[PierreGondois]

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 
---
 .../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/RandomNumberGenerator/RngDxe/ArmRngDxe.c
+++ b/SecurityPkg/RandomNumberGenerator/RngDxe/ArmRngDxe.c
@@ -28,70 +28,10 @@
 #include 
 #include 
 #include 
-#include 

[edk2-devel] [PATCH v6 19/19] ArmVirtPkg: Kvmtool: Add RNG support using FW-TRNG interface

[PierreGondois]

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: Sami Mujawar 
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 (#94595): https://edk2.groups.io/g/devel/message/94595
Mute This Topic: https://groups.io/mt/94020053/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH v6 17/19] SecurityPkg/RngDxe: Rename AArch64/RngDxe.c

[PierreGondois]

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 (#94593): https://edk2.groups.io/g/devel/message/94593
Mute This Topic: https://groups.io/mt/94020047/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH v6 15/19] SecurityPkg/RngDxe: Add AArch64 RawAlgorithm support through TrngLib

[PierreGondois]

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: Sami Mujawar 
---
 .../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 ();
+  while (CollectedEntropyBits < RequiredEntropyBits) {
+EntropyBits = MIN ((RequiredEntropyBits - CollectedEntropyBits), MaxBits);
+Status  = GetTrngEntropy (
+  

[edk2-devel] [PATCH v6 16/19] SecurityPkg/RngDxe: Add debug warning for NULL PcdCpuRngSupportedAlgorithm

[PierreGondois]

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 
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 (#94592): https://edk2.groups.io/g/devel/message/94592
Mute This Topic: https://groups.io/mt/94020043/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH v6 14/19] SecurityPkg/RngDxe: Check before advertising Cpu Rng algo

[PierreGondois]

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 
---
 .../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 (PcdCpuRngSupportedAlgorithm);
-
-  CopyMem (&RNGAlgorithmList[0], CpuRngSupportedAlgorithm, sizeof 
(EFI_RNG_ALGORITHM));
+  if (RNGAlgorithmList == NULL) {
+return EFI_INVALID_PARAMETER;
+  }
 
+  // There is no gap in the array, so copy the block.
+  CopyMem (RNGAlgorithmList, mAvailableAlgoArray, RequiredSize);
   *RNGAlgorithmListSize = RequiredSize;
   return EFI_SUCCESS;
 }
diff --git a/SecurityPkg/RandomNumberGenerator/RngDxe/Rand/RngDxe.c 
b/SecurityPkg/RandomNumberGenerator/RngDxe/Rand/RngDxe.c
index 8f5d8e740f5e..677600bed7ab 100644
--

[edk2-devel] [PATCH v6 13/19] SecurityPkg/RngDxe: Documentation/include/parameter cleanup

[PierreGondois]

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 (#94589): https://edk2.groups.io/g/devel/message/94589
Mute This Topic: https://groups.io/mt/94020039/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH v6 12/19] SecurityPkg/RngDxe: Remove ArchGetSupportedRngAlgorithms()

[PierreGondois]

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 v6 11/19] SecurityPkg/RngDxe: Replace Pcd with Sp80090Ctr256Guid

[PierreGondois]

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 
---
 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 (#94587): https://edk2.groups.io/g/devel/message/94587
Mute This Topic: https://groups.io/mt/94020036/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH v6 10/19] SecurityPkg/RngDxe: Rename RdRandGenerateEntropy to generic name

[PierreGondois]

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: Sami Mujawar 
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

[edk2-devel] [PATCH v6 08/19] ArmPkg: Add FID definitions for Firmware TRNG

[PierreGondois]

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: Sami Mujawar 
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 (#94584): https://edk2.groups.io/g/devel/message/94584
Mute This Topic: https://groups.io/mt/94020032/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH v6 09/19] ArmPkg/TrngLib: Add Arm Firmware TRNG library

[PierreGondois]

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: Sami Mujawar 
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_UNSUP

[edk2-devel] [PATCH v6 07/19] MdePkg/TrngLib: Add NULL instance of TRNG Library

[PierreGondois]

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: Sami Mujawar 
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

[edk2-devel] [PATCH v6 03/19] ArmPkg/ArmMonitorLib: Add ArmMonitorLib

[PierreGondois]

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 
Reviewed-by: Leif Lindholm 
---
 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 (#94579): https://edk2.groups.io/g/devel/message/94579
Mute This Topic: https://groups.io/mt/94020018/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH v6 06/19] MdePkg/TrngLib: Definition for TRNG library class interface

[PierreGondois]

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: Sami Mujawar 
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]
   ## @

[edk2-devel] [PATCH v6 05/19] ArmPkg/ArmHvcLibNull: Add NULL instance of ArmHvcLib

[PierreGondois]

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 (#94581): https://edk2.groups.io/g/devel/message/94581
Mute This Topic: https://groups.io/mt/94020024/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH v6 04/19] ArmPkg: Sort HVC/SMC section alphbetically in ArmPkg.dsc

[PierreGondois]

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 (#94580): https://edk2.groups.io/g/devel/message/94580
Mute This Topic: https://groups.io/mt/94020020/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH v6 02/19] ArmPkg/ArmMonitorLib: Definition for ArmMonitorLib library class

[PierreGondois]

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 
Reviewed-by: Leif Lindholm 
---
 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 (#94578): https://edk2.groups.io/g/devel/message/94578
Mute This Topic: https://groups.io/mt/94020016/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH v6 00/19] Add Raw algorithm support using Arm FW-TRNG interface

[PierreGondois]

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

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/ArmMonitorLib/ArmMonitorLib.c  |  34 ++
 .../Library/ArmMonitorLib/ArmMonitorLib.inf   |  29 ++
 ArmVirtPkg/ArmVirtKvmTool

[edk2-devel] [PATCH v6 01/19] ArmPkg: PCD to select conduit for monitor calls

[PierreGondois]

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: Sami Mujawar 
Signed-off-by: Pierre Gondois 
Reviewed-by: Leif Lindholm 
---
 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 (#94577): https://edk2.groups.io/g/devel/message/94577
Mute This Topic: https://groups.io/mt/94020013/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

[Michael D Kinney]

Hi Abner,

One comment is on adding a new CPU type dir name of 'X86' for 
content that is common for IA32/X64.

I can imagine a similar case for ARM/AARCH64 and for the
RISCV (32, 64, 128) cases.

I think I would prefer to drop X86 and if there are files
that are common to multiple CPU architectures then they
are considered common and are in top directory of module
and the file header and INF file can clearly document
which CPU archs the file applies.

Mike

> -Original Message-
> From: Chang, Abner 
> Sent: Friday, September 30, 2022 12:11 AM
> To: Ni, Ray ; Attar, AbdulLateef (Abdul Lateef) 
> ; Sunil V L
> ; devel@edk2.groups.io; Kinney, Michael D 
> 
> Cc: lichao ; Kirkendall, Garrett 
> ; Grimes, Paul ; He,
> Jiangang ; Leif Lindholm ; 
> Andrew Fish 
> Subject: RE: [edk2-devel] The principles of EDK2 module reconstruction for 
> archs
> 
> [AMD Official Use Only - General]
> 
> Thanks Ray, here are my responses.
> https://github.com/tianocore-docs/edk2-CCodingStandardsSpecification/pull/2
> 
> @Kinney, Michael D we may also need your clarification on the comments.
> 
> 
> > -Original Message-
> > From: Ni, Ray 
> > Sent: Thursday, September 29, 2022 3:42 PM
> > To: Attar, AbdulLateef (Abdul Lateef) ; Chang,
> > Abner ; Sunil V L ;
> > devel@edk2.groups.io
> > Cc: Kinney, Michael D ; lichao
> > ; Kirkendall, Garrett ;
> > Grimes, Paul ; He, Jiangang
> > ; Leif Lindholm ;
> > 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,
> > Comments in
> > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
> > ub.com%2Ftianocore-docs%2Fedk2-
> > CCodingStandardsSpecification%2Fpull%2F2%23pullrequestreview-
> > 1124763311&data=05%7C01%7CAbner.Chang%40amd.com%7Cd825e24
> > 8625541e3f43e08daa1ee2883%7C3dd8961fe4884e608e11a82d994e183d%7C0
> > %7C0%7C638000341502885565%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC
> > 4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%
> > 7C%7C%7C&sdata=RXxgpbEr6ivbqP1R6%2B3Rxl%2ByJAnaUJuaYYKdfCH
> > 8jo8%3D&reserved=0
> >
> > We can discuss more in tomorrow's meeting.
> >
> >
> > > -Original Message-
> > > From: Attar, AbdulLateef (Abdul Lateef) 
> > > Sent: Thursday, September 29, 2022 3:11 PM
> > > To: Chang, Abner ; Sunil V L
> > > ; devel@edk2.groups.io; Ni, Ray
> > > 
> > > Cc: Kinney, Michael D ; lichao
> > > ; Kirkendall, Garrett
> > > ; Grimes, Paul ;
> > He,
> > > Jiangang ; Leif Lindholm
> > > ; Andrew Fish 
> > > Subject: RE: [edk2-devel] The principles of EDK2 module reconstruction
> > > for archs
> > >
> > > Hi Abner,
> > > Looks good to me.
> > > Reviewed-by:  Abdul Lateef Attar 
> > >
> > > Thanks
> > > AbduL
> > >
> > > -Original Message-
> > > From: Chang, Abner 
> > > Sent: 28 September 2022 20:31
> > > To: Sunil V L ; devel@edk2.groups.io;
> > > ray...@intel.com
> > > Cc: Kinney, Michael D ; lichao
> > > ; Kirkendall, Garrett
> > > ; Grimes, Paul ;
> > He,
> > > Jiangang ; Attar, AbdulLateef (Abdul Lateef)
> > > ; Leif Lindholm
> > > ; Andrew Fish 
> > > Subject: RE: [edk2-devel] The principles of EDK2 module reconstruction
> > > for archs
> > >
> > > [AMD Official Use Only - General]
> > >
> > > I just had created PR to update edkII C coding standard spec for the
> > > file and directory naming. We can review and confirm this update first
> > > and then go back to the principles of EDK2 module reconstruction for 
> > > archs.
> > > Here is the PR:
> > >
> > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
> > > ub.com%2Ftianocore-docs%2Fedk2-
> > &data=05%7C01%7CAbner.Chang%40amd.c
> > >
> > om%7Cd825e248625541e3f43e08daa1ee2883%7C3dd8961fe4884e608e11a82
> > d994e18
> > >
> > 3d%7C0%7C0%7C638000341502885565%7CUnknown%7CTWFpbGZsb3d8eyJ
> > WIjoiMC4wLj
> > >
> > AwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%
> > 7C%7C&a
> > >
> > mp;sdata=X4z9puj81nIGTqtMxC9igDZyBPOT6OTWSU%2BjoIowo%2BE%3D&a
> > mp;reserv
> > > ed=0
> > > CCodingStandardsSpecification/pull/2
> > >
> > > The naming rule is mainly for the new module or new file IMO. Some
> > > existing module may not meet the guidelines mentioned in this spec.
> > > Thus we need the principles of EDK2 module reconstruction on the
> > > existing module to support other processor archs and not impacting the
> > existing platforms (e.g.
> > > rename the INF file or directory to meet the guidelines).
> > >
> > > Sunil, seems RISC-V CpuDxe meet the guideline. Please check it.
> > > Just feel that having  CpuDxe.c to Riscv64 folder is not quite a best
> > > solution. I think at least we can abstract the protocol structure and
> > > protocol installation under CpuDxe\ and have the arch implementation
> > > under arch folder. We can discuss this later after we confirming the
> > guideline and principles.
> > >
> > > Th

Re: [edk2-devel] [PATCH 0/2] Reconstruction on SmmCpuFeaturesLib

[Michael D Kinney]

Hi Abner,

Did you use git mv to rename the file.  It can help track history of changes.

Mike

> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Chang, Abner 
> via groups.io
> Sent: Friday, September 30, 2022 2:52 AM
> To: devel@edk2.groups.io
> Cc: Abdul Lateef Attar ; Garrett Kirkendall 
> ; Paul Grimes ;
> Dong, Eric ; Ni, Ray ; Kumar, Rahul R 
> 
> Subject: [edk2-devel] [PATCH 0/2] Reconstruction on SmmCpuFeaturesLib
> 
> From: Abner Chang 
> 
> This patch set is part of below BZ 3860:
> https://bugzilla.tianocore.org/show_bug.cgi?id=3860
> 
> This is the reconstruction on SmmCpuFeaturesLib to accommodate AMD
> implementation of SmmCpuFeaturesLib. Intel specific implementation
> is stripped away from SmmCpuFeaturesLibCommon.c and put into
> IntelSmmCpuFeaturesLib.c.
> 
> This patch set is the preparation for AMD SmmCpuFeaturesLib
> upstream. In the follow up pacthes, AMD will create a new INF file
> SmmAmdSmmCpuFeaturesLib.inf under \SmmCpuFeaturesLib,
> AmdSmmCpuFeaturesLib.c for the AMD specific implementation.
> 
> Signed-off-by: Abner Chang 
> Cc: Abdul Lateef Attar 
> Cc: Garrett Kirkendall 
> Cc: Paul Grimes 
> Cc: Eric Dong 
> Cc: Ray Ni 
> Cc: Rahul Kumar 
> 
> Abner Chang (2):
>   UefiCpuPkg/SmmCpuFeaturesLib: Abstract arch dependent code
>   UefiCpuPkg/SmmCpuFeaturesLib: Clean up header file inclusion in
> SmmStm.c
> 
>  .../SmmCpuFeaturesLib/SmmCpuFeaturesLib.inf   |   1 +
>  .../SmmCpuFeaturesLibStm.inf  |   1 +
>  .../StandaloneMmCpuFeaturesLib.inf|   1 +
>  .../SmmCpuFeaturesLib/CpuFeaturesLib.h|   6 +
>  .../IntelSmmCpuFeaturesLib.c  | 403 ++
>  .../SmmCpuFeaturesLibCommon.c | 391 +
>  UefiCpuPkg/Library/SmmCpuFeaturesLib/SmmStm.c |   3 -
>  7 files changed, 413 insertions(+), 393 deletions(-)
>  create mode 100644 
> UefiCpuPkg/Library/SmmCpuFeaturesLib/IntelSmmCpuFeaturesLib.c
> 
> --
> 2.37.1.windows.1
> 
> 
> 
> 
> 



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#94574): https://edk2.groups.io/g/devel/message/94574
Mute This Topic: https://groups.io/mt/94013083/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v3 29/34] MdePkg/BaseSynchronizationLib: LoongArch cache related code.

[Michael D Kinney]

Reviewed-by: Michael D Kinney 

> -Original Message-
> From: Chao Li 
> Sent: Tuesday, September 27, 2022 4:14 AM
> To: devel@edk2.groups.io
> Cc: Kinney, Michael D ; Gao, Liming 
> ; Liu, Zhiguang
> ; Baoqi Zhang 
> Subject: [PATCH v3 29/34] MdePkg/BaseSynchronizationLib: LoongArch cache 
> related code.
> 
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4053
> 
> Support LoongArch cache related functions.
> 
> Cc: Michael D Kinney 
> Cc: Liming Gao 
> Cc: Zhiguang Liu 
> 
> Signed-off-by: Chao Li 
> Co-authored-by: Baoqi Zhang 
> ---
>  .../BaseSynchronizationLib.inf|   6 +
>  .../LoongArch64/AsmSynchronization.S  | 122 +
>  .../LoongArch64/Synchronization.c | 233 ++
>  3 files changed, 361 insertions(+)
>  create mode 100644 
> MdePkg/Library/BaseSynchronizationLib/LoongArch64/AsmSynchronization.S
>  create mode 100644 
> MdePkg/Library/BaseSynchronizationLib/LoongArch64/Synchronization.c
> 
> diff --git a/MdePkg/Library/BaseSynchronizationLib/BaseSynchronizationLib.inf
> b/MdePkg/Library/BaseSynchronizationLib/BaseSynchronizationLib.inf
> index 02ba12961a..dd66ec1d03 100755
> --- a/MdePkg/Library/BaseSynchronizationLib/BaseSynchronizationLib.inf
> +++ b/MdePkg/Library/BaseSynchronizationLib/BaseSynchronizationLib.inf
> @@ -4,6 +4,7 @@
>  #  Copyright (c) 2007 - 2018, Intel Corporation. All rights reserved.
> 
>  #  Portions copyright (c) 2008 - 2009, Apple Inc. All rights reserved.
> 
>  #  Copyright (c) 2020, Hewlett Packard Enterprise Development LP. All rights 
> reserved.
> 
> +#  Copyright (c) 2022, Loongson Technology Corporation Limited. All rights 
> reserved.
> 
>  #
> 
>  #  SPDX-License-Identifier: BSD-2-Clause-Patent
> 
>  #
> 
> @@ -82,6 +83,11 @@
>Synchronization.c
> 
>RiscV64/Synchronization.S
> 
> 
> 
> +[Sources.LOONGARCH64]
> 
> +  Synchronization.c
> 
> +  LoongArch64/Synchronization.c| GCC
> 
> +  LoongArch64/AsmSynchronization.S | GCC
> 
> +
> 
>  [Packages]
> 
>MdePkg/MdePkg.dec
> 
> 
> 
> diff --git 
> a/MdePkg/Library/BaseSynchronizationLib/LoongArch64/AsmSynchronization.S
> b/MdePkg/Library/BaseSynchronizationLib/LoongArch64/AsmSynchronization.S
> new file mode 100644
> index 00..3f1b06172d
> --- /dev/null
> +++ b/MdePkg/Library/BaseSynchronizationLib/LoongArch64/AsmSynchronization.S
> @@ -0,0 +1,122 @@
> +#--
> +#
> +# LoongArch synchronization ASM functions.
> +#
> +# Copyright (c) 2022, Loongson Technology Corporation Limited. All rights 
> reserved.
> +#
> +# SPDX-License-Identifier: BSD-2-Clause-Patent
> +#
> +#--
> +
> +ASM_GLOBAL ASM_PFX(AsmInternalSyncCompareExchange16)
> +ASM_GLOBAL ASM_PFX(AsmInternalSyncCompareExchange32)
> +ASM_GLOBAL ASM_PFX(AsmInternalSyncCompareExchange64)
> +ASM_GLOBAL ASM_PFX(AsmInternalSyncIncrement)
> +ASM_GLOBAL ASM_PFX(AsmInternalSyncDecrement)
> +
> +/**
> +UINT32
> +EFIAPI
> +AsmInternalSyncCompareExchange16 (
> +  IN volatile UINT32 *Ptr32,
> +  IN UINT64  Mask,
> +  IN UINT64  LocalCompareValue,
> +  IN UINT64  LocalExchangeValue
> +  )
> +**/
> +ASM_PFX(AsmInternalSyncCompareExchange16):
> +1:
> +  ll.w  $t0, $a0, 0x0
> +  and   $t1, $t0, $a1
> +  bne   $t1, $a2, 2f
> +  andn  $t1, $t0, $a1
> +  or$t1, $t1, $a3
> +  sc.w  $t1, $a0, 0x0
> +  beqz  $t1, 1b
> +  b 3f
> +2:
> +  dbar  0
> +3:
> +  move   $a0, $t0
> +  jirl   $zero, $ra, 0
> +
> +/**
> +UINT32
> +EFIAPI
> +AsmInternalSyncCompareExchange32 (
> +  IN volatile UINT32 *Value,
> +  IN UINT64  CompareValue,
> +  IN UINT64  ExchangeValue
> +  )
> +**/
> +ASM_PFX(AsmInternalSyncCompareExchange32):
> +1:
> +  ll.w  $t0, $a0, 0x0
> +  bne   $t0, $a1, 2f
> +  move  $t0, $a2
> +  sc.w  $t0, $a0, 0x0
> +  beqz  $t0, 1b
> +  b 3f
> +2:
> +  dbar  0
> +3:
> +  move   $a0, $t0
> +  jirl   $zero, $ra, 0
> +
> +/**
> +UINT64
> +EFIAPI
> +AsmInternalSyncCompareExchange64 (
> +  IN volatile UINT64 *Value,
> +  IN UINT64  CompareValue,
> +  IN UINT64  ExchangeValue
> +  )
> +**/
> +ASM_PFX(AsmInternalSyncCompareExchange64):
> +1:
> +  ll.d  $t0, $a0, 0x0
> +  bne   $t0, $a1, 2f
> +  move  $t0, $a2
> +  sc.d  $t0, $a0, 0x0
> +  beqz  $t0, 1b
> +  b 3f
> +2:
> +  dbar  0
> +3:
> +  move   $a0, $t0
> +  jirl   $zero, $ra, 0
> +
> +/**
> +UINT32
> +EFIAPI
> +AsmInternalSyncIncrement (
> +  IN  volatile UINT32  *Value
> +  )
> +**/
> +ASM_PFX(AsmInternalSyncIncrement):
> +  move $t0, $a0
> +  dbar 0
> +  ld.w $t1, $t0, 0x0
> +  li.w $t2, 1
> +  amadd.w  $t1, $t2, $t0
> +
> +  ld.w $a0, $t0, 0x0
> +  jirl $zero, $ra, 0
> +
> +/**
> +UINT32
> +EFIAPI
> +AsmInternalSyncDecrement (
> +  IN  volatile UINT32  *Value
> +  )
> +**/
> +ASM_PFX(AsmInternalSyncDecrement):
> +  move $t0, $a0
> +  dbar 0
> +  ld.w $t1, $t0, 0x0
> +  li.w $t2, -1
> +

Re: [edk2-devel] [edk2-platforms PATCH 0/2] Platform/RaspberryPi: SyncPcie() fixes

[Jeremy Linton]

On 9/29/22 14:53, Adrien Thierry wrote:

This patch series does a few fixes in the SyncPcie() function, more
specifically in the logic that deletes the pci node to prevent Linux from
resetting the XHCI controller.


Hmm, that code not being exactly right isn't surprising, I went through 
about a dozen revisions looking for the one that fixed it consistently 
and in the end this version worked with some older kernels (and likely 
dt) but doesn't work with any of the recent ones.


But... I think I found an actual fix a couple months ago while testing 
the DT->SMCCC pci config space code. Which is to update the ranges 
property as well. With that change the firmware can reset the XHCI 
controller in recent Linux's, so there isn't a need to remove the XHCI node.



There is a copy of the patch hiding on my github

https://github.com/jlinton/edk2-platforms/commit/50540bd24f93b633c3597b5dc58c1a1a3b49bf7f#diff-373e67aaa16dd9ac2428d5acc3d73ef218b2ed6d24f3350d5af558cba03cf5adR378

along with a change to update the compatible property to 
pci-host-smc-generic and remove the ranges property which should be 
ignored... :)


If you just add the range tweak, does that fix the XHCI config in your 
setup too?



I really need to start getting many of those old/stale patches cleaned 
up and merged, but its not been a high priority.





Adrien Thierry (2):
   Platform/RaspberryPi: fix pci DT node address in SyncPcie()
   Platform/RaspberryPi: delete usb node instead of pci in SyncPcie()

  Platform/RaspberryPi/Drivers/FdtDxe/FdtDxe.c | 6 +++---
  1 file changed, 3 insertions(+), 3 deletions(-)


base-commit: e55f0527dde48a5f139c1b8f35acc4e6b59dd794




-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#94572): https://edk2.groups.io/g/devel/message/94572
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]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH] SecurityPkg: Remove enforcement of final GoIdle transition for CRB commands

[Yao, Jiewen]

Merged https://github.com/tianocore/edk2/pull/3431


> -Original Message-
> From: Gonzalez Del Cueto, Rodrigo 
> Sent: Thursday, September 22, 2022 3:36 PM
> To: devel@edk2.groups.io
> Cc: Gonzalez Del Cueto, Rodrigo ;
> Yao, Jiewen ; Wang, Jian J 
> Subject: [PATCH] SecurityPkg: Remove enforcement of final GoIdle transition
> for CRB commands
> 
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4077
> 
> Following the design described in the TCG specification,
> the driver implementation of the CRB protocol does not require
> enforcing completing the transition to goIdle at the end of a command
> sequence.
> 
> Signed-off-by: "Gonzalez Del Cueto, Rodrigo"
> 
> Cc: Jiewen Yao 
> Cc: Jian J Wang 
> ---
>  SecurityPkg/Library/Tpm2DeviceLibDTpm/Tpm2Ptp.c | 13 -
>  1 file changed, 13 deletions(-)
> 
> diff --git a/SecurityPkg/Library/Tpm2DeviceLibDTpm/Tpm2Ptp.c
> b/SecurityPkg/Library/Tpm2DeviceLibDTpm/Tpm2Ptp.c
> index 840265292a..1f9ac5ab5a 100644
> --- a/SecurityPkg/Library/Tpm2DeviceLibDTpm/Tpm2Ptp.c
> +++ b/SecurityPkg/Library/Tpm2DeviceLibDTpm/Tpm2Ptp.c
> @@ -381,19 +381,6 @@ GoIdle_Exit:
>//
>MmioWrite32 ((UINTN)&CrbReg->CrbControlRequest,
> PTP_CRB_CONTROL_AREA_REQUEST_GO_IDLE);
> 
> -  //
> -  // Only enforce Idle state transition if execution fails when
> CRBIdleBypass==1
> -  // Leave regular Idle delay at the beginning of next command execution
> -  //
> -  if (GetCachedIdleByPass () == 1) {
> -Status = PtpCrbWaitRegisterBits (
> -   &CrbReg->CrbControlStatus,
> -   PTP_CRB_CONTROL_AREA_STATUS_TPM_IDLE,
> -   0,
> -   PTP_TIMEOUT_C
> -   );
> -  }
> -
>return Status;
>  }
> 
> --
> 2.25.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#94571): https://edk2.groups.io/g/devel/message/94571
Mute This Topic: https://groups.io/mt/93843955/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v3 29/34] MdePkg/BaseSynchronizationLib: LoongArch cache related code.

[Chao Li]

Hi Mike,
I'm guessing you're a little busy, or forgot about this issue. :)
I have converted the inline assembly code to ASM code, please review this patch 
again, thanks!

Thanks,
Chao


On 9月 27 2022, at 7:27 晚上, chao li  wrote:
> Hi Mike,
> I have converted the inline assembly code to ASM code, please review this 
> patch again, thanks!
>
>
> Thanks,
> Chao
> 
>
> On 9月 27 2022, at 7:13 晚上, Chao Li  wrote:
> > REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4053
> >
> > Support LoongArch cache related functions.
> > Cc: Michael D Kinney 
> > Cc: Liming Gao 
> > Cc: Zhiguang Liu 
> >
> > Signed-off-by: Chao Li 
> > Co-authored-by: Baoqi Zhang 
> > ---
> > .../BaseSynchronizationLib.inf | 6 +
> > .../LoongArch64/AsmSynchronization.S | 122 +
> > .../LoongArch64/Synchronization.c | 233 ++
> > 3 files changed, 361 insertions(+)
> > create mode 100644 
> > MdePkg/Library/BaseSynchronizationLib/LoongArch64/AsmSynchronization.S
> > create mode 100644 
> > MdePkg/Library/BaseSynchronizationLib/LoongArch64/Synchronization.c
> >
> > diff --git 
> > a/MdePkg/Library/BaseSynchronizationLib/BaseSynchronizationLib.inf 
> > b/MdePkg/Library/BaseSynchronizationLib/BaseSynchronizationLib.inf
> > index 02ba12961a..dd66ec1d03 100755
> > --- a/MdePkg/Library/BaseSynchronizationLib/BaseSynchronizationLib.inf
> > +++ b/MdePkg/Library/BaseSynchronizationLib/BaseSynchronizationLib.inf
> > @@ -4,6 +4,7 @@
> > # Copyright (c) 2007 - 2018, Intel Corporation. All rights reserved.
> >
> > # Portions copyright (c) 2008 - 2009, Apple Inc. All rights reserved.
> > # Copyright (c) 2020, Hewlett Packard Enterprise Development LP. All rights 
> > reserved.
> > +# Copyright (c) 2022, Loongson Technology Corporation Limited. All rights 
> > reserved.
> > #
> > # SPDX-License-Identifier: BSD-2-Clause-Patent
> > #
> > @@ -82,6 +83,11 @@
> > Synchronization.c
> >
> > RiscV64/Synchronization.S
> >
> >
> > +[Sources.LOONGARCH64]
> > + Synchronization.c
> > + LoongArch64/Synchronization.c | GCC
> > + LoongArch64/AsmSynchronization.S | GCC
> > +
> > [Packages]
> > MdePkg/MdePkg.dec
> >
> >
> > diff --git 
> > a/MdePkg/Library/BaseSynchronizationLib/LoongArch64/AsmSynchronization.S 
> > b/MdePkg/Library/BaseSynchronizationLib/LoongArch64/AsmSynchronization.S
> > new file mode 100644
> > index 00..3f1b06172d
> > --- /dev/null
> > +++ b/MdePkg/Library/BaseSynchronizationLib/LoongArch64/AsmSynchronization.S
> > @@ -0,0 +1,122 @@
> > +#--
> > +#
> > +# LoongArch synchronization ASM functions.
> > +#
> > +# Copyright (c) 2022, Loongson Technology Corporation Limited. All rights 
> > reserved.
> > +#
> > +# SPDX-License-Identifier: BSD-2-Clause-Patent
> > +#
> > +#--
> > +
> > +ASM_GLOBAL ASM_PFX(AsmInternalSyncCompareExchange16)
> > +ASM_GLOBAL ASM_PFX(AsmInternalSyncCompareExchange32)
> > +ASM_GLOBAL ASM_PFX(AsmInternalSyncCompareExchange64)
> > +ASM_GLOBAL ASM_PFX(AsmInternalSyncIncrement)
> > +ASM_GLOBAL ASM_PFX(AsmInternalSyncDecrement)
> > +
> > +/**
> > +UINT32
> > +EFIAPI
> > +AsmInternalSyncCompareExchange16 (
> > + IN volatile UINT32 *Ptr32,
> > + IN UINT64 Mask,
> > + IN UINT64 LocalCompareValue,
> > + IN UINT64 LocalExchangeValue
> > + )
> > +**/
> > +ASM_PFX(AsmInternalSyncCompareExchange16):
> > +1:
> > + ll.w $t0, $a0, 0x0
> > + and $t1, $t0, $a1
> > + bne $t1, $a2, 2f
> > + andn $t1, $t0, $a1
> > + or $t1, $t1, $a3
> > + sc.w $t1, $a0, 0x0
> > + beqz $t1, 1b
> > + b 3f
> > +2:
> > + dbar 0
> > +3:
> > + move $a0, $t0
> > + jirl $zero, $ra, 0
> > +
> > +/**
> > +UINT32
> > +EFIAPI
> > +AsmInternalSyncCompareExchange32 (
> > + IN volatile UINT32 *Value,
> > + IN UINT64 CompareValue,
> > + IN UINT64 ExchangeValue
> > + )
> > +**/
> > +ASM_PFX(AsmInternalSyncCompareExchange32):
> > +1:
> > + ll.w $t0, $a0, 0x0
> > + bne $t0, $a1, 2f
> > + move $t0, $a2
> > + sc.w $t0, $a0, 0x0
> > + beqz $t0, 1b
> > + b 3f
> > +2:
> > + dbar 0
> > +3:
> > + move $a0, $t0
> > + jirl $zero, $ra, 0
> > +
> > +/**
> > +UINT64
> > +EFIAPI
> > +AsmInternalSyncCompareExchange64 (
> > + IN volatile UINT64 *Value,
> > + IN UINT64 CompareValue,
> > + IN UINT64 ExchangeValue
> > + )
> > +**/
> > +ASM_PFX(AsmInternalSyncCompareExchange64):
> > +1:
> > + ll.d $t0, $a0, 0x0
> > + bne $t0, $a1, 2f
> > + move $t0, $a2
> > + sc.d $t0, $a0, 0x0
> > + beqz $t0, 1b
> > + b 3f
> > +2:
> > + dbar 0
> > +3:
> > + move $a0, $t0
> > + jirl $zero, $ra, 0
> > +
> > +/**
> > +UINT32
> > +EFIAPI
> > +AsmInternalSyncIncrement (
> > + IN volatile UINT32 *Value
> > + )
> > +**/
> > +ASM_PFX(AsmInternalSyncIncrement):
> > + move $t0, $a0
> > + dbar 0
> > + ld.w $t1, $t0, 0x0
> > + li.w $t2, 1
> > + amadd.w $t1, $t2, $t0
> > +
> > + ld.w $a0, $t0, 0x0
> > + jirl $zero, $ra, 0
> > +
> > +/**
> > +UINT32
> > +EFIAPI
> > +AsmInternalSyncDecrement (
> > + IN volatile UINT32 *Value
> > + )
> > +**/

[edk2-devel] [PATCH 2/2] UefiCpuPkg/SmmCpuFeaturesLib: Clean up header file inclusion in SmmStm.c

[Chang, Abner via groups.io]

From: Abner Chang 

Remove the header files those are already included in
CpuFeatureLib.h.

Signed-off-by: Abner Chang 
Cc: Abdul Lateef Attar 
Cc: Garrett Kirkendall 
Cc: Paul Grimes 
Cc: Eric Dong 
Cc: Ray Ni 
Cc: Rahul Kumar 
---
 UefiCpuPkg/Library/SmmCpuFeaturesLib/SmmStm.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/UefiCpuPkg/Library/SmmCpuFeaturesLib/SmmStm.c 
b/UefiCpuPkg/Library/SmmCpuFeaturesLib/SmmStm.c
index 4e8f897f5e9..3cf162ada01 100644
--- a/UefiCpuPkg/Library/SmmCpuFeaturesLib/SmmStm.c
+++ b/UefiCpuPkg/Library/SmmCpuFeaturesLib/SmmStm.c
@@ -7,11 +7,8 @@
 **/
 
 #include 
-#include 
 #include 
-#include 
 #include 
-#include 
 #include 
 #include 
 #include 
-- 
2.37.1.windows.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#94569): https://edk2.groups.io/g/devel/message/94569
Mute This Topic: https://groups.io/mt/94013091/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] UefiCpuPkg/SmmCpuFeaturesLib: Abstract arch dependent code

[Chang, Abner via groups.io]

From: Abner Chang 

This change strips away Intel X86 implementation and put
it in the IntelSmmCpuFeatureLib

Signed-off-by: Abner Chang 
Cc: Abdul Lateef Attar 
Cc: Garrett Kirkendall 
Cc: Paul Grimes 
Cc: Eric Dong 
Cc: Ray Ni 
Cc: Rahul Kumar 
---
 .../SmmCpuFeaturesLib/SmmCpuFeaturesLib.inf   |   1 +
 .../SmmCpuFeaturesLibStm.inf  |   1 +
 .../StandaloneMmCpuFeaturesLib.inf|   1 +
 .../SmmCpuFeaturesLib/CpuFeaturesLib.h|   6 +
 .../IntelSmmCpuFeaturesLib.c  | 403 ++
 .../SmmCpuFeaturesLibCommon.c | 391 +
 6 files changed, 413 insertions(+), 390 deletions(-)
 create mode 100644 
UefiCpuPkg/Library/SmmCpuFeaturesLib/IntelSmmCpuFeaturesLib.c

diff --git a/UefiCpuPkg/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.inf 
b/UefiCpuPkg/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.inf
index 7b5cef97008..9ac7dde78f8 100644
--- a/UefiCpuPkg/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.inf
+++ b/UefiCpuPkg/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.inf
@@ -18,6 +18,7 @@
 
 [Sources]
   CpuFeaturesLib.h
+  IntelSmmCpuFeaturesLib.c
   SmmCpuFeaturesLib.c
   SmmCpuFeaturesLibCommon.c
   SmmCpuFeaturesLibNoStm.c
diff --git a/UefiCpuPkg/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLibStm.inf 
b/UefiCpuPkg/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLibStm.inf
index 85214ee31cd..86d367e0a09 100644
--- a/UefiCpuPkg/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLibStm.inf
+++ b/UefiCpuPkg/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLibStm.inf
@@ -19,6 +19,7 @@
 
 [Sources]
   CpuFeaturesLib.h
+  IntelSmmCpuFeaturesLib.c
   SmmCpuFeaturesLibCommon.c
   SmmStm.c
   SmmStm.h
diff --git 
a/UefiCpuPkg/Library/SmmCpuFeaturesLib/StandaloneMmCpuFeaturesLib.inf 
b/UefiCpuPkg/Library/SmmCpuFeaturesLib/StandaloneMmCpuFeaturesLib.inf
index 3eacab48db3..61890205e18 100644
--- a/UefiCpuPkg/Library/SmmCpuFeaturesLib/StandaloneMmCpuFeaturesLib.inf
+++ b/UefiCpuPkg/Library/SmmCpuFeaturesLib/StandaloneMmCpuFeaturesLib.inf
@@ -20,6 +20,7 @@
 
 [Sources]
   CpuFeaturesLib.h
+  IntelSmmCpuFeaturesLib.c
   StandaloneMmCpuFeaturesLib.c
   SmmCpuFeaturesLibCommon.c
   SmmCpuFeaturesLibNoStm.c
diff --git a/UefiCpuPkg/Library/SmmCpuFeaturesLib/CpuFeaturesLib.h 
b/UefiCpuPkg/Library/SmmCpuFeaturesLib/CpuFeaturesLib.h
index 8a1c2adc5c4..fd3e902547c 100644
--- a/UefiCpuPkg/Library/SmmCpuFeaturesLib/CpuFeaturesLib.h
+++ b/UefiCpuPkg/Library/SmmCpuFeaturesLib/CpuFeaturesLib.h
@@ -9,6 +9,12 @@
 #ifndef CPU_FEATURES_LIB_H_
 #define CPU_FEATURES_LIB_H_
 
+#include 
+#include 
+#include 
+#include 
+#include 
+
 /**
   Performs library initialization.
 
diff --git a/UefiCpuPkg/Library/SmmCpuFeaturesLib/IntelSmmCpuFeaturesLib.c 
b/UefiCpuPkg/Library/SmmCpuFeaturesLib/IntelSmmCpuFeaturesLib.c
new file mode 100644
index 000..cb4897b21e3
--- /dev/null
+++ b/UefiCpuPkg/Library/SmmCpuFeaturesLib/IntelSmmCpuFeaturesLib.c
@@ -0,0 +1,403 @@
+/** @file
+Implementation shared across all library instances.
+
+Copyright (c) 2010 - 2019, Intel Corporation. All rights reserved.
+Copyright (c) Microsoft Corporation.
+SPDX-License-Identifier: BSD-2-Clause-Patent
+
+**/
+
+#include "CpuFeaturesLib.h"
+
+#include 
+#include 
+#include 
+
+//
+// Machine Specific Registers (MSRs)
+//
+#define  SMM_FEATURES_LIB_IA32_MTRR_CAP0x0FE
+#define  SMM_FEATURES_LIB_IA32_FEATURE_CONTROL 0x03A
+#define  SMM_FEATURES_LIB_IA32_SMRR_PHYSBASE   0x1F2
+#define  SMM_FEATURES_LIB_IA32_SMRR_PHYSMASK   0x1F3
+#define  SMM_FEATURES_LIB_IA32_CORE_SMRR_PHYSBASE  0x0A0
+#define  SMM_FEATURES_LIB_IA32_CORE_SMRR_PHYSMASK  0x0A1
+#defineEFI_MSR_SMRR_MASK   0xF000
+#defineEFI_MSR_SMRR_PHYS_MASK_VALIDBIT11
+#define  SMM_FEATURES_LIB_SMM_FEATURE_CONTROL  0x4E0
+
+//
+// MSRs required for configuration of SMM Code Access Check
+//
+#define SMM_FEATURES_LIB_IA32_MCA_CAP  0x17D
+#define   SMM_CODE_ACCESS_CHK_BIT  BIT58
+
+//
+// Set default value to assume IA-32 Architectural MSRs are used
+//
+UINT32  mSmrrPhysBaseMsr = SMM_FEATURES_LIB_IA32_SMRR_PHYSBASE;
+UINT32  mSmrrPhysMaskMsr = SMM_FEATURES_LIB_IA32_SMRR_PHYSMASK;
+
+//
+// Set default value to assume MTRRs need to be configured on each SMI
+//
+BOOLEAN  mNeedConfigureMtrrs = TRUE;
+
+//
+// Array for state of SMRR enable on all CPUs
+//
+BOOLEAN  *mSmrrEnabled;
+
+/**
+  Performs library initialization.
+
+  This initialization function contains common functionality shared betwen all
+  library instance constructors.
+
+**/
+VOID
+CpuFeaturesLibInitialization (
+  VOID
+  )
+{
+  UINT32  RegEax;
+  UINT32  RegEdx;
+  UINTN   FamilyId;
+  UINTN   ModelId;
+
+  //
+  // Retrieve CPU Family and Model
+  //
+  AsmCpuid (CPUID_VERSION_INFO, &RegEax, NULL, NULL, &RegEdx);
+  FamilyId = (RegEax >> 8) & 0xf;
+  ModelId  = (RegEax >> 4) & 0xf;
+  if ((FamilyId == 0x06) || (FamilyId == 0x0f)) {
+ModelId = ModelId | ((RegEax >> 12) & 0xf0);
+  }
+
+  //
+  // Check CPUID(CPUID_VERSION_INFO).EDX[12] fo

[edk2-devel] [PATCH 0/2] Reconstruction on SmmCpuFeaturesLib

[Chang, Abner via groups.io]

From: Abner Chang 

This patch set is part of below BZ 3860:
https://bugzilla.tianocore.org/show_bug.cgi?id=3860

This is the reconstruction on SmmCpuFeaturesLib to accommodate AMD
implementation of SmmCpuFeaturesLib. Intel specific implementation
is stripped away from SmmCpuFeaturesLibCommon.c and put into
IntelSmmCpuFeaturesLib.c.

This patch set is the preparation for AMD SmmCpuFeaturesLib
upstream. In the follow up pacthes, AMD will create a new INF file
SmmAmdSmmCpuFeaturesLib.inf under \SmmCpuFeaturesLib, 
AmdSmmCpuFeaturesLib.c for the AMD specific implementation.

Signed-off-by: Abner Chang 
Cc: Abdul Lateef Attar 
Cc: Garrett Kirkendall 
Cc: Paul Grimes 
Cc: Eric Dong 
Cc: Ray Ni 
Cc: Rahul Kumar 

Abner Chang (2):
  UefiCpuPkg/SmmCpuFeaturesLib: Abstract arch dependent code
  UefiCpuPkg/SmmCpuFeaturesLib: Clean up header file inclusion in
SmmStm.c

 .../SmmCpuFeaturesLib/SmmCpuFeaturesLib.inf   |   1 +
 .../SmmCpuFeaturesLibStm.inf  |   1 +
 .../StandaloneMmCpuFeaturesLib.inf|   1 +
 .../SmmCpuFeaturesLib/CpuFeaturesLib.h|   6 +
 .../IntelSmmCpuFeaturesLib.c  | 403 ++
 .../SmmCpuFeaturesLibCommon.c | 391 +
 UefiCpuPkg/Library/SmmCpuFeaturesLib/SmmStm.c |   3 -
 7 files changed, 413 insertions(+), 393 deletions(-)
 create mode 100644 
UefiCpuPkg/Library/SmmCpuFeaturesLib/IntelSmmCpuFeaturesLib.c

-- 
2.37.1.windows.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#94567): https://edk2.groups.io/g/devel/message/94567
Mute This Topic: https://groups.io/mt/94013083/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] The principles of EDK2 module reconstruction for archs (wiki page on tianocore.github.io)

[Chang, Abner via groups.io]

[AMD Official Use Only - General]

Hi all,
Addition to the File and Directory Names in EDK II C Coding standard spec, here 
is the draft of wiki page for reconstructing the existing module for processor 
arch and vendor implementation.
https://github.com/changab/tianocore.github.io/wiki/The-Principles-of-EDK2-Module-Reconstruction-for-the-Processor-Architecture

Thanks
Abner


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#94566): https://edk2.groups.io/g/devel/message/94566
Mute This Topic: https://groups.io/mt/94012743/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v4 4/6] MdeModulePkg: DxeMain accepts all memory at EBS if needed

[Ard Biesheuvel]

On Thu, 29 Sept 2022 at 20:14, Dionna Amalie Glaze
 wrote:
>
> >
> > Can you explain a bit more why this PCD is needed?
> >
>
> I'll expand the comment further, but essentially we need a bit in the
> firmware to persist from a call into a protocol to the eventual call
> to ExitBootServices. If we needed offline persistence, then we'd need
> to standardize a new bit in the OsIndications variable. We don't so we
> make due with a Pcd.
>

As I mentioned elsewhere, I'd prefer to avoid a dynamic PCD here.

For Ray's benefit, I'll copy/paste my proposal here that I made in one
of the other thread:

"""
Given that dynamic PCDs are optional but protocols are not, can we
just drop the PCD and (in view of some other comments below) do the
following:

- Define a protocol in MdeModulePkg that ExitBootServices() will
invoke after disarming the timer but before finalizing the memory map.
It doesn't have to be specific to memory acceptance at all, the only
thing that matters is that it is invoked at the right time (and
perhaps only on the first call to EBS()). E.g.,
gEdkiiExitBootServicesCallbackProtocol with a single method called
TerminateMemoryMapPreHook(). This protocol is fundamentally internal
to EDK2 and does not require inclusion in PI or UEFI

- Define a protocol in OvmfPkg that will be called by the OS loader to
indicate that it is capable of taking charge of the unaccepted memory,
and so it does not need the firmware to do so on its behalf, by
accepting all of it during ExitBootServices().

- Implement a single DXE driver in OvmfPkg (or add the functionality
to an existing one) that provides an implementation of the former
protocol, and implements the latter protocol by uninstalling the
former again. This means the 'accept all memory' routine can be moved
out of DXE core as well, and into your driver.
"""


>
> >
> > I am not following the logic here 100%. As far as I can tell, if
> > accepting all memory succeeded without errors, ExitBootServices()
> > returns with EFI_SUCCESS, even though it has modified the memory map.
> > This means the actual memory map is out of sync with the last
> > GetMemoryMap() call performed by the OS loader before it called
> > ExitBootServices(), and so it will still contain unaccepted memory,
> > right?
>
> Ah yes you're right, I missed that part. I'll change it to return
> EFI_WARN_STALE_DATA if any memory region gets accepted, and force a
> failure in DxeMain if the status is an error or that warning.
>

The only documented error code for ExitBootServices() is
EFI_INVALID_PARAMETER, which indicates that the map key has changes,
so this is the one you should return in this case. EFI_WARN_STALE_DATA
is not an error code (it has the MSB cleared) so macros like
EFI_ERROR() will not identify it as an error.


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#94565): https://edk2.groups.io/g/devel/message/94565
Mute This Topic: https://groups.io/mt/93975251/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] edk2/ovmf version tracking

[Gerd Hoffmann]

  Hi,

OVMF builds carry version '0.0.0'.  I'd like to replace that with
something more useful.  Attached below is a patch doing that by
hooking a script into PREBUILD.  That is probably not the most
elegant way to do it ...

While looking around I have not found any edk2 version information in
the source tree.  So, when building from a edk2 tarball there is no
version information available.  Other projects have a VERSION file in
the toplevel directory, or something language-specific like the version
field in python's setup.cfg.  I think ekd2 should store the name of the
most recent stable tag in some file too.

I think the version information should be automatically generated by
some script to be as precise a possible.  When building from a git
checkout we can get the version information from git.  When building
packages (rpm/deb/...) storing the package version would be useful too,
either by automatically detecting package builds (as the script below
does for rpm builds), or by allowing to override the version information
using build options so package build scrips can handle it that way.

Comments?
Suggestions how to do that best?

take care,
  Gerd

diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc
index f39d9cd117e6..94029720318f 100644
--- a/OvmfPkg/OvmfPkgX64.dsc
+++ b/OvmfPkg/OvmfPkgX64.dsc
@@ -24,6 +24,7 @@ [Defines]
   BUILD_TARGETS  = NOOPT|DEBUG|RELEASE
   SKUID_IDENTIFIER   = DEFAULT
   FLASH_DEFINITION   = OvmfPkg/OvmfPkgX64.fdf
+  PREBUILD   = sh OvmfPkg/SmbiosPlatformDxe/Version.sh
 
   #
   # Defines for default states.  These can be changed on the command line.
diff --git a/OvmfPkg/SmbiosPlatformDxe/SmbiosPlatformDxe.c 
b/OvmfPkg/SmbiosPlatformDxe/SmbiosPlatformDxe.c
index 94249d3ff1b0..e3a16196bbdc 100644
--- a/OvmfPkg/SmbiosPlatformDxe/SmbiosPlatformDxe.c
+++ b/OvmfPkg/SmbiosPlatformDxe/SmbiosPlatformDxe.c
@@ -14,10 +14,11 @@
 #include   // EFI_SMBIOS_PROTOCOL
 
 #include "SmbiosPlatformDxe.h"
+#include "Version.h"
 
 #define TYPE0_STRINGS \
   "EFI Development Kit II / OVMF\0" /* Vendor */ \
-  "0.0.0\0" /* BiosVersion */ \
+  EDK2_BUILD_VERSION "\0"   /* BiosVersion */ \
   "02/06/2015\0"/* BiosReleaseDate */
 //
 // Type definition and contents of the default Type 0 SMBIOS table.
diff --git a/OvmfPkg/SmbiosPlatformDxe/.gitignore 
b/OvmfPkg/SmbiosPlatformDxe/.gitignore
new file mode 100644
index ..a40297ad16db
--- /dev/null
+++ b/OvmfPkg/SmbiosPlatformDxe/.gitignore
@@ -0,0 +1 @@
+Version.h
diff --git a/OvmfPkg/SmbiosPlatformDxe/Version.sh 
b/OvmfPkg/SmbiosPlatformDxe/Version.sh
new file mode 100755
index ..31d4f5c0080b
--- /dev/null
+++ b/OvmfPkg/SmbiosPlatformDxe/Version.sh
@@ -0,0 +1,18 @@
+#!/bin/sh
+
+outfile="${0%.sh}.h"
+
+if test "${RPM_PACKAGE_NAME}" != ""; then
+# building rpm package
+VERSION="${RPM_PACKAGE_NAME}-${RPM_PACKAGE_VERSION}-${RPM_PACKAGE_RELEASE}"
+elif test -d .git -a -x "$(which git)"; then
+# building from git checkout
+VERSION="$(git describe --tag --match edk2-stable*)"
+else
+# fallback
+VERSION="unknown"
+fi
+
+cat 

Re: [edk2-devel] The principles of EDK2 module reconstruction for archs

[Chang, Abner via groups.io]

[AMD Official Use Only - General]

Thanks Ray, here are my responses. 
https://github.com/tianocore-docs/edk2-CCodingStandardsSpecification/pull/2

@Kinney, Michael D we may also need your clarification on the comments.


> -Original Message-
> From: Ni, Ray 
> Sent: Thursday, September 29, 2022 3:42 PM
> To: Attar, AbdulLateef (Abdul Lateef) ; Chang,
> Abner ; Sunil V L ;
> devel@edk2.groups.io
> Cc: Kinney, Michael D ; lichao
> ; Kirkendall, Garrett ;
> Grimes, Paul ; He, Jiangang
> ; Leif Lindholm ;
> 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,
> Comments in
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
> ub.com%2Ftianocore-docs%2Fedk2-
> CCodingStandardsSpecification%2Fpull%2F2%23pullrequestreview-
> 1124763311&data=05%7C01%7CAbner.Chang%40amd.com%7Cd825e24
> 8625541e3f43e08daa1ee2883%7C3dd8961fe4884e608e11a82d994e183d%7C0
> %7C0%7C638000341502885565%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC
> 4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%
> 7C%7C%7C&sdata=RXxgpbEr6ivbqP1R6%2B3Rxl%2ByJAnaUJuaYYKdfCH
> 8jo8%3D&reserved=0
> 
> We can discuss more in tomorrow's meeting.
> 
> 
> > -Original Message-
> > From: Attar, AbdulLateef (Abdul Lateef) 
> > Sent: Thursday, September 29, 2022 3:11 PM
> > To: Chang, Abner ; Sunil V L
> > ; devel@edk2.groups.io; Ni, Ray
> > 
> > Cc: Kinney, Michael D ; lichao
> > ; Kirkendall, Garrett
> > ; Grimes, Paul ;
> He,
> > Jiangang ; Leif Lindholm
> > ; Andrew Fish 
> > Subject: RE: [edk2-devel] The principles of EDK2 module reconstruction
> > for archs
> >
> > Hi Abner,
> > Looks good to me.
> > Reviewed-by:  Abdul Lateef Attar 
> >
> > Thanks
> > AbduL
> >
> > -Original Message-
> > From: Chang, Abner 
> > Sent: 28 September 2022 20:31
> > To: Sunil V L ; devel@edk2.groups.io;
> > ray...@intel.com
> > Cc: Kinney, Michael D ; lichao
> > ; Kirkendall, Garrett
> > ; Grimes, Paul ;
> He,
> > Jiangang ; Attar, AbdulLateef (Abdul Lateef)
> > ; Leif Lindholm
> > ; Andrew Fish 
> > Subject: RE: [edk2-devel] The principles of EDK2 module reconstruction
> > for archs
> >
> > [AMD Official Use Only - General]
> >
> > I just had created PR to update edkII C coding standard spec for the
> > file and directory naming. We can review and confirm this update first
> > and then go back to the principles of EDK2 module reconstruction for archs.
> > Here is the PR:
> >
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
> > ub.com%2Ftianocore-docs%2Fedk2-
> &data=05%7C01%7CAbner.Chang%40amd.c
> >
> om%7Cd825e248625541e3f43e08daa1ee2883%7C3dd8961fe4884e608e11a82
> d994e18
> >
> 3d%7C0%7C0%7C638000341502885565%7CUnknown%7CTWFpbGZsb3d8eyJ
> WIjoiMC4wLj
> >
> AwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%
> 7C%7C&a
> >
> mp;sdata=X4z9puj81nIGTqtMxC9igDZyBPOT6OTWSU%2BjoIowo%2BE%3D&a
> mp;reserv
> > ed=0
> > CCodingStandardsSpecification/pull/2
> >
> > The naming rule is mainly for the new module or new file IMO. Some
> > existing module may not meet the guidelines mentioned in this spec.
> > Thus we need the principles of EDK2 module reconstruction on the
> > existing module to support other processor archs and not impacting the
> existing platforms (e.g.
> > rename the INF file or directory to meet the guidelines).
> >
> > Sunil, seems RISC-V CpuDxe meet the guideline. Please check it.
> > Just feel that having  CpuDxe.c to Riscv64 folder is not quite a best
> > solution. I think at least we can abstract the protocol structure and
> > protocol installation under CpuDxe\ and have the arch implementation
> > under arch folder. We can discuss this later after we confirming the
> guideline and principles.
> >
> > Thanks
> > Abner
> >
> > > -Original Message-
> > > From: Sunil V L 
> > > Sent: Wednesday, September 28, 2022 3:34 PM
> > > To: devel@edk2.groups.io; ray...@intel.com
> > > Cc: Chang, Abner ; Kinney, Michael D
> > > ; lichao ;
> > > Kirkendall, Garrett ; Grimes, Paul
> > > ; He, Jiangang ; Attar,
> > > AbdulLateef (Abdul Lateef) ; Leif
> > > Lindholm ; 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.
> > >
> > >
> > > On Wed, Sep 28, 2022 at 03:33:45AM +, Ni, Ray wrote:
> > > Hi Ray,
> > > >
> > > >   1.  When a new arch's implementation is introduced to the
> > > > existing
> > > module which was developed for the specific arch:
> > > >
> > > >   1.  The folder reconstruction:
> > > >
> > > >   *   Create arch folder for the existing arch implementation
> > > > [Ray] Do you move existing arch implementation to that arch folder?
> > > > It will
> > > break existing pl