From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=66.187.233.73; helo=mx1.redhat.com; envelope-from=lersek@redhat.com; receiver=edk2-devel@lists.01.org Received: from mx1.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 3E6EF22568604 for ; Thu, 8 Mar 2018 11:48:06 -0800 (PST) Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.rdu2.redhat.com [10.11.54.3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id D844EBD9E; Thu, 8 Mar 2018 19:54:21 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-120-50.rdu2.redhat.com [10.10.120.50]) by smtp.corp.redhat.com (Postfix) with ESMTP id 35B5C10A85AD; Thu, 8 Mar 2018 19:54:12 +0000 (UTC) To: marcandre.lureau@redhat.com, edk2-devel@lists.01.org, jiewen.yao@intel.com Cc: pjones@redhat.com, stefanb@linux.vnet.ibm.com, qemu-devel@nongnu.org, javierm@redhat.com References: <20180307155746.18526-1-marcandre.lureau@redhat.com> <20180307155746.18526-9-marcandre.lureau@redhat.com> From: Laszlo Ersek Message-ID: Date: Thu, 8 Mar 2018 20:54:11 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <20180307155746.18526-9-marcandre.lureau@redhat.com> X-Scanned-By: MIMEDefang 2.78 on 10.11.54.3 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.1]); Thu, 08 Mar 2018 19:54:21 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.1]); Thu, 08 Mar 2018 19:54:21 +0000 (UTC) for IP:'10.11.54.3' DOMAIN:'int-mx03.intmail.prod.int.rdu2.redhat.com' HELO:'smtp.corp.redhat.com' FROM:'lersek@redhat.com' RCPT:'' Subject: Re: [PATCH v2 8/8] ovmf: add DxeTpm2MeasureBootLib X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2018 19:48:06 -0000 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit (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 > > 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 > Cc: Stefan Berger > Contributed-under: TianoCore Contribution Agreement 1.0 > Signed-off-by: Marc-André Lureau > --- > 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] > > !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