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/PeiDxeTpmPlatformHierarchyLib.c
 create mode 100644 SecurityPkg/Library/PeiDxeTpmPlatformHierarchyLib/PeiDxeTpmPlatformHierarchyLib.inf
 create mode 100644 SecurityPkg/Library/PeiDxeTpmPlatformHierarchyLibNull/PeiDxeTpmPlatformHierarchyLib.c
 create mode 100644 SecurityPkg/Library/PeiDxeTpmPlatformHierarchyLibNull/PeiDxeTpmPlatformHierarchyLib.inf

-- 
2.31.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#80135): https://edk2.groups.io/g/devel/message/80135
Mute This Topic: https://groups.io/mt/85316773/1787277
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [importer@patchew.org]
-=-=-=-=-=-=-=-=-=-=-=-

I apologize that you see this 3 times now. I thought something went 
wrong with the smtp delivery since the messages didn't appear as fast as 
expected, but obviously that wasn't the case and now it really went wrong.

   Stefan



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#80144): https://edk2.groups.io/g/devel/message/80144
Mute This Topic: https://groups.io/mt/85316773/1787277
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [importer@patchew.org]
-=-=-=-=-=-=-=-=-=-=-=-

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



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#80267): https://edk2.groups.io/g/devel/message/80267
Mute This Topic: https://groups.io/mt/85316773/1787277
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [importer@patchew.org]
-=-=-=-=-=-=-=-=-=-=-=-

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



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#80271): https://edk2.groups.io/g/devel/message/80271
Mute This Topic: https://groups.io/mt/85316773/1787277
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [importer@patchew.org]
-=-=-=-=-=-=-=-=-=-=-=-

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
> 
> 
> 
> 
> 



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#80274): https://edk2.groups.io/g/devel/message/80274
Mute This Topic: https://groups.io/mt/85316773/1787277
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [importer@patchew.org]
-=-=-=-=-=-=-=-=-=-=-=-

On 9/6/21 8:34 AM, Yao, Jiewen wrote:
>
> 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.

We have to call ConfigureTpmPlatformHierarchy () some time *after* the 
handling of physical presence interface (PPI) platform opcodes since the 
TPM 2 commands they produce may require access to the TPM 2's platform 
hierarchy, so we cannot disable that hierarchy before handling PPI. For 
x86 machines I found the call to handling the PPI opcodes in different 
files and placed that call right after it. On ARM it's a bit different. 
Here it's the fact that I placed that call into the same function 
PlatformBootManagerAfterConsole as it is on x86. This seemed a safe place.

   Stefan


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#80352): https://edk2.groups.io/g/devel/message/80352
Mute This Topic: https://groups.io/mt/85316773/1787277
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [importer@patchew.org]
-=-=-=-=-=-=-=-=-=-=-=-

Hi Stefan
According to our security policy, the PPI must be sent before EndOfDxe.
Then registering PlatformAuth clear at EndOfDxe is safe. I still don’t get your point on why we have do in PlatformBds.

At least, I do want to make sure all X86 implementation are align to one solution.

Also, for PEI, I don’t think we shall modify the Tcg2Pei in this patch set.
The platform auth clear is platform action. I think we need a standalone PEIM, to allow platform do its own stuff.

All in all, I try to understand, why not just copy the solution in MinPlatformPkg?
A standalone TcgPlatformPei/Dxe?

Thank you
Yao Jiewen

> -----Original Message-----
> From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Stefan
> Berger
> Sent: Wednesday, September 8, 2021 8:54 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:
> >
> > 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.
> 
> We have to call ConfigureTpmPlatformHierarchy () some time *after* the
> handling of physical presence interface (PPI) platform opcodes since the
> TPM 2 commands they produce may require access to the TPM 2's platform
> hierarchy, so we cannot disable that hierarchy before handling PPI. For
> x86 machines I found the call to handling the PPI opcodes in different
> files and placed that call right after it. On ARM it's a bit different.
> Here it's the fact that I placed that call into the same function
> PlatformBootManagerAfterConsole as it is on x86. This seemed a safe place.
> 
>    Stefan
> 
> 
> 
> 



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#80367): https://edk2.groups.io/g/devel/message/80367
Mute This Topic: https://groups.io/mt/85316773/1787277
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [importer@patchew.org]
-=-=-=-=-=-=-=-=-=-=-=-

On 9/8/21 10:37 AM, Yao, Jiewen wrote:
> Hi Stefan
> According to our security policy, the PPI must be sent before EndOfDxe.
> Then registering PlatformAuth clear at EndOfDxe is safe. I still don’t get your point on why we have do in PlatformBds.
>
> At least, I do want to make sure all X86 implementation are align to one solution.
>
> Also, for PEI, I don’t think we shall modify the Tcg2Pei in this patch set.
> The platform auth clear is platform action. I think we need a standalone PEIM, to allow platform do its own stuff.
>
> All in all, I try to understand, why not just copy the solution in MinPlatformPkg?
> A standalone TcgPlatformPei/Dxe?

I tried to import Tcg2PlatformDxe with it's .c and .inf files but cannot 
get its EntryPoint invoked when running OvmfPkg/OvmfPkgX64.dsc


>
> Thank you
> Yao Jiewen
>


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#80379): https://edk2.groups.io/g/devel/message/80379
Mute This Topic: https://groups.io/mt/85316773/1787277
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [importer@patchew.org]
-=-=-=-=-=-=-=-=-=-=-=-

Many reasons on an Entrypoint not called.
I share my experence below (I encountered all of them before):
1) You update the code in a wrong tree.
2) The image is not rebuild. You still use old image.
3) The image is rebuild, but the image is not reburn to the flash.
4) The driver is not in final image.
5) The dependency is not satisfied.
6) It is actually called and run, but it fails to dump debug message to the console, which make you think it is not called.
7) It is actually called, but it gets some error and exits earlier than you expect.

Debug BKM:
1) Ensure you are working on the right tree.
2) Use a tool to scan the final image.
3) Burn the new image again.
4) Ensure driver is included in FDF.
5) Check the dependency in final build report.
6) Ensure you link a good debug lib, and debug lib can output something at that time.
7) Add a debug as the first code at entrypoint.

Thank you
Yao Jiewen


> -----Original Message-----
> From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Stefan
> Berger
> Sent: Thursday, September 9, 2021 4:35 AM
> To: Yao, Jiewen <jiewen.yao@intel.com>; devel@edk2.groups.io; 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/8/21 10:37 AM, Yao, Jiewen wrote:
> > Hi Stefan
> > According to our security policy, the PPI must be sent before EndOfDxe.
> > Then registering PlatformAuth clear at EndOfDxe is safe. I still don’t get your
> point on why we have do in PlatformBds.
> >
> > At least, I do want to make sure all X86 implementation are align to one
> solution.
> >
> > Also, for PEI, I don’t think we shall modify the Tcg2Pei in this patch set.
> > The platform auth clear is platform action. I think we need a standalone PEIM,
> to allow platform do its own stuff.
> >
> > All in all, I try to understand, why not just copy the solution in MinPlatformPkg?
> > A standalone TcgPlatformPei/Dxe?
> 
> I tried to import Tcg2PlatformDxe with it's .c and .inf files but cannot
> get its EntryPoint invoked when running OvmfPkg/OvmfPkgX64.dsc
> 
> 
> >
> > Thank you
> > Yao Jiewen
> >
> 
> 
> 
> 



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#80387): https://edk2.groups.io/g/devel/message/80387
Mute This Topic: https://groups.io/mt/85316773/1787277
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [importer@patchew.org]
-=-=-=-=-=-=-=-=-=-=-=-

On 9/8/21 8:19 PM, Yao, Jiewen wrote:
> Many reasons on an Entrypoint not called.
> I share my experence below (I encountered all of them before):
> 1) You update the code in a wrong tree.
> 2) The image is not rebuild. You still use old image.
> 3) The image is rebuild, but the image is not reburn to the flash.
> 4) The driver is not in final image.
> 5) The dependency is not satisfied.
> 6) It is actually called and run, but it fails to dump debug message to the console, which make you think it is not called.
> 7) It is actually called, but it gets some error and exits earlier than you expect.
The entry point currently has an endless loop in it, thus should stop 
edk2, but it doesn't.
>
> Debug BKM:
> 1) Ensure you are working on the right tree.
> 2) Use a tool to scan the final image.
> 3) Burn the new image again.
> 4) Ensure driver is included in FDF.
> 5) Check the dependency in final build report.
> 6) Ensure you link a good debug lib, and debug lib can output something at that time.
> 7) Add a debug as the first code at entrypoint.

I have tried a lot of things but it doesn't work . I don't know what is 
wrong. My current tree is here:

git: https://github.com/stefanberger/edk2.git

branch: ovmf_disable_platform_hierarchy.v7

web: 
https://github.com/stefanberger/edk2/tree/stefanberger/ovmf_disable_platform_hierarchy.v7

I am using the following command line to build it. Only 
OvmfPkg/OvmfPkgX64.dsc needs to work it this point, the other targets 
still need modification after v6.

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


    Stefan


>
> Thank you
> Yao Jiewen
>
>
>> -----Original Message-----
>> From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Stefan
>> Berger
>> Sent: Thursday, September 9, 2021 4:35 AM
>> To: Yao, Jiewen <jiewen.yao@intel.com>; devel@edk2.groups.io; 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/8/21 10:37 AM, Yao, Jiewen wrote:
>>> Hi Stefan
>>> According to our security policy, the PPI must be sent before EndOfDxe.
>>> Then registering PlatformAuth clear at EndOfDxe is safe. I still don’t get your
>> point on why we have do in PlatformBds.
>>> At least, I do want to make sure all X86 implementation are align to one
>> solution.
>>> Also, for PEI, I don’t think we shall modify the Tcg2Pei in this patch set.
>>> The platform auth clear is platform action. I think we need a standalone PEIM,
>> to allow platform do its own stuff.
>>> All in all, I try to understand, why not just copy the solution in MinPlatformPkg?
>>> A standalone TcgPlatformPei/Dxe?
>> I tried to import Tcg2PlatformDxe with it's .c and .inf files but cannot
>> get its EntryPoint invoked when running OvmfPkg/OvmfPkgX64.dsc
>>
>>
>>> Thank you
>>> Yao Jiewen
>>>
>>
>> 
>>


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#80428): https://edk2.groups.io/g/devel/message/80428
Mute This Topic: https://groups.io/mt/85316773/1787277
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [importer@patchew.org]
-=-=-=-=-=-=-=-=-=-=-=-

i
  Hi,

> > 4) The driver is not in final image.
> > 5) The dependency is not satisfied.

> The entry point currently has an endless loop in it, thus should stop edk2,
> but it doesn't.

Cases (4) + (5) should be easy to figure by checking the log.
ovmf logs every driver loaded, and it also logs drivers loaded but not
initialized (which can be a dependency problem).

(the log is written to the qemu debug console, so try "qemu -chardev
stdio,id=fw.log -device isa-debugcon,iobase=0x402,chardev=fm.log").

HTH & take care,
  Gerd



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#80430): https://edk2.groups.io/g/devel/message/80430
Mute This Topic: https://groups.io/mt/85316773/1787277
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [importer@patchew.org]
-=-=-=-=-=-=-=-=-=-=-=-

On 9/9/21 7:37 AM, Gerd Hoffmann wrote:
> i
>    Hi,
>
>>> 4) The driver is not in final image.
>>> 5) The dependency is not satisfied.
>> The entry point currently has an endless loop in it, thus should stop edk2,
>> but it doesn't.
> Cases (4) + (5) should be easy to figure by checking the log.
> ovmf logs every driver loaded, and it also logs drivers loaded but not
> initialized (which can be a dependency problem).
>
> (the log is written to the qemu debug console, so try "qemu -chardev
> stdio,id=fw.log -device isa-debugcon,iobase=0x402,chardev=fm.log").

Thanks. It was a missing entry in the .fdf file...

    Stefan


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#80446): https://edk2.groups.io/g/devel/message/80446
Mute This Topic: https://groups.io/mt/85316773/1787277
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [importer@patchew.org]
-=-=-=-=-=-=-=-=-=-=-=-