From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: None (no SPF record) identity=mailfrom; client-ip=148.163.156.1; helo=mx0a-001b2d01.pphosted.com; envelope-from=stefanb@linux.vnet.ibm.com; receiver=edk2-devel@lists.01.org Received: from mx0a-001b2d01.pphosted.com (mx0a-001b2d01.pphosted.com [148.163.156.1]) (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 D97D220955F3E for ; Fri, 2 Mar 2018 05:29:18 -0800 (PST) Received: from pps.filterd (m0098410.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w22DXcSt131537 for ; Fri, 2 Mar 2018 08:35:27 -0500 Received: from e34.co.us.ibm.com (e34.co.us.ibm.com [32.97.110.152]) by mx0a-001b2d01.pphosted.com with ESMTP id 2gf6qua93a-1 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NOT) for ; Fri, 02 Mar 2018 08:35:27 -0500 Received: from localhost by e34.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Fri, 2 Mar 2018 06:35:26 -0700 Received: from b03cxnp07028.gho.boulder.ibm.com (9.17.130.15) by e34.co.us.ibm.com (192.168.1.134) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Fri, 2 Mar 2018 06:35:23 -0700 Received: from b03ledav003.gho.boulder.ibm.com (b03ledav003.gho.boulder.ibm.com [9.17.130.234]) by b03cxnp07028.gho.boulder.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id w22DZMIA14418378; Fri, 2 Mar 2018 06:35:22 -0700 Received: from b03ledav003.gho.boulder.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id DC1566A03C; Fri, 2 Mar 2018 06:35:22 -0700 (MST) Received: from sbct-3.pok.ibm.com (unknown [9.47.158.153]) by b03ledav003.gho.boulder.ibm.com (Postfix) with ESMTP id 487746A03B; Fri, 2 Mar 2018 06:35:22 -0700 (MST) To: Laszlo Ersek , marcandre.lureau@redhat.com, edk2-devel@lists.01.org References: <20180223132311.26555-1-marcandre.lureau@redhat.com> <20180223132311.26555-7-marcandre.lureau@redhat.com> <4dc45713-b15d-0db5-d72e-ccb007cd2487@redhat.com> <9b615ca0-bc5a-e160-928d-07042b93e9a0@redhat.com> Cc: pjones@redhat.com, jiewen.yao@intel.com, qemu-devel@nongnu.org, javierm@redhat.com From: Stefan Berger Date: Fri, 2 Mar 2018 08:35:21 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <9b615ca0-bc5a-e160-928d-07042b93e9a0@redhat.com> X-TM-AS-GCONF: 00 x-cbid: 18030213-0016-0000-0000-00000855E9B5 X-IBM-SpamModules-Scores: X-IBM-SpamModules-Versions: BY=3.00008609; HX=3.00000241; KW=3.00000007; PH=3.00000004; SC=3.00000254; SDB=6.00997282; UDB=6.00507079; IPR=6.00776600; MB=3.00019817; MTD=3.00000008; XFM=3.00000015; UTC=2018-03-02 13:35:25 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 18030213-0017-0000-0000-00003DAEA5DA Message-Id: X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-03-02_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1709140000 definitions=main-1803020161 Subject: Re: [Qemu-devel] [PATCH 6/7] ovmf: link with Tcg2ConfigDxe module 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: Fri, 02 Mar 2018 13:29:19 -0000 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 03/02/2018 06:12 AM, Laszlo Ersek wrote: > On 03/01/18 17:59, Stefan Berger wrote: >> On 02/26/2018 04:58 AM, Laszlo Ersek wrote: >>> On 02/23/18 14:23, marcandre.lureau@redhat.com wrote: >>>> From: Marc-André Lureau >>>> >>>> The module allows to tweak and interact with the TPM. Note that many >>>> actions are broken due to implementation of qemu TPM (providing it's >>>> own ACPI table), and the lack of PPI implementation. >>>> >>>> CC: Laszlo Ersek >>>> CC: Stefan Berger >>>> Contributed-under: TianoCore Contribution Agreement 1.0 >>>> Signed-off-by: Marc-André Lureau >>>> --- >>>> OvmfPkg/OvmfPkgX64.dsc | 2 ++ >>>> OvmfPkg/OvmfPkgX64.fdf | 1 + >>>> 2 files changed, 3 insertions(+) >>>> >>>> diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc >>>> index 9bd0709f98..2281bd5ff8 100644 >>>> --- a/OvmfPkg/OvmfPkgX64.dsc >>>> +++ b/OvmfPkg/OvmfPkgX64.dsc >>>> @@ -669,6 +669,8 @@ >>>> >>>> NULL|SecurityPkg/Library/HashInstanceLibSha1/HashInstanceLibSha1.inf >>>> >>>> NULL|SecurityPkg/Library/HashInstanceLibSha256/HashInstanceLibSha256.inf >>>> } >>>> + >>>> + SecurityPkg/Tcg/Tcg2Config/Tcg2ConfigDxe.inf >>>> !endif >>>> !if $(SECURE_BOOT_ENABLE) == TRUE >>>> diff --git a/OvmfPkg/OvmfPkgX64.fdf b/OvmfPkg/OvmfPkgX64.fdf >>>> index b8dd7ecae4..985404850f 100644 >>>> --- a/OvmfPkg/OvmfPkgX64.fdf >>>> +++ b/OvmfPkg/OvmfPkgX64.fdf >>>> @@ -399,6 +399,7 @@ INF >>>> MdeModulePkg/Universal/Variable/RuntimeDxe/VariableRuntimeDxe.inf >>>> !if $(TPM2_ENABLE) == TRUE >>>> INF SecurityPkg/Tcg/Tcg2Dxe/Tcg2Dxe.inf >>>> +INF SecurityPkg/Tcg/Tcg2Config/Tcg2ConfigDxe.inf >>>> !endif >>>> >>>> ################################################################################ >>>> >>>> >>> Please drop this patch. >>> >>> In my earlier investigation I wrote, Tcg2ConfigDxe "[p]rovides a Setup >>> TUI interface to configure the TPM. IIUC, it can also save the >>> configured TPM type for subsequent boots (see Tcg2ConfigPei.inf above)". >>> >>> The INF file itself says "This module is only for reference only, each >>> platform should have its own setup page." >>> >>> And Jiewen wrote earlier, "Tcg2ConfigPei/Dxe are platform sample driver. >>> A platform may have its own version based upon platform requirement. For >>> example, if a platform supports fTPM, it may use another Tcg2Config >>> driver." >>> >>> Given that OVMF lacks PEI-phase variable access, and that I consequently >>> suggested cloning, and seriously trimming, Tcg2ConfigPei, it makes no >>> sense to include an HII dialog that sets a variable for PEI phase >>> consumption. Also, as you say, many of the exposed operations are broken >>> due to lack of PPI support. So let's just postpone the inclusion of this >>> driver, for now. >> Just FYI: The PPI support for the OS requires ACPI > OK > >> and, as it is >> currently implemented, SMF where UEFI variables are manipulated. > (I assume s/SMF/SMM/) correct. > > You are correct to write "as it is currently implemented". My point in > my previous email(s) was that QEMU should generate the ACPI payload > needed by the OS, for queueing PPI opcodes (i.e. OVMF should install > QEMU's AML, *not* the sample AML code in SecurityPkg). In turn the AML > from QEMU should queue the PPI opcodes in the custom register block of > the TPM device (which is anyway the only NVRAM-emulation possibility > under SeaBIOS). We can emulate other NVRAM as well. It is a possibility and provides the flexibility of setting flags per implemented PPI code indicating whether the firmware implements the codes and sysfs entries in Linux can then show what is actually supported. If you write code '23' into sysfs and ACPI has no clue whether the firmware implements '23', then you may reboot for nothing and start wondering what is going on because the effect isn't there. Also I don't think we'll implement the same set of commands in both firmwares that we would want to hard-code the checking for implemented code in ACPI produced by the firmware. > > Given that the PPI opcodes will henceforth not be stored in a UEFI > variable under OVMF either, the SMM requirement in the AML falls away > completely. I would not modify that code but keep what is there right now and write some glue code around it: Upon reboot detect what PPI code has been set, if any, and write it into the UEFI variable. Then existing UEFI code reads the variable (stemming either from OS or a menu operation) and acts upon it. That keeps much of the existing code unmodified, which I find appealing. Also the code for the menu wouldn't have to be modified. > > Retrieving the PPI opcodes for processing from the custom MMIO register > block of the TPM device, after reboot, as opposed to reading them out of > a UEFI variable, will take custom code in OVMF. We'll get there. That custom MMIO register block could, in the worst case, be assigned a different purpose in a future spec... Stefan > >> Some >> menu items in the TPM 2 menu (also TPM 1.2) also require these UEFI >> variables of the PPI interface so that UEFI can react on the menu >> choices upon re. > (I assume s/re/reboot/) > > In "SecurityPkg/Tcg/Tcg2Config/Tcg2Config.vfr" (which is the "Visual > Form Representation" of the dialog we're talking about), I see three > variable references. The structures for those are defined in > "SecurityPkg/Tcg/Tcg2Config/Tcg2ConfigNvData.h": > > - TCG2_CONFIGURATION_INFO > - TCG2_CONFIGURATION > - TCG2_VERSION > > I think the last two are irrelevant under OVMF / QEMU (fixed version 2 > TPM, and ACPI comes from QEMU -- consistent with my other comments for > the PEI phase modules). > > TCG2_CONFIGURATION_INFO looks more complex, so perhaps we'll have to > scavenge its handling for OVMF. However, it seems that > TCG2_CONFIGURATION_INFO is not needed in the PEI phase. > > ... Understand this right: I'd be bursting from joy if OVMF had > PEI-phase r/o variable access. I got that feature working for QEMU. But > all my attempts to upstream the work failed (apparently because I'm not > willing to develop a parallel "fake" for Xen -- on Xen, NVRAM/pflash > doesn't even exist, so even if the PEI variable service existed on Xen, > it would have zero chance to return valid data.) > > Laszlo >