Re: [PATCH v2 8/8] ovmf: add DxeTpm2MeasureBootLib

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

Besides the comment below, I should have used the example in OvmfPkg.

Please refer to https://github.com/tianocore/edk2/blob/master/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c

The EfiBootManagerDispatchDeferredImages() API call is added just after gEfiDxeSmmReadyToLockProtocolGuid.

So I don’t see any problem in OVMF pkg.


Thank you
Yao Jiewen

> -----Original Message-----
> From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of Yao,
> Jiewen
> Sent: Friday, March 9, 2018 8:39 AM
> To: Laszlo Ersek <lersek@redhat.com>; marcandre.lureau@redhat.com;
> edk2-devel@lists.01.org
> Cc: javierm@redhat.com; pjones@redhat.com; qemu-devel@nongnu.org
> Subject: Re: [edk2] [PATCH v2 8/8] ovmf: add DxeTpm2MeasureBootLib
> 
> Very good question.
> Comment below:
> 
> > -----Original Message-----
> > From: Laszlo Ersek [mailto:lersek@redhat.com]
> > Sent: Friday, March 9, 2018 3:54 AM
> > To: marcandre.lureau@redhat.com; edk2-devel@lists.01.org; Yao, Jiewen
> > <jiewen.yao@intel.com>
> > Cc: pjones@redhat.com; stefanb@linux.vnet.ibm.com;
> > qemu-devel@nongnu.org; javierm@redhat.com
> > 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, marcandre.lureau@redhat.com wrote:
> > > From: Marc-André Lureau <marcandre.lureau@redhat.com>
> > >
> > > 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 <lersek@redhat.com>
> > > Cc: Stefan Berger <stefanb@linux.vnet.ibm.com>
> > > Contributed-under: TianoCore Contribution Agreement 1.0
> > > Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
> > > ---
> > >  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/Sec
> urityStubDxe/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/Librar
> y/UefiBootManagerLib.h and implemented in
> https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Library/UefiB
> ootManagerLib/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
> _______________________________________________
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel