Re: [Qemu-devel] [PATCH v2 8/8] ovmf: add DxeTpm2MeasureBootLib

[Yao, Jiewen]

Very good question.
Comment below:

> -----Original Message-----
> From: Laszlo Ersek [mailto:address@hidden
> Sent: Friday, March 9, 2018 3:54 AM
> To: address@hidden; address@hidden; Yao, Jiewen
> <address@hidden>
> Cc: address@hidden; address@hidden;
> address@hidden; address@hidden
> Subject: Re: [PATCH v2 8/8] ovmf: add DxeTpm2MeasureBootLib
> 
> (Jiewen, below I have a question for you as well; please help with that.)
> 
> On 03/07/18 16:57, address@hidden wrote:
> > From: Marc-André Lureau <address@hidden>
> >
> > The library registers a security management handler, to measure images
> > that are not measure in PEI phase.
> >
> > This seems to work for example with the qemu PXE rom:
> >
> > Loading driver at 0x0003E6C2000 EntryPoint=0x0003E6C9076 8086100e.efi
> >
> > And the following binary_bios_measurements log entry seems to be
> > added:
> >
> > PCR: 2      type: EV_EFI_BOOT_SERVICES_DRIVER       size: 0x4e      digest:
> 70a22475e9f18806d2ed9193b48d80d26779d9a4
> >
> > Cc: Laszlo Ersek <address@hidden>
> > Cc: Stefan Berger <address@hidden>
> > Contributed-under: TianoCore Contribution Agreement 1.0
> > Signed-off-by: Marc-André Lureau <address@hidden>
> > ---
> >  OvmfPkg/OvmfPkgX64.dsc | 3 +++
> >  1 file changed, 3 insertions(+)
> >
> > diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc
> > index 7753852144fb..9db1712e3623 100644
> > --- a/OvmfPkg/OvmfPkgX64.dsc
> > +++ b/OvmfPkg/OvmfPkgX64.dsc
> > @@ -662,6 +662,9 @@ [Components]
> >      <LibraryClasses>
> >  !if $(SECURE_BOOT_ENABLE) == TRUE
> >
> NULL|SecurityPkg/Library/DxeImageVerificationLib/DxeImageVerificationLib.inf
> > +!endif
> > +!if $(TPM2_ENABLE) == TRUE
> > +
> NULL|SecurityPkg/Library/DxeTpm2MeasureBootLib/DxeTpm2MeasureBootLib.i
> nf
> >  !endif
> >    }
> >
> >
> 
> (1) Marc-André, please change the subject line to:
> 
> OvmfPkg: plug DxeTpm2MeasureBootLib into SecurityStubDxe
> 
> 
> (2) I have a question for Jiewen:
> 
> DxeTpm2MeasureBootLib consumes the TCG2 protocol, but it does not depend
> on it with a DEPEX. Instead, DxeTpm2MeasureBootHandler() tries to locate
> the protocol on every invocation.
[Jiewen] Yes.

> This means that SecurityStubDxe may produce the Security and Security2
> Architectural Protocols before measurements into the TPM2 device are
> possible.
[Jiewen] Yes.

> Therefore, UEFI_DRIVER modules (which depend on all of the
> Arch protocols) may be started before they can be measured into the TPM.
> 
> Now, this is likely no problem for UEFI_DRIVER modules that are built
> into the firmware volume(s), because those are measured by Tcg2Pei
> anyway.
[Jiewen] That is TRUE.

However, it would be a problem for UEFI_DRIVER modules / apps
> that come from external media (disk, network, PCI oprom, etc).
[Jiewen] By design, the 3rd part module should not be invoked before EndOfDxe.
All Arch Protocol Ready is not strong enough. :-)
Please refer to 
https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Universal/SecurityStubDxe/Defer3rdPartyImageLoad.c

If a non-FV image is loaded before EndOfDxe, it will be queued into 
mDeferred3rdPartyImage.

We also added EfiBootManagerDispatchDeferredImages() API in 
https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Include/Library/UefiBootManagerLib.h
 and implemented in 
https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Library/UefiBootManagerLib/BmMisc.c
A platform must call EfiBootManagerDispatchDeferredImages(), if the platform 
supports PCI OROM.

You can find the sample code in 
https://github.com/tianocore/edk2-platforms/blob/devel-MinPlatform/Platform/Intel/MinPlatformPkg/Bds/Library/DxePlatformBootManagerLib/BdsPlatform.c



> However, such are loaded only in the BDS phase, and BDS is only entered
> after all of the DXE drivers are dispatched from the firmware volumes.
> In other words, the ordering between Tcg2Dxe and external UEFI_DRIVER /
> UEFI_APPLICATION modules is ensured that Tcg2Dxe will be dispatched in
> the DXE phase, while the latter will only be loaded in BDS.
> 
> Is this intentional? Is my understanding correct?

[Jiewen] Right. The only assumption is: Tcg2Dxe is included in the firmware 
volume and it is dispatched before EndOfDxe.



> 
> (3) If that's the case, then Marc-André, please add the following to the
> commit message:
> 
> --------
> Hooking DxeTpm2MeasureBootLib into SecurityStubDxe ensures that the
> Security and Security2 Arch protocols will entail, by the time of
> entering the BDS phase, the measuring of UEFI binaries into the TPM.
> Thus, external UEFI_DRIVER and UEFI_APPLICATION modules (which are
> loaded in the BDS phase, from disk, network, PCI oprom, etc) will be
> measured.
> 
> Drivers dispatched in the DXE phase before Tcg2Dxe will not be measured
> individually; however such drivers come from the firmware volume(s), and
> those are measured in the PEI phase by Tcg2Pei.
> --------
> 
> Thanks!
> Laszlo