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 9F86D210F154E for ; Tue, 14 Aug 2018 07:51:12 -0700 (PDT) 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 99BD1401EF23; Tue, 14 Aug 2018 14:51:11 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-120-27.rdu2.redhat.com [10.10.120.27]) by smtp.corp.redhat.com (Postfix) with ESMTP id B0A451017D4B; Tue, 14 Aug 2018 14:51:08 +0000 (UTC) To: heyi.guo@linaro.org, "Yao, Jiewen" Cc: "edk2-devel@lists.01.org" , "Zhang, Chao B" , =?UTF-8?Q?Marc-Andr=c3=a9_Lureau?= , Stefan Berger References: <20180810084950.GA32368@ecs-e536.expressvpn> <67261275-360A-40ED-A668-AF1265A39AFD@intel.com> <20180813010715.GA1974@ecs-e536.expressvpn> <74D8A39837DF1E4DA445A8C0B3885C503AD06403@shsmsx102.ccr.corp.intel.com> <20180814061801.GA2691@ecs-e536.expressvpn> From: Laszlo Ersek Message-ID: <523610f5-c450-b776-998a-ccb563d0aa7a@redhat.com> Date: Tue, 14 Aug 2018 16:51:07 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <20180814061801.GA2691@ecs-e536.expressvpn> 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.5]); Tue, 14 Aug 2018 14:51:11 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.5]); Tue, 14 Aug 2018 14:51:11 +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: Question about SecurityPkg/DxeTcg2PhysicalPresenceLib X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Aug 2018 14:51:12 -0000 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Hello Heyi, (+ Marc-André and Stefan) On 08/14/18 08:18, heyi.guo@linaro.org wrote: > Hi Jiewen, > > I searched the code in EDK2, and found there is another implementation > of DxeTcg2PhysicalPresenceLib for OVMF: the function > Tcg2PhysicalPresenceLibProcessRequest() is called in > PlatformBootManagerAfterConsole() on OVMF, and it doesn't invoke > VariableLockProtocol->RequestToLock() in > Tcg2PhysicalPresenceLibProcessRequest(). > > Is this also an reference solution? Does it have any drawback > comparing with the implementation in SecurityPkg? we didn't specifically intend the solution seen in OvmfPkg as a "reference solution", but you are welcome to copy it if you wish. With Marc-André and Stefan we had discussed the exact dependency problem that you point out for a very long time. I have three comments on that now. (1) The answer that Jiewen gave you first (i.e., set up one trusted console in the BeforeConsole PlatformBootManager hook) is documented in the edk2 tree. Unfortunately, it is not documented in the "PlatformBootManagerLib.h" class header. But it is documented near the BeforeConsole call site in BdsEntry() [MdeModulePkg/Universal/BdsDxe/BdsEntry.c]: > // Do the platform init, can be customized by OEM/IBV > // Possible things that can be done in PlatformBootManagerBeforeConsole: > // > Update console variable: 1. include hot-plug devices; 2. Clear ConIn and add SOL for AMT > // > Register new Driver#### or Boot#### > // > Register new Key####: e.g.: F12 > // > Signal ReadyToLock event > // > Authentication action: 1. connect Auth devices; 2. Identify auto logon user. > // > PERF_INMODULE_BEGIN("PlatformBootManagerBeforeConsole"); > PlatformBootManagerBeforeConsole (); > PERF_INMODULE_END("PlatformBootManagerBeforeConsole"); See the "connect Auth devices" action. (2) In a virtual machine especially, where the hardware configuration might change from boot to boot, it's basically impossible to identify a trusted console device for TPM / "physical presence" purposes. This is why we needed a different solution for OvmfPkg. The "trusted console before EndOfDxe" platform requirement is impractical in general as well. To my understanding, the point of processing (=confirming) the queued TPM2 PPI opcodes before EndOfDxe is that 3rd-party UEFI drivers not interfere with their display and acceptance. But, if you have a physical computer with only a USB keyboard and a discrete PCIE GPU, then your *only* console, trusted or not, is that pair of devices. For them to function together as a console, the UEFI driver in the GPU option ROM has to be executed. And that will only ever occur after EndOfDxe. (BTW this example applies to virtual machines directly; you may have a VM with an assigned (VFIO) GPU, and no other display device, not even a serial port. In that case, no driver that is built into OVMF will let you output anything to the screen.) (3) The solution we chose can be read in the messages of the commits that introduced (a) the Tcg2PhysicalPresenceLibProcessRequest() implementation, (b) the call to the same, in OvmfPkg. (Just use "git-blame".) Namely, - b9777bb42e4f ("OvmfPkg: add Tcg2PhysicalPresenceLibQemu", 2018-05-22) - 8d65d3b25e35 ("OvmfPkg/PlatformBootManagerLib: process TPM PPI request", 2018-05-22) In the first patch, all code related to TCG2_PHYSICAL_PRESENCE*_VARIABLE are dropped from the library instance, because QEMU's virtual TPM device provides a non-standard hardware mechanism for queueing PPI opcodes for after reboot. This obviates the info channel through UEFI variables (and eliminates a *huge* complication with ACPI code that enters SMM for variable access, etc). (Our understanding is that the *queueing* of PPI opcodes is not a firmware-privileged operation (i.e. a privileged user at the OS level is allowed to do it); only the interactive *confirmation* of the queued PPI opcodes is firmware-privileged.) In the second patch, the solution is to consider all consoles trusted, and to rely on the user to enable Secure Boot. Then Secure Boot will verify those 3rd-party UEFI drivers as well that are necessary for setting up consoles. If an attacker manages to compromise the OS and to queue some crafted PPI opcodes, the firmware will still faithfully ask the user for confirming those (i.e. the attacker cannot hide or mis-represent the queued PPI opcodes). Because, the drivers instrumental to console setup are protected from instruction stream tampering with Secure Boot. (They are not protected from data-attacks by SB, but neither are DXE drivers that are built directly into the system firmware.) Thanks Laszlo