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

["Yao, Jiewen" <jiewen.yao@intel.com>]

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