From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) by mx.groups.io with SMTP id smtpd.web10.12564.1629882446876152410 for ; Wed, 25 Aug 2021 02:07:27 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@intel.onmicrosoft.com header.s=selector2-intel-onmicrosoft-com header.b=hB5Asll6; spf=pass (domain: intel.com, ip: 192.55.52.120, mailfrom: jiewen.yao@intel.com) X-IronPort-AV: E=McAfee;i="6200,9189,10086"; a="215641242" X-IronPort-AV: E=Sophos;i="5.84,350,1620716400"; d="scan'208";a="215641242" Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by fmsmga104.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 25 Aug 2021 02:07:25 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.84,350,1620716400"; d="scan'208";a="527151485" Received: from fmsmsx605.amr.corp.intel.com ([10.18.126.85]) by FMSMGA003.fm.intel.com with ESMTP; 25 Aug 2021 02:07:15 -0700 Received: from fmsmsx605.amr.corp.intel.com (10.18.126.85) by fmsmsx605.amr.corp.intel.com (10.18.126.85) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2242.4; Wed, 25 Aug 2021 02:07:15 -0700 Received: from fmsedg602.ED.cps.intel.com (10.1.192.136) by fmsmsx605.amr.corp.intel.com (10.18.126.85) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2242.4 via Frontend Transport; Wed, 25 Aug 2021 02:07:15 -0700 Received: from NAM12-MW2-obe.outbound.protection.outlook.com (104.47.66.48) by edgegateway.intel.com (192.55.55.71) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2242.10; Wed, 25 Aug 2021 02:07:14 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=W4J/cnciGeI+woaGIbnrYPOk+gv8ngoMKFeGCitFX+Gw2Vy0MxkPhoLXCcxt16Zim+XgTm+whXS2VEVcBwj2E9q7KREyEIv3JBDfaTg7Gr5yKeMFEfEGg0RT07EcxeGA5Lf5+ESymmti7Pvk7cBYUFYDUJ4oxNzuG5RwYDwqX0e5RugmIyjASTqEakXwkZ80FT9Ut6Q0676H0VYLi4zPlWPzO7R0P04owSs3umL8m9krWDUR4qYSBuZel1WscV3GPvDu2sLkcDtgBnWWFKsLKCXhU1g1JMVrBz5vv5l8W8hvFTYMDVXuQMxz3l3mVWPpZprgwlybLc/9hBDWIYnskw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=7Gpz0c2u8zWgRECIcMkFbYP0c9km7hA5qkqYfw8ylSs=; b=bsUrjQFhJdjxSvWJVBaA4A9dLSJBY3z1DmSUGcIzrzQQOA35e4j0hCUmrScK3AQGlgFWEPPEbE7cjYUURdugiFnKg9MajpoSELF0iVAHFL6qdqDWHMh6BahRmGuQrUf6PAjCyfaOE3HIScTvRToV1sjcOitQOUJS/14oHsNBev3/N7OLFFh1hu4fLBFiNIE06hA09/Oy8dImNBYX4wJlUc/iorKeCmk3os12nZfTcQ6x7081SdIjgPJzXhgx5tyFbG6rqATjEO7cDAdC1ryWRzWgC3xwBvRdgkJCDjC2M/1QhOstga+FoiD+9NEGTn9BCaczbXpMuoipl4TpJ+61Rg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=intel.com; dmarc=pass action=none header.from=intel.com; dkim=pass header.d=intel.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=intel.onmicrosoft.com; s=selector2-intel-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=7Gpz0c2u8zWgRECIcMkFbYP0c9km7hA5qkqYfw8ylSs=; b=hB5Asll6VkXsQaY59Fs5x99cgoRb0qOXk98l4ubKKphDdXAkeCQzeMxzPMhxsM1qItI/Sbj57/H/Exnvgu80J5LWeyGe7MFCYktu7f5G0Xmxk/zjS01AxbvkVlhrej0xQsed10xKPJ0qVP+S+q809YUTA0tBgNFjy3uHJd0vnAc= Received: from PH0PR11MB4885.namprd11.prod.outlook.com (2603:10b6:510:35::14) by PH0PR11MB4997.namprd11.prod.outlook.com (2603:10b6:510:31::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4436.19; Wed, 25 Aug 2021 09:07:13 +0000 Received: from PH0PR11MB4885.namprd11.prod.outlook.com ([fe80::e97b:e466:268f:fb79]) by PH0PR11MB4885.namprd11.prod.outlook.com ([fe80::e97b:e466:268f:fb79%6]) with mapi id 15.20.4436.024; Wed, 25 Aug 2021 09:07:13 +0000 From: "Yao, Jiewen" To: "devel@edk2.groups.io" , "kraxel@redhat.com" CC: Ard Biesheuvel , "Xu, Min M" , "Ard Biesheuvel" , "Justen, Jordan L" , Brijesh Singh , "Erdem Aktas" , James Bottomley , "Tom Lendacky" Subject: Re: [edk2-devel] [PATCH 18/23] OvmfPkg: Enable Tdx in SecMain.c Thread-Topic: [edk2-devel] [PATCH 18/23] OvmfPkg: Enable Tdx in SecMain.c Thread-Index: AQHXj3FdcI3h9T1gnEKykKGFK85I0at6bd2AgAB/3gCAARvDgIAGmLcAgAANpQCAARgVkIAAJW8AgAADM8A= Date: Wed, 25 Aug 2021 09:07:13 +0000 Message-ID: References: <95f116893a4a17c7e0966e240a650f871c9f9392.1628767741.git.min.m.xu@intel.com> <20210819064937.o646vxjebwzgfgoz@sirius.home.kraxel.org> <20210820072253.plne3mudm3dj6777@sirius.home.kraxel.org> <20210825075218.mpmkcwu3zo6tykm2@sirius.home.kraxel.org> In-Reply-To: <20210825075218.mpmkcwu3zo6tykm2@sirius.home.kraxel.org> Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-version: 11.5.1.3 dlp-product: dlpe-windows dlp-reaction: no-action authentication-results: edk2.groups.io; dkim=none (message not signed) header.d=none;edk2.groups.io; dmarc=none action=none header.from=intel.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: b5a1c571-deb8-48d3-991c-08d967a7ba6d x-ms-traffictypediagnostic: PH0PR11MB4997: x-ld-processed: 46c98d88-e344-4ed4-8496-4ed7712e255d,ExtAddr x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: ISDiPuniECkQ38JpzZL2reaRU6GVPUKsOrc7m51uXFbzG5yougLjaPCsisrzxR/JK4N/rrzDKhzHWNjselvvt34JiGgTp7poxahR/3ANrHCFtCnivYsCy1ZCaVqY/T3fjWnTu0QNyo9+Tgecb/WYeTGuYn8MD8Ri9jbgBoTpPTjKNlCh5jIcSrQ1qDLZ40PSSPZH4o+IidtiSUp4gAcCSKoU977wHo5MIQyVGG41xtd6RAd9AgE2VQ4TaoVEOpu8C95aciAsvfKrfvd+esL+6oL6+kxAngFrt8jeIYX0TdtkTbMydc0iqskndVJKI6Tc0RM23MjeR1Ym0YTLqqgbQopQyRC1s92/7NI7Ax4vGRXayEdWOYpIpEbbOMm93eiHQiLX/8we73OILDNbiejsvnJdZWeo9sPjKdAgKM9GulCIlhsRfz/FL7fpT6B3cn0da5XKW2lV8HZ0dU7h+Ngaykp8IUppMqx4GoZPKS46rOo/hUMtRvfC8HSQ6q5gOMvru9ijPlnpjBQ81I2wvMSz3mPyb00V6z+sE15/mAozwC4Vf7oGRWgOk3bKKu5SvOousgBl6N58q+2da2KyBIEAFE/luq8J5plhQbUXDSxkCo70CFtlr/KTF+omyf1fN28oUp2MKVY5SY8KcC/7D7S7U1jFjQvDJseI487pAjcrtK77kpq7Jy09iTnhiUjqgoAghn71a+AF2Z5FHtKku3u0l6atD4aRxqpZysSpuFQIIuf1kbqn005s7za1JhEbcJ/NSumN95wYv4U5viZCobkJ9Fvn+nZTx9u7osa64w1xag6wh6xZ6FjVSjYL4fHwT+ydqswBg4hEwfoeJGa9zOq7YA== x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PH0PR11MB4885.namprd11.prod.outlook.com;PTR:;CAT:NONE;SFS:(4636009)(346002)(366004)(396003)(39860400002)(376002)(136003)(76116006)(66946007)(66476007)(4326008)(316002)(38070700005)(54906003)(52536014)(110136005)(66556008)(64756008)(66446008)(5660300002)(33656002)(71200400001)(2906002)(83380400001)(8676002)(7696005)(26005)(478600001)(53546011)(122000001)(966005)(6506007)(8936002)(38100700002)(86362001)(55016002)(9686003)(186003);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?JOEHDhpcGSZNJtjkRJdS1CmwuO8WcwpnZMk0AeGJWtcpjDTlQOb1uBST0fL9?= =?us-ascii?Q?YOuy4beqpsiLa4HjBe9CBFbKJnba1vO39s3YHTfx+Yj6sLE7feW+Es+o9S9R?= =?us-ascii?Q?P0wBJug3HKTRSdQODpYAdKeFPGQ5QV7PyBeyMNcKFFk5bsa7zwWzYhp6l5qk?= =?us-ascii?Q?+AmVJs3Gid6b0BcWvBou94cFhgumfBFAT0UFjD5UoDMgfUGHwDMHcgiyCvej?= =?us-ascii?Q?0zfWWdqJkC8etituMjcmzM+Bu8q24AnED6ahyyC0PiXg1p6CMWD3nWJhVIaq?= =?us-ascii?Q?0oguwz4NHFN1vmeFPNfZqHIl6JvnQDyMWdH84Jo+Qc5oGvxwXgORyuPjbGVI?= =?us-ascii?Q?9XW00U2WJIk9EZqBHHXxDvAILH1LM2K2zzR2oPbERNlu6uuWpewd4RiM1MUx?= =?us-ascii?Q?4ws/zBnlrEW7ZO9XVQK43eERMm2FkoHQLpBCaMLOC8L+2pVIEfECbeLBas4d?= =?us-ascii?Q?uR+hUCQClZyin1sFT6qN0yyqqyEpsjd9LyQiy4O0lCm4anmfRGdfihFmXvNJ?= =?us-ascii?Q?f9Wsw3PHni7ts9ea7rDcVkW5JxW1B3iKBjDh1IltJirsSDKB5bAEhORTkwV3?= =?us-ascii?Q?YA7c0iG4iCZaT2kddf0M47zKyhkHEfbJYNvjEQWXOcdQmNdStlcm4NG0+w1Z?= =?us-ascii?Q?A/intLuWWU0OLcQS45oAaWSFE9eFfWlQxx4bqeVAqdgbT5va0SSbHklTB5Uk?= =?us-ascii?Q?f5IMoT/Hv2/H6lH06twG+7C8gHcPGRilGr2NSSDbX6Rr6uCEjjkPloQJ8nZV?= =?us-ascii?Q?jag6o9eUeH+bVewcMwsgfNq9cvlgwGd6kQOun84Li+fbiaviDLbWhe6A24sv?= =?us-ascii?Q?VeirXMQ5qUuZq+DdzB7xAPDDcc1+onjNVWhStDv67JdW7m7NFXVvxCKGxCQJ?= =?us-ascii?Q?gQQybSWPoBdkaYLeTUlHq4RS29MmwjfIJkks9Ak2CLlHzPhQ1j9lnVc+fa3q?= =?us-ascii?Q?GYIe7UeIQ2uJIbsUcH8N+75pL0CwidPcml8kI2K1/OBmDiGgbghoDX+oe0UE?= =?us-ascii?Q?Gz5K36asU+IzK3MNXjCCQgY9vQNU9cMQbFgkzqHVCeYAtk0EQyNeXj9iL9B1?= =?us-ascii?Q?C69SlCuzlItwAg5tbovYT5sDfuzXqhMoOlHtMfGlx4E78/N4Z6ILNSvSA3/Z?= =?us-ascii?Q?fYCLgrvtCM5YsQ0jucrj5x1RWCos1GVp9UpaH3sYaZY2TOnoad/u4aGdky1K?= =?us-ascii?Q?URJTphuAJwsdEHNgy4nju3eVYOPactqxk7FFTsLPM8uNzdhQattw+tHiMySf?= =?us-ascii?Q?1W5KZqR6bfHCHAAjgmjKYPupsDlvX0Vt1cou9+jeP4sP7cwXNysSedcOr9te?= =?us-ascii?Q?hP9k8sp/2r1a+UZQ4nDq+w6Q?= MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: PH0PR11MB4885.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: b5a1c571-deb8-48d3-991c-08d967a7ba6d X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Aug 2021 09:07:13.2917 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 46c98d88-e344-4ed4-8496-4ed7712e255d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: XV1ExkRGcImI8f0RVsGQbC/JqjfMgGv1Ik+s9TrGh20T/QQuft3KhxqjV4Ca4NpoxNjAkqmfIf/xnNg3rHAKWg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR11MB4997 Return-Path: jiewen.yao@intel.com X-OriginatorOrg: intel.com Content-Language: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Comment below: > -----Original Message----- > From: devel@edk2.groups.io On Behalf Of Gerd > Hoffmann > Sent: Wednesday, August 25, 2021 3:52 PM > To: Yao, Jiewen > Cc: Ard Biesheuvel ; Xu, Min M ; > devel@edk2.groups.io; Ard Biesheuvel ; Justen, > Jordan L ; Brijesh Singh ; > Erdem Aktas ; James Bottomley > ; Tom Lendacky > Subject: Re: [edk2-devel] [PATCH 18/23] OvmfPkg: Enable Tdx in SecMain.c >=20 > Hi, >=20 > > fw_cfg is just a KVM/QEMU specific way to pass some parameter, but not > > all parameter. For example, OVMF today still get the memory size from > > CMOS. > > > https://github.com/tianocore/edk2/blob/master/OvmfPkg/PlatformPei/MemDe > tect.c#L278 >=20 > Patches to fix that are on the list. [Jiewen] Surprisingly. It was sent one week ago. I obviously miss that email. Please file a Bugzilla and include me in CC list next time. >=20 > > In TDVF design, we choose the use TDX defined initial pointer to pass > > the initial memory information - TD_HOB, instead of CMOS region. > > Please help me understand what is the real concern here. >=20 > Well, qemu settled to the fw_cfg design or a number of reasons. It is > pretty flexible for example. The firmware can ask for the information > it needs at any time and can store it as it pleases. >=20 > I'd suggest to not take it for granted that an additional alternative > way to do basically the same thing will be accepted to upstream qemu. > Submit your patches to qemu-devel to discuss that. [Jiewen] I think Intel Linux team is doing that separately. >=20 > > That means, if you get the same data twice from the fw_cfg, the TDVF > > must measure them twice. And TDVF may need handle the case that the > > data in first call is different with the data in second call. >=20 > Most fw_cfg entries are constant anyway, so we can easily avoid a second > call by caching the results of the first call if that helps TDVF. [Jiewen] It is possible. We can have multiple ways: 1) Per usage cache. However, that means every driver need use its own way t= o cache the data, either PCD or HOB in PEI phase. Also driver A need to kno= w clearly that driver B will use the same data, then it will cache otherwis= e it will not cache. I treat it as a huge burden for the developer. 2) Always cache per driver. That means every driver need follow the same pa= ttern: search cache, if miss the get it and cache it. But it still cannot g= uarantee the data order in different path architecturally. 3) Always cache in one common driver. One driver can get all data one time = and cache them. That can resolve the data order problem. I am not sure if t= hat is desired. But I cannot see too much difference between passing data a= t entry point. >=20 > > Using HOB in the initial pointer can be an alternative pattern to > > mitigate such risk. We just need measure them once then any component > > can use that. Also, it can help the people to evaluate the RTMR hash > > and TD event log data for the configuration in attestation flow, > > because the configuration is independent with the code execution flow. >=20 > Well, it covers only the memory map, correct? All other configuration > is still loaded from fw_cfg. I can't see the improvement here. [Jiewen] At this point of time, memory map is the most important parameter = in the TD Hob, because we do need the memory information at the TD entrypoi= nt. That is mandatory for any TD boot. The fw_cfg is still allowed in the TDVF design guide, just because we feel = it is a burden to convert everything suddenly. I hope to limit the configuration from VMM. Most fw_cfg will NOT be used fo= r TDVF, for example, "etc/smi", "etc/tpm", "etc/edk2/https/cacerts", "etc/m= sr_feature_control", "etc/system-states", especially in the container use c= ase. The flexibility is a double-sward. You can treat the TD Hob as the boot parameter for the kernel, here is the = kernel =3D=3D TDVF. Having a static way to get configuration data in memory at one time is the = simplest solution, from my perspective.=20 >=20 > How do you pass the HOB to the guest? Copy data to guest ram? Map a > ro page into guest address space? What happens on VM reset? [Jiewen] Yes, VMM will prepare the memory information based upon TDVF metad= ata. The VMM need copy TD HOB data to a predefined memory region according to TD= VF metadata. I don't fully understand the VM reset question. I try to answer. But if tha= t is not what you are asking, please clarify. This action that VMM initiates TD HOB happens when the VMM launches a TD gu= est. After that the region will becomes TD private memory and own by TD. VMM can= no longer access it (no read/no write). If VM reset, then this memory is gone. If VMM need launch a new TD, the VMM need initiate the data again. >=20 > > Please be aware that confidential computing (TDX) changes the threat > > model completely, any input from VMM is considered as malicious. > > Current solution might be OK for normal OVMF. But it does not mean the > > same solution is still the best one for confidential computing use > > case. >=20 > Well, SEV seems to be happy with fw_cfg. > Any input from AMD on the topic? >=20 > take care, > Gerd >=20 >=20 >=20 >=20 >=20