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

[Laszlo Ersek <lersek@redhat.com>]

(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.inf
>  !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.

This means that SecurityStubDxe may produce the Security and Security2
Architectural Protocols before measurements into the TPM2 device are
possible. 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. However, it would be a problem for UEFI_DRIVER modules / apps
that come from external media (disk, network, PCI oprom, etc).

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?


(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