From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (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 A4AC121B06E71 for ; Fri, 14 Jul 2017 14:29:39 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id C58B232A8A0; Fri, 14 Jul 2017 21:31:28 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com C58B232A8A0 Authentication-Results: ext-mx05.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx05.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=lersek@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com C58B232A8A0 Received: from lacos-laptop-7.usersys.redhat.com (ovpn-116-91.phx2.redhat.com [10.3.116.91]) by smtp.corp.redhat.com (Postfix) with ESMTP id 7559658883; Fri, 14 Jul 2017 21:31:22 +0000 (UTC) To: Peter Jones Cc: Amarnath Valluri , Stefan Berger , edk2-devel-01 , Javier Martinez Canillas , qemu devel list , Jiewen Yao , =?UTF-8?Q?Marc-Andr=c3=a9_Lureau?= References: <20170714203044.lplfddes2wvn2oco@redhat.com> From: Laszlo Ersek Message-ID: <9022a9e6-7c0c-e6e4-d603-a391c2d447ec@redhat.com> Date: Fri, 14 Jul 2017 23:31:21 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <20170714203044.lplfddes2wvn2oco@redhat.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.29]); Fri, 14 Jul 2017 21:31:29 +0000 (UTC) Subject: Re: investigating TPM for OVMF-on-QEMU X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jul 2017 21:29:39 -0000 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit On 07/14/17 22:30, Peter Jones wrote: > On Fri, Jul 14, 2017 at 08:04:14PM +0200, Laszlo Ersek wrote: >> (2e) Modules that we should use. Again, in increasing order of >> dependence. And here I'll comment as well on what these do: >> >> Tcg2Config/Tcg2ConfigPei.inf -- Informs the firmware globally >> about the TPM device type. This >> module can perform device >> detection or read a cached value >> from a non-volatile UEFI >> variable. >> >> Tcg2Pei/Tcg2Pei.inf -- Initializes the TPM device and >> measures the firmware volumes in >> the PEI phase into the TPM's >> platform config registers. >> >> Tcg2Dxe/Tcg2Dxe.inf -- Measures DXE phase (and later) >> modules into the TPM's PCRs, and >> also lets the OS boot loader >> measure things, by exposing the >> EFI_TCG2_PROTOCOL. >> >> Tcg2Config/Tcg2ConfigDxe.inf -- Provides a Setup TUI interface to >> configure the TPM. IIUC, it can >> also save the configured TPM type >> for subsequent boots (see >> Tcg2ConfigPei.inf above). >> >> This driver stack supports the TIS (MMIO) hardware interface, which >> is advertized to the OS in the TPM2 ACPI Table's "start method" >> field with value 6. (The according macro is TPM2_START_METHOD_MMIO >> in the QEMU source code, and EFI_TPM2_ACPI_TABLE_START_METHOD_TIS >> in the edk2 source code.) >> >> Including these drivers should result in a functional >> EFI_TCG2_PROTOCOL, which is what OS boot loaders primarily care >> about, as I understand. >> >> Importantly, the driver stack above requires PEI-phase variable >> access, therefore >> must be solved >> first. >> >> (I have had patches for said BZ ready for a while. I've failed to >> upstream them thus far because a pflash-based varstore is a hard >> requirement for them. I think that's a natural requirement, but >> thus far my arguments haven't proved compelling enough.) > > It does seem pretty natural... what's the counter argument? Jordan holds the opinion that "we should continue to support the memory vars, even if they have some obvious drawbacks": http://mid.mail-archive.com/149065122031.28789.9113394760317457361@jljusten-skl I'm of a different opinion: while I agree that we should not break the existing memory emulation, I'm also convinced that we should not develop new features for it, especially when a new feature (such as PEI-phase R/O variable access) simply cannot be *sensibly* extended to said emulation. Please see the first discussion under my original patch set: http://mid.mail-archive.com/148969026858.27582.5519307275216644796@jljusten-skl.jf.intel.com http://mid.mail-archive.com/319ff8f1-4e99-f977-5c2e-75509a222706@redhat.com http://mid.mail-archive.com/c20c6604-2153-aa57-cee5-24089a79b1e9@redhat.com http://mid.mail-archive.com/149034108785.2439.14733776608486243050@jljusten-skl http://mid.mail-archive.com/4b06b195-d8fb-a33e-3492-74fe396ebf6e@redhat.com And the second discussion under Jordan's counter-proposal: http://mid.mail-archive.com/a12bbf61-3f55-2fda-b855-58aeb99a4f42@redhat.com http://mid.mail-archive.com/149065122031.28789.9113394760317457361@jljusten-skl http://mid.mail-archive.com/121bb81b-08d1-d854-cf6f-ebc8268eb360@redhat.com http://mid.mail-archive.com/149076505135.12962.12298731900768295093@jljusten-skl Thanks Laszlo