From nobody Sat Nov 1 08:18:03 2025 Delivered-To: importer@patchew.org Authentication-Results: mx.zohomail.com; spf=none (zoho.com: 198.145.21.10 is neither permitted nor denied by domain of lists.01.org) smtp.mailfrom=edk2-devel-bounces@lists.01.org; dmarc=fail(p=none dis=none) header.from=redhat.com Return-Path: Received: from ml01.01.org (ml01.01.org [198.145.21.10]) by mx.zohomail.com with SMTPS id 1526568453499387.27869511310166; Thu, 17 May 2018 07:47:33 -0700 (PDT) Received: from [127.0.0.1] (localhost [IPv6:::1]) by ml01.01.org (Postfix) with ESMTP id B04D0207E4DFB; Thu, 17 May 2018 07:47:31 -0700 (PDT) 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 B9494207E36A7 for ; Thu, 17 May 2018 07:47:29 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.rdu2.redhat.com [10.11.54.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 0E433805A52F; Thu, 17 May 2018 14:47:29 +0000 (UTC) Received: from localhost (ovpn-112-71.ams2.redhat.com [10.36.112.71]) by smtp.corp.redhat.com (Postfix) with ESMTP id B1CC92166BAD; Thu, 17 May 2018 14:47:28 +0000 (UTC) X-Original-To: edk2-devel@lists.01.org Received-SPF: none (zoho.com: 198.145.21.10 is neither permitted nor denied by domain of lists.01.org) client-ip=198.145.21.10; envelope-from=edk2-devel-bounces@lists.01.org; helo=ml01.01.org; Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=66.187.233.73; helo=mx1.redhat.com; envelope-from=marcandre.lureau@redhat.com; receiver=edk2-devel@lists.01.org From: marcandre.lureau@redhat.com To: edk2-devel@lists.01.org Date: Thu, 17 May 2018 16:47:13 +0200 Message-Id: <20180517144713.18647-5-marcandre.lureau@redhat.com> In-Reply-To: <20180517144713.18647-1-marcandre.lureau@redhat.com> References: <20180517144713.18647-1-marcandre.lureau@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.78 on 10.11.54.6 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.8]); Thu, 17 May 2018 14:47:29 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.8]); Thu, 17 May 2018 14:47:29 +0000 (UTC) for IP:'10.11.54.6' DOMAIN:'int-mx06.intmail.prod.int.rdu2.redhat.com' HELO:'smtp.corp.redhat.com' FROM:'marcandre.lureau@redhat.com' RCPT:'' Subject: [edk2] [PATCH v2 4/4] OvmfPkg/PlatformBootManagerLib: process TPM PPI request X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: qemu-devel@nongnu.org, javierm@redhat.com, pjones@redhat.com, jiewen.yao@intel.com, lersek@redhat.com Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Errors-To: edk2-devel-bounces@lists.01.org Sender: "edk2-devel" X-ZohoMail: RSF_4 Z_629925259 SPT_0 From: Marc-Andr=C3=A9 Lureau Call Tcg2PhysicalPresenceLibProcessRequest() to process pending PPI requests from PlatformBootManagerAfterConsole(). Laszlo understanding of edk2 is that the PPI operation processing was meant to occur *entirely* before End-Of-Dxe, so that 3rd party UEFI drivers couldn't interfere with PPI opcode processing *at all*. He suggested that we should *not* call Tcg2PhysicalPresenceLibProcessRequest() from BeforeConsole(). Because, an "auth" console, i.e. one that does not depend on a 3rd party driver, is *in general* impossible to guarantee. Instead we could opt to trust 3rd party drivers, and use the "normal" console(s) in AfterConsole(), in order to let the user confirm the PPI requests. It will depend on the user to enable Secure Boot, so that the trustworthiness of those 3rd party drivers is ensured. If an attacker roots the guest OS from within, queues some TPM2 PPI requests, and also modifies drivers on the EFI system partition and/or in GPU option ROMs (?), then those drivers will not load after guest reboot, and thus the dependent console(s) won't be used for confirming the PPI requests. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Marc-Andr=C3=A9 Lureau --- OvmfPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf | 2 ++ OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c | 8 ++++= ++++ 2 files changed, 10 insertions(+) diff --git a/OvmfPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.= inf b/OvmfPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf index 27789b7377bc..4b72c44bcf0a 100644 --- a/OvmfPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf +++ b/OvmfPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf @@ -38,6 +38,7 @@ [Packages] IntelFrameworkModulePkg/IntelFrameworkModulePkg.dec SourceLevelDebugPkg/SourceLevelDebugPkg.dec OvmfPkg/OvmfPkg.dec + SecurityPkg/SecurityPkg.dec =20 [LibraryClasses] BaseLib @@ -56,6 +57,7 @@ [LibraryClasses] LoadLinuxLib QemuBootOrderLib UefiLib + Tcg2PhysicalPresenceLib =20 [Pcd] gUefiOvmfPkgTokenSpaceGuid.PcdEmuVariableEvent diff --git a/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c b/OvmfPkg= /Library/PlatformBootManagerLib/BdsPlatform.c index 004b753f4d26..8b1beaa3e207 100644 --- a/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c +++ b/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c @@ -16,6 +16,7 @@ #include #include #include +#include =20 =20 // @@ -1410,6 +1411,13 @@ PlatformBootManagerAfterConsole ( // PciAcpiInitialization (); =20 + + // + // Process TPM PPI request + // + Tcg2PhysicalPresenceLibProcessRequest (NULL); + + // // Process QEMU's -kernel command line option // --=20 2.17.0.253.g3dd125b46d _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel