Date   

[PATCH v2 1/1] ArmPkg: Implement PlatformBootManagerLib for LinuxBoot

Nhi Pham
 

LinuxBoot is a firmware that replaces specific firmware functionality
like the UEFI DXE phase with a Linux kernel and runtime. It is built-in
UEFI image like an application, which is executed at the end of DXE
phase.

To achieve the LinuxBoot boot flow "SEC->PEI->DXE->BDS->LinuxBoot",
today we use the common well-known GUID of UEFI Shell for LinuxBoot
payload, so LinuxBoot developers can effortlessly find the UEFI Shell
Application and replace it with the LinuxBoot payload without
recompiling platform EDK2 (There might be an issue with a few systems
that don't have a UEFI Shell). Also, we have a hard requirement to force
the BDS to boot into the LinuxBoot as it is essentially required that
only the LinuxBoot boot option is permissible and UEFI is an
intermediate bootstrap phase. Considering all the above, it is
reasonable to just have a new GUID for LinuxBoot and require a LinuxBoot
specific BDS implementation. In addition, with making the BDS
implementation simpler, we can reduce many DXE drivers which we think it
is not necessary for LinuxBoot booting.

This patch adds a new PlatformBootManagerLib implementation which
registers only the gArmTokenSpaceGuid.PcdLinuxBootFileGuid for LinuxBoot
payload as an active boot option. It allows BDS to jump to the LinuxBoot
quickly by skipping the UiApp and UEFI Shell.

The PlatformBootManagerLib library derived from
ArmPkg/Library/PlatformBootManagerLib.

Cc: Leif Lindholm <leif@nuviainc.com>
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>

Signed-off-by: Nhi Pham <nhi@os.amperecomputing.com>
---
ArmPkg/ArmPkg.dec | 8 +
ArmPkg/ArmPkg.dsc | 2 +
ArmPkg/Library/LinuxBootBootManagerLib/LinuxBootBootManagerLib.inf | 58 +++++++
ArmPkg/Library/LinuxBootBootManagerLib/LinuxBootBm.c | 178 ++++++++++++++++++++
4 files changed, 246 insertions(+)

diff --git a/ArmPkg/ArmPkg.dec b/ArmPkg/ArmPkg.dec
index 214b2f589217..f68e6ee00860 100644
--- a/ArmPkg/ArmPkg.dec
+++ b/ArmPkg/ArmPkg.dec
@@ -3,6 +3,7 @@
#
# Copyright (c) 2009 - 2010, Apple Inc. All rights reserved.<BR>
# Copyright (c) 2011 - 2021, ARM Limited. All rights reserved.
+# Copyright (c) 2021, Ampere Computing LLC. All rights reserved.
#
# SPDX-License-Identifier: BSD-2-Clause-Patent
#
@@ -382,3 +383,10 @@ [PcdsFixedAtBuild.common, PcdsDynamic.common]
#
gArmTokenSpaceGuid.PcdPciBusMin|0x0|UINT32|0x00000059
gArmTokenSpaceGuid.PcdPciBusMax|0x0|UINT32|0x0000005A
+
+[PcdsDynamicEx]
+ #
+ # This dynamic PCD hold the GUID of a firmware FFS which contains
+ # the LinuxBoot payload.
+ #
+ gArmTokenSpaceGuid.PcdLinuxBootFileGuid|{0x0}|VOID*|0x0000005C
diff --git a/ArmPkg/ArmPkg.dsc b/ArmPkg/ArmPkg.dsc
index 926986cf7fbb..ffb1c261861e 100644
--- a/ArmPkg/ArmPkg.dsc
+++ b/ArmPkg/ArmPkg.dsc
@@ -5,6 +5,7 @@
# Copyright (c) 2011 - 2021, Arm Limited. All rights reserved.<BR>
# Copyright (c) 2016, Linaro Ltd. All rights reserved.<BR>
# Copyright (c) Microsoft Corporation.<BR>
+# Copyright (c) 2021, Ampere Computing LLC. All rights reserved.
#
# SPDX-License-Identifier: BSD-2-Clause-Patent
#
@@ -150,6 +151,7 @@ [Components.common]
ArmPkg/Library/ArmSmcPsciResetSystemLib/ArmSmcPsciResetSystemLib.inf
ArmPkg/Library/PeiServicesTablePointerLib/PeiServicesTablePointerLib.inf
ArmPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf
+ ArmPkg/Library/LinuxBootBootManagerLib/LinuxBootBootManagerLib.inf

ArmPkg/Drivers/ArmCrashDumpDxe/ArmCrashDumpDxe.inf
ArmPkg/Drivers/ArmScmiDxe/ArmScmiDxe.inf
diff --git a/ArmPkg/Library/LinuxBootBootManagerLib/LinuxBootBootManagerLib.inf b/ArmPkg/Library/LinuxBootBootManagerLib/LinuxBootBootManagerLib.inf
new file mode 100644
index 000000000000..139b6171990a
--- /dev/null
+++ b/ArmPkg/Library/LinuxBootBootManagerLib/LinuxBootBootManagerLib.inf
@@ -0,0 +1,58 @@
+## @file
+# Implementation for PlatformBootManagerLib library class interfaces.
+#
+# Copyright (C) 2015-2016, Red Hat, Inc.
+# Copyright (c) 2014, ARM Ltd. All rights reserved.<BR>
+# Copyright (c) 2007 - 2014, Intel Corporation. All rights reserved.<BR>
+# Copyright (c) 2016, Linaro Ltd. All rights reserved.<BR>
+# Copyright (c) 2020 - 2021, Ampere Computing LLC. All rights reserved.<BR>
+#
+# SPDX-License-Identifier: BSD-2-Clause-Patent
+#
+##
+
+[Defines]
+ INF_VERSION = 0x0001001B
+ BASE_NAME = LinuxBootBootManagerLib
+ FILE_GUID = 1FA91547-DB23-4F6A-8AF8-3B9782A7F917
+ MODULE_TYPE = DXE_DRIVER
+ VERSION_STRING = 1.0
+ LIBRARY_CLASS = PlatformBootManagerLib|DXE_DRIVER
+
+#
+# The following information is for reference only and not required by the build tools.
+#
+# VALID_ARCHITECTURES = ARM AARCH64
+#
+
+[Sources]
+ LinuxBootBm.c
+
+[Packages]
+ ArmPkg/ArmPkg.dec
+ MdeModulePkg/MdeModulePkg.dec
+ MdePkg/MdePkg.dec
+ ShellPkg/ShellPkg.dec
+
+[LibraryClasses]
+ BaseLib
+ BaseMemoryLib
+ DebugLib
+ MemoryAllocationLib
+ PcdLib
+ PrintLib
+ UefiBootManagerLib
+ UefiBootServicesTableLib
+ UefiLib
+ UefiRuntimeServicesTableLib
+
+[Pcd]
+ gArmTokenSpaceGuid.PcdLinuxBootFileGuid
+
+[Guids]
+ gEfiEndOfDxeEventGroupGuid
+ gUefiShellFileGuid
+ gZeroGuid
+
+[Protocols]
+ gEfiLoadedImageProtocolGuid
diff --git a/ArmPkg/Library/LinuxBootBootManagerLib/LinuxBootBm.c b/ArmPkg/Library/LinuxBootBootManagerLib/LinuxBootBm.c
new file mode 100644
index 000000000000..f4941780efcd
--- /dev/null
+++ b/ArmPkg/Library/LinuxBootBootManagerLib/LinuxBootBm.c
@@ -0,0 +1,178 @@
+/** @file
+ Implementation for PlatformBootManagerLib library class interfaces.
+
+ Copyright (C) 2015-2016, Red Hat, Inc.
+ Copyright (c) 2014 - 2019, ARM Ltd. All rights reserved.<BR>
+ Copyright (c) 2004 - 2018, Intel Corporation. All rights reserved.<BR>
+ Copyright (c) 2016, Linaro Ltd. All rights reserved.<BR>
+ Copyright (c) 2020 - 2021, Ampere Computing LLC. All rights reserved.<BR>
+
+ SPDX-License-Identifier: BSD-2-Clause-Patent
+
+**/
+
+#include <Uefi.h>
+
+#include <Guid/EventGroup.h>
+#include <Library/BaseLib.h>
+#include <Library/BaseMemoryLib.h>
+#include <Library/DebugLib.h>
+#include <Library/DevicePathLib.h>
+#include <Library/MemoryAllocationLib.h>
+#include <Library/PcdLib.h>
+#include <Library/UefiBootManagerLib.h>
+#include <Library/UefiBootServicesTableLib.h>
+#include <Library/UefiLib.h>
+#include <Library/UefiRuntimeServicesTableLib.h>
+#include <Protocol/LoadedImage.h>
+#include <Protocol/PlatformBootManager.h>
+
+STATIC
+VOID
+PlatformRegisterFvBootOption (
+ CONST EFI_GUID *FileGuid,
+ CHAR16 *Description,
+ UINT32 Attributes
+ )
+{
+ EFI_STATUS Status;
+ INTN OptionIndex;
+ EFI_BOOT_MANAGER_LOAD_OPTION NewOption;
+ EFI_BOOT_MANAGER_LOAD_OPTION *BootOptions;
+ UINTN BootOptionCount;
+ MEDIA_FW_VOL_FILEPATH_DEVICE_PATH FileNode;
+ EFI_LOADED_IMAGE_PROTOCOL *LoadedImage;
+ EFI_DEVICE_PATH_PROTOCOL *DevicePath;
+
+ Status = gBS->HandleProtocol (
+ gImageHandle,
+ &gEfiLoadedImageProtocolGuid,
+ (VOID **)&LoadedImage
+ );
+ ASSERT_EFI_ERROR (Status);
+
+ EfiInitializeFwVolDevicepathNode (&FileNode, FileGuid);
+ DevicePath = DevicePathFromHandle (LoadedImage->DeviceHandle);
+ ASSERT (DevicePath != NULL);
+ DevicePath = AppendDevicePathNode (
+ DevicePath,
+ (EFI_DEVICE_PATH_PROTOCOL *)&FileNode
+ );
+ ASSERT (DevicePath != NULL);
+
+ Status = EfiBootManagerInitializeLoadOption (
+ &NewOption,
+ LoadOptionNumberUnassigned,
+ LoadOptionTypeBoot,
+ Attributes,
+ Description,
+ DevicePath,
+ NULL,
+ 0
+ );
+ ASSERT_EFI_ERROR (Status);
+ FreePool (DevicePath);
+
+ BootOptions = EfiBootManagerGetLoadOptions (
+ &BootOptionCount,
+ LoadOptionTypeBoot
+ );
+
+ OptionIndex = EfiBootManagerFindLoadOption (
+ &NewOption,
+ BootOptions,
+ BootOptionCount
+ );
+
+ if (OptionIndex == -1) {
+ Status = EfiBootManagerAddLoadOptionVariable (&NewOption, MAX_UINTN);
+ ASSERT_EFI_ERROR (Status);
+ }
+ EfiBootManagerFreeLoadOption (&NewOption);
+ EfiBootManagerFreeLoadOptions (BootOptions, BootOptionCount);
+}
+
+/**
+ Do the platform specific action before the console is connected.
+
+ Such as:
+ Update console variable;
+ Register new Driver#### or Boot####;
+ Signal ReadyToLock event.
+**/
+VOID
+EFIAPI
+PlatformBootManagerBeforeConsole (
+ VOID
+ )
+{
+ //
+ // Signal EndOfDxe PI Event
+ //
+ EfiEventGroupSignal (&gEfiEndOfDxeEventGroupGuid);
+}
+
+/**
+ Do the platform specific action after the console is connected.
+
+ Such as:
+ Dynamically switch output mode;
+ Signal console ready platform customized event;
+ Run diagnostics like memory testing;
+ Connect certain devices;
+ Dispatch additional option roms.
+**/
+VOID
+EFIAPI
+PlatformBootManagerAfterConsole (
+ VOID
+ )
+{
+ EFI_GUID LinuxBootFileGuid;
+
+ CopyGuid (&LinuxBootFileGuid, PcdGetPtr (PcdLinuxBootFileGuid));
+
+ if (!CompareGuid (&LinuxBootFileGuid, &gZeroGuid)) {
+ //
+ // Register LinuxBoot
+ //
+ PlatformRegisterFvBootOption (
+ &LinuxBootFileGuid,
+ L"LinuxBoot",
+ LOAD_OPTION_ACTIVE
+ );
+ } else {
+ DEBUG ((DEBUG_ERROR, "%a: PcdLinuxBootFileGuid was not set!\n", __FUNCTION__));
+ }
+}
+
+/**
+ This function is called each second during the boot manager waits the
+ timeout.
+
+ @param TimeoutRemain The remaining timeout.
+**/
+VOID
+EFIAPI
+PlatformBootManagerWaitCallback (
+ UINT16 TimeoutRemain
+ )
+{
+ return;
+}
+
+/**
+ The function is called when no boot option could be launched,
+ including platform recovery options and options pointing to applications
+ built into firmware volumes.
+
+ If this function returns, BDS attempts to enter an infinite loop.
+**/
+VOID
+EFIAPI
+PlatformBootManagerUnableToBoot (
+ VOID
+ )
+{
+ return;
+}
--
2.17.1


Re: [PATCH V1 1/1] RedfishPkg:Fix various typos

Nickle Wang
 

Thanks for catching these typos.

Reviewed-by: Nickle Wang <nickle.wang@hpe.com>

Nickle

-----Original Message-----
From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Abner Chang
Sent: Tuesday, September 7, 2021 10:41 AM
To: zhoucheng <zhoucheng@phytium.com.cn>; devel@edk2.groups.io
Subject: Re: [edk2-devel] [PATCH V1 1/1] RedfishPkg:Fix various typos

Thanks for the corrections.

Reviewed-by: Abner Chang <abner.chang@hpe.com>


-----Original Message-----
From: zhoucheng [mailto:zhoucheng@phytium.com.cn]
Sent: Tuesday, September 7, 2021 10:18 AM
To: devel@edk2.groups.io
Cc: Chang, Abner (HPS SW/FW Technologist) <abner.chang@hpe.com>
Subject: [PATCH V1 1/1] RedfishPkg:Fix various typos

Fix various typos in comments and documentation.

Signed-off-by: Cheng Zhou <zhoucheng@phytium.com.cn>
Reviewed-by: Nickle Wang <nickle.wang@hpe.com>
Cc: Abner Chang <abner.chang@hpe.com>
---
RedfishPkg/Include/Library/RedfishHostInterfaceLib.h | 2 +-
RedfishPkg/RedfishRestExDxe/RedfishRestExInternal.h | 2 +-
RedfishPkg/RedfishCredentialDxe/RedfishCredentialDxe.c | 2 +-
RedfishPkg/RedfishHostInterfaceDxe/RedfishHostInterfaceDxe.c | 4 ++--
RedfishPkg/RedfishRestExDxe/RedfishRestExImpl.c | 2 +-
5 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/RedfishPkg/Include/Library/RedfishHostInterfaceLib.h
b/RedfishPkg/Include/Library/RedfishHostInterfaceLib.h
index fe37b2739a73..ad134e8f9b06 100644
--- a/RedfishPkg/Include/Library/RedfishHostInterfaceLib.h
+++ b/RedfishPkg/Include/Library/RedfishHostInterfaceLib.h
@@ -40,7 +40,7 @@ RedfishPlatformHostInterfaceDeviceDescriptor (
this function using FreePool().
param[in] IndexOfProtocolData The index of protocol data.

- @retval EFI_SUCESS Protocol records are all returned.
+ @retval EFI_SUCCESS Protocol records are all returned.
@retval EFI_NOT_FOUND No more protocol records.
@retval Others Fail to get protocol records.
**/
diff --git a/RedfishPkg/RedfishRestExDxe/RedfishRestExInternal.h
b/RedfishPkg/RedfishRestExDxe/RedfishRestExInternal.h
index a75985928ce2..b91bf39fdaa1 100644
--- a/RedfishPkg/RedfishRestExDxe/RedfishRestExInternal.h
+++ b/RedfishPkg/RedfishRestExDxe/RedfishRestExInternal.h
@@ -41,7 +41,7 @@
REST service.
@param[in] HttpReceiveEfiStatus This is the status return from
HttpIoRecvResponse

- @retval EFI_SUCCESS The payload receive from Redfish service in
sucessfully.
+ @retval EFI_SUCCESS The payload receive from Redfish service in
successfully.
@retval EFI_NOT_READY May need to resend the HTTP request.
@retval EFI_DEVICE_ERROR Something wrong and can't be resolved.
@retval Others Other errors as indicated.
diff --git a/RedfishPkg/RedfishCredentialDxe/RedfishCredentialDxe.c
b/RedfishPkg/RedfishCredentialDxe/RedfishCredentialDxe.c
index f48d1d011c80..0c6891ce9c0e 100644
--- a/RedfishPkg/RedfishCredentialDxe/RedfishCredentialDxe.c
+++ b/RedfishPkg/RedfishCredentialDxe/RedfishCredentialDxe.c
@@ -129,7 +129,7 @@ RedfishCredentialStopService (
@param ImageHandle Image handle this driver.
@param SystemTable Pointer to SystemTable.

- @retval EFI_SUCESS This function always complete successfully.
+ @retval EFI_SUCCESS This function always complete successfully.

**/
EFI_STATUS
diff --git
a/RedfishPkg/RedfishHostInterfaceDxe/RedfishHostInterfaceDxe.c
b/RedfishPkg/RedfishHostInterfaceDxe/RedfishHostInterfaceDxe.c
index ec7faefed789..531f44ef030b 100644
--- a/RedfishPkg/RedfishHostInterfaceDxe/RedfishHostInterfaceDxe.c
+++ b/RedfishPkg/RedfishHostInterfaceDxe/RedfishHostInterfaceDxe.c
@@ -24,7 +24,7 @@
/**
Create SMBIOS type 42 record for Redfish host interface.

- @retval EFI_SUCESS SMBIOS type 42 record is created.
+ @retval EFI_SUCCESS SMBIOS type 42 record is created.
@retval Others Fail to create SMBIOS 42 record.

**/
@@ -226,7 +226,7 @@ ON_EXIT:
@param ImageHandle Image handle this driver.
@param SystemTable Pointer to SystemTable.

- @retval EFI_SUCESS This function always complete successfully.
+ @retval EFI_SUCCESS This function always complete successfully.

**/
EFI_STATUS
diff --git a/RedfishPkg/RedfishRestExDxe/RedfishRestExImpl.c
b/RedfishPkg/RedfishRestExDxe/RedfishRestExImpl.c
index 006b64adc03a..18d8811f69c6 100644
--- a/RedfishPkg/RedfishRestExDxe/RedfishRestExImpl.c
+++ b/RedfishPkg/RedfishRestExDxe/RedfishRestExImpl.c
@@ -47,7 +47,7 @@ ResetHttpTslSession (
REST service.
@param[in] HttpIoReceiveStatus This is the status return from
HttpIoRecvResponse

- @retval EFI_SUCCESS The payload receive from Redfish service in
sucessfully.
+ @retval EFI_SUCCESS The payload receive from Redfish service in
successfully.
@retval EFI_NOT_READY May need to resend the HTTP request.
@retval EFI_DEVICE_ERROR Something wrong and can't be resolved.
@retval Others Other errors as indicated.
--
2.17.1


Re: [PATCH V1 1/1] RedfishPkg:Fix various typos

Abner Chang
 

Thanks for the corrections.

Reviewed-by: Abner Chang <abner.chang@hpe.com>

-----Original Message-----
From: zhoucheng [mailto:zhoucheng@phytium.com.cn]
Sent: Tuesday, September 7, 2021 10:18 AM
To: devel@edk2.groups.io
Cc: Chang, Abner (HPS SW/FW Technologist) <abner.chang@hpe.com>
Subject: [PATCH V1 1/1] RedfishPkg:Fix various typos

Fix various typos in comments and documentation.

Signed-off-by: Cheng Zhou <zhoucheng@phytium.com.cn>
Reviewed-by: Nickle Wang <nickle.wang@hpe.com>
Cc: Abner Chang <abner.chang@hpe.com>
---
RedfishPkg/Include/Library/RedfishHostInterfaceLib.h | 2 +-
RedfishPkg/RedfishRestExDxe/RedfishRestExInternal.h | 2 +-
RedfishPkg/RedfishCredentialDxe/RedfishCredentialDxe.c | 2 +-
RedfishPkg/RedfishHostInterfaceDxe/RedfishHostInterfaceDxe.c | 4 ++--
RedfishPkg/RedfishRestExDxe/RedfishRestExImpl.c | 2 +-
5 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/RedfishPkg/Include/Library/RedfishHostInterfaceLib.h
b/RedfishPkg/Include/Library/RedfishHostInterfaceLib.h
index fe37b2739a73..ad134e8f9b06 100644
--- a/RedfishPkg/Include/Library/RedfishHostInterfaceLib.h
+++ b/RedfishPkg/Include/Library/RedfishHostInterfaceLib.h
@@ -40,7 +40,7 @@ RedfishPlatformHostInterfaceDeviceDescriptor (
this function using FreePool().
param[in] IndexOfProtocolData The index of protocol data.

- @retval EFI_SUCESS Protocol records are all returned.
+ @retval EFI_SUCCESS Protocol records are all returned.
@retval EFI_NOT_FOUND No more protocol records.
@retval Others Fail to get protocol records.
**/
diff --git a/RedfishPkg/RedfishRestExDxe/RedfishRestExInternal.h
b/RedfishPkg/RedfishRestExDxe/RedfishRestExInternal.h
index a75985928ce2..b91bf39fdaa1 100644
--- a/RedfishPkg/RedfishRestExDxe/RedfishRestExInternal.h
+++ b/RedfishPkg/RedfishRestExDxe/RedfishRestExInternal.h
@@ -41,7 +41,7 @@
REST service.
@param[in] HttpReceiveEfiStatus This is the status return from
HttpIoRecvResponse

- @retval EFI_SUCCESS The payload receive from Redfish service in
sucessfully.
+ @retval EFI_SUCCESS The payload receive from Redfish service in
successfully.
@retval EFI_NOT_READY May need to resend the HTTP request.
@retval EFI_DEVICE_ERROR Something wrong and can't be resolved.
@retval Others Other errors as indicated.
diff --git a/RedfishPkg/RedfishCredentialDxe/RedfishCredentialDxe.c
b/RedfishPkg/RedfishCredentialDxe/RedfishCredentialDxe.c
index f48d1d011c80..0c6891ce9c0e 100644
--- a/RedfishPkg/RedfishCredentialDxe/RedfishCredentialDxe.c
+++ b/RedfishPkg/RedfishCredentialDxe/RedfishCredentialDxe.c
@@ -129,7 +129,7 @@ RedfishCredentialStopService (
@param ImageHandle Image handle this driver.
@param SystemTable Pointer to SystemTable.

- @retval EFI_SUCESS This function always complete successfully.
+ @retval EFI_SUCCESS This function always complete successfully.

**/
EFI_STATUS
diff --git a/RedfishPkg/RedfishHostInterfaceDxe/RedfishHostInterfaceDxe.c
b/RedfishPkg/RedfishHostInterfaceDxe/RedfishHostInterfaceDxe.c
index ec7faefed789..531f44ef030b 100644
--- a/RedfishPkg/RedfishHostInterfaceDxe/RedfishHostInterfaceDxe.c
+++ b/RedfishPkg/RedfishHostInterfaceDxe/RedfishHostInterfaceDxe.c
@@ -24,7 +24,7 @@
/**
Create SMBIOS type 42 record for Redfish host interface.

- @retval EFI_SUCESS SMBIOS type 42 record is created.
+ @retval EFI_SUCCESS SMBIOS type 42 record is created.
@retval Others Fail to create SMBIOS 42 record.

**/
@@ -226,7 +226,7 @@ ON_EXIT:
@param ImageHandle Image handle this driver.
@param SystemTable Pointer to SystemTable.

- @retval EFI_SUCESS This function always complete successfully.
+ @retval EFI_SUCCESS This function always complete successfully.

**/
EFI_STATUS
diff --git a/RedfishPkg/RedfishRestExDxe/RedfishRestExImpl.c
b/RedfishPkg/RedfishRestExDxe/RedfishRestExImpl.c
index 006b64adc03a..18d8811f69c6 100644
--- a/RedfishPkg/RedfishRestExDxe/RedfishRestExImpl.c
+++ b/RedfishPkg/RedfishRestExDxe/RedfishRestExImpl.c
@@ -47,7 +47,7 @@ ResetHttpTslSession (
REST service.
@param[in] HttpIoReceiveStatus This is the status return from
HttpIoRecvResponse

- @retval EFI_SUCCESS The payload receive from Redfish service in
sucessfully.
+ @retval EFI_SUCCESS The payload receive from Redfish service in
successfully.
@retval EFI_NOT_READY May need to resend the HTTP request.
@retval EFI_DEVICE_ERROR Something wrong and can't be resolved.
@retval Others Other errors as indicated.
--
2.17.1


Re: [RFC] RISC-V QEMU virtual package

Abner Chang
 

-----Original Message-----
From: gaoliming [mailto:gaoliming@byosoft.com.cn]
Sent: Tuesday, September 7, 2021 9:09 AM
To: devel@edk2.groups.io; Chang, Abner (HPS SW/FW Technologist)
<abner.chang@hpe.com>; 'Gerd Hoffmann' <kraxel@redhat.com>; 'Ard
Biesheuvel' <ardb@kernel.org>
Cc: 'Yao, Jiewen' <jiewen.yao@intel.com>; 'Ard Biesheuvel'
<ard.biesheuvel@arm.com>; 'Kinney, Michael D'
<michael.d.kinney@intel.com>; 'Leif Lindholm' <leif@nuviainc.com>; 'Ni, Ray'
<ray.ni@intel.com>; Schaefer, Daniel <daniel.schaefer@hpe.com>; 'Sunil V L'
<sunilvl@ventanamicro.com>; 'Ard Biesheuvel' <ardb+tianocore@kernel.org>
Subject: 回复: [edk2-devel] [RFC] RISC-V QEMU virtual package

Abner:
I prefer to use git mv command to move those modules from ArmVirtPkg to
OvmfPkg. This way can still keep git history for those modules.
Yeah sure, this is much better.

You can create the second patch to update ArmVirtPkg DSC/FDF, or
combine
this change into the first patch.
I will just send two patches for ArmVirtPkg changes, then have the separate patch set for RiscvVirtPkg.

Thanks
Abner


Thanks
Liming
-----邮件原件-----
发件人: devel@edk2.groups.io <devel@edk2.groups.io> 代表 Abner
Chang
发送时间: 2021年9月6日 21:05
收件人: Gerd Hoffmann <kraxel@redhat.com>; Ard Biesheuvel
<ardb@kernel.org>
抄送: Yao, Jiewen <jiewen.yao@intel.com>; devel@edk2.groups.io;
gaoliming
<gaoliming@byosoft.com.cn>; Ard Biesheuvel <ard.biesheuvel@arm.com>;
Kinney, Michael D <michael.d.kinney@intel.com>; Leif Lindholm
<leif@nuviainc.com>; Ni, Ray <ray.ni@intel.com>; Schaefer, Daniel
<daniel.schaefer@hpe.com>; Sunil V L <sunilvl@ventanamicro.com>; Ard
Biesheuvel <ardb+tianocore@kernel.org>
主题: Re: [edk2-devel] [RFC] RISC-V QEMU virtual package

Ok thanks, do we need the two steps to migrate FDT modules under
OvmfPkg/?
1. One patch set to clone those modules under OvmfPkg/
2. One patch set of ArmVirtPkg change to use those modules and deletes
the
ones under ArmVirtPkg/.

Or we just do all at once? I prefer to have two steps. How do you think?

Another question, who would like to be the reviewers of OvmfPkg/Fdt/*?
Any
volunteers from CC list?

Thanks
Abner

-----Original Message-----
From: Gerd Hoffmann [mailto:kraxel@redhat.com]
Sent: Monday, September 6, 2021 8:19 PM
To: Ard Biesheuvel <ardb@kernel.org>
Cc: Yao, Jiewen <jiewen.yao@intel.com>; Chang, Abner (HPS SW/FW
Technologist) <abner.chang@hpe.com>; devel@edk2.groups.io;
gaoliming
<gaoliming@byosoft.com.cn>; Ard Biesheuvel
<ard.biesheuvel@arm.com>;
Kinney, Michael D <michael.d.kinney@intel.com>; Leif Lindholm
<leif@nuviainc.com>; Ni, Ray <ray.ni@intel.com>; Schaefer, Daniel
<daniel.schaefer@hpe.com>; Sunil V L <sunilvl@ventanamicro.com>; Ard
Biesheuvel <ardb+tianocore@kernel.org>
Subject: Re: [edk2-devel] [RFC] RISC-V QEMU virtual package

Hi,

On Mon, Sep 06, 2021 at 02:04:48PM +0200, Ard Biesheuvel wrote:
On Mon, 6 Sept 2021 at 13:44, Yao, Jiewen <jiewen.yao@intel.com>
wrote:

I think it makes sense to put Fdt to OvmfPkg. I suggest an Fdt
folder and
put all things there.

I also think we define Fdt feature in
https://github.com/tianocore/edk2/blob/master/Maintainers.txt to add
reviewer there to help review the code.
Agreed.
Agreeing too.

take care,
Gerd




Re: [PATCH v6 00/29] Add AMD Secure Nested Paging (SEV-SNP) support

Yao, Jiewen
 

Thank you Brijesh
It took me a while to review this series. Here is my feedback.
I am not sure what you prefer, to put all comment together? Or reply 29 email separately?
Let me put them together in this version. If you prefer a different way, please let me know.

My strategy is same as previous. I will focus on common part and review as detail as possible.
For SEV specific thing, I will ACK and let AMD people make decision unless I have big concern on the design.
You can add my A-B and R-B in next version.


0001-OvmfPkg-reserve-SNP-secrets-page
Reviewed-by: Jiewen Yao <Jiewen.yao@intel.com>

0002-OvmfPkg-reserve-CPUID-page-for-SEV-SNP
Reviewed-by: Jiewen Yao <Jiewen.yao@intel.com>

0003-OvmfPkg-ResetVector-introduce-SEV-SNP-boot-block-GUID
I am still thinking if it is possible to move all SEV define GUID blob to a standalone file, and TDX define GUID blob to another file.
Anyway, that can be done later.
Reviewed-by: Jiewen Yao <Jiewen.yao@intel.com>

0004-OvmfPkg-ResetVector-invalidate-the-GHCB-page
Acked-by: Jiewen Yao <Jiewen.yao@intel.com>

0005-OvmfPkg-ResetVector-check-the-vmpl-level
Acked-by: Jiewen Yao <Jiewen.yao@intel.com>

0006-OvmfPkg-ResetVector-pre-validate-the-data-pages-used-in-SEC-phase
Acked-by: Jiewen Yao <Jiewen.yao@intel.com>

0007-OvmfPkg-ResetVector-use-SEV-SNP-validated-CPUID-values
Acked-by: Jiewen Yao <Jiewen.yao@intel.com>

0008-UefiCpuPkg-Define-the-SEV-SNP-specific-dynamic-PCDs
I really don't like the idea to use BOOL PcdSevEsIsEnabled and PcdSevSnpIsEnabled.
Can we define *one* PCD - such as PcdConfidentialComputingCategory?
We can assign range 0x0000~0xFFFF to AMD SEV, 0x10000~0x1FFFF to Intel TDX.
Then SEV=0x0000, SEV-ES=0x0001, SEV-SNP=0x0002, and TDX=0x10000 later.
I really don't want to keep adding PCD endlessly in the future, like PcdSevXXXIsEnabled, PcdSevYYYIsEnabled, PcdTdxIsEnabled, PcdTdx20Enabled, PcdTdx30Enabled, ......


0009-OvmfPkg-MemEncryptSevLib-add-MemEncryptSevSnpEnabled()
I am not sure since we have PCD in 0008, why we need to expose the function - MemEncryptSevSnpIsEnabled() and MemEncryptSevEsIsEnabled()?
Should we always use PCD anywhere else?
Anyway, Acked-by: Jiewen Yao <Jiewen.yao@intel.com>

0010-OvmfPkg-SecMain-move-SEV-specific-routines-in-AmdSev.c
Reviewed-by: Jiewen Yao <Jiewen.yao@intel.com>

0011-OvmfPkg-SecMain-register-GHCB-gpa-for-the-SEV-SNP-guest
Acked-by: Jiewen Yao <Jiewen.yao@intel.com>

0012-OvmfPkg-VmgExitLib-use-SEV-SNP-validated-CPUID-values
Acked-by: Jiewen Yao <Jiewen.yao@intel.com>

0013-OvmfPkg-PlatformPei-register-GHCB-gpa-for-the-SEV-SNP-guest
Acked-by: Jiewen Yao <Jiewen.yao@intel.com>

0014-OvmfPkg-AmdSevDxe-do-not-use-extended-PCI-config-space
Acked-by: Jiewen Yao <Jiewen.yao@intel.com>

0015-OvmfPkg-MemEncryptSevLib-add-support-to-validate-system-RAM
Acked-by: Jiewen Yao <Jiewen.yao@intel.com>

0016-OvmfPkg-BaseMemEncryptSevLib-skip-the-pre-validated-system-RAM
Acked-by: Jiewen Yao <Jiewen.yao@intel.com>

0017-OvmfPkg-MemEncryptSevLib-add-support-to-validate-4GB-memory-in-PEI-phase
Acked-by: Jiewen Yao <Jiewen.yao@intel.com>

0018-OvmfPkg-SecMain-pre-validate-the-memory-used-for-decompressing-Fv
Acked-by: Jiewen Yao <Jiewen.yao@intel.com>

0019-OvmfPkg-PlatformPei-validate-the-system-RAM-when-SNP-is-active
Acked-by: Jiewen Yao <Jiewen.yao@intel.com>

0020-OvmfPkg-PlatformPei-set-the-SEV-SNP-enabled-PCD
See 0008

0021-OvmfPkg-PlatformPei-set-the-Hypervisor-Features-PCD
Acked-by: Jiewen Yao <Jiewen.yao@intel.com>

0022-MdePkg-GHCB-increase-the-GHCB-protocol-max-version
Acked-by: Jiewen Yao <Jiewen.yao@intel.com>

0023-UefiCpuPkg-MpLib-add-support-to-register-GHCB-GPA-when-SEV-SNP-is-enabled
1) See 0008.
2) For MpFuncs.nasm, I recommend to move AmdSev specific initialization to a standalone file, such as Sev.nasm

0024-UefiCpuPkg-MpInitLib-use-BSP-to-do-extended-topology-check
See 0023

0025-OvmfPkg-MemEncryptSevLib-change-the-page-state-in-the-RMP-table
Acked-by: Jiewen Yao <Jiewen.yao@intel.com>

0026-OvmfPkg-MemEncryptSevLib-skip-page-state-change-for-Mmio-address
Acked-by: Jiewen Yao <Jiewen.yao@intel.com>

0027-OvmfPkg-PlatformPei-mark-cpuid-and-secrets-memory-reserved-in-EFI-map
Would you please move SEV specific init to another Sev.c?
Also I found MemEncryptSevEsIsEnabled() and MemEncryptSevSnpIsEnabled() are there.
I suggest just use one API
MemEncryptSevEsIsEnabled() {
DoSevInitializeRamRegions()
}
Then you can check more in DoSevInitializeRamRegions().
DoSevInitializeRamRegions() {
MemEncryptSevSnpIsEnabled() {
}
}

0028-OvmfPkg-AmdSev-expose-the-SNP-reserved-pages-through-configuration-table
I am not convinced to include SEV specific data structure in a generic structure in ConfidentialComputingSecret.h.
I recommend moving it to SEV specific file.

0029-UefiCpuPkg-MpInitLib-Use-SEV-SNP-AP-Creation-NAE-event-to-launch-APs
See 0008, 0023.
I recommend to move SevSnpCreateSaveArea() to Sev.c.

Thank you
Yao Jiewen

-----Original Message-----
From: Brijesh Singh <brijesh.singh@amd.com>
Sent: Thursday, September 2, 2021 12:16 AM
To: devel@edk2.groups.io
Cc: James Bottomley <jejb@linux.ibm.com>; Xu, Min M <min.m.xu@intel.com>;
Yao, Jiewen <jiewen.yao@intel.com>; Tom Lendacky
<thomas.lendacky@amd.com>; Justen, Jordan L <jordan.l.justen@intel.com>;
Ard Biesheuvel <ardb+tianocore@kernel.org>; Erdem Aktas
<erdemaktas@google.com>; Michael Roth <Michael.Roth@amd.com>; Gerd
Hoffmann <kraxel@redhat.com>; Brijesh Singh <brijesh.singh@amd.com>
Subject: [PATCH v6 00/29] Add AMD Secure Nested Paging (SEV-SNP) support

BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3275

SEV-SNP builds upon existing SEV and SEV-ES functionality while adding
new hardware-based memory protections. SEV-SNP adds strong memory
integrity
protection to help prevent malicious hypervisor-based attacks like data
replay, memory re-mapping and more in order to create an isolated memory
encryption environment.

This series provides the basic building blocks to support booting the SEV-SNP
VMs, it does not cover all the security enhancement introduced by the SEV-SNP
such as interrupt protection.

Many of the integrity guarantees of SEV-SNP are enforced through a new
structure called the Reverse Map Table (RMP). Adding a new page to SEV-SNP
VM requires a 2-step process. First, the hypervisor assigns a page to the
guest using the new RMPUPDATE instruction. This transitions the page to
guest-invalid. Second, the guest validates the page using the new PVALIDATE
instruction. The SEV-SNP VMs can use the new "Page State Change Request
NAE"
defined in the GHCB specification to ask hypervisor to add or remove page
from the RMP table.

Each page assigned to the SEV-SNP VM can either be validated or unvalidated,
as indicated by the Validated flag in the page's RMP entry. There are two
approaches that can be taken for the page validation: Pre-validation and
Lazy Validation.

Under pre-validation, the pages are validated prior to first use. And under
lazy validation, pages are validated when first accessed. An access to a
unvalidated page results in a #VC exception, at which time the exception
handler may validate the page. Lazy validation requires careful tracking of
the validated pages to avoid validating the same GPA more than once. The
recently introduced "Unaccepted" memory type can be used to communicate
the
unvalidated memory ranges to the Guest OS.

At this time we only support the pre-validation. OVMF detects all the available
system RAM in the PEI phase. When SEV-SNP is enabled, the memory is validated
before it is made available to the EDK2 core.

Now that series contains all the basic support required to launch SEV-SNP
guest. We are still missing the Interrupt security feature provided by the
SNP. The feature will be added after the base support is accepted.

Additional resources
---------------------
SEV-SNP whitepaper
https://www.amd.com/system/files/TechDocs/SEV-SNP-strengthening-vm-
isolation-with-integrity-protection-and-more.pdf

APM 2: https://www.amd.com/system/files/TechDocs/24593.pdf (section 15.36)

The complete source is available at
https://github.com/AMDESE/ovmf/tree/sev-snp-rfc-5

GHCB spec:
https://developer.amd.com/wp-content/resources/56421.pdf

SEV-SNP firmware specification:
https://www.amd.com/system/files/TechDocs/56860.pdf

Change since v5:
* When possible use the CPUID value from CPUID page
* Move the SEV specific functions from SecMain.c in AmdSev.c
* Rebase to the latest code
* Add the review feedback from Yao.

Change since v4:
* Use the correct MSR for the SEV_STATUS
* Add VMPL-0 check

Change since v3:
* ResetVector: move all SEV specific code in AmdSev.asm and add macros to
keep
the code readable.
* Drop extending the EsWorkArea to contain SNP specific state.
* Drop the GhcbGpa library and call the VmgExit directly to register GHCB GPA.
* Install the CC blob config table from AmdSevDxe instead of extending the
AmdSev/SecretsDxe for it.
* Add the separate PCDs for the SNP Secrets.

Changes since v2:
* Add support for the AP creation.
* Use the module-scoping override to make AmdSevDxe use the IO port for PCI
reads.
* Use the reserved memory type for CPUID and Secrets page.
*
Changes since v1:
* Drop the interval tree support to detect the pre-validated overlap region.
* Use an array to keep track of pre-validated regions.
* Add support to query the Hypervisor feature and verify that SNP feature is
supported.
* Introduce MemEncryptSevClearMmioPageEncMask() to clear the C-bit from
MMIO ranges.
* Pull the SevSecretDxe and SevSecretPei into OVMF package build.
* Extend the SevSecretDxe to expose confidential computing blob location
through
EFI configuration table.

Brijesh Singh (25):
OvmfPkg: reserve SNP secrets page
OvmfPkg: reserve CPUID page for SEV-SNP
OvmfPkg/ResetVector: introduce SEV-SNP boot block GUID
OvmfPkg/ResetVector: invalidate the GHCB page
OvmfPkg/ResetVector: check the vmpl level
OvmfPkg/ResetVector: pre-validate the data pages used in SEC phase
UefiCpuPkg: Define the SEV-SNP specific dynamic PCDs
OvmfPkg/MemEncryptSevLib: add MemEncryptSevSnpEnabled()
OvmfPkg/SecMain: move SEV specific routines in AmdSev.c
OvmfPkg/SecMain: register GHCB gpa for the SEV-SNP guest
OvmfPkg/PlatformPei: register GHCB gpa for the SEV-SNP guest
OvmfPkg/AmdSevDxe: do not use extended PCI config space
OvmfPkg/MemEncryptSevLib: add support to validate system RAM
OvmfPkg/BaseMemEncryptSevLib: skip the pre-validated system RAM
OvmfPkg/MemEncryptSevLib: add support to validate > 4GB memory in PEI
phase
OvmfPkg/SecMain: pre-validate the memory used for decompressing Fv
OvmfPkg/PlatformPei: validate the system RAM when SNP is active
OvmfPkg/PlatformPei: set the SEV-SNP enabled PCD
OvmfPkg/PlatformPei: set the Hypervisor Features PCD
MdePkg/GHCB: increase the GHCB protocol max version
UefiCpuPkg/MpLib: add support to register GHCB GPA when SEV-SNP is
enabled
OvmfPkg/MemEncryptSevLib: change the page state in the RMP table
OvmfPkg/MemEncryptSevLib: skip page state change for Mmio address
OvmfPkg/PlatformPei: mark cpuid and secrets memory reserved in EFI map
OvmfPkg/AmdSev: expose the SNP reserved pages through configuration
table

Michael Roth (3):
OvmfPkg/ResetVector: use SEV-SNP-validated CPUID values
OvmfPkg/VmgExitLib: use SEV-SNP-validated CPUID values
UefiCpuPkg/MpInitLib: use BSP to do extended topology check

Tom Lendacky (1):
UefiCpuPkg/MpInitLib: Use SEV-SNP AP Creation NAE event to launch APs

OvmfPkg/OvmfPkg.dec | 23 +
UefiCpuPkg/UefiCpuPkg.dec | 11 +
OvmfPkg/AmdSev/AmdSevX64.dsc | 5 +-
OvmfPkg/Bhyve/BhyveX64.dsc | 5 +-
OvmfPkg/OvmfPkgIa32.dsc | 1 +
OvmfPkg/OvmfPkgIa32X64.dsc | 6 +-
OvmfPkg/OvmfPkgX64.dsc | 5 +-
OvmfPkg/OvmfXen.dsc | 5 +-
OvmfPkg/OvmfPkgX64.fdf | 12 +-
OvmfPkg/AmdSevDxe/AmdSevDxe.inf | 7 +
.../DxeMemEncryptSevLib.inf | 3 +
.../PeiMemEncryptSevLib.inf | 7 +
.../SecMemEncryptSevLib.inf | 3 +
OvmfPkg/Library/VmgExitLib/SecVmgExitLib.inf | 2 +
OvmfPkg/Library/VmgExitLib/VmgExitLib.inf | 3 +
OvmfPkg/PlatformPei/PlatformPei.inf | 10 +
OvmfPkg/ResetVector/ResetVector.inf | 6 +
OvmfPkg/Sec/SecMain.inf | 4 +
UefiCpuPkg/Library/MpInitLib/DxeMpInitLib.inf | 4 +
UefiCpuPkg/Library/MpInitLib/PeiMpInitLib.inf | 4 +
MdePkg/Include/Register/Amd/Ghcb.h | 2 +-
.../Guid/ConfidentialComputingSecret.h | 18 +
OvmfPkg/Include/Library/MemEncryptSevLib.h | 26 +
.../X64/SnpPageStateChange.h | 31 ++
.../BaseMemEncryptSevLib/X64/VirtualMemory.h | 19 +
OvmfPkg/Sec/AmdSev.h | 95 ++++
UefiCpuPkg/Library/MpInitLib/MpLib.h | 20 +
OvmfPkg/AmdSevDxe/AmdSevDxe.c | 23 +
.../DxeMemEncryptSevLibInternal.c | 27 ++
.../Ia32/MemEncryptSevLib.c | 17 +
.../PeiMemEncryptSevLibInternal.c | 27 ++
.../SecMemEncryptSevLibInternal.c | 19 +
.../X64/DxeSnpSystemRamValidate.c | 40 ++
.../X64/PeiDxeVirtualMemory.c | 167 ++++++-
.../X64/PeiSnpSystemRamValidate.c | 126 +++++
.../X64/SecSnpSystemRamValidate.c | 36 ++
.../X64/SnpPageStateChangeInternal.c | 295 ++++++++++++
OvmfPkg/Library/VmgExitLib/VmgExitVcHandler.c | 444 ++++++++++++++++--
OvmfPkg/PlatformPei/AmdSev.c | 192 ++++++++
OvmfPkg/PlatformPei/MemDetect.c | 21 +
OvmfPkg/Sec/AmdSev.c | 267 +++++++++++
OvmfPkg/Sec/SecMain.c | 160 +------
UefiCpuPkg/Library/MpInitLib/DxeMpLib.c | 11 +-
.../MpInitLib/Ia32/SevSnpRmpAdjustInternal.c | 31 ++
UefiCpuPkg/Library/MpInitLib/MpLib.c | 286 ++++++++++-
.../MpInitLib/X64/SevSnpRmpAdjustInternal.c | 44 ++
OvmfPkg/FvmainCompactScratchEnd.fdf.inc | 5 +
OvmfPkg/ResetVector/Ia16/ResetVectorVtf0.asm | 28 ++
OvmfPkg/ResetVector/Ia32/AmdSev.asm | 307 +++++++++++-
OvmfPkg/ResetVector/ResetVector.nasmb | 6 +
UefiCpuPkg/Library/MpInitLib/MpEqu.inc | 2 +
UefiCpuPkg/Library/MpInitLib/X64/MpFuncs.nasm | 78 +++
52 files changed, 2771 insertions(+), 225 deletions(-)
create mode 100644
OvmfPkg/Library/BaseMemEncryptSevLib/X64/SnpPageStateChange.h
create mode 100644 OvmfPkg/Sec/AmdSev.h
create mode 100644
OvmfPkg/Library/BaseMemEncryptSevLib/X64/DxeSnpSystemRamValidate.c
create mode 100644
OvmfPkg/Library/BaseMemEncryptSevLib/X64/PeiSnpSystemRamValidate.c
create mode 100644
OvmfPkg/Library/BaseMemEncryptSevLib/X64/SecSnpSystemRamValidate.c
create mode 100644
OvmfPkg/Library/BaseMemEncryptSevLib/X64/SnpPageStateChangeInternal.c
create mode 100644 OvmfPkg/Sec/AmdSev.c
create mode 100644
UefiCpuPkg/Library/MpInitLib/Ia32/SevSnpRmpAdjustInternal.c
create mode 100644
UefiCpuPkg/Library/MpInitLib/X64/SevSnpRmpAdjustInternal.c

--
2.17.1


回复: [edk2-devel] Event: TianoCore Bug Triage - APAC / NAMO - 09/07/2021 #cal-reminder

gaoliming
 

Hi, all

 

 The following new issues will be reviewed this week.

 

3264

EDK2 Pla

Placehol

thomas.abraham@...

UNCO

Make use of Edk2 Packages Path so that module INFs in Platform/ARM are more portable.

Mon 05:29

sean.brogan@...

3608

EDK2

Code

unassigned@...

UNCO

Error Message is misleading when enrolling security boot keys failed

Mon 03:33

chunpeng.hou@...

3607

EDK2

Code

unassigned@...

UNCO

Can not access new members added to SMBIOS_TABLE_TYPE9 structure after variable data

Mon 03:19

sainadhn@...

3606

EDK2

Code

unassigned@...

UNCO

VMs that created from CentOS-7-x86_64-DVD-1708.iso fail to boot

Mon 01:38

lei.liu@...

3604

EDK2

Tools

unassigned@...

UNCO

Build races+failure with -j > 1 in MAKEFLAGS

Fri 08:07

jamie@...

3528

Tianocor

Code

unassigned@...

UNCO

Add SMM NV variable support in universal UEFI payload

Fri 06:24

guo.dong@...

3603

EDK2

Code

unassigned@...

UNCO

UefiPayloadPkg: build warnings for IA32+X64 (GCC)

Thu 15:33

kingsumos@...

3602

EDK2 Tes

UEFI-SCT

unassigned@...

UNCO

AuthVariableServicesBBTestConformance.c return code checks

Thu 13:36

stuart.yoder@...

3601

EDK2 Tes

UEFI-SCT

unassigned@...

UNCO

QemuVideoDxe SCT inconsistent test failures and logging issue

Thu 10:40

shashi.mallela@...

3598

EDK2 Cod

Specific

unassigned@...

UNCO

ACPI spec - Allow FFixedHW OpRegion

2021-08-31

samer.el-haj-mahmoud@...

3600

EDK2

Tools

steven.shi@...

UNCO

The $(MODULE_DIR) variable cannot work properly in INF file

2021-08-31

cosmo.lai@...

3599

EDK2

Code

unassigned@...

UNCO

RFE: add support for the microvm machine type (qemu)

2021-08-31

kraxel@...

3590

EDK2

Code

unassigned@...

UNCO

The BootManagerMenuApp would show incorrect when the boot option description is too long

2021-08-30

zhichao.gao@...

3571

EDK2

Code

unassigned@...

UNCO

setup browser stucked when frequently plug and unplug usb storege

2021-08-30

xiewenyi0201@...

3596

Tianocor

Code

unassigned@...

UNCO

Add parallel hash feature into BaseCryptLib

2021-08-30

zhihao.li@...

3581

EDK2

Code

unassigned@...

UNCO

shell invocation might cause inconsistencies in memory maps presented to a operating system

2021-08-27

pspacek@...

3593

EDK2

Code

unassigned@...

UNCO

OVMF: use qemu firmware config instead of cmos for memory detection

2021-08-26

kraxel@...

3592

EDK2

Code

unassigned@...

UNCO

PciBusDxedisable option rom decode

2021-08-26

562918695@...

 

Thanks

Liming

发件人: devel@edk2.groups.io <devel@edk2.groups.io> 代表 devel@edk2.groups.io Calendar
发送时间: 202197 9:30
收件人: devel@edk2.groups.io
主题: [edk2-devel] Event: TianoCore Bug Triage - APAC / NAMO - 09/07/2021 #cal-reminder

 

Reminder: TianoCore Bug Triage - APAC / NAMO

When:
09/07/2021
6:30pm to 7:30pm
(UTC-07:00) America/Los Angeles

Where:
https://teams.microsoft.com/l/meetup-join/19%3ameeting_OTUyZTg2NjgtNDhlNS00ODVlLTllYTUtYzg1OTNjNjdiZjFh%40thread.v2/0?context=%7b%22Tid%22%3a%2246c98d88-e344-4ed4-8496-4ed7712e255d%22%2c%22Oid%22%3a%22b286b53a-1218-4db3-bfc9-3d4c5aa7669e%22%7d

Organizer: Liming Gao gaoliming@...

View Event

Description:

TianoCore Bug Triage - APAC / NAMO

Hosted by Liming Gao

 

________________________________________________________________________________

Microsoft Teams meeting

Join on your computer or mobile app

Click here to join the meeting

Join with a video conferencing device

teams@...

Video Conference ID: 116 062 094 0

Alternate VTC dialing instructions

Or call in (audio only)

+1 916-245-6934,,77463821#   United States, Sacramento

Phone Conference ID: 774 638 21#

Find a local number | Reset PIN

Learn More | Meeting options


Event: TianoCore Bug Triage - APAC / NAMO - 09/07/2021 #cal-reminder

devel@edk2.groups.io Calendar <noreply@...>
 

Reminder: TianoCore Bug Triage - APAC / NAMO

When:
09/07/2021
6:30pm to 7:30pm
(UTC-07:00) America/Los Angeles

Where:
https://teams.microsoft.com/l/meetup-join/19%3ameeting_OTUyZTg2NjgtNDhlNS00ODVlLTllYTUtYzg1OTNjNjdiZjFh%40thread.v2/0?context=%7b%22Tid%22%3a%2246c98d88-e344-4ed4-8496-4ed7712e255d%22%2c%22Oid%22%3a%22b286b53a-1218-4db3-bfc9-3d4c5aa7669e%22%7d

Organizer: Liming Gao gaoliming@...

View Event

Description:

TianoCore Bug Triage - APAC / NAMO

Hosted by Liming Gao

 

________________________________________________________________________________

Microsoft Teams meeting

Join on your computer or mobile app

Click here to join the meeting

Join with a video conferencing device

teams@...

Video Conference ID: 116 062 094 0

Alternate VTC dialing instructions

Or call in (audio only)

+1 916-245-6934,,77463821#   United States, Sacramento

Phone Conference ID: 774 638 21#

Find a local number | Reset PIN

Learn More | Meeting options


回复: [edk2-devel] Python2.7 is not working with the EDK2 build system

gaoliming
 

Bob:

 Yes. Python3 is the formal support. We recommend user to use Python3. But, if user meets the issue in Python2, user can still report the issue in BaseTools. Its priority may be low. For this case, it is the regression issue caused by the recent change. The patch owner is also identified. So, I suggest the patch owner to follow up and enhance his patch.

 

Thanks

Liming

发件人: devel@edk2.groups.io <devel@edk2.groups.io> 代表 Sunny Wang
发送时间: 202196 21:16
收件人: Feng, Bob C <bob.c.feng@...>; gaoliming <gaoliming@...>; devel@edk2.groups.io; Chen, Christine <yuwei.chen@...>; 'Cole Robinson' <crobinso@...>
抄送: Sami Mujawar <Sami.Mujawar@...>; Samer El-Haj-Mahmoud <Samer.El-Haj-Mahmoud@...>; 'Gerd Hoffmann' <kraxel@...>; Sunny Wang <Sunny.Wang@...>
主题: Re: [edk2-devel] Python2.7 is not working with the EDK2 build system

 

Thanks for checking this, Bob and Liming.

 

Hi Bob,

 

Yeah, I was aware of that as well. It makes sense to switch Python2 to Python3. However, Python 2 was discontinued for a while, but there seems no announcement in the mailing list or code change for cleaning up Python 2 stuff in edk2 BaseTools, which may make users feel Python 2 is still useable and cause confusion. Of course, I may miss some activities about deprecating Python 2 in edk2. If so, could you point me out? I just want to have an obvious way to inform edk2 users that Python 2 doesn’t work. If you think this email is good enough as a notification to the edk2 users, I’m fine with this.

 

Moreover, for a quick improvement, how about we add a python version check in the build script to prevent code building and remind users to use Python 3?     

 

Thanks,

Sunny

From: Feng, Bob C <bob.c.feng@...>
Sent: 06 September 2021 10:31
To: gaoliming <gaoliming@...>; devel@edk2.groups.io; Sunny Wang <Sunny.Wang@...>; Chen, Christine <yuwei.chen@...>; 'Cole Robinson' <crobinso@...>
Cc: Sami Mujawar <Sami.Mujawar@...>; Samer El-Haj-Mahmoud <Samer.El-Haj-Mahmoud@...>; 'Gerd Hoffmann' <kraxel@...>
Subject: RE: [edk2-devel] Python2.7 is not working with the EDK2 build system

 

Hi Sunny,

 

EDK II only formally supports Python 3 now because Python 2 is EOL with no support.  So I’d suggest BaseTools users switch Python2 to Python3.

 

Thanks,

Bob

 

From: gaoliming <gaoliming@...>
Sent: Monday, September 6, 2021 9:10 AM
To: devel@edk2.groups.io; Sunny.Wang@...; Feng, Bob C <bob.c.feng@...>; Chen, Christine <yuwei.chen@...>; 'Cole Robinson' <crobinso@...>
Cc: 'Sami Mujawar' <Sami.Mujawar@...>; 'Samer El-Haj-Mahmoud' <Samer.El-Haj-Mahmoud@...>; 'Gerd Hoffmann' <kraxel@...>
Subject:
回复: [edk2-devel] Python2.7 is not working with the EDK2 build system

 

Sunny:

 If Robinson has no response, I suggest to revert this change first.

 

Robinson:

 Can you give your fix plan for this regression issue?

 

Thanks

Liming

发件人: devel@edk2.groups.io <devel@edk2.groups.io> 代表 Sunny Wang
发送时间: 202194 2:09
收件人: Feng, Bob C <bob.c.feng@...>; Liming Gao <gaoliming@...>; Yuwei Chen <yuwei.chen@...>; Cole Robinson <crobinso@...>; devel@edk2.groups.io
抄送: Sunny Wang <Sunny.Wang@...>; Sami Mujawar <Sami.Mujawar@...>; Samer El-Haj-Mahmoud <Samer.El-Haj-Mahmoud@...>
主题: [edk2-devel] Python2.7 is not working with the EDK2 build system

 

Hi all,

 

I just ran into this build issue. After checking the edk2 emails, I saw some of you already ran into this build issue as well. At least, I saw two email threads below talking about this issue.  

https://edk2.groups.io/g/devel/message/80068?p=,,,20,0,0,0::recentpostdate%252Fsticky,,python,20,2,0,85296733

https://edk2.groups.io/g/devel/message/79022?p=,,,20,0,0,0::recentpostdate%2525252Fsticky,,DeprecationWarnings,20,2,0,84409128

 

The main purpose of this email is to have obvious email subject to get people’s attention, so that people won’t spend time to check this when running into this issue.

The solution at this moment is to use Python 3 instead (Use “export PYTHON_COMMAND=/usr/bin/python3” instead of “export PYTHON_COMMAND=/usr/bin/python”).   

 

Hi Robinson,

Are you working on this now? If you’re busy with other things, how about we revert your patch first?

 

Hi Bob, Liming, and Yuwei,

What do you prefer to do at this moment? Wait for Robinson? or revert the change?

 

Best Regards,

Sunny

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.


回复: [edk2-devel] [RFC] RISC-V QEMU virtual package

gaoliming
 

Abner:
I prefer to use git mv command to move those modules from ArmVirtPkg to
OvmfPkg. This way can still keep git history for those modules.

You can create the second patch to update ArmVirtPkg DSC/FDF, or combine
this change into the first patch.

Thanks
Liming
-----邮件原件-----
发件人: devel@edk2.groups.io <devel@edk2.groups.io> 代表 Abner Chang
发送时间: 2021年9月6日 21:05
收件人: Gerd Hoffmann <kraxel@redhat.com>; Ard Biesheuvel
<ardb@kernel.org>
抄送: Yao, Jiewen <jiewen.yao@intel.com>; devel@edk2.groups.io; gaoliming
<gaoliming@byosoft.com.cn>; Ard Biesheuvel <ard.biesheuvel@arm.com>;
Kinney, Michael D <michael.d.kinney@intel.com>; Leif Lindholm
<leif@nuviainc.com>; Ni, Ray <ray.ni@intel.com>; Schaefer, Daniel
<daniel.schaefer@hpe.com>; Sunil V L <sunilvl@ventanamicro.com>; Ard
Biesheuvel <ardb+tianocore@kernel.org>
主题: Re: [edk2-devel] [RFC] RISC-V QEMU virtual package

Ok thanks, do we need the two steps to migrate FDT modules under
OvmfPkg/?
1. One patch set to clone those modules under OvmfPkg/
2. One patch set of ArmVirtPkg change to use those modules and deletes the
ones under ArmVirtPkg/.

Or we just do all at once? I prefer to have two steps. How do you think?

Another question, who would like to be the reviewers of OvmfPkg/Fdt/*? Any
volunteers from CC list?

Thanks
Abner

-----Original Message-----
From: Gerd Hoffmann [mailto:kraxel@redhat.com]
Sent: Monday, September 6, 2021 8:19 PM
To: Ard Biesheuvel <ardb@kernel.org>
Cc: Yao, Jiewen <jiewen.yao@intel.com>; Chang, Abner (HPS SW/FW
Technologist) <abner.chang@hpe.com>; devel@edk2.groups.io; gaoliming
<gaoliming@byosoft.com.cn>; Ard Biesheuvel <ard.biesheuvel@arm.com>;
Kinney, Michael D <michael.d.kinney@intel.com>; Leif Lindholm
<leif@nuviainc.com>; Ni, Ray <ray.ni@intel.com>; Schaefer, Daniel
<daniel.schaefer@hpe.com>; Sunil V L <sunilvl@ventanamicro.com>; Ard
Biesheuvel <ardb+tianocore@kernel.org>
Subject: Re: [edk2-devel] [RFC] RISC-V QEMU virtual package

Hi,

On Mon, Sep 06, 2021 at 02:04:48PM +0200, Ard Biesheuvel wrote:
On Mon, 6 Sept 2021 at 13:44, Yao, Jiewen <jiewen.yao@intel.com>
wrote:

I think it makes sense to put Fdt to OvmfPkg. I suggest an Fdt
folder and
put all things there.

I also think we define Fdt feature in
https://github.com/tianocore/edk2/blob/master/Maintainers.txt to add
reviewer there to help review the code.
Agreed.
Agreeing too.

take care,
Gerd




Re: [PATCH v2 1/1] OvmfPkg: Introduce 16MiB flash size for (primarily) Linuxboot

Devon Bautista
 

So DXEFV needs more space then. I'm wondering that the size doesn't
change according to the commit message. Looking at the fdf files it
seems PEIFV and DXEFV don't have a fixed size, seems everything is
fine as long as the compressed image fits into FVMAIN_COMPACT.

take care,
Gerd
DXEFV would indeed need more space, but I recall that in the first
version of this patch, Laszlo commented:

(2) [FD.MEMFD] should immediately benefit from this change, even if
your downstream populates FVMAIN_COMPACT with something else than
PEIFV and DXEFV. First, we're almost out of (uncompressed) DXEFV space
again.
Second, especially the confidential computing technologies have been
gobbling up the nice, low, free space in FD.MEMFD the way a kid with a
sweet tooth empties a cookie jar. This change is already compat
breaking, so I'd like to see *some* proposal (separate patches) for
enlarging *and pushing up* PEIFV and DXEFV.
For the latter point, I figured that it might be beneficial to expand
FVMAIN_COMPACT as a whole to allow for the possibility of growing either
DXEFV _or_ PEIFV, or both.

Best,
Devon


Re: [PATCH v5 0/8] Ovmf: Disable the TPM2 platform hierarchy

Yao, Jiewen
 

For 3, I don’t understand your problem.
But I don’t think we need link NULL lib instance for Tcg2Dxe.

Thank you
Yao Jiewen

-----Original Message-----
From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Yao, Jiewen
Sent: Monday, September 6, 2021 11:05 PM
To: devel@edk2.groups.io; stefanb@linux.ibm.com; Stefan Berger
<stefanb@linux.vnet.ibm.com>
Cc: mhaeuser@posteo.de; spbrogan@outlook.com;
marcandre.lureau@redhat.com; kraxel@redhat.com
Subject: Re: [edk2-devel] [PATCH v5 0/8] Ovmf: Disable the TPM2 platform
hierarchy

For 2, https://github.com/tianocore/edk2-
platforms/tree/master/Platform/Intel/MinPlatformPkg/Tcg

The edk2-platform solution is to let Tcg2PlatformDxe and Tcg2PlatformPei link
Library/PeiDxeTpmPlatformHierarchyLib.

The DSC/FDF can include Tcg2PlatformDxe and Tcg2PlatformPei. No BDS change
is required.


-----Original Message-----
From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Stefan
Berger
Sent: Monday, September 6, 2021 9:50 PM
To: devel@edk2.groups.io; Yao, Jiewen <jiewen.yao@intel.com>; Stefan
Berger
<stefanb@linux.vnet.ibm.com>
Cc: mhaeuser@posteo.de; spbrogan@outlook.com;
marcandre.lureau@redhat.com; kraxel@redhat.com
Subject: Re: [edk2-devel] [PATCH v5 0/8] Ovmf: Disable the TPM2 platform
hierarchy


On 9/6/21 8:34 AM, Yao, Jiewen wrote:
Hi Stefan
Thank you very much for the work.

I would like to double confirm with you on several things:
1) S3 resume - According to security guideline, we can randomize platform
hiearachy if S3 start state fail.

REF: https://github.com/tianocore/edk2-
platforms/blob/master/Platform/Intel/MinPlatformPkg/Tcg/Tcg2PlatformPei/T
cg2PlatformPei.c

But I did not see your S3 solution there.
That may be a omission, also for ARM.



2) I am curious, why you don't use a DXE driver, but choose to like to BDS lib
for the DXE case.

I don't know the difference. Is the code in edk2-platforms unsuitable?


You also include a NULL lib there, which seems unnecessary, if you use a
DXE/PEI module

The downside of linking to BDS lib is that you have to change all BDS lib
instance, which is a big burden.
And you still have code to choose NULL lib v.s. real Lib based upon TPM
enable
flag.

How about just include Tcg2PlatformPei/Tcg2PlatformDxe to securityPkg as
well? Then we can remove the TcgPlatform from MinPlatform totally.

3) In some platform, you add TpmPlatformHierarchyLib to Tcg2Dxe. Would
you please help me understand why?

SecurityPkg/Tcg/Tcg2Dxe/Tcg2Dxe.inf {
<LibraryClasses>
Tpm2DeviceLib|SecurityPkg/Library/Tpm2DeviceLibRouter/Tpm2DeviceLibRout
erDxe.inf
TpmPlatformHierarchyLib|SecurityPkg/Library/PeiDxeTpmPlatformHierarchyLib/
PeiDxeTpmPlatformHierarchyLib.inf
NULL|SecurityPkg/Library/Tpm2DeviceLibDTpm/Tpm2InstanceLibDTpm.inf

I cannot compile several of the target platforms that I have made
modifications to that I thought were correct but have done so 'blindly'.
For example , I cannot compile for OvmfPkg/AmdSev/AmdSevX64.dsc, it
fails for me for this reason:

# build -p OvmfPkg/AmdSev/AmdSevX64.dsc -b DEBUG -a X64 -t GCC5 -D
TPM_ENABLE -D TPM_CONFIG_ENABLE -D SECURE_BOOT_ENABLE -D
NETWORK_TLS_ENABLE

mkfs.fat 4.2 (2021-01-31)
grub2-mkimage: error: cannot open `/usr/lib/grub/x86_64-efi/moddep.lst':
No such file or directory.


This here is an example of a platform I cannot build at all (before my
modifications) but would need changes as well:

$ build -p OvmfPkg/OvmfPkgIa32X64.dsc -b DEBUG -a IA32 -t GCC5 -D
TPM_ENABLE -D TPM_CONFIG_ENABLE -D SECURE_BOOT_ENABLE -D
NETWORK_TLS_ENABLE

[...]

Active Platform          =
/home/stefanb/dev/edk2/OvmfPkg/OvmfPkgIa32X64.dsc
.

build.py...
 : error F001: Module
/home/stefanb/dev/edk2/MdeModulePkg/Universal/DevicePathDxe/DevicePat
hDxe.inf
NOT found in DSC file; Is it really a binary module?



Should I drop the targets I cannot compile for or that seem broken just
to begin with?


Does someone else want to take a pass on this series? I have to say that
I work with too many unknowns here so that this is now the preferred
path from my perspective.

Thanks.

   Stefan








Re: [PATCH v5 0/8] Ovmf: Disable the TPM2 platform hierarchy

Yao, Jiewen
 

For 2, https://github.com/tianocore/edk2-platforms/tree/master/Platform/Intel/MinPlatformPkg/Tcg

The edk2-platform solution is to let Tcg2PlatformDxe and Tcg2PlatformPei link Library/PeiDxeTpmPlatformHierarchyLib.

The DSC/FDF can include Tcg2PlatformDxe and Tcg2PlatformPei. No BDS change is required.

-----Original Message-----
From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Stefan
Berger
Sent: Monday, September 6, 2021 9:50 PM
To: devel@edk2.groups.io; Yao, Jiewen <jiewen.yao@intel.com>; Stefan Berger
<stefanb@linux.vnet.ibm.com>
Cc: mhaeuser@posteo.de; spbrogan@outlook.com;
marcandre.lureau@redhat.com; kraxel@redhat.com
Subject: Re: [edk2-devel] [PATCH v5 0/8] Ovmf: Disable the TPM2 platform
hierarchy


On 9/6/21 8:34 AM, Yao, Jiewen wrote:
Hi Stefan
Thank you very much for the work.

I would like to double confirm with you on several things:
1) S3 resume - According to security guideline, we can randomize platform
hiearachy if S3 start state fail.

REF: https://github.com/tianocore/edk2-
platforms/blob/master/Platform/Intel/MinPlatformPkg/Tcg/Tcg2PlatformPei/T
cg2PlatformPei.c

But I did not see your S3 solution there.
That may be a omission, also for ARM.



2) I am curious, why you don't use a DXE driver, but choose to like to BDS lib
for the DXE case.

I don't know the difference. Is the code in edk2-platforms unsuitable?


You also include a NULL lib there, which seems unnecessary, if you use a
DXE/PEI module

The downside of linking to BDS lib is that you have to change all BDS lib
instance, which is a big burden.
And you still have code to choose NULL lib v.s. real Lib based upon TPM enable
flag.

How about just include Tcg2PlatformPei/Tcg2PlatformDxe to securityPkg as
well? Then we can remove the TcgPlatform from MinPlatform totally.

3) In some platform, you add TpmPlatformHierarchyLib to Tcg2Dxe. Would
you please help me understand why?

SecurityPkg/Tcg/Tcg2Dxe/Tcg2Dxe.inf {
<LibraryClasses>
Tpm2DeviceLib|SecurityPkg/Library/Tpm2DeviceLibRouter/Tpm2DeviceLibRout
erDxe.inf
TpmPlatformHierarchyLib|SecurityPkg/Library/PeiDxeTpmPlatformHierarchyLib/
PeiDxeTpmPlatformHierarchyLib.inf
NULL|SecurityPkg/Library/Tpm2DeviceLibDTpm/Tpm2InstanceLibDTpm.inf

I cannot compile several of the target platforms that I have made
modifications to that I thought were correct but have done so 'blindly'.
For example , I cannot compile for OvmfPkg/AmdSev/AmdSevX64.dsc, it
fails for me for this reason:

# build -p OvmfPkg/AmdSev/AmdSevX64.dsc -b DEBUG -a X64 -t GCC5 -D
TPM_ENABLE -D TPM_CONFIG_ENABLE -D SECURE_BOOT_ENABLE -D
NETWORK_TLS_ENABLE

mkfs.fat 4.2 (2021-01-31)
grub2-mkimage: error: cannot open `/usr/lib/grub/x86_64-efi/moddep.lst':
No such file or directory.


This here is an example of a platform I cannot build at all (before my
modifications) but would need changes as well:

$ build -p OvmfPkg/OvmfPkgIa32X64.dsc -b DEBUG -a IA32 -t GCC5 -D
TPM_ENABLE -D TPM_CONFIG_ENABLE -D SECURE_BOOT_ENABLE -D
NETWORK_TLS_ENABLE

[...]

Active Platform          = /home/stefanb/dev/edk2/OvmfPkg/OvmfPkgIa32X64.dsc
.

build.py...
 : error F001: Module
/home/stefanb/dev/edk2/MdeModulePkg/Universal/DevicePathDxe/DevicePat
hDxe.inf
NOT found in DSC file; Is it really a binary module?



Should I drop the targets I cannot compile for or that seem broken just
to begin with?


Does someone else want to take a pass on this series? I have to say that
I work with too many unknowns here so that this is now the preferred
path from my perspective.

Thanks.

   Stefan





Re: [PATCH] OvmfPkg/OvmfXen: Fix build with QemuKernelLoaderFsDxe

Ard Biesheuvel
 

On Mon, 6 Sept 2021 at 16:03, Anthony PERARD <anthony.perard@citrix.com> wrote:

From: Anthony PERARD <anthony.perard@citrix.com>

VerifyBlob() has been added recently to QemuKernelLoaderFsDxe, also
QemuKernelLoaderFsDxe has also been added recently to OvmfXen but
without an implementation of VerifyBlob().

Fix this by adding the same runes that has been addde to
OvmfPkgX64.dsc.

Fixes: 9f3eda177a4b ("OvmfPkg/OvmfXen: add QemuKernelLoaderFsDxe")
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Oops. Thanks for the fix

Merged as #1953




---
OvmfPkg/OvmfXen.dsc | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/OvmfPkg/OvmfXen.dsc b/OvmfPkg/OvmfXen.dsc
index 1a9c06c164a8..a31519e356b7 100644
--- a/OvmfPkg/OvmfXen.dsc
+++ b/OvmfPkg/OvmfXen.dsc
@@ -587,7 +587,10 @@ [Components]
NULL|OvmfPkg/Csm/LegacyBootMaintUiLib/LegacyBootMaintUiLib.inf
!endif
}
- OvmfPkg/QemuKernelLoaderFsDxe/QemuKernelLoaderFsDxe.inf
+ OvmfPkg/QemuKernelLoaderFsDxe/QemuKernelLoaderFsDxe.inf {
+ <LibraryClasses>
+ NULL|OvmfPkg/Library/BlobVerifierLibNull/BlobVerifierLibNull.inf
+ }
OvmfPkg/XenIoPvhDxe/XenIoPvhDxe.inf
OvmfPkg/XenIoPciDxe/XenIoPciDxe.inf
OvmfPkg/XenBusDxe/XenBusDxe.inf
--
Anthony PERARD


[PATCH] OvmfPkg/OvmfXen: Fix build with QemuKernelLoaderFsDxe

Anthony PERARD
 

From: Anthony PERARD <anthony.perard@citrix.com>

VerifyBlob() has been added recently to QemuKernelLoaderFsDxe, also
QemuKernelLoaderFsDxe has also been added recently to OvmfXen but
without an implementation of VerifyBlob().

Fix this by adding the same runes that has been addde to
OvmfPkgX64.dsc.

Fixes: 9f3eda177a4b ("OvmfPkg/OvmfXen: add QemuKernelLoaderFsDxe")
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
OvmfPkg/OvmfXen.dsc | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/OvmfPkg/OvmfXen.dsc b/OvmfPkg/OvmfXen.dsc
index 1a9c06c164a8..a31519e356b7 100644
--- a/OvmfPkg/OvmfXen.dsc
+++ b/OvmfPkg/OvmfXen.dsc
@@ -587,7 +587,10 @@ [Components]
NULL|OvmfPkg/Csm/LegacyBootMaintUiLib/LegacyBootMaintUiLib.inf
!endif
}
- OvmfPkg/QemuKernelLoaderFsDxe/QemuKernelLoaderFsDxe.inf
+ OvmfPkg/QemuKernelLoaderFsDxe/QemuKernelLoaderFsDxe.inf {
+ <LibraryClasses>
+ NULL|OvmfPkg/Library/BlobVerifierLibNull/BlobVerifierLibNull.inf
+ }
OvmfPkg/XenIoPvhDxe/XenIoPvhDxe.inf
OvmfPkg/XenIoPciDxe/XenIoPciDxe.inf
OvmfPkg/XenBusDxe/XenBusDxe.inf
--
Anthony PERARD


Re: [PATCH v5 0/8] Ovmf: Disable the TPM2 platform hierarchy

Stefan Berger
 

On 9/6/21 8:34 AM, Yao, Jiewen wrote:
Hi Stefan
Thank you very much for the work.

I would like to double confirm with you on several things:
1) S3 resume - According to security guideline, we can randomize platform hiearachy if S3 start state fail.

REF: https://github.com/tianocore/edk2-platforms/blob/master/Platform/Intel/MinPlatformPkg/Tcg/Tcg2PlatformPei/Tcg2PlatformPei.c

But I did not see your S3 solution there.
That may be a omission, also for ARM.



2) I am curious, why you don't use a DXE driver, but choose to like to BDS lib for the DXE case.
I don't know the difference. Is the code in edk2-platforms unsuitable?


You also include a NULL lib there, which seems unnecessary, if you use a DXE/PEI module

The downside of linking to BDS lib is that you have to change all BDS lib instance, which is a big burden.
And you still have code to choose NULL lib v.s. real Lib based upon TPM enable flag.

How about just include Tcg2PlatformPei/Tcg2PlatformDxe to securityPkg as well? Then we can remove the TcgPlatform from MinPlatform totally.

3) In some platform, you add TpmPlatformHierarchyLib to Tcg2Dxe. Would you please help me understand why?

SecurityPkg/Tcg/Tcg2Dxe/Tcg2Dxe.inf {
<LibraryClasses>
Tpm2DeviceLib|SecurityPkg/Library/Tpm2DeviceLibRouter/Tpm2DeviceLibRouterDxe.inf
TpmPlatformHierarchyLib|SecurityPkg/Library/PeiDxeTpmPlatformHierarchyLib/PeiDxeTpmPlatformHierarchyLib.inf
NULL|SecurityPkg/Library/Tpm2DeviceLibDTpm/Tpm2InstanceLibDTpm.inf
I cannot compile several of the target platforms that I have made modifications to that I thought were correct but have done so 'blindly'. For example , I cannot compile for OvmfPkg/AmdSev/AmdSevX64.dsc, it fails for me for this reason:

# build -p OvmfPkg/AmdSev/AmdSevX64.dsc -b DEBUG -a X64 -t GCC5 -D TPM_ENABLE -D TPM_CONFIG_ENABLE -D SECURE_BOOT_ENABLE -D NETWORK_TLS_ENABLE

mkfs.fat 4.2 (2021-01-31)
grub2-mkimage: error: cannot open `/usr/lib/grub/x86_64-efi/moddep.lst': No such file or directory.


This here is an example of a platform I cannot build at all (before my modifications) but would need changes as well:

$ build -p OvmfPkg/OvmfPkgIa32X64.dsc -b DEBUG -a IA32 -t GCC5 -D TPM_ENABLE -D TPM_CONFIG_ENABLE -D SECURE_BOOT_ENABLE -D NETWORK_TLS_ENABLE

[...]

Active Platform          = /home/stefanb/dev/edk2/OvmfPkg/OvmfPkgIa32X64.dsc
.

build.py...
 : error F001: Module /home/stefanb/dev/edk2/MdeModulePkg/Universal/DevicePathDxe/DevicePathDxe.inf NOT found in DSC file; Is it really a binary module?



Should I drop the targets I cannot compile for or that seem broken just to begin with?


Does someone else want to take a pass on this series? I have to say that I work with too many unknowns here so that this is now the preferred path from my perspective.

Thanks.

   Stefan


Re: [PATCH v6 06/29] OvmfPkg/ResetVector: pre-validate the data pages used in SEC phase

Min Xu
 

On September 6, 2021 8:17 PM, Gerd Hoffman wrote:
Hi,

sevSnpBootBlockStart:
+ DD SNP_HV_VALIDATED_START
+ DD SNP_HV_VALIDATED_END
We pack all the Tdx information into a blob (TdxMetadata). These tdx
information Includes the BFV(i.e. OVMF_CODE.fd), the CFV(i.e.
OVMF_VARS.fd), TdMailbox, etc.
The offset to the TdxMetadata is in the GUIDed chain in
ResetVectorVtf0.asm.

In the future new metadata can be added into the TdxMetadata without
changes in ResetVectorVtf0.asm.
[ Looking at https://www.mail-
archive.com/devel@edk2.groups.io/msg33605.html ]

So, there isn't much tdx-specific in tdx-metadata. Most ranges are
TDX_METADATA_SECTION_TYPE_TEMP_MEM which I think basically means
these ranges should be accepted by the hypervisor, which is pretty much the
same issue snp tries to solve with this pre-validation range. Then there are
the ranges for code (aka bfv), for vars (aka cfv) and td_hob.

td_hob is the only tdx-specific item there, and even that concept (pass
memory ranges as hob list from hypervisor to guest) might be useful outside
tdx.
Mailbox is tdx-specific too. But Stack/Heap/OvmfWorkarea/OvmfPageTable are
common. BFV/CFV are common too.

So, can we settle on one approach for this please? I think the tdx-metadata
style approach is more flexible and future-proof. It can easily be extended
without changing data structures, we only need new section types. I expect
this will work better long-term when it comes to backward-compatibility.

I'd suggest we generalize the tdx-metadata idea and define both generic and
vmm-specific section types:

enum {
OVMF_SECTION_TYPE_UNDEFINED = 0;

/* generic */
OVMF_SECTION_TYPE_CODE = 0x100,
OVMF_SECTION_TYPE_VARS
OVMF_SECTION_TYPE_SEC_MEM /* vmm should accept/validate this */

/* sev */
OVMF_SECTION_TYPE_SEV_SECRETS = 0x200,
OVMF_SECTION_TYPE_SEV_CPUID /* or move to generic? */

/* tdx */
OVMV_SECTION_TYPE_TDX_TD_HOB = 0x300,
};

Comments?
TDX has similar section type.
But I am not sure if SEV can use this metadata mechanism.
Need SEV's comments.

Looking at tdx-metadata I have a few questions:

+_Bfv:
+ DD TDX_BFV_RAW_DATA_OFFSET
+ DD TDX_BFV_RAW_DATA_SIZE

What is this and why is it needed?
Host VMM need to measure the code part (BFV) to MRTD register
(which is similar to TPM PCRs).

+ DQ TDX_BFV_MEMORY_BASE
+ DQ TDX_BFV_MEMORY_SIZE

Why "DQ"? TDX is defined to start in 32bit mode, so you can hardly have
addresses here which do not fit into "DD", correct?
Those are the memory. TDX is running in long mode. So it is DQ.

+ DD TDX_METADATA_SECTION_TYPE_BFV
+ DD TDX_METADATA_ATTRIBUTES_EXTENDMR

What does this attribute mean?
It indicates if the host VMM should use TDCALL[TDH.MR.EXTEND] for this section.
https://software.intel.com/content/dam/develop/external/us/en/documents/tdx-virtual-firmware-design-guide-rev-1.pdf
Please refer to Section 11 TDVF Metadata for more detailed information.
Note: this Section will be updated according to the comments from the community.
Thanks!
Min


Re: Python2.7 is not working with the EDK2 build system

Sunny Wang
 

Thanks for checking this, Bob and Liming.

 

Hi Bob,

 

Yeah, I was aware of that as well. It makes sense to switch Python2 to Python3. However, Python 2 was discontinued for a while, but there seems no announcement in the mailing list or code change for cleaning up Python 2 stuff in edk2 BaseTools, which may make users feel Python 2 is still useable and cause confusion. Of course, I may miss some activities about deprecating Python 2 in edk2. If so, could you point me out? I just want to have an obvious way to inform edk2 users that Python 2 doesn’t work. If you think this email is good enough as a notification to the edk2 users, I’m fine with this.

 

Moreover, for a quick improvement, how about we add a python version check in the build script to prevent code building and remind users to use Python 3?     

 

Thanks,

Sunny

From: Feng, Bob C <bob.c.feng@...>
Sent: 06 September 2021 10:31
To: gaoliming <gaoliming@...>; devel@edk2.groups.io; Sunny Wang <Sunny.Wang@...>; Chen, Christine <yuwei.chen@...>; 'Cole Robinson' <crobinso@...>
Cc: Sami Mujawar <Sami.Mujawar@...>; Samer El-Haj-Mahmoud <Samer.El-Haj-Mahmoud@...>; 'Gerd Hoffmann' <kraxel@...>
Subject: RE: [edk2-devel] Python2.7 is not working with the EDK2 build system

 

Hi Sunny,

 

EDK II only formally supports Python 3 now because Python 2 is EOL with no support.  So I’d suggest BaseTools users switch Python2 to Python3.

 

Thanks,

Bob

 

From: gaoliming <gaoliming@...>
Sent: Monday, September 6, 2021 9:10 AM
To: devel@edk2.groups.io; Sunny.Wang@...; Feng, Bob C <bob.c.feng@...>; Chen, Christine <yuwei.chen@...>; 'Cole Robinson' <crobinso@...>
Cc: 'Sami Mujawar' <Sami.Mujawar@...>; 'Samer El-Haj-Mahmoud' <Samer.El-Haj-Mahmoud@...>; 'Gerd Hoffmann' <kraxel@...>
Subject: 回复: [edk2-devel] Python2.7 is not working with the EDK2 build system

 

Sunny:

 If Robinson has no response, I suggest to revert this change first.

 

Robinson:

 Can you give your fix plan for this regression issue?

 

Thanks

Liming

发件人: devel@edk2.groups.io <devel@edk2.groups.io> 代表 Sunny Wang
发送时间: 202194 2:09
收件人: Feng, Bob C <bob.c.feng@...>; Liming Gao <gaoliming@...>; Yuwei Chen <yuwei.chen@...>; Cole Robinson <crobinso@...>; devel@edk2.groups.io
抄送: Sunny Wang <Sunny.Wang@...>; Sami Mujawar <Sami.Mujawar@...>; Samer El-Haj-Mahmoud <Samer.El-Haj-Mahmoud@...>
主题: [edk2-devel] Python2.7 is not working with the EDK2 build system

 

Hi all,

 

I just ran into this build issue. After checking the edk2 emails, I saw some of you already ran into this build issue as well. At least, I saw two email threads below talking about this issue.  

https://edk2.groups.io/g/devel/message/80068?p=,,,20,0,0,0::recentpostdate%252Fsticky,,python,20,2,0,85296733

https://edk2.groups.io/g/devel/message/79022?p=,,,20,0,0,0::recentpostdate%2525252Fsticky,,DeprecationWarnings,20,2,0,84409128

 

The main purpose of this email is to have obvious email subject to get people’s attention, so that people won’t spend time to check this when running into this issue.

The solution at this moment is to use Python 3 instead (Use “export PYTHON_COMMAND=/usr/bin/python3” instead of “export PYTHON_COMMAND=/usr/bin/python”).   

 

Hi Robinson,

Are you working on this now? If you’re busy with other things, how about we revert your patch first?

 

Hi Bob, Liming, and Yuwei,

What do you prefer to do at this moment? Wait for Robinson? or revert the change?

 

Best Regards,

Sunny

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.


Re: [RFC] RISC-V QEMU virtual package

Abner Chang
 

Ok thanks, do we need the two steps to migrate FDT modules under OvmfPkg/?
1. One patch set to clone those modules under OvmfPkg/
2. One patch set of ArmVirtPkg change to use those modules and deletes the ones under ArmVirtPkg/.

Or we just do all at once? I prefer to have two steps. How do you think?

Another question, who would like to be the reviewers of OvmfPkg/Fdt/*? Any volunteers from CC list?

Thanks
Abner

-----Original Message-----
From: Gerd Hoffmann [mailto:kraxel@redhat.com]
Sent: Monday, September 6, 2021 8:19 PM
To: Ard Biesheuvel <ardb@kernel.org>
Cc: Yao, Jiewen <jiewen.yao@intel.com>; Chang, Abner (HPS SW/FW
Technologist) <abner.chang@hpe.com>; devel@edk2.groups.io; gaoliming
<gaoliming@byosoft.com.cn>; Ard Biesheuvel <ard.biesheuvel@arm.com>;
Kinney, Michael D <michael.d.kinney@intel.com>; Leif Lindholm
<leif@nuviainc.com>; Ni, Ray <ray.ni@intel.com>; Schaefer, Daniel
<daniel.schaefer@hpe.com>; Sunil V L <sunilvl@ventanamicro.com>; Ard
Biesheuvel <ardb+tianocore@kernel.org>
Subject: Re: [edk2-devel] [RFC] RISC-V QEMU virtual package

Hi,

On Mon, Sep 06, 2021 at 02:04:48PM +0200, Ard Biesheuvel wrote:
On Mon, 6 Sept 2021 at 13:44, Yao, Jiewen <jiewen.yao@intel.com> wrote:

I think it makes sense to put Fdt to OvmfPkg. I suggest an Fdt folder and
put all things there.

I also think we define Fdt feature in
https://github.com/tianocore/edk2/blob/master/Maintainers.txt to add
reviewer there to help review the code.
Agreed.
Agreeing too.

take care,
Gerd


Re: [PATCH v5 0/8] Ovmf: Disable the TPM2 platform hierarchy

Yao, Jiewen
 

Hi Stefan
Thank you very much for the work.

I would like to double confirm with you on several things:
1) S3 resume - According to security guideline, we can randomize platform hiearachy if S3 start state fail.

REF: https://github.com/tianocore/edk2-platforms/blob/master/Platform/Intel/MinPlatformPkg/Tcg/Tcg2PlatformPei/Tcg2PlatformPei.c

But I did not see your S3 solution there.

2) I am curious, why you don't use a DXE driver, but choose to like to BDS lib for the DXE case.
You also include a NULL lib there, which seems unnecessary, if you use a DXE/PEI module.

The downside of linking to BDS lib is that you have to change all BDS lib instance, which is a big burden.
And you still have code to choose NULL lib v.s. real Lib based upon TPM enable flag.

How about just include Tcg2PlatformPei/Tcg2PlatformDxe to securityPkg as well? Then we can remove the TcgPlatform from MinPlatform totally.

3) In some platform, you add TpmPlatformHierarchyLib to Tcg2Dxe. Would you please help me understand why?

SecurityPkg/Tcg/Tcg2Dxe/Tcg2Dxe.inf {
<LibraryClasses>
Tpm2DeviceLib|SecurityPkg/Library/Tpm2DeviceLibRouter/Tpm2DeviceLibRouterDxe.inf
TpmPlatformHierarchyLib|SecurityPkg/Library/PeiDxeTpmPlatformHierarchyLib/PeiDxeTpmPlatformHierarchyLib.inf
NULL|SecurityPkg/Library/Tpm2DeviceLibDTpm/Tpm2InstanceLibDTpm.inf

-----Original Message-----
From: Stefan Berger <stefanb@linux.vnet.ibm.com>
Sent: Thursday, September 2, 2021 5:22 AM
To: devel@edk2.groups.io
Cc: mhaeuser@posteo.de; spbrogan@outlook.com;
marcandre.lureau@redhat.com; kraxel@redhat.com; Yao, Jiewen
<jiewen.yao@intel.com>; Stefan Berger <stefanb@linux.vnet.ibm.com>
Subject: [PATCH v5 0/8] Ovmf: Disable the TPM2 platform hierarchy

This series imports code from the edk2-platforms project related to
disabling the TPM2 platform hierarchy in Ovmf and ArmVirtPkg. It
addresses the Ovmf aspects of the following bugs:

https://bugzilla.tianocore.org/show_bug.cgi?id=3510
https://bugzilla.tianocore.org/show_bug.cgi?id=3499

I have patched the .dsc files and successfully test-built with most of
them. Some I could not build because they failed for other reasons
unrelated to this series.

I tested the changes with QEMU on x86 following the build of
ArmVirtQemu.dsc and OvmfPkgX64.dsc.

The disablement of the platform hierarchy is done after possibly
handling PPI. Following TPM 2 logs on Arm, only PCR extensions are
following afterwards until GRUB takes over.

Neither one of the following commands should work anymore on first
try:

With IBM tss2 tools:
tsshierarchychangeauth -hi p -pwdn newpass

With Intel tss2 tools:
tpm2_changeauth -c platform newpass

Regards,
Stefan

v5:
- Modified patch 1 copies the code from edk2-platforms
- Modified patch 2 fixes bugs in the code
- Modified patch 4 introduces required PCD

v4:
- Fixed and simplified code imported from edk2-platforms

v3:
- Referencing Null implementation on Bhyve and Xen platforms
- Add support in ArmVirtPkg


Stefan Berger (8):
SecurityPkg/TPM: Import PeiDxeTpmPlatformHierarchyLib.c from
edk2-platforms
SecurityPkg/TPM: Fix bugs in imported PeiDxeTpmPlatformHierarchyLib
SecurityPkg/TPM: Add a NULL implementation of TpmPlatformHierarchyLib
SecurityPkg: Introduce new PCD PcdRandomizePlatformHierarchy
OvmfPkg: Reference new TPM classes in the build system for compilation
OvmfPkg: Disable the TPM2 platform hierarchy
ArmVirtPkg: Reference new TPM classes in the build system for
compilation
ArmVirtPkg: Disable the TPM2 platform hierarchy

ArmVirtPkg/ArmVirtCloudHv.dsc | 1 +
ArmVirtPkg/ArmVirtQemu.dsc | 3 +
ArmVirtPkg/ArmVirtQemuKernel.dsc | 1 +
ArmVirtPkg/ArmVirtXen.dsc | 1 +
.../PlatformBootManagerLib/PlatformBm.c | 6 +
.../PlatformBootManagerLib.inf | 2 +
OvmfPkg/AmdSev/AmdSevX64.dsc | 3 +
OvmfPkg/Bhyve/BhyveX64.dsc | 1 +
.../PlatformBootManagerLib/BdsPlatform.c | 6 +
.../PlatformBootManagerLib.inf | 1 +
.../PlatformBootManagerLibBhyve/BdsPlatform.c | 7 +
.../PlatformBootManagerLibGrub/BdsPlatform.c | 7 +
OvmfPkg/OvmfPkgIa32.dsc | 3 +
OvmfPkg/OvmfPkgIa32X64.dsc | 3 +
OvmfPkg/OvmfPkgX64.dsc | 3 +
OvmfPkg/OvmfXen.dsc | 1 +
.../Include/Library/TpmPlatformHierarchyLib.h | 27 ++
.../PeiDxeTpmPlatformHierarchyLib.c | 255 ++++++++++++++++++
.../PeiDxeTpmPlatformHierarchyLib.inf | 44 +++
.../PeiDxeTpmPlatformHierarchyLib.c | 19 ++
.../PeiDxeTpmPlatformHierarchyLib.inf | 31 +++
SecurityPkg/SecurityPkg.dec | 6 +
22 files changed, 431 insertions(+)
create mode 100644 SecurityPkg/Include/Library/TpmPlatformHierarchyLib.h
create mode 100644
SecurityPkg/Library/PeiDxeTpmPlatformHierarchyLib/PeiDxeTpmPlatformHierar
chyLib.c
create mode 100644
SecurityPkg/Library/PeiDxeTpmPlatformHierarchyLib/PeiDxeTpmPlatformHierar
chyLib.inf
create mode 100644
SecurityPkg/Library/PeiDxeTpmPlatformHierarchyLibNull/PeiDxeTpmPlatformHi
erarchyLib.c
create mode 100644
SecurityPkg/Library/PeiDxeTpmPlatformHierarchyLibNull/PeiDxeTpmPlatformHi
erarchyLib.inf

--
2.31.1


Re: [RFC] RISC-V QEMU virtual package

Gerd Hoffmann
 

Hi,

On Mon, Sep 06, 2021 at 02:04:48PM +0200, Ard Biesheuvel wrote:
On Mon, 6 Sept 2021 at 13:44, Yao, Jiewen <jiewen.yao@intel.com> wrote:

I think it makes sense to put Fdt to OvmfPkg. I suggest an Fdt folder and put all things there.

I also think we define Fdt feature in https://github.com/tianocore/edk2/blob/master/Maintainers.txt to add reviewer there to help review the code.
Agreed.
Agreeing too.

take care,
Gerd

2141 - 2160 of 82350