Date   

[PATCH v3 0/4] OvmfPkg: Disable the TPM 2 platform hierarchy

Stefan Berger
 

This series of patches adds support for disabling the TPM 2 platform
hierarchy to Ovmf. To be able to do this we have to handle TPM 2
physical presence interface (PPI) opcodes before the TPM 2 platform
hierarchy is disabled otherwise TPM 2 commands that are sent due to the
PPI opcodes may fail if the platform hierarchy is already disabled.
Therefore, we need to invoke the handler function
Tcg2PhysicalPresenceLibProcessRequest from within
PlatformBootManagerBeforeConsole. Since handling of PPI opcodes may require
interaction with the user, we also move PlatformInitializeConsole
to before the handling of PPI codes so that the keyboard is available
when needed. The PPI handling code will activate the default consoles
only if it requires user interaction.

Regards,
Stefan

v3:
- Added Yao's R-b's
- Added Amd, Bhyve, and Ovmf maintainers and reviewers to Cc
=
v2:
- 1/4: Added missing link library
- 2/4: Modified other BdsPlatform.c files as well
- Added Yao's comments to 1/2 and 2/2


Stefan Berger (4):
OvmfPkg/TPM PPI: Connect default consoles for user interaction
OvmfPkg: Handle TPM 2 physical presence opcodes much earlier
OvmfPkg: Reference new Tcg2PlatformDxe in the build system for
compilation
OvmfPkg: Reference new Tcg2PlatformPei in the build system

OvmfPkg/AmdSev/AmdSevX64.dsc | 8 ++++++++
OvmfPkg/AmdSev/AmdSevX64.fdf | 2 ++
.../PlatformBootManagerLib/BdsPlatform.c | 19 +++++++++++--------
.../PlatformBootManagerLibBhyve/BdsPlatform.c | 17 ++++++++++-------
.../PlatformBootManagerLibGrub/BdsPlatform.c | 17 ++++++++++-------
.../DxeTcg2PhysicalPresenceLib.c | 5 +++++
.../DxeTcg2PhysicalPresenceLib.inf | 1 +
OvmfPkg/OvmfPkgIa32.dsc | 8 ++++++++
OvmfPkg/OvmfPkgIa32.fdf | 2 ++
OvmfPkg/OvmfPkgIa32X64.dsc | 8 ++++++++
OvmfPkg/OvmfPkgIa32X64.fdf | 2 ++
OvmfPkg/OvmfPkgX64.dsc | 8 ++++++++
OvmfPkg/OvmfPkgX64.fdf | 2 ++
13 files changed, 77 insertions(+), 22 deletions(-)

--
2.31.1


[PATCH v3 1/4] OvmfPkg/TPM PPI: Connect default consoles for user interaction

Stefan Berger
 

From: Stefan Berger <stefanb@linux.vnet.ibm.com>

Activate the default console when user interaction is required for
the processing of TPM 2 physical presence interface opcodes.

Background:
TPM 2 physical presence interface (PPI) opcodes need to be handled before
the TPM 2 platform hierarchy is disabled. Due to this requirement we will
move the function call to handle the PPI opcodes into
PlatformBootManagerBeforeConsole() which runs before the initialization
of the consoles. However, since for interaction with the user we need
the console to be available, activate it now before displaying any message
to the user.

Cc: Rebecca Cran <rebecca@bsdio.com>
Cc: Peter Grehan <grehan@freebsd.org>
Cc: Brijesh Singh <brijesh.singh@amd.com>
Cc: Erdem Aktas <erdemaktas@google.com>
Cc: James Bottomley <jejb@linux.ibm.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Min Xu <min.m.xu@intel.com>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Stefan Berger <stefanb@linux.ibm.com>
Reviewed-by: Jiewen Yao <Jiewen.yao@intel.com>
---
.../Tcg2PhysicalPresenceLibQemu/DxeTcg2PhysicalPresenceLib.c | 5 +++++
.../DxeTcg2PhysicalPresenceLib.inf | 1 +
2 files changed, 6 insertions(+)

diff --git a/OvmfPkg/Library/Tcg2PhysicalPresenceLibQemu/DxeTcg2PhysicalPre=
senceLib.c b/OvmfPkg/Library/Tcg2PhysicalPresenceLibQemu/DxeTcg2PhysicalPre=
senceLib.c
index 00d76ba2c2..33a470f6d8 100644
--- a/OvmfPkg/Library/Tcg2PhysicalPresenceLibQemu/DxeTcg2PhysicalPresenceLi=
b.c
+++ b/OvmfPkg/Library/Tcg2PhysicalPresenceLibQemu/DxeTcg2PhysicalPresenceLi=
b.c
@@ -32,6 +32,7 @@ SPDX-License-Identifier: BSD-2-Clause-Patent
#include <Library/UefiBootServicesTableLib.h>=0D
#include <Library/UefiLib.h>=0D
#include <Library/UefiRuntimeServicesTableLib.h>=0D
+#include <Library/UefiBootManagerLib.h>=0D
=0D
#include <Library/Tcg2PhysicalPresenceLib.h>=0D
=0D
@@ -591,6 +592,10 @@ Tcg2UserConfirm (
return FALSE;=0D
}=0D
=0D
+ // Console for user interaction=0D
+ // We need to connect all trusted consoles for TCG PP. Here we treat all=
consoles in OVMF to be trusted consoles.=0D
+ EfiBootManagerConnectAllDefaultConsoles ();=0D
+=0D
if (TpmPpCommand < TCG2_PHYSICAL_PRESENCE_STORAGE_MANAGEMENT_BEGIN) {=0D
if (CautionKey) {=0D
TmpStr1 =3D Tcg2PhysicalPresenceGetStringById (STRING_TOKEN (TPM_CAU=
TION_KEY));=0D
diff --git a/OvmfPkg/Library/Tcg2PhysicalPresenceLibQemu/DxeTcg2PhysicalPre=
senceLib.inf b/OvmfPkg/Library/Tcg2PhysicalPresenceLibQemu/DxeTcg2PhysicalP=
resenceLib.inf
index 85ce0e2b29..5b5417c321 100644
--- a/OvmfPkg/Library/Tcg2PhysicalPresenceLibQemu/DxeTcg2PhysicalPresenceLi=
b.inf
+++ b/OvmfPkg/Library/Tcg2PhysicalPresenceLibQemu/DxeTcg2PhysicalPresenceLi=
b.inf
@@ -59,6 +59,7 @@
PrintLib=0D
QemuFwCfgLib=0D
Tpm2CommandLib=0D
+ UefiBootManagerLib=0D
UefiBootServicesTableLib=0D
UefiLib=0D
UefiRuntimeServicesTableLib=0D
--=20
2.31.1


[PATCH v3 4/4] OvmfPkg: Reference new Tcg2PlatformPei in the build system

Stefan Berger
 

From: Stefan Berger <stefanb@linux.vnet.ibm.com>

Compile the Tcg2PlatformPei related code now to support TPM 2 platform
hierachy disablement if the TPM state cannot be resumed upon S3 resume.

Cc: Rebecca Cran <rebecca@bsdio.com>
Cc: Peter Grehan <grehan@freebsd.org>
Cc: Brijesh Singh <brijesh.singh@amd.com>
Cc: Erdem Aktas <erdemaktas@google.com>
Cc: James Bottomley <jejb@linux.ibm.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Min Xu <min.m.xu@intel.com>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Stefan Berger <stefanb@linux.ibm.com>
Reviewed-by: Jiewen Yao <Jiewen.yao@intel.com>
---
OvmfPkg/AmdSev/AmdSevX64.dsc | 4 ++++
OvmfPkg/AmdSev/AmdSevX64.fdf | 1 +
OvmfPkg/OvmfPkgIa32.dsc | 4 ++++
OvmfPkg/OvmfPkgIa32.fdf | 1 +
OvmfPkg/OvmfPkgIa32X64.dsc | 4 ++++
OvmfPkg/OvmfPkgIa32X64.fdf | 1 +
OvmfPkg/OvmfPkgX64.dsc | 4 ++++
OvmfPkg/OvmfPkgX64.fdf | 1 +
8 files changed, 20 insertions(+)

diff --git a/OvmfPkg/AmdSev/AmdSevX64.dsc b/OvmfPkg/AmdSev/AmdSevX64.dsc
index 3079f4b503..5ee5445116 100644
--- a/OvmfPkg/AmdSev/AmdSevX64.dsc
+++ b/OvmfPkg/AmdSev/AmdSevX64.dsc
@@ -637,6 +637,10 @@
NULL|SecurityPkg/Library/HashInstanceLibSha512/HashInstanceLibSha512=
.inf=0D
NULL|SecurityPkg/Library/HashInstanceLibSm3/HashInstanceLibSm3.inf=0D
}=0D
+ SecurityPkg/Tcg/Tcg2PlatformPei/Tcg2PlatformPei.inf {=0D
+ <LibraryClasses>=0D
+ TpmPlatformHierarchyLib|SecurityPkg/Library/PeiDxeTpmPlatformHierarc=
hyLib/PeiDxeTpmPlatformHierarchyLib.inf=0D
+ }=0D
!endif=0D
=0D
#=0D
diff --git a/OvmfPkg/AmdSev/AmdSevX64.fdf b/OvmfPkg/AmdSev/AmdSevX64.fdf
index a9f675303f..542722ac6b 100644
--- a/OvmfPkg/AmdSev/AmdSevX64.fdf
+++ b/OvmfPkg/AmdSev/AmdSevX64.fdf
@@ -154,6 +154,7 @@ INF OvmfPkg/Tcg/TpmMmioSevDecryptPei/TpmMmioSevDecrypt=
Pei.inf
INF OvmfPkg/Tcg/Tcg2Config/Tcg2ConfigPei.inf=0D
INF SecurityPkg/Tcg/TcgPei/TcgPei.inf=0D
INF SecurityPkg/Tcg/Tcg2Pei/Tcg2Pei.inf=0D
+INF SecurityPkg/Tcg/Tcg2PlatformPei/Tcg2PlatformPei.inf=0D
!endif=0D
=0D
##########################################################################=
######=0D
diff --git a/OvmfPkg/OvmfPkgIa32.dsc b/OvmfPkg/OvmfPkgIa32.dsc
index 923a012f0c..6a5be97c05 100644
--- a/OvmfPkg/OvmfPkgIa32.dsc
+++ b/OvmfPkg/OvmfPkgIa32.dsc
@@ -717,6 +717,10 @@
NULL|SecurityPkg/Library/HashInstanceLibSha512/HashInstanceLibSha512=
.inf=0D
NULL|SecurityPkg/Library/HashInstanceLibSm3/HashInstanceLibSm3.inf=0D
}=0D
+ SecurityPkg/Tcg/Tcg2PlatformPei/Tcg2PlatformPei.inf {=0D
+ <LibraryClasses>=0D
+ TpmPlatformHierarchyLib|SecurityPkg/Library/PeiDxeTpmPlatformHierarc=
hyLib/PeiDxeTpmPlatformHierarchyLib.inf=0D
+ }=0D
!endif=0D
=0D
#=0D
diff --git a/OvmfPkg/OvmfPkgIa32.fdf b/OvmfPkg/OvmfPkgIa32.fdf
index bb3b53626e..775ea2d710 100644
--- a/OvmfPkg/OvmfPkgIa32.fdf
+++ b/OvmfPkg/OvmfPkgIa32.fdf
@@ -166,6 +166,7 @@ INF OvmfPkg/Tcg/TpmMmioSevDecryptPei/TpmMmioSevDecrypt=
Pei.inf
INF OvmfPkg/Tcg/Tcg2Config/Tcg2ConfigPei.inf=0D
INF SecurityPkg/Tcg/TcgPei/TcgPei.inf=0D
INF SecurityPkg/Tcg/Tcg2Pei/Tcg2Pei.inf=0D
+INF SecurityPkg/Tcg/Tcg2PlatformPei/Tcg2PlatformPei.inf=0D
!endif=0D
=0D
##########################################################################=
######=0D
diff --git a/OvmfPkg/OvmfPkgIa32X64.dsc b/OvmfPkg/OvmfPkgIa32X64.dsc
index b907b36973..71227d1b70 100644
--- a/OvmfPkg/OvmfPkgIa32X64.dsc
+++ b/OvmfPkg/OvmfPkgIa32X64.dsc
@@ -730,6 +730,10 @@
NULL|SecurityPkg/Library/HashInstanceLibSha512/HashInstanceLibSha512=
.inf=0D
NULL|SecurityPkg/Library/HashInstanceLibSm3/HashInstanceLibSm3.inf=0D
}=0D
+ SecurityPkg/Tcg/Tcg2PlatformPei/Tcg2PlatformPei.inf {=0D
+ <LibraryClasses>=0D
+ TpmPlatformHierarchyLib|SecurityPkg/Library/PeiDxeTpmPlatformHierarc=
hyLib/PeiDxeTpmPlatformHierarchyLib.inf=0D
+ }=0D
!endif=0D
=0D
[Components.X64]=0D
diff --git a/OvmfPkg/OvmfPkgIa32X64.fdf b/OvmfPkg/OvmfPkgIa32X64.fdf
index 030638ae78..245ca94044 100644
--- a/OvmfPkg/OvmfPkgIa32X64.fdf
+++ b/OvmfPkg/OvmfPkgIa32X64.fdf
@@ -166,6 +166,7 @@ INF OvmfPkg/Tcg/TpmMmioSevDecryptPei/TpmMmioSevDecrypt=
Pei.inf
INF OvmfPkg/Tcg/Tcg2Config/Tcg2ConfigPei.inf=0D
INF SecurityPkg/Tcg/TcgPei/TcgPei.inf=0D
INF SecurityPkg/Tcg/Tcg2Pei/Tcg2Pei.inf=0D
+INF SecurityPkg/Tcg/Tcg2PlatformPei/Tcg2PlatformPei.inf=0D
!endif=0D
=0D
##########################################################################=
######=0D
diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc
index 8aca437a9b..52f7598cf1 100644
--- a/OvmfPkg/OvmfPkgX64.dsc
+++ b/OvmfPkg/OvmfPkgX64.dsc
@@ -729,6 +729,10 @@
NULL|SecurityPkg/Library/HashInstanceLibSha512/HashInstanceLibSha512=
.inf=0D
NULL|SecurityPkg/Library/HashInstanceLibSm3/HashInstanceLibSm3.inf=0D
}=0D
+ SecurityPkg/Tcg/Tcg2PlatformPei/Tcg2PlatformPei.inf {=0D
+ <LibraryClasses>=0D
+ TpmPlatformHierarchyLib|SecurityPkg/Library/PeiDxeTpmPlatformHierarc=
hyLib/PeiDxeTpmPlatformHierarchyLib.inf=0D
+ }=0D
!endif=0D
=0D
#=0D
diff --git a/OvmfPkg/OvmfPkgX64.fdf b/OvmfPkg/OvmfPkgX64.fdf
index 888363ff9d..b6cc3cabdd 100644
--- a/OvmfPkg/OvmfPkgX64.fdf
+++ b/OvmfPkg/OvmfPkgX64.fdf
@@ -185,6 +185,7 @@ INF OvmfPkg/Tcg/TpmMmioSevDecryptPei/TpmMmioSevDecrypt=
Pei.inf
INF OvmfPkg/Tcg/Tcg2Config/Tcg2ConfigPei.inf=0D
INF SecurityPkg/Tcg/TcgPei/TcgPei.inf=0D
INF SecurityPkg/Tcg/Tcg2Pei/Tcg2Pei.inf=0D
+INF SecurityPkg/Tcg/Tcg2PlatformPei/Tcg2PlatformPei.inf=0D
!endif=0D
=0D
##########################################################################=
######=0D
--=20
2.31.1


[PATCH v3 2/4] OvmfPkg: Handle TPM 2 physical presence opcodes much earlier

Stefan Berger
 

From: Stefan Berger <stefanb@linux.vnet.ibm.com>

Handle the TPM 2 physical presence interface (PPI) opcodes in
PlatformBootManagerBeforeConsole() before the TPM 2 platform hierarchy
is disabled. Since the handling of the PPI opcodes may require inter-
action with the user, initialize the keyboard before handling PPI codes.

Cc: Rebecca Cran <rebecca@bsdio.com>
Cc: Peter Grehan <grehan@freebsd.org>
Cc: Brijesh Singh <brijesh.singh@amd.com>
Cc: Erdem Aktas <erdemaktas@google.com>
Cc: James Bottomley <jejb@linux.ibm.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Min Xu <min.m.xu@intel.com>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Stefan Berger <stefanb@linux.ibm.com>
Reviewed-by: Jiewen Yao <Jiewen.yao@intel.com>
---
.../PlatformBootManagerLib/BdsPlatform.c | 19 +++++++++++--------
.../PlatformBootManagerLibBhyve/BdsPlatform.c | 17 ++++++++++-------
.../PlatformBootManagerLibGrub/BdsPlatform.c | 17 ++++++++++-------
3 files changed, 31 insertions(+), 22 deletions(-)

diff --git a/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c b/OvmfPkg=
/Library/PlatformBootManagerLib/BdsPlatform.c
index 71f63b2448..4448722e19 100644
--- a/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c
+++ b/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c
@@ -387,8 +387,19 @@ PlatformBootManagerBeforeConsole (
SaveS3BootScript ();=0D
}=0D
=0D
+ // We need to connect all trusted consoles for TCG PP. Here we treat all=
=0D
+ // consoles in OVMF to be trusted consoles.=0D
+ PlatformInitializeConsole (=0D
+ XenDetected() ? gXenPlatformConsole : gPlatformConsole);=0D
+=0D
+ //=0D
+ // Process TPM PPI request; this may require keyboard input=0D
+ //=0D
+ Tcg2PhysicalPresenceLibProcessRequest (NULL);=0D
+=0D
//=0D
// Prevent further changes to LockBoxes or SMRAM.=0D
+ // Any TPM 2 Physical Presence Interface opcode must be handled before.=
=0D
//=0D
Handle =3D NULL;=0D
Status =3D gBS->InstallProtocolInterface (&Handle,=0D
@@ -402,9 +413,6 @@ PlatformBootManagerBeforeConsole (
//=0D
EfiBootManagerDispatchDeferredImages ();=0D
=0D
- PlatformInitializeConsole (=0D
- XenDetected() ? gXenPlatformConsole : gPlatformConsole);=0D
-=0D
FrontPageTimeout =3D GetFrontPageTimeoutFromQemu ();=0D
PcdStatus =3D PcdSet16S (PcdPlatformBootTimeOut, FrontPageTimeout);=0D
ASSERT_RETURN_ERROR (PcdStatus);=0D
@@ -1511,11 +1519,6 @@ PlatformBootManagerAfterConsole (
//=0D
PciAcpiInitialization ();=0D
=0D
- //=0D
- // Process TPM PPI request=0D
- //=0D
- Tcg2PhysicalPresenceLibProcessRequest (NULL);=0D
-=0D
//=0D
// Process QEMU's -kernel command line option=0D
//=0D
diff --git a/OvmfPkg/Library/PlatformBootManagerLibBhyve/BdsPlatform.c b/Ov=
mfPkg/Library/PlatformBootManagerLibBhyve/BdsPlatform.c
index eaade4adea..513d2f00a7 100644
--- a/OvmfPkg/Library/PlatformBootManagerLibBhyve/BdsPlatform.c
+++ b/OvmfPkg/Library/PlatformBootManagerLibBhyve/BdsPlatform.c
@@ -375,8 +375,18 @@ PlatformBootManagerBeforeConsole (
//=0D
EfiEventGroupSignal (&gEfiEndOfDxeEventGroupGuid);=0D
=0D
+ // We need to connect all trusted consoles for TCG PP. Here we treat all=
=0D
+ // consoles in OVMF to be trusted consoles.=0D
+ PlatformInitializeConsole (gPlatformConsole);=0D
+=0D
+ //=0D
+ // Process TPM PPI request=0D
+ //=0D
+ Tcg2PhysicalPresenceLibProcessRequest (NULL);=0D
+=0D
//=0D
// Prevent further changes to LockBoxes or SMRAM.=0D
+ // Any TPM 2 Physical Presence Interface opcode must be handled before.=
=0D
//=0D
Handle =3D NULL;=0D
Status =3D gBS->InstallProtocolInterface (&Handle,=0D
@@ -390,8 +400,6 @@ PlatformBootManagerBeforeConsole (
//=0D
EfiBootManagerDispatchDeferredImages ();=0D
=0D
- PlatformInitializeConsole (gPlatformConsole);=0D
-=0D
PlatformRegisterOptionsAndKeys ();=0D
=0D
//=0D
@@ -1445,11 +1453,6 @@ PlatformBootManagerAfterConsole (
//=0D
PciAcpiInitialization ();=0D
=0D
- //=0D
- // Process TPM PPI request=0D
- //=0D
- Tcg2PhysicalPresenceLibProcessRequest (NULL);=0D
-=0D
//=0D
// Perform some platform specific connect sequence=0D
//=0D
diff --git a/OvmfPkg/Library/PlatformBootManagerLibGrub/BdsPlatform.c b/Ovm=
fPkg/Library/PlatformBootManagerLibGrub/BdsPlatform.c
index 7cceeea487..1c5405f620 100644
--- a/OvmfPkg/Library/PlatformBootManagerLibGrub/BdsPlatform.c
+++ b/OvmfPkg/Library/PlatformBootManagerLibGrub/BdsPlatform.c
@@ -338,8 +338,18 @@ PlatformBootManagerBeforeConsole (
//=0D
EfiEventGroupSignal (&gEfiEndOfDxeEventGroupGuid);=0D
=0D
+ // We need to connect all trusted consoles for TCG PP. Here we treat all=
=0D
+ // consoles in OVMF to be trusted consoles.=0D
+ PlatformInitializeConsole (gPlatformConsole);=0D
+=0D
+ //=0D
+ // Process TPM PPI request=0D
+ //=0D
+ Tcg2PhysicalPresenceLibProcessRequest (NULL);=0D
+=0D
//=0D
// Prevent further changes to LockBoxes or SMRAM.=0D
+ // Any TPM 2 Physical Presence Interface opcode must be handled before.=
=0D
//=0D
Handle =3D NULL;=0D
Status =3D gBS->InstallProtocolInterface (&Handle,=0D
@@ -353,8 +363,6 @@ PlatformBootManagerBeforeConsole (
//=0D
EfiBootManagerDispatchDeferredImages ();=0D
=0D
- PlatformInitializeConsole (gPlatformConsole);=0D
-=0D
Status =3D gRT->SetVariable (=0D
EFI_TIME_OUT_VARIABLE_NAME,=0D
&gEfiGlobalVariableGuid,=0D
@@ -1310,11 +1318,6 @@ PlatformBootManagerAfterConsole (
//=0D
PciAcpiInitialization ();=0D
=0D
- //=0D
- // Process TPM PPI request=0D
- //=0D
- Tcg2PhysicalPresenceLibProcessRequest (NULL);=0D
-=0D
//=0D
// Process QEMU's -kernel command line option=0D
//=0D
--=20
2.31.1


Re: [PATCH V6 1/1] OvmfPkg: Enable TDX in ResetVector

Vishal Annapurve
 

Hi Min, Brijesh,

Regarding:
> diff --git a/OvmfPkg/ResetVector/Ia16/ResetVectorVtf0.asm b/OvmfPkg/ResetVector/Ia16/ResetVectorVtf0.asm
> ...
> +%ifdef ARCH_IA32
>     nop
>     nop
>     jmp     EarlyBspInitReal16
>
>+%else
>+
>+    smsw    ax

We are having intermittent VM crashes with running this code in AMD-SEV enabled VMs. As per the AMD64 manual section 15.8.1, executing "smsw" instruction doesn't result in bit 63 being set in EXITINFO1 and KVM ends up emulating "smsw" instruction by trying to read encrypted guest VM memory as per the code. Since KVM tries to make sense of different random cipher texts in different boots, it seems to intermittently result in visible issues.

Is this expected behavior or do we miss some configuration or patches that are recommended by AMD?

Regards,
Vishal

On Tue, Sep 14, 2021 at 4:54 PM Brijesh Singh via groups.io <brijesh.singh=amd.com@groups.io> wrote:
Hi Min,

A quick question below.

On 9/14/21 3:50 AM, Min Xu wrote:
> RFC: https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugzilla.tianocore.org%2Fshow_bug.cgi%3Fid%3D3429&amp;data=04%7C01%7Cbrijesh.singh%40amd.com%7C2cca2f0a7fb44084da2b08d9775cb220%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637672062275443867%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=4zfuIDvTGDNCt%2BD3u7uUR0n6hHDzv%2FI8NkqoUJhsx8Y%3D&amp;reserved=0
>
> Intel's Trust Domain Extensions (Intel TDX) refers to an Intel technology
> that extends Virtual Machines Extensions (VMX) and Multi-Key Total Memory
> Encryption (MKTME) with a new kind of virutal machines guest called a
> Trust Domain (TD). A TD is desinged to run in a CPU mode that protects the
> confidentiality of TD memory contents and the TD's CPU state from other
> software, including the hosting Virtual-Machine Monitor (VMM), unless
> explicitly shared by the TD itself.
>
> Note: Intel TDX is only available on X64, so the Tdx related changes are
> in X64 path. In IA32 path, there may be null stub to make the build
> success.
>
> This patch includes below major changes.
>
> 1. Definition of BFV & CFV
> Tdx Virtual Firmware (TDVF) includes one Firmware Volume (FV) known
> as the Boot Firmware Volume (BFV). The FV format is defined in the
> UEFI Platform Initialization (PI) spec. BFV includes all TDVF components
> required during boot.
>
> TDVF also include a configuration firmware volume (CFV) that is separated
> from the BFV. The reason is because the CFV is measured in RTMR, while
> the BFV is measured in MRTD.
>
> In practice BFV is the code part of Ovmf image (OVMF_CODE.fd). CFV is the
> vars part of Ovmf image (OVMF_VARS.fd).
>
> 2. PcdOvmfImageSizeInKb
> PcdOvmfImageSizeInKb indicates the size of Ovmf image. It is used to
> calculate the offset of TdxMetadata in ResetVectorVtf0.asm.

In SEV-SNP v7 series, I implemented the metadata support. I did not see
a need for the PcdOvmfImageSizeInKB. Why do you need it? I think your
calculation below will not work if someone is using the OVMF_CODE.fd
instead of OVMF.fd. Have you tried booting with OVMF_CODE.fd ?

thanks








Re: [RFC] Add parallel hash feature into CryptoPkg.BaseCryptLib.

Yao, Jiewen
 

OK. The interface ParallelHash256HashAll() seems OK for me.

 

Some comment:

1) Please add EFIAPI for ParallelHash256HashAll().

2) Please use BOOLEAN as return value.

3) Please remove LeftEncode() and RightEncode() from https://github.com/zhihaoli1064/edk2/blob/master/CryptoPkg/Include/Library/BaseCryptLib.h. They shall be internal functions.

4) Do we really need expose cSHAKE* API? If the request is just to support ParallelHash256, then cSHAKE API could be internal one.

5) I suggest to make this API work in non-MP case as well. In current version, it will fail for non-MP system, right? I think we can let BSP do all the work in that case.

 

  if (StartedApNum == 0) {

    ReturnValue = 1;

    goto Exit;

  }

 

 

Thank you

Yao Jiewen

 

 

From: Li, Zhihao <zhihao.li@...>
Sent: Tuesday, September 14, 2021 12:03 PM
To: Yao, Jiewen <jiewen.yao@...>; Andrew Fish <afish@...>; Ethin Probst <harlydavidsen@...>; Kinney, Michael D <michael.d.kinney@...>; edk2-devel-groups-io <devel@edk2.groups.io>
Cc: Wang, Jian J <jian.j.wang@...>; Wu, Hao A <hao.a.wu@...>; Lu, XiaoyuX <xiaoyux.lu@...>; Jiang, Guomin <guomin.jiang@...>; gaoliming@...; Fu, Siyuan <siyuan.fu@...>; Wu, Yidong <yidong.wu@...>; Li, Aaron <aaron.li@...>
Subject: RE: [edk2-devel] [RFC] Add parallel hash feature into CryptoPkg.BaseCryptLib.

 

Hi, Jiewen

Thanks for your suggestions.

In view of your advice, this RFC only talk about the new feature----Parallel hash.

Mainly modification in https://github.com/zhihaoli1064/edk2/blob/master/CryptoPkg/Library/BaseCryptLib/Hash/Smm/ParallelHashSmm.c

Others will be designed anew.

 

From: Yao, Jiewen <jiewen.yao@...>
Sent: Thursday, September 9, 2021 6:04 PM
To: Li, Zhihao <zhihao.li@...>; Andrew Fish <afish@...>; Ethin Probst <harlydavidsen@...>; Kinney, Michael D <michael.d.kinney@...>; edk2-devel-groups-io <devel@edk2.groups.io>
Cc: Wang, Jian J <jian.j.wang@...>; Wu, Hao A <hao.a.wu@...>; Lu, XiaoyuX <xiaoyux.lu@...>; Jiang, Guomin <guomin.jiang@...>; gaoliming@...; Fu, Siyuan <siyuan.fu@...>; Wu, Yidong <yidong.wu@...>; Li, Aaron <aaron.li@...>
Subject: RE: [edk2-devel] [RFC] Add parallel hash feature into CryptoPkg.BaseCryptLib.

 

Hi

AllowList and DenyList are *secure boot* concept.

FMP auth lib is for *signed capsule* and it does not consider secure boot – allow list and deny list.

 

In my mind, neither secure boot and FSP auth shall know the existence of parallel hash. The verification logic shall be isolated.

 

Sorry, I don’t understand the design.

 

I am worried that you put too many concept together.

 

Adding parallel hash is one thing.

Adding allow list and deny list to FMP is another thing.

Please don’t mix them together.

 

I would like to request a design review for this feature.

 

Thank you

Yao Jiewen

 

From: Li, Zhihao <zhihao.li@...>
Sent: Thursday, September 9, 2021 5:49 PM
To: Yao, Jiewen <jiewen.yao@...>; Andrew Fish <afish@...>; Ethin Probst <harlydavidsen@...>; Kinney, Michael D <michael.d.kinney@...>; edk2-devel-groups-io <devel@edk2.groups.io>
Cc: Wang, Jian J <jian.j.wang@...>; Wu, Hao A <hao.a.wu@...>; Lu, XiaoyuX <xiaoyux.lu@...>; Jiang, Guomin <guomin.jiang@...>; gaoliming@...; Fu, Siyuan <siyuan.fu@...>; Wu, Yidong <yidong.wu@...>; Li, Aaron <aaron.li@...>
Subject: RE: [edk2-devel] [RFC] Add parallel hash feature into CryptoPkg.BaseCryptLib.

 

I send this mail for asking that if there are any comments about parallel hash feature.

 

Mainly modification:

CryptoPkg: https://github.com/zhihaoli1064/edk2/blob/master/CryptoPkg/Library/BaseCryptLib/Hash/Smm/ParallelHashSmm.c

MdeMoudulePkg: https://github.com/zhihaoli1064/edk2/blob/master/MdeModulePkg/Include/Library/FmpAuthenticationLib.h              line59-67

SecurityPkg: https://github.com/zhihaoli1064/edk2/blob/master/SecurityPkg/Library/FmpAuthenticationLibPkcs7/FmpAuthenticationLibPkcs7.c line119-188,287-350

 

From: Li, Zhihao  
Sent: Friday, September 3, 2021 4:44 PM
To: Yao, Jiewen <jiewen.yao@...>; Andrew Fish <afish@...>; edk2-devel-groups-io <devel@edk2.groups.io>; Kinney, Michael D <michael.d.kinney@...>
Cc: Wang, Jian J <jian.j.wang@...>; Wu, Hao A <hao.a.wu@...>; Lu, XiaoyuX <XiaoyuX.Lu@...>; Jiang, Guomin <Guomin.Jiang@...>; gaoliming@...; Fu, Siyuan <siyuan.fu@...>; Wu, Yidong <yidong.wu@...>; Li, Aaron <aaron.li@...>
Subject: RE: [edk2-devel] [RFC] Add parallel hash feature into CryptoPkg.BaseCryptLib.

 

Hi, Jiewen

I try to explant what means “more than once authentication(e.g. VerifyImageWithDenylist and VerifyImageWithAllowlist)”.

When we confirm the image is effective, we have to confirm not only that image certificate is on the whitelist, but also that it is not on the blacklist.

So it have two steps in verification process(only talk about FmpAuthentication)­­----- VerifyImageWithDenylist and VerifyImageWithAllowlist.

VerifyImageWithDenylist confirms it not in blacklist while VerifyImageWithAllowlist confirms it in whitelist.

èVerifyImageWithDenylist should do FmpAuthentication and failed. VerifyImageWithAllowlist Should do FmpAuthentication and success.

In our design:

Result=parallelhash256(image);------

Status1= VerifyImageWithDenylist(image,result);---------

Status2= VerifyImageWithAllowlist(image,result);---------

Status1 is failed, status2 is successèimage is effective.

If do it inside of AuthenticateFmpImage

In step ②,it need do parallelhash256(image) .

And in step ③,it also need do parallelhash256(image) .

Because AuthenticateFmpImage Function is inside of VerifyImageWithDenylist And VerifyImageWithAllowlist.

Poc code link of edk2:

https://github.com/zhihaoli1064/edk2/blob/master/CryptoPkg/Library/BaseCryptLib/Hash/Smm/ParallelHashSmm.c

 

 

From: Yao, Jiewen <jiewen.yao@...>
Sent: Friday, September 3, 2021 3:07 PM
To: Li, Zhihao <zhihao.li@...>; Andrew Fish <afish@...>; edk2-devel-groups-io <devel@edk2.groups.io>; Kinney, Michael D <michael.d.kinney@...>
Cc: Wang, Jian J <jian.j.wang@...>; Wu, Hao A <hao.a.wu@...>; Lu, XiaoyuX <xiaoyux.lu@...>; Jiang, Guomin <guomin.jiang@...>; gaoliming@...; Fu, Siyuan <siyuan.fu@...>; Wu, Yidong <yidong.wu@...>; Li, Aaron <aaron.li@...>
Subject: RE: [edk2-devel] [RFC] Add parallel hash feature into CryptoPkg.BaseCryptLib.

 

Sorry, I hardly understand the explanation.

Do you have a URL for the POC code?

 

 

From: Li, Zhihao <zhihao.li@...>
Sent: Friday, September 3, 2021 2:58 PM
To: Yao, Jiewen <jiewen.yao@...>; Andrew Fish <afish@...>; edk2-devel-groups-io <devel@edk2.groups.io>; Kinney, Michael D <michael.d.kinney@...>
Cc: Wang, Jian J <jian.j.wang@...>; Wu, Hao A <hao.a.wu@...>; Lu, XiaoyuX <xiaoyux.lu@...>; Jiang, Guomin <guomin.jiang@...>; gaoliming@...; Fu, Siyuan <siyuan.fu@...>; Wu, Yidong <yidong.wu@...>; Li, Aaron <aaron.li@...>
Subject: RE: [edk2-devel] [RFC] Add parallel hash feature into CryptoPkg.BaseCryptLib.

 

Hi

Some explanation for confusion.

 

  1. Is the result of the parallel hash identical to the current hash?  

The result of parallelhash256 do not identical to the current hash. And we are not intention to let parallelhash256 replace the current hash(SHA-256). But doing the parallel hash before the current hash to reduce the size of current hash input. Otherwise, the parallel hash effect is compressing the size of FmpAuthentication input and the use of MP Services is the inseparable part of this algorithm. It’s a new hash algorithm. So it should not move to FmpAuthenticationLib.

  1. Why we cannot do it inside of AuthenticateFmpImage?

Because of more than once authentication(e.g. VerifyImageWithDenylist and VerifyImageWithAllowlist), if we do the parallel hash inside of AuthenticateFmpImage(Denylist auth), we have to do another parallel hash for Allowlist’s AuthenticateFmpImage. It’s repeat operation.

 

Poc code in branch named dev/sfu5/parallel_hash_ossl

The verify flow is:

  ImageParaHash = ParallelHash-256 (Image)

PKCS7_Verify (PublicKey, ImageParaHash)

 

In FmpAuthenticationLibPkcs7 ,the parameter Output of FmpAuthenticatedHandlerPkcs7WithParallelhash is image digest. It replace the original image.

 

FmpAuthenticatedHandlerPkcs7WithParallelhash (

  IN EFI_FIRMWARE_IMAGE_AUTHENTICATION  *Image,

  IN UINTN                              ImageSize,

  IN CONST UINT8                        *PublicKeyData,

  IN UINTN                              PublicKeyDataLength,

  IN UINT8                              *Output

  )

{

  RETURN_STATUS                             Status;

  BOOLEAN                                   CryptoStatus;

  VOID                                      *P7Data;

  UINTN                                     P7Length;

  VOID                                      *TempBuffer;

  UINTN                                     PayloadHeaderSize = 69;

  UINTN                                     ParallelhashSize = 64;

 

  P7Length = Image->AuthInfo.Hdr.dwLength - (OFFSET_OF(WIN_CERTIFICATE_UEFI_GUID, CertData));

  P7Data = Image->AuthInfo.CertData;

 

  // It is a signature across the variable data and the Monotonic Count value.

  TempBuffer = AllocatePool(sizeof(Image->MonotonicCount) + ParallelhashSize + PayloadHeaderSize);

  CopyMem(

    (UINT8 *)TempBuffer,

    (UINT8 *)Image + sizeof(Image->MonotonicCount) + Image->AuthInfo.Hdr.dwLength,

    PayloadHeaderSize

    );

  CopyMem(

    (UINT8 *)TempBuffer + PayloadHeaderSize,

    Output,

    ParallelhashSize

    );

  CopyMem(

    (UINT8 *)TempBuffer + PayloadHeaderSize + ParallelhashSize,

    &Image->MonotonicCount,

    sizeof(Image->MonotonicCount)

    );

  CryptoStatus = Pkcs7Verify(

                   P7Data,

                   P7Length,

                   PublicKeyData,

                   PublicKeyDataLength,

                   (UINT8 *)TempBuffer,

                   PayloadHeaderSize + ParallelhashSize + sizeof(Image->MonotonicCount)

                   );

  FreePool(TempBuffer);

 

 

From: Yao, Jiewen <jiewen.yao@...>
Sent: Friday, September 3, 2021 9:02 AM
To: Andrew Fish <afish@...>; edk2-devel-groups-io <devel@edk2.groups.io>; Kinney, Michael D <michael.d.kinney@...>
Cc: Li, Zhihao <zhihao.li@...>; Wang, Jian J <jian.j.wang@...>; Wu, Hao A <hao.a.wu@...>; Lu, XiaoyuX <xiaoyux.lu@...>; Jiang, Guomin <guomin.jiang@...>; gaoliming@...; Fu, Siyuan <siyuan.fu@...>; Wu, Yidong <yidong.wu@...>; Li, Aaron <aaron.li@...>
Subject: RE: [edk2-devel] [RFC] Add parallel hash feature into CryptoPkg.BaseCryptLib.

 

Hi

Comment on 2/3.

 

I am not sure if the a new function AuthenticateFmpImageWithParallelhash() is absolutely necessary.

Why you do the parallel hash before authentication and transfer the result to AuthenticateFmpImage?

Why we cannot do it inside of AuthenticateFmpImage?

 

Ideally, we hope to hide *algorithm* from *business logic*.

Do you have any POC link?

 

Thank you

Yao Jiewen

 

From: Andrew Fish <afish@...>
Sent: Friday, September 3, 2021 7:16 AM
To: edk2-devel-groups-io <devel@edk2.groups.io>; Kinney, Michael D <michael.d.kinney@...>
Cc: Li, Zhihao <zhihao.li@...>; Yao, Jiewen <jiewen.yao@...>; Wang, Jian J <jian.j.wang@...>; Wu, Hao A <hao.a.wu@...>; Lu, XiaoyuX <xiaoyux.lu@...>; Jiang, Guomin <guomin.jiang@...>; gaoliming@...; Fu, Siyuan <siyuan.fu@...>; Wu, Yidong <yidong.wu@...>; Li, Aaron <aaron.li@...>
Subject: Re: [edk2-devel] [RFC] Add parallel hash feature into CryptoPkg.BaseCryptLib.

 

 

 

On Sep 2, 2021, at 8:50 AM, Michael D Kinney <michael.d.kinney@...> wrote:

 

Hi Zhihao,

 

Is the result of the parallel hash identical to the current hash?  If so, then can we simply have a new instance of the FmpAuthenticationLib and hide the ParallelHash256 digest inside this implementation of this new instance?

 

I do not think BaseCryptLib should depend on CPU MP Services Protocol.  Can the use of MP Services be moved up into the implementation of the new FmpAuthenticationLib?  If new BASE compatible primitives need to be added to BaseCryptLib to support parallel hash, then those likely make sense.

 

 

 

Mike,

 

Stupid question but the BaseCryptLib seems to really be DxeCryptLib[1]? So are you worried about adding the dependency to this DXE Lib? It depends on UefiRuntimeServicesTableLib. Looks like SysCall/TimerWrapper.c[2] uses gRT->GetTime(). It looks like if the time services are not available it returns 0 from time(), so there is only a quality of service implication to when it it is used but no Depex?

 

 

How do you decide how many CPU threads to use? 

 

 

If we end up splitting this up for “others” to handle the MP in DXE, PEI, or MM then I think we probably need a more robust API set that abstracts breaking up the work, and combining it back tougher. Well you would need the worker functions to processes the broken up data on the APs. So I would imagine and API that splits the work and you pass in the number of APs (or APs + BSP) and you get N buffers out to process? Those buffers should describe the chunk to the worker function, and when the worker function is done the get the answer function can calculate the results from that. 

 

 

[1] We don’t have a Base implementation of BaseCryptLib. 

CryptoPkg/Library/BaseCryptLib/BaseCryptLib.inf

LIBRARY_CLASS                  = BaseCryptLib|DXE_DRIVER DXE_CORE UEFI_APPLICATION UEFI_DRIVER

 

CryptoPkg/Library/BaseCryptLib/PeiCryptLib.inf

LIBRARY_CLASS                  = BaseCryptLib|PEIM PEI_CORE

 

 CryptoPkg/Library/BaseCryptLib/RuntimeCryptLib.inf

LIBRARY_CLASS                  = BaseCryptLib|DXE_RUNTIME_DRIVER

 

CryptoPkg/Library/BaseCryptLib/SmmCryptLib.inf

  LIBRARY_CLASS                  = BaseCryptLib|DXE_SMM_DRIVER SMM_CORE MM_STANDALONE

 

 

Thanks,

 

Andrew Fish

 

Thanks,

 

Mike

 

From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Li, Zhihao
Sent: Wednesday, September 1, 2021 6:38 PM
To: devel@edk2.groups.io
Cc: Yao, Jiewen <jiewen.yao@...>; Wang, Jian J <jian.j.wang@...>; Wu, Hao A <hao.a.wu@...>; Lu, XiaoyuX <xiaoyux.lu@...>; Jiang, Guomin <guomin.jiang@...>; gaoliming@...; Fu, Siyuan <siyuan.fu@...>; Wu, Yidong <yidong.wu@...>; Li, Aaron <aaron.li@...>
Subject: [edk2-devel] [RFC] Add parallel hash feature into CryptoPkg.BaseCryptLib

 

Hi, everyone.

We want to add new hash algorithm—cSHAKE256/ParallelHash256 defined by NIST SP 800-185—into BaseCryptLib of CryptoPkg. This feature can be applied for digital authentication functions like Capsule Update. It utilizes multi-processor to calculate the image digest in parallel for update capsule authentication so that lessen the time of capsule authentication.

 

 

[Background]

The intention of this change is to improve the capsule authentication performance.

Currently, the image is calculated to a hash value (usually by SHA-256), then the hash value be signed by a certificate. The header, certificate, and image binary be sealed to the capsule. In authentication phase, the program should calculate the hash using image binary in capsule and then perform authentication procedures.

 

[Proposal]

Now, we propose a new authentication flow, which firstly pre-calculates the ParallelHash256 digest of the image binary in parallel with multi-processors, then use the ParallelHash256 digest (instead of original image binary) in subsequent SHA-256 hash for sign/authentication.

Since the big size image be compressed to the ParallelHash256 digest that only have 256 bytes, the time of SHA-256 running would be less.

 

[Required Changes]

Mainly in CryptoPkg, MdeModulePkg, SecurityPkg:

1. CryptoPkg: need to add the new hash algorithm named cSHAKE256/ParallelHash256 in BaseCrypLib. The ParallelHash function will consume CPU MP Service Protocol, not sure if this is allowed in BaseCryptLib?

2. MdeMoudulePkg: Add new authenticate function AuthenticateFmpImageWithParallelhash() to FmpAuthenticationLib. This is because original AuthenticateFmpImage() interface only have 4 parameters  while the new have 5 parameters. The 5th parameter is ParallelHash256 digest raised above. We try to do the parallel hash before authentication and transfer the result to AuthenticateFmpImage function as parameter. So that we can do only once parallel hash externally in the case of multiple authentication which saves more time.

3. SecurityPkg: Add new function named FmpAuthenticatedHandlerPkcs7WithParallelhash() and AuthenticateFmpImageWithParallelhash() to FmpAuthenticationLibPkcs7. This is because original interfaces not have the formal parameter (ParallelHash256 digest) we need. We try to do the parallel hash before authentication and transfer the result to AuthenticateFmpImage and FmpAuthenticatedHandlerPkcs7 function as parameter. So that we can do only once parallel hash externally in the case of multiple authentication which saves more time.

 

Please let me know if you have any comment or concern on this proposed change.

 

Thanks for your time and feedback!

Best regards,
Zhihao

 

 


Re: [PATCH 0/3] Add support for gdb and lldb

Andrew Fish
 

Sorry the patches stalled out. I need to push them….

Thanks,

Andrew Fish

On Sep 14, 2021, at 4:47 PM, Rebecca Cran <rebecca@...> wrote:

I was wondering what your plan for committing these to the repo is? It would be nice to get them committed so people can start using them.


-- 
Rebecca Cran


On 8/8/21 3:46 PM, Andrew Fish via groups.io wrote:
This patch set adds debugging support for gdb and lldb.
It also adds generic debugging classes that use a file like object to
make it easy to import into any debugger that supports Python.

Since these debugging scripts don't depend on any EFI code I was thinking
we could place them in the root of the repo to be easy to discover.

I've tested gdb on Ubuntu and lldb on macOS for IA32 and X64.

Andrew Fish (3):
  efi_debugging.py: - Add debugger agnostic debugging Python Classes
  efi_gdb.py: - Add gdb EFI commands and pretty Print
  efi_lldb.py: - Add lldb EFI commands and pretty Print

 efi_debugging.py | 2187 ++++++++++++++++++++++++++++++++++++++++++++++
 efi_gdb.py       |  918 +++++++++++++++++++
 efi_lldb.py      | 1044 ++++++++++++++++++++++
 3 files changed, 4149 insertions(+)
 create mode 100755 efi_debugging.py
 create mode 100755 efi_gdb.py
 create mode 100755 efi_lldb.py






Re: [PATCH 0/3] Add support for gdb and lldb

Rebecca Cran
 

I was wondering what your plan for committing these to the repo is? It would be nice to get them committed so people can start using them.


--
Rebecca Cran

On 8/8/21 3:46 PM, Andrew Fish via groups.io wrote:
This patch set adds debugging support for gdb and lldb.
It also adds generic debugging classes that use a file like object to
make it easy to import into any debugger that supports Python.

Since these debugging scripts don't depend on any EFI code I was thinking
we could place them in the root of the repo to be easy to discover.

I've tested gdb on Ubuntu and lldb on macOS for IA32 and X64.

Andrew Fish (3):
efi_debugging.py: - Add debugger agnostic debugging Python Classes
efi_gdb.py: - Add gdb EFI commands and pretty Print
efi_lldb.py: - Add lldb EFI commands and pretty Print

efi_debugging.py | 2187 ++++++++++++++++++++++++++++++++++++++++++++++
efi_gdb.py | 918 +++++++++++++++++++
efi_lldb.py | 1044 ++++++++++++++++++++++
3 files changed, 4149 insertions(+)
create mode 100755 efi_debugging.py
create mode 100755 efi_gdb.py
create mode 100755 efi_lldb.py


Re: [PATCH v2 0/4] OvmfPkg: Disable the TPM 2 platform hierarchy

Stefan Berger
 

On 9/14/21 6:26 PM, Yao, Jiewen wrote:
Reviewed-by: Jiewen Yao <Jiewen.yao@intel.com>

I will wait for a week, to see if there is any feedback from AMD or Bhyve reviewer.
I can repost as v3 with your Reviewed-by's cc'ing them.


    Stefan



Thank you
Yao Jiewen


-----Original Message-----
From: Stefan Berger <stefanb@linux.ibm.com>
Sent: Tuesday, September 14, 2021 10:18 PM
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.ibm.com>
Subject: [PATCH v2 0/4] OvmfPkg: Disable the TPM 2 platform hierarchy

This series of patches adds support for disabling the TPM 2 platform
hierarchy to Ovmf. To be able to do this we have to handle TPM 2
physical presence interface (PPI) opcodes before the TPM 2 platform
hierarchy is disabled otherwise TPM 2 commands that are sent due to the
PPI opcodes may fail if the platform hierarchy is already disabled.
Therefore, we need to invoke the handler function
Tcg2PhysicalPresenceLibProcessRequest from within
PlatformBootManagerBeforeConsole. Since handling of PPI opcodes may
require
interaction with the user, we also move PlatformInitializeConsole
to before the handling of PPI codes so that the keyboard is available
when needed. The PPI handling code will activate the default consoles
only if it requires user interaction.

Regards,
Stefan

v2:
- 1/4: Added missing link library
- 2/4: Modified other BdsPlatform.c files as well
- Added Yao's comments to 1/2 and 2/2

Stefan Berger (4):
OvmfPkg/TPM PPI: Connect default consoles for user interaction
OvmfPkg: Handle TPM 2 physical presence opcodes much earlier
OvmfPkg: Reference new Tcg2PlatformDxe in the build system for
compilation
OvmfPkg: Reference new Tcg2PlatformPei in the build system

OvmfPkg/AmdSev/AmdSevX64.dsc | 8 ++++++++
OvmfPkg/AmdSev/AmdSevX64.fdf | 2 ++
.../PlatformBootManagerLib/BdsPlatform.c | 19 +++++++++++--------
.../PlatformBootManagerLibBhyve/BdsPlatform.c | 16 +++++++++-------
.../PlatformBootManagerLibGrub/BdsPlatform.c | 16 +++++++++-------
.../DxeTcg2PhysicalPresenceLib.c | 5 +++++
.../DxeTcg2PhysicalPresenceLib.inf | 1 +
OvmfPkg/OvmfPkgIa32.dsc | 8 ++++++++
OvmfPkg/OvmfPkgIa32.fdf | 2 ++
OvmfPkg/OvmfPkgIa32X64.dsc | 8 ++++++++
OvmfPkg/OvmfPkgIa32X64.fdf | 2 ++
OvmfPkg/OvmfPkgX64.dsc | 8 ++++++++
OvmfPkg/OvmfPkgX64.fdf | 2 ++
13 files changed, 75 insertions(+), 22 deletions(-)

--
2.31.1



Re: [PATCH v2 0/4] OvmfPkg: Disable the TPM 2 platform hierarchy

Yao, Jiewen
 

Reviewed-by: Jiewen Yao <Jiewen.yao@intel.com>

I will wait for a week, to see if there is any feedback from AMD or Bhyve reviewer.

Thank you
Yao Jiewen

-----Original Message-----
From: Stefan Berger <stefanb@linux.ibm.com>
Sent: Tuesday, September 14, 2021 10:18 PM
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.ibm.com>
Subject: [PATCH v2 0/4] OvmfPkg: Disable the TPM 2 platform hierarchy

This series of patches adds support for disabling the TPM 2 platform
hierarchy to Ovmf. To be able to do this we have to handle TPM 2
physical presence interface (PPI) opcodes before the TPM 2 platform
hierarchy is disabled otherwise TPM 2 commands that are sent due to the
PPI opcodes may fail if the platform hierarchy is already disabled.
Therefore, we need to invoke the handler function
Tcg2PhysicalPresenceLibProcessRequest from within
PlatformBootManagerBeforeConsole. Since handling of PPI opcodes may
require
interaction with the user, we also move PlatformInitializeConsole
to before the handling of PPI codes so that the keyboard is available
when needed. The PPI handling code will activate the default consoles
only if it requires user interaction.

Regards,
Stefan

v2:
- 1/4: Added missing link library
- 2/4: Modified other BdsPlatform.c files as well
- Added Yao's comments to 1/2 and 2/2

Stefan Berger (4):
OvmfPkg/TPM PPI: Connect default consoles for user interaction
OvmfPkg: Handle TPM 2 physical presence opcodes much earlier
OvmfPkg: Reference new Tcg2PlatformDxe in the build system for
compilation
OvmfPkg: Reference new Tcg2PlatformPei in the build system

OvmfPkg/AmdSev/AmdSevX64.dsc | 8 ++++++++
OvmfPkg/AmdSev/AmdSevX64.fdf | 2 ++
.../PlatformBootManagerLib/BdsPlatform.c | 19 +++++++++++--------
.../PlatformBootManagerLibBhyve/BdsPlatform.c | 16 +++++++++-------
.../PlatformBootManagerLibGrub/BdsPlatform.c | 16 +++++++++-------
.../DxeTcg2PhysicalPresenceLib.c | 5 +++++
.../DxeTcg2PhysicalPresenceLib.inf | 1 +
OvmfPkg/OvmfPkgIa32.dsc | 8 ++++++++
OvmfPkg/OvmfPkgIa32.fdf | 2 ++
OvmfPkg/OvmfPkgIa32X64.dsc | 8 ++++++++
OvmfPkg/OvmfPkgIa32X64.fdf | 2 ++
OvmfPkg/OvmfPkgX64.dsc | 8 ++++++++
OvmfPkg/OvmfPkgX64.fdf | 2 ++
13 files changed, 75 insertions(+), 22 deletions(-)

--
2.31.1


Re: Question about EDK2 and commit signing

Marvin Häuser
 

On 14/09/2021 20:02, James Bottomley wrote:
On Mon, 2021-09-13 at 19:31 +0000, Marvin Häuser wrote:
Hey Pedro,

Same point as before really, why would an attacker have access to
your SSH key but not your GPG key? This scenario leaves out the
possibly of an HTTPS over SSH attack, in which case as a security-
aware person you use 2FA of course ( :) ), which means this is not
possible without creating a personal access token. There is very
little reason to do this at all - I never did this before, and I
don't know anyone who does this with their private or work GitHub
account (I think a few use it for CI?), at least that I know of. And
even if you need one, and you give it push rights to actually push
with, and you require GPG signatures globally, you again are keeping
those two factors at least close together, if not in the same spot.
I think the scenario in question was someone hacking into github. They
can bypass your ssh login requirement without needing your key, because
that's enforced by github but they can't sign your commit unless they
compromise your laptop or token. There are many ways of hacking a
cloud service besides simply trying to fake the login or extract the
token from the user.
For the green "verified" tick it'd be sufficient to just enrol a new GPG key. There'd need to be some manual verification that it's always the same GPG key, which would require some trusted channel of transmission and updating it in case it is lost. To get literally anything out of this, a significant extra effort is required.

Best regards,
Marvin


The way we get around this in Linux is with signed tags, but github
doesn't support that workflow.

I still really don't think signed commits adds much, even to github,
because to be informationally useful, all commits have to be signed.
Plus, anyway, if the entire site is compromised there'll be bigger
problems than checking commit signatures ...

James


Re: [PATCH V6 1/1] OvmfPkg: Enable TDX in ResetVector

Brijesh Singh
 

Hi Vishal,

On 9/14/21 2:00 PM, Vishal Annapurve wrote:
Hi Min, Brijesh,
Regarding:
diff --git a/OvmfPkg/ResetVector/Ia16/ResetVectorVtf0.asm b/OvmfPkg/ResetVector/Ia16/ResetVectorVtf0.asm
...
+%ifdef ARCH_IA32
     nop
     nop
     jmp     EarlyBspInitReal16

+%else
+
+ smsw    ax
We are having intermittent VM crashes with running this code in AMD-SEV enabled VMs. As per the AMD64 manual <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.amd.com%2Fsystem%2Ffiles%2FTechDocs%2F24593.pdf&data=04%7C01%7Cbrijesh.singh%40amd.com%7C652023e953924957972a08d977b2031a%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637672430875783281%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=VFiIbcV6H4xx5XZd%2F0OZjerSfJwLfUjK7mPU9JHY05E%3D&reserved=0> section 15.8.1, executing "smsw" instruction doesn't result in bit 63 being set in EXITINFO1 and KVM ends up emulating "smsw" instruction by trying to read encrypted guest VM memory as per the code <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.kernel.org%2Fpub%2Fscm%2Fvirt%2Fkvm%2Fkvm.git%2Ftree%2Farch%2Fx86%2Fkvm%2Fsvm%2Fsvm.c%23n2495&data=04%7C01%7Cbrijesh.singh%40amd.com%7C652023e953924957972a08d977b2031a%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637672430875783281%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=jSw7PLfXjhB8utM7Dxx2P%2F5M3fqvO3q3DBaFW%2Bu03A8%3D&reserved=0>. Since KVM tries to make sense of different random cipher texts in different boots, it seems to intermittently result in visible issues.
The smsw does not provide decode assist, in those cases KVM reads the guest memory and tries to decode. With encrypted guest, the memory contains the ciphertext and hypervisor will not be able to decode the instruction.

But it brings a question to Min, why we are using the smsw ? why cannot use mov CRx. The smsw was meant for very old processors (286 or 8086 etc) and is used for legacy compatibility. The recommendation is to use the mov CRx. The mov CRx will provide the decode assist to HV.

I looked at the Intel architecture manual [1] and it also recommends using the mov CRx. The text from the Intel doc.

SMSW is only useful in operating-system software. However,
it is not a privileged instruction and can be used in
application programs if CR4.UMIP = 0. It is provided for
compatibility with the Intel 286 processor. Programs and
procedures intended to run on IA-32 and Intel 64 processors
beginning with the Intel386 processors should use the
MOV CR instruction to load the machine status word.


[1] https://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-software-developer-instruction-set-reference-manual-325383.pdf


Is this expected behavior or do we miss some configuration or patches that are recommended by AMD?
This is expected because the smsw does not provide a decode assist, and encrypted guest will have issues with it. Lets understand the reason behind using the smsw.

Regards,
Vishal
On Tue, Sep 14, 2021 at 4:54 PM Brijesh Singh via groups.io <https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fgroups.io%2F&data=04%7C01%7Cbrijesh.singh%40amd.com%7C652023e953924957972a08d977b2031a%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637672430875793279%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=%2Br4xRTlrqoERthTLJ2YNQAPrKzYX6fid2Q9WNyKybrw%3D&reserved=0> <brijesh.singh=amd.com@groups.io <mailto:amd.com@groups.io>> wrote:
Hi Min,
A quick question below.
On 9/14/21 3:50 AM, Min Xu wrote:
> RFC:
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugzilla.tianocore.org%2Fshow_bug.cgi%3Fid%3D3429&;data=04%7C01%7Cbrijesh.singh%40amd.com%7C2cca2f0a7fb44084da2b08d9775cb220%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637672062275443867%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=4zfuIDvTGDNCt%2BD3u7uUR0n6hHDzv%2FI8NkqoUJhsx8Y%3D&amp;reserved=0
<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugzilla.tianocore.org%2Fshow_bug.cgi%3Fid%3D3429&data=04%7C01%7Cbrijesh.singh%40amd.com%7C652023e953924957972a08d977b2031a%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637672430875793279%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=E5bfIvEeyWTgUqnmllwKgSwxycqhzfNnZ72O0i0UKww%3D&reserved=0>
>
> Intel's Trust Domain Extensions (Intel TDX) refers to an Intel
technology
> that extends Virtual Machines Extensions (VMX) and Multi-Key
Total Memory
> Encryption (MKTME) with a new kind of virutal machines guest called a
> Trust Domain (TD). A TD is desinged to run in a CPU mode that
protects the
> confidentiality of TD memory contents and the TD's CPU state from
other
> software, including the hosting Virtual-Machine Monitor (VMM), unless
> explicitly shared by the TD itself.
>
> Note: Intel TDX is only available on X64, so the Tdx related
changes are
> in X64 path. In IA32 path, there may be null stub to make the build
> success.
>
> This patch includes below major changes.
>
> 1. Definition of BFV & CFV
> Tdx Virtual Firmware (TDVF) includes one Firmware Volume (FV) known
> as the Boot Firmware Volume (BFV). The FV format is defined in the
> UEFI Platform Initialization (PI) spec. BFV includes all TDVF
components
> required during boot.
>
> TDVF also include a configuration firmware volume (CFV) that is
separated
> from the BFV. The reason is because the CFV is measured in RTMR,
while
> the BFV is measured in MRTD.
>
> In practice BFV is the code part of Ovmf image (OVMF_CODE.fd).
CFV is the
> vars part of Ovmf image (OVMF_VARS.fd).
>
> 2. PcdOvmfImageSizeInKb
> PcdOvmfImageSizeInKb indicates the size of Ovmf image. It is used to
> calculate the offset of TdxMetadata in ResetVectorVtf0.asm.
In SEV-SNP v7 series, I implemented the metadata support. I did not see
a need for the PcdOvmfImageSizeInKB. Why do you need it? I think your
calculation below will not work if someone is using the OVMF_CODE.fd
instead of OVMF.fd. Have you tried booting with OVMF_CODE.fd ?
thanks


Re: [edk2-platforms] [PATCH V1] SimicsOpenBoardPkg: Fix GCC Build

Nate DeSimone
 

-----Original Message-----
From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Nate DeSimone
Sent: Tuesday, August 31, 2021 4:40 PM
To: devel@edk2.groups.io
Cc: Agyeman, Prince <prince.agyeman@intel.com>; Kinney, Michael D <michael.d.kinney@intel.com>
Subject: [edk2-devel] [edk2-platforms] [PATCH V1] SimicsOpenBoardPkg: Fix GCC Build

Cc: Agyeman Prince <prince.agyeman@intel.com>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Signed-off-by: Nate DeSimone <nathaniel.l.desimone@intel.com>
---
.../SimicsOpenBoardPkg/BoardX58Ich10/OpenBoardPkgPcd.dsc | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/Platform/Intel/SimicsOpenBoardPkg/BoardX58Ich10/OpenBoardPkgPcd.dsc b/Platform/Intel/SimicsOpenBoardPkg/BoardX58Ich10/OpenBoardPkgPcd.dsc
index 251f46f812..88009b8f10 100644
--- a/Platform/Intel/SimicsOpenBoardPkg/BoardX58Ich10/OpenBoardPkgPcd.dsc
+++ b/Platform/Intel/SimicsOpenBoardPkg/BoardX58Ich10/OpenBoardPkgPcd.dsc
@@ -221,8 +221,6 @@
gEfiMdeModulePkgTokenSpaceGuid.PcdSmiHandlerProfilePropertyMask|0x1
!endif
gEfiMdeModulePkgTokenSpaceGuid.PcdUse1GPageTable|TRUE
- gEfiMdeModulePkgTokenSpaceGuid.PcdVideoHorizontalResolution|1024
- gEfiMdeModulePkgTokenSpaceGuid.PcdVideoVerticalResolution|600
gPcAtChipsetPkgTokenSpaceGuid.PcdHpetBaseAddress|0xFED00000

######################################
@@ -238,6 +236,8 @@
gEfiMdeModulePkgTokenSpaceGuid.PcdAcpiS3Enable|FALSE
gEfiMdeModulePkgTokenSpaceGuid.PcdEmuVariableNvStoreReserved|0
gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableBase64|0
+ gEfiMdeModulePkgTokenSpaceGuid.PcdVideoHorizontalResolution|1024
+ gEfiMdeModulePkgTokenSpaceGuid.PcdVideoVerticalResolution|600

######################################
# Board Configuration
--
2.27.0.windows.1


Re: Question about EDK2 and commit signing

James Bottomley
 

On Mon, 2021-09-13 at 19:31 +0000, Marvin Häuser wrote:
Hey Pedro,

Same point as before really, why would an attacker have access to
your SSH key but not your GPG key? This scenario leaves out the
possibly of an HTTPS over SSH attack, in which case as a security-
aware person you use 2FA of course ( :) ), which means this is not
possible without creating a personal access token. There is very
little reason to do this at all - I never did this before, and I
don't know anyone who does this with their private or work GitHub
account (I think a few use it for CI?), at least that I know of. And
even if you need one, and you give it push rights to actually push
with, and you require GPG signatures globally, you again are keeping
those two factors at least close together, if not in the same spot.
I think the scenario in question was someone hacking into github. They
can bypass your ssh login requirement without needing your key, because
that's enforced by github but they can't sign your commit unless they
compromise your laptop or token. There are many ways of hacking a
cloud service besides simply trying to fake the login or extract the
token from the user.

The way we get around this in Linux is with signed tags, but github
doesn't support that workflow.

I still really don't think signed commits adds much, even to github,
because to be informationally useful, all commits have to be signed.
Plus, anyway, if the entire site is compromised there'll be bigger
problems than checking commit signatures ...

James


Re: [PATCH v3 0/4] AndroidBootImgLib improvements

Jeff Brasen
 

So for patch 3: This is only a change if mAndroidBootImg->UpdateDtb == NULL. 

This seemed like a bug as we would not add the initrd values nor would we use the fdt from the BootImg if that is where the device tree was sourced from. 

It seems like either we should require UpdateDtb to be implemented (which seems to cause greater compatibility issues) or we install the device tree we have if that function isn't implemented.

As far as merging goes I am fine either way. Our particular flow won't hit this path as we don't have a device tree in the bootimg (use the system config table) and we will have the new pcd set, but this seemed like a bug while I looking at this code.

Thanks,

Jeff


From: Leif Lindholm <leif@...>
Sent: Tuesday, September 14, 2021 9:00 AM
To: Jeff Brasen <jbrasen@...>
Cc: devel@edk2.groups.io <devel@edk2.groups.io>; daniel.schaefer@... <daniel.schaefer@...>; abner.chang@... <abner.chang@...>; ardb+tianocore@... <ardb+tianocore@...>; Jun Nie <jun.nie@...>
Subject: Re: [PATCH v3 0/4] AndroidBootImgLib improvements
 
External email: Use caution opening links or attachments


Hi Jeff,

Thanks for this.
This set looks good to me, with a slight question mark wrt behaviour
compatibility with previous versions for 3/4.
(I think it's fine, but I'm a bear of very little brain, and it's been
several years since I reviewed this code, and even longer since I
really interacted with Android.
^
| shameless plug for more EmbeddedPkg reviewer volunteers.)

I've added Jun Nie, who wrote the original version of this code, to
see if he has any comments.

1-2/4 are obviously unproblematic, and I could merge those ahead of
time if preferred. You can add
Reviewed-by: Leif Lindholm <leif@...>
for those if there are any further revisions of the set.

Best Regards,

Leif

On Mon, Sep 13, 2021 at 23:18:47 +0000, Jeff Brasen wrote:
> Added support for using loadfile2 approach for passing ramdisk to linux.
> Created patch series for general error handling improvments based on
> review feedback.
> If ACPI tables are in system table or PCD is defined the LoadFile2 method
> of passing initrd will be used.
>
> [v3]
> -Code review cleanup
> -Removed duplicate header file
> -Added change to allow FDT to install if UpdateDtb function is not defined
> -Added specific ACPI check
> -Moved install functions to subfunctions
>
> [v2]
> -Added review feedback
> -General improvements to error handling
>
> [v1]
> - Intial revision
>
>
> Jeff Brasen (4):
>   EmbeddedPkg: Remove duplicate libfdt.h include
>   EmbeddedPkg: AndroidBootImgBoot error handling updates
>   EmbeddedPkg: Install FDT if UpdateDtb is not present
>   EmbeddedPkg: Add LoadFile2 for linux initrd
>
>  EmbeddedPkg/EmbeddedPkg.dec                   |   1 +
>  .../AndroidBootImgLib/AndroidBootImgLib.inf   |   4 +
>  .../AndroidBootImgLib/AndroidBootImgLib.c     | 275 +++++++++++++++---
>  3 files changed, 233 insertions(+), 47 deletions(-)
>
> --
> 2.17.1
>


[edk2-libc Patch 1/1] AppPkg/Applications/Python/Python3.6.8: add support for atexit builtin module in py 3.6.8

Jayaprakash, N
 

REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3626

This commit adds support for the atexit a builtin module
in standard python 3.6.8 to it's UEFI port. There are tools
like Chipsec which are dependent on it but it can be used by
other python scripts running on UEFI shell with the help of
py 3.6.8 interpreter. Tested the changes on IA32 and X64 emulators
and it is working good.

Cc: Rebecca Cran <rebecca@nuviainc.com>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Signed-off-by: Jayaprakash N <n.jayaprakash@intel.com>
---
AppPkg/Applications/Python/Python-3.6.8/Py368ReadMe.txt | 1 +
.../Python/Python-3.6.8/PyMod-3.6.8/Modules/config.c | 2 ++
AppPkg/Applications/Python/Python-3.6.8/Python368.inf | 1 +
3 files changed, 4 insertions(+)

diff --git a/AppPkg/Applications/Python/Python-3.6.8/Py368ReadMe.txt b/AppPkg/Applications/Python/Python-3.6.8/Py368ReadMe.txt
index 69bb6bd..fb81228 100644
--- a/AppPkg/Applications/Python/Python-3.6.8/Py368ReadMe.txt
+++ b/AppPkg/Applications/Python/Python-3.6.8/Py368ReadMe.txt
@@ -175,6 +175,7 @@ system as follows:
_symtable Modules/symtablemodule.c
_weakref Modules/_weakref.c
array Modules/arraymodule.c
+ atexit Modules/atexitmodule.c
binascii Modules/binascii.c
cmath Modules/cmathmodule.c
datetime Modules/_datetimemodule.c
diff --git a/AppPkg/Applications/Python/Python-3.6.8/PyMod-3.6.8/Modules/config.c b/AppPkg/Applications/Python/Python-3.6.8/PyMod-3.6.8/Modules/config.c
index 4b1eb0f..5ee42d8 100644
--- a/AppPkg/Applications/Python/Python-3.6.8/PyMod-3.6.8/Modules/config.c
+++ b/AppPkg/Applications/Python/Python-3.6.8/PyMod-3.6.8/Modules/config.c
@@ -65,6 +65,7 @@ extern PyObject* PyInit__weakref(void);
extern PyObject* init_winreg(void);
extern PyObject* PyInit_zlib(void);
extern PyObject* initbz2(void);
+extern PyObject* PyInit_atexit(void);

extern PyObject* PyMarshal_Init(void);
extern PyObject* _PyWarnings_Init(void);
@@ -111,6 +112,7 @@ struct _inittab _PyImport_Inittab[] = {
{"gc", PyInit_gc},
{"math", PyInit_math},
{"array", PyInit_array},
+ {"atexit", PyInit_atexit},
{"_datetime", PyInit__datetime},
{"parser", PyInit_parser},
{"pyexpat", PyInit_pyexpat},
diff --git a/AppPkg/Applications/Python/Python-3.6.8/Python368.inf b/AppPkg/Applications/Python/Python-3.6.8/Python368.inf
index d2e6e73..b98b4a7 100644
--- a/AppPkg/Applications/Python/Python-3.6.8/Python368.inf
+++ b/AppPkg/Applications/Python/Python-3.6.8/Python368.inf
@@ -215,6 +215,7 @@
Modules/_io/iobase.c #
Modules/_io/stringio.c #
Modules/_io/textio.c #
+ Modules/atexitmodule.c #

#Modules/cjkcodecs
Modules/cjkcodecs/multibytecodec.c #
--
2.32.0.windows.2


[edk2-libc Patch 0/1] Python-3.6.8 add support for atexit builtin module

Jayaprakash, N
 

Jayaprakash Nevara (1):
AppPkg/Applications/Python/Python-3.6.8: add support for atexit builtin
module in py 3.6.8

AppPkg/Applications/Python/Python-3.6.8/Py368ReadMe.txt | 1 +
.../Python/Python-3.6.8/PyMod-3.6.8/Modules/config.c | 2 ++
AppPkg/Applications/Python/Python-3.6.8/Python368.inf | 1 +
3 files changed, 4 insertions(+)

--
2.32.0.windows.2


Re: [PATCH v3 0/4] AndroidBootImgLib improvements

Leif Lindholm
 

Hi Jeff,

Thanks for this.
This set looks good to me, with a slight question mark wrt behaviour
compatibility with previous versions for 3/4.
(I think it's fine, but I'm a bear of very little brain, and it's been
several years since I reviewed this code, and even longer since I
really interacted with Android.
^
| shameless plug for more EmbeddedPkg reviewer volunteers.)

I've added Jun Nie, who wrote the original version of this code, to
see if he has any comments.

1-2/4 are obviously unproblematic, and I could merge those ahead of
time if preferred. You can add
Reviewed-by: Leif Lindholm <leif@nuviainc.com>
for those if there are any further revisions of the set.

Best Regards,

Leif

On Mon, Sep 13, 2021 at 23:18:47 +0000, Jeff Brasen wrote:
Added support for using loadfile2 approach for passing ramdisk to linux.
Created patch series for general error handling improvments based on
review feedback.
If ACPI tables are in system table or PCD is defined the LoadFile2 method
of passing initrd will be used.

[v3]
-Code review cleanup
-Removed duplicate header file
-Added change to allow FDT to install if UpdateDtb function is not defined
-Added specific ACPI check
-Moved install functions to subfunctions

[v2]
-Added review feedback
-General improvements to error handling

[v1]
- Intial revision


Jeff Brasen (4):
EmbeddedPkg: Remove duplicate libfdt.h include
EmbeddedPkg: AndroidBootImgBoot error handling updates
EmbeddedPkg: Install FDT if UpdateDtb is not present
EmbeddedPkg: Add LoadFile2 for linux initrd

EmbeddedPkg/EmbeddedPkg.dec | 1 +
.../AndroidBootImgLib/AndroidBootImgLib.inf | 4 +
.../AndroidBootImgLib/AndroidBootImgLib.c | 275 +++++++++++++++---
3 files changed, 233 insertions(+), 47 deletions(-)

--
2.17.1


Re: [edk2-platforms PATCH 1/4] BeagleBoardPkg: Remove the configuration and image headers from flash

Leif Lindholm
 

Ard, I think you were the one who converted the old crazy header stuff
to what we have now. Do you remember how this all fits together?

For the *other* 3 patches, but not this one:
Reviewed-by: Leif Lindholm <leif@nuviainc.com>

On Fri, Sep 10, 2021 at 20:57:11 -0600, Rebecca Cran wrote:
Remove the configuration and image headers from the flash image.
This was likely intended for the UEFI firmware to be loaded by the ROM
code, but the BeagleBoard only has 64KB SRAM and so EDK2 needs to be
executed as a second stage loader.

Signed-off-by: Rebecca Cran <rebecca@bsdio.com>
---
Platform/BeagleBoard/BeagleBoardPkg/BeagleBoardPkg.fdf | 13 ++-----------
1 file changed, 2 insertions(+), 11 deletions(-)

diff --git a/Platform/BeagleBoard/BeagleBoardPkg/BeagleBoardPkg.fdf b/Platform/BeagleBoard/BeagleBoardPkg/BeagleBoardPkg.fdf
index a2cfeb3bc27b..dbae015ff382 100644
--- a/Platform/BeagleBoard/BeagleBoardPkg/BeagleBoardPkg.fdf
+++ b/Platform/BeagleBoard/BeagleBoardPkg/BeagleBoardPkg.fdf
@@ -23,7 +23,7 @@


[FD.BeagleBoard_EFI]
-BaseAddress = 0x80007DF8|gArmTokenSpaceGuid.PcdFdBaseAddress #The base address of the FLASH Device.
+BaseAddress = 0x80008000|gArmTokenSpaceGuid.PcdFdBaseAddress #The base address of the FLASH Device.
Size = 0x000B0000|gArmTokenSpaceGuid.PcdFdSize #The size in bytes of the FLASH Device
ErasePolarity = 1
BlockSize = 0x1
@@ -44,16 +44,7 @@ NumBlocks = 0xB0000
# RegionType <FV, DATA, or FILE>
#
################################################################################
-0x00000000|0x00000200
-FILE = Platform/BeagleBoard/BeagleBoardPkg/ConfigurationHeader.bin
-
-0x00000200|0x00000008
-DATA = {
- 0xF8, 0xFD, 0x0A, 0x00, # image size: 0xB0000 - 0x208 == 0xAFDF8
- 0x00, 0x80, 0x00, 0x80 # entry point: 0x80008000
-}
-
-0x00000208|0x000AFDF8
+0x00000000|0x000B0000
gArmTokenSpaceGuid.PcdFvBaseAddress|gArmTokenSpaceGuid.PcdFvSize
FV = FVMAIN_COMPACT

--
2.31.1


Re: [PATCH] Platform/Qemu/Sbsa: Update TF-A binaries with QEMU "max" cpu support

Leif Lindholm
 

On Tue, Sep 14, 2021 at 13:45:34 +0100, Leif Lindholm wrote:
On Tue, Sep 14, 2021 at 14:18:06 +0200, Marcin Juszkiewicz wrote:
W dniu 14.09.2021 o 14:07, Leif Lindholm pisze:
Hi Marcin,

Thanks!

Reviewed-by: Leif Lindholm<leif@nuviainc.com>

But could you give me access to this patch on a public branch
somewhere, where I can pick it down from?
It is in https://github.com/hrw/fork-tianocore-edk2-non-osi/commit/f2b8581d4e5cceeb73e10f4e7391379359e14743
Thanks!
Can you update it with a Signed-off-by:?
Thanks!

Pushed as 2ac5396ddf24.

/
Leif

5281 - 5300 of 85885