From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by mx.groups.io with SMTP id smtpd.web10.17596.1629908939774230336 for ; Wed, 25 Aug 2021 09:29:00 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@intel.onmicrosoft.com header.s=selector2-intel-onmicrosoft-com header.b=TQmAdzQs; spf=pass (domain: intel.com, ip: 134.134.136.24, mailfrom: jiewen.yao@intel.com) X-IronPort-AV: E=McAfee;i="6200,9189,10087"; a="217564150" X-IronPort-AV: E=Sophos;i="5.84,351,1620716400"; d="scan'208";a="217564150" Received: from fmsmga006.fm.intel.com ([10.253.24.20]) by orsmga102.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 25 Aug 2021 09:28:59 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.84,351,1620716400"; d="scan'208";a="684571382" Received: from fmsmsx604.amr.corp.intel.com ([10.18.126.84]) by fmsmga006.fm.intel.com with ESMTP; 25 Aug 2021 09:28:58 -0700 Received: from fmsmsx601.amr.corp.intel.com (10.18.126.81) by fmsmsx604.amr.corp.intel.com (10.18.126.84) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2242.10; Wed, 25 Aug 2021 09:28:57 -0700 Received: from fmsedg602.ED.cps.intel.com (10.1.192.136) by fmsmsx601.amr.corp.intel.com (10.18.126.81) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2242.10 via Frontend Transport; Wed, 25 Aug 2021 09:28:57 -0700 Received: from NAM12-BN8-obe.outbound.protection.outlook.com (104.47.55.175) 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 09:28:56 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=BVTmm3v8k20VubXcgjuYnE9xxC4a3EKE/F2/QT4HGGpi4WMk6+q1IOgw60xnZZcO6PE6MK5Otrg+fEKZxmQjf+k5sZ6UO+0x1mbbXmEzKoJUq9MxIQq3ekId1G5a8CY1+BsrLBIW8OUeAImphpJpn9J1gvQPx2RN55eZftVbcxrH2QFSeD+7DfeT6rPK1+cDJSMti14uYhqXXW6nR1Vel99AAF3YAa9qdgxf6JTNu9jdSbKaTIh2YntcDVI7K1/jzvL/4Rt8d8ZIjkPoTIDztUvkZ4lTvIicRPfgWi8HjaZCiflTYkIyemiBiTcSqeUFlFTRvC/GQ5RrbMRKfPs0UA== 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=kcjVo5VZmEFmAMkbjwDu2d2Ozcxy+3hVi8mNJzgayw4=; b=hY/LPnZYTx6od8mlpZqMYkDHIp4Fb0VNn5hLItZBlxIDxrrtf3cSldyPP5NPC1Lzy4IaJxrsjChskJWzBaxRZHcUYYohR2TkeX1TqW10rccmIXlu3gIiJ8jYlskf1H/St0EFhg1UiQj6wHZQSLDmvajPRYjbJ4Y/Jci+Luq7/lMsZrmB4PhJTLwvEad0IFVFkcQJHDjveydXsd3T0mdg5ZkABWh4xgrtYIJbYl6ZiOGndchxzRC16GzDV7nAjfoWEmw3XAOBbdSRQuPbOrTyZExkkN3SXPQR+XePAR+zOvKUeoYLJtrWTEPAHXNQlBThExuKd3c2ZP1PY5D6HWBy0A== 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=kcjVo5VZmEFmAMkbjwDu2d2Ozcxy+3hVi8mNJzgayw4=; b=TQmAdzQswI8XAp69jyGQJZeT9shGa59ggzEN+KMG8VxCXJVZ2xrNDXR+xwogTKmjsg4Oz7E1aRtMChuQh1SfO2jboQEWfYbQBEuEIDNZUtRBoBgnXGlcVHX65i+KmX/e4TDfGNaKmOqEoANklihB0FXZtkwKv6n+oFw8PqU33oY= Received: from PH0PR11MB4885.namprd11.prod.outlook.com (2603:10b6:510:35::14) by PH0PR11MB4920.namprd11.prod.outlook.com (2603:10b6:510:41::22) 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 16:28:51 +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 16:28:51 +0000 From: "Yao, Jiewen" To: "kraxel@redhat.com" CC: "devel@edk2.groups.io" , Ard Biesheuvel , "Xu, Min M" , Ard Biesheuvel , "Justen, Jordan L" , Brijesh Singh , Erdem Aktas , James Bottomley , Tom Lendacky , "Yamahata, Isaku" 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/3gCAARvDgIAGmLcAgAANpQCAARgVkIAAJW8AgAADM8CAAHH8gIAACJBw Date: Wed, 25 Aug 2021 16:28:51 +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> <20210825145143.rp3gqcqzd6fktkjk@sirius.home.kraxel.org> In-Reply-To: <20210825145143.rp3gqcqzd6fktkjk@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: redhat.com; dkim=none (message not signed) header.d=none;redhat.com; dmarc=none action=none header.from=intel.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: f1aeac0e-e89a-43c5-96e3-08d967e56c59 x-ms-traffictypediagnostic: PH0PR11MB4920: 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: tZUuqTVUnQzlDaTk0mmPtxlvdZ9TZmuMv69e6nqnIGlnQfnEIdmY73NxdhPrDAb9HBqq+fAaJ+OZppGj8uW0+FugISvgQF+LDA5qaW3qMJQtGhPV2q/ORp4aQa2LHKXJg9Jv00Os3hvzFMmLl860sEvwn62YzUD72qkIg4HbQy5QDlEPC6cpVLEPA6TqpODBPPwBbxWZkeLeMnf80IcbClE11nuqPMxjSGMS7WC4Qbfito2/9xfkp89qvhclGQeya7QS6FKNTC9CLJNoaT2dXbEW3+wwB50PlXKGDpRl1lHwaCeVkQWthQ36HttVWOCvPYgO4QxdZHWQq4y3mrLqAO+PLR2ugkeswB5u7e10AoqD9chPdXL6p6FOf5l9LqvJM5bt0Fm4lKSlkDL9Axl1DvgYONHKZPIGQKYkKMsIJmrheSHge8U2mg8io8jS1Na+/Hhvk+ihRcD5Bz7h5jQ46qAAy8ozycL221SEld/03jFD/YdkL/syO6L8eHVty10rMM34sGuDd2D8RUKs0lRpapdGB9dOhgBfmRW6yqrBFZ/rinEcKoJeyvGrhBR34yKdwyiqEFVq9vdUur++mjydby17O21VMx7ST6ov826lKpDNa0nK7BN2h/0nhcEmPThdJKAJRFQfNLc6Scv1gYp2dxLnK5KS2wTeZ4tRCs/E3yBb7p2HPbct8CM/Wku7P/7O0VaEUX+zS+UpKR7VeIz6pbzXD8uSiBuA7qHJEwkFKCvy1z2lYd2oLx6IMYdlOE3ENObr8/SQglS/0U6DzD4IfiSxh+L75SKfUgWN7CwKtvmeRW8uDNQKpIyxkgQ2v9k/f5qhZKmSgWRBVNz6bYfL9Q== 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)(366004)(71200400001)(4326008)(53546011)(55016002)(83380400001)(6506007)(5660300002)(66476007)(186003)(52536014)(966005)(66446008)(76116006)(54906003)(66556008)(64756008)(38070700005)(7696005)(508600001)(66946007)(107886003)(8936002)(8676002)(33656002)(9686003)(38100700002)(122000001)(86362001)(316002)(6916009)(2906002)(26005);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?k7pWpmp6QGRoOCe6rTxRrpEM0TMt0EHVRwIImRm6X5Ep0/WFE+vOQxvajWzJ?= =?us-ascii?Q?9bXHJvrVbWnd0GslFmgXiqENun+FTYedIlzm1T8kLBnqFv2C68382/qO6GqW?= =?us-ascii?Q?Cb7FXjam+LlfGM8rN4C7+fJ4vVVUiTX1/ax0j9LJ/ENiQfSTqewcz1EunRP8?= =?us-ascii?Q?7QUTsU0RRXp80SxhPyVqX6alVOHKLbMkfzLjBLp7TfXLKpSYIcC4WOkqDuTC?= =?us-ascii?Q?jooo6hOziRiwkWTjSWiQ9A4pwH1JH4/okO9T7pUXeAlMdgwgPk461ybdAA9N?= =?us-ascii?Q?kO3HFcW+Msrivn8d4p/cuh9M8lFhIX4vruDGz4xL68+sWvCfO6aBEsQN0bZv?= =?us-ascii?Q?ARl0TF9EYJNSydqzHo91hD6DSg4zU4ul2GAGOX+08qYwoeR4bGUUcNcoECu5?= =?us-ascii?Q?VEMsCDtDWE5tMURdsY9x+2q4MhHHWZToVTyUn4DoQmnZzSi1fua2LiDpAgJb?= =?us-ascii?Q?BoDf2iumUxfzz9K+0K82YCqnvWwn3rTZW0hsZmu5b5YBTd5EEe42Z5YItL/C?= =?us-ascii?Q?DFwKHUF9NfyLuuxqhBDDO2cY72piNXqeBA/VfrowTzNtZ76CN+AW/6t26XcK?= =?us-ascii?Q?IOnSSo9dVz4Ua57TJvnIWbR9P0DZ4ghxSELooQs/MsjcSltTgGn55MjQg2LF?= =?us-ascii?Q?EN2iNST3XZCL/orbJzq4A99nKHs74Fx4qE8Jug/Q2bpdYkXzvyWnPsFp8XVN?= =?us-ascii?Q?Fm0+3coeMzx6RJaYm0JysrxGPfDr7k03jGwrKa1oTApoq0sNCqfc/LEcISG6?= =?us-ascii?Q?eqWLjVtIRuBOSH0XvsmpMsfKeAUTIfHCGVaSX21QdTO1F/bB+5JSPz8aX/7h?= =?us-ascii?Q?zYu8sZ1GizekJaH7wS7j1Nk5cBUDmjIjvFfOd5DPFDkWLnyIo7zNdzYmVhCN?= =?us-ascii?Q?RwChIwnMt4jWwm9qCeYSQ+XOeG5jLDOUzKxulcq10s98P6NZG7ngvBjR50tW?= =?us-ascii?Q?L+zQAxehKSWM7QZ/B5lPaI8DkMnpHKTawV3yU33KNkCVI4lTGZA+Noz11pPI?= =?us-ascii?Q?v1tVcQsUUi0NbTmpoGdr4/Y/ukgUNmXTxVxZHygUCmMbCA4mTjKEAh07qba/?= =?us-ascii?Q?3OfCZE6363vMQEJMt00T9T0XU+UqkVs0Q9QSfnKYyoqqno1XcuuAAO+M0X+0?= =?us-ascii?Q?1P0Vv/Vny/v9UAFHqeHB4Q89trwLEAaQ4gC+PGgWGCbrr94ow3jHLDDBVFcA?= =?us-ascii?Q?ZZJh6rGEF3ehy+d287mCfoCbP7FQZFY1vEeo5QeakuRIATRXga0m6eq2ZOkL?= =?us-ascii?Q?4A4X6nSwQ5CJOWmKjXGZMybNKvMVSla3YPcYC3n8vA434Rmtwp/cDgspHfqJ?= =?us-ascii?Q?8WmXfhEyVEVHZFE9mZaeg99U?= 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: f1aeac0e-e89a-43c5-96e3-08d967e56c59 X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Aug 2021 16:28:51.1035 (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: pMwhVw3/+zhr6MCNAAC4EVmd9mT18isiGjsIPGiLUvLQqPFeQf6k5W4Pxup74KoytO1h0rsNHuJdVFBHVh4KLg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR11MB4920 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: kraxel@redhat.com > Sent: Wednesday, August 25, 2021 10:52 PM > To: Yao, Jiewen > Cc: devel@edk2.groups.io; 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 >=20 > Hi, >=20 > > > > In TDVF design, we choose the use TDX defined initial pointer to pa= ss > > > > the initial memory information - TD_HOB, instead of CMOS region. > > > > Please help me understand what is the real concern here. > > > > > > Well, qemu settled to the fw_cfg design or a number of reasons. It i= s > > > pretty flexible for example. The firmware can ask for the informatio= n > > > it needs at any time and can store it as it pleases. > > > > > > 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 > Please ask them to send the patches. Changes like this obviously need > coordination and agreement between qemu and edk2 projects, and ideally > both guest and host code is reviewed in parallel. [Jiewen] Sure. I add Yamahata, Isaku here. He can help answer t= he KVM/QEMU related question. Some reference for QEMU: https://lists.nongnu.org/archive/html/qemu-devel/2021-07/msg01682.html in patchwork, https://patchwork.kernel.org/project/qemu-devel/cover/cover.1= 625704980.git.isaku.yamahata@intel.com/ And I guess you probably need look at the KVM as well. >=20 > > > Most fw_cfg entries are constant anyway, so we can easily avoid a sec= ond > > > 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 w= ay to > 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 sam= e > pattern: search cache, if miss the get it and cache it. But it still cann= ot guarantee > the data order in different path architecturally. > > 3) Always cache in one common driver. One driver can get all data one t= ime > and cache them. That can resolve the data order problem. I am not sure if= that is > desired. But I cannot see too much difference between passing data at ent= ry > point. >=20 > Not investigated yet. seabios fw_cfg handling is close to (3) for small > items (not kernel or initrd or other large data sets) so I think I would > look into that first. [Jiewen] I don't think it is urgent at this moment. >=20 > > > > Using HOB in the initial pointer can be an alternative pattern to > > > > mitigate such risk. We just need measure them once then any compone= nt > > > > can use that. Also, it can help the people to evaluate the RTMR has= h > > > > and TD event log data for the configuration in attestation flow, > > > > because the configuration is independent with the code execution fl= ow. > > > > > > Well, it covers only the memory map, correct? All other configuratio= n > > > 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 entrypoint. That is mandatory for any TD boot. >=20 > Well, I can see that the memory map is kind of special here because you > need that quite early in the firmware initialization workflow. [Jiewen] That is correct. >=20 > > The fw_cfg is still allowed in the TDVF design guide, just because we > > feel it is a burden to convert everything suddenly. >=20 > What is the longer-term plan here? >=20 > Does it make sense to special-case the memory map? >=20 > If we want handle other fw_cfg items that way too later on, shouldn't we > better check how we can improve the fw_cfg interface so it works better > with confidential computing? [Jiewen] So far, my hope is to limit the fw_cfg as much as possible. My worry is that we have to measure fw_cfg everywhere. If we miss one place= , it will be a completeness vulnerability for trusted computing. I also think if we can add measurement code inside of fw_cfg get function. Then we need improve the FwCfg API - Current style: QemuFwCfgSelectItem() += QemuFwCfgReadxxx() is not friendly for measurement. For example, we can co= mbine them and do QemuFwCfgSelectRead (). The QemuFwCfgWritexxx() interface may also bring inconsistency issue. If we= use this API, we have 2 copy data. One is in TDVF (trusted), and the other= is in VMM/QEMU (untrusted). What if the VMM modifies its untrusted copy? What I can see is many potential attack surfaces. :-( >=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? >=20 > > [Jiewen] Yes, VMM will prepare the memory information based upon TDVF > > metadata. The VMM need copy TD HOB data to a predefined memory region > > according to TDVF metadata. >=20 > Is all that documented somewhere? The TVDF design overview focuses on > the guest/firmware side of things, so it isn't very helpful here. [Jiewen] The TDX architecture define this architecture way, the RCX/R9 refe= r is the pointer. We have a couple of TDX document at https://software.intel.com/content/www/= us/en/develop/articles/intel-trust-domain-extensions.html https://software.intel.com/content/dam/develop/external/us/en/documents/tdx= -module-1eas-v0.85.039.pdf Section 8.1 defines the VCPU init state. The RCX/R8 hold the launch paramet= er. https://software.intel.com/content/dam/develop/external/us/en/documents/tdx= -virtual-firmware-design-guide-rev-1.pdf Section 4.1.2 describes the TD HOB usage for RCX/R8. Section 7 adds more de= tail on memory map reporting. Please let me know if you need any other information. >=20 > Did I mention posting the qemu patches would be a good idea? >=20 > > I don't fully understand the VM reset question. I try to answer. But if= that is not > what you are asking, please clarify. >=20 > What happens if you reboot the guest? >=20 > On non-TDX guests the VM will be reset, the cpu will jump to the reset > vector (executing from rom / flash), firmware will re-initialize > everything and re-load any config information it needs from fw_cfg >=20 > > This action that VMM initiates TD HOB happens when the VMM launches a T= D > guest. > > 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 > Sounds like reset is not supported, you need to stop and re-start the > guest instead. Is that correct? [Jiewen] That is correct. In our definition, reset =3D=3D stop + restart. >=20 > take care, > Gerd