From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by mx.groups.io with SMTP id smtpd.web12.5400.1631591382669518804 for ; Mon, 13 Sep 2021 20:49:43 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@intel.onmicrosoft.com header.s=selector2-intel-onmicrosoft-com header.b=jFp0i/yB; spf=pass (domain: intel.com, ip: 192.55.52.88, mailfrom: jiewen.yao@intel.com) X-IronPort-AV: E=McAfee;i="6200,9189,10106"; a="244196088" X-IronPort-AV: E=Sophos;i="5.85,291,1624345200"; d="scan'208";a="244196088" Received: from orsmga003.jf.intel.com ([10.7.209.27]) by fmsmga101.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 13 Sep 2021 20:49:41 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.85,291,1624345200"; d="scan'208";a="433499761" Received: from fmsmsx602.amr.corp.intel.com ([10.18.126.82]) by orsmga003.jf.intel.com with ESMTP; 13 Sep 2021 20:49:41 -0700 Received: from fmsmsx610.amr.corp.intel.com (10.18.126.90) by fmsmsx602.amr.corp.intel.com (10.18.126.82) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2242.12; Mon, 13 Sep 2021 20:49:40 -0700 Received: from fmsmsx610.amr.corp.intel.com (10.18.126.90) by fmsmsx610.amr.corp.intel.com (10.18.126.90) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2242.12; Mon, 13 Sep 2021 20:49:40 -0700 Received: from fmsedg601.ED.cps.intel.com (10.1.192.135) by fmsmsx610.amr.corp.intel.com (10.18.126.90) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2242.12 via Frontend Transport; Mon, 13 Sep 2021 20:49:40 -0700 Received: from NAM10-BN7-obe.outbound.protection.outlook.com (104.47.70.100) by edgegateway.intel.com (192.55.55.70) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2242.12; Mon, 13 Sep 2021 20:49:39 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=VrLTHPg2RVhDox33h48DAqMnRxKB8FNRcLcdAh+8+adg84KmrE1qQjaLKtY1edaMta28Gt0P7dQ59cNFB9qpEX+K/1jGJarnimHc4HU+iaw577sORWvxscy+1K1ey4y+cHo124mGZu1yspLEQW0SNltSLXUno/Vlyq6zZ9SMq+76AlhI/mNC6yiKJL9ERVSGKxZbRqolvLpEhEFEJQkNhnt/A2Thnos6DbsTj1HmqWUhBFwU50Ba5KuZmrAXSwC3C/Oalu/lO6OeTR34UJNvJYurxtx1IJCIHf61xz4VJl1a7ClXJ4ScCd+cquXsCSnOYn+/LzAZxN1nxUQPxngQtg== 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; bh=f8YomQFgEapqmvZtJ3HzB6M8zp4+qDXDehhulWOnfjM=; b=JISbKqOKh71m3F6qnFb2iu8hMYn56A/reI5TCwIloiiDvvG+A3Q2AJbqNE8eWsGKKJMvxSEPZCiUOFdLI3uUBOX4QWrHxCWRhdqAULWfHq47Ks6sh2k65K9IhzYvavx8z1XDvkUfNnTdl3bwz50jS9BKwqY68+31vlFuaT4gvlXiW8jUiI9HgQJPm/vPHyM+g81Rg0W7hsRsi+OTXs7Dw4nLtVnzAz4trvLkiSlinxWwml9OJIu9FzaA6bhk4ab5xWYRBc6Mh9+H28Boun3GxB0wSrIo0AhTVVHSwObPxcuZ14uSXnpx4lN5rCj2tBaPbMLxippKOamLZlooE+6BSA== 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=f8YomQFgEapqmvZtJ3HzB6M8zp4+qDXDehhulWOnfjM=; b=jFp0i/yBu0UgArJjzv/5DHyOisVRSA2oOwD0kjKC1B4HHtdxzV6/Fcb9s1GEYs+ofmG70eEYyTZ4n5O5eK9lOdYWf59qhBZCCTbweAToZ9Gskf3ukxIC9dlFnnYprsWbjeqX6v9BwUm//SlHhob1TUKIjmwrpSEGbtE0TDiAggU= Received: from PH0PR11MB4885.namprd11.prod.outlook.com (2603:10b6:510:35::14) by PH0PR11MB4982.namprd11.prod.outlook.com (2603:10b6:510:37::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4500.17; Tue, 14 Sep 2021 03:49:31 +0000 Received: from PH0PR11MB4885.namprd11.prod.outlook.com ([fe80::754e:42e9:16cd:1306]) by PH0PR11MB4885.namprd11.prod.outlook.com ([fe80::754e:42e9:16cd:1306%7]) with mapi id 15.20.4500.019; Tue, 14 Sep 2021 03:49:31 +0000 From: "Yao, Jiewen" To: "devel@edk2.groups.io" , "kraxel@redhat.com" , "Xu, Min M" CC: Brijesh Singh , James Bottomley , Tom Lendacky , "Justen, Jordan L" , Ard Biesheuvel , Erdem Aktas , Michael Roth Subject: Re: [edk2-devel] [PATCH v6 06/29] OvmfPkg/ResetVector: pre-validate the data pages used in SEC phase Thread-Topic: [edk2-devel] [PATCH v6 06/29] OvmfPkg/ResetVector: pre-validate the data pages used in SEC phase Thread-Index: AQHXn00Xnf9GtccuQU2BS8Sh0jQvAKuQaC2AgAXRNwCAALolAIAAEYAAgAEqagCACsZu4A== Date: Tue, 14 Sep 2021 03:49:31 +0000 Message-ID: References: <20210901161646.24763-1-brijesh.singh@amd.com> <20210901161646.24763-7-brijesh.singh@amd.com> <20210902082029.tfdt4s5s76qknpiq@sirius.home.kraxel.org> <20210906121650.vwgt5y5hdwxfugvh@sirius.home.kraxel.org> <20210907070732.xcokfdn5iw3wyqbu@sirius.home.kraxel.org> In-Reply-To: <20210907070732.xcokfdn5iw3wyqbu@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: timeout-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: 7ea533ff-5f09-4e6f-a1c0-08d97732a8ff x-ms-traffictypediagnostic: PH0PR11MB4982: 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: 0SjCBC7Kf2IiwjFYNjE+kyzKK9uLb/rtPGaasIwUAogALqOKfTCJrLOdrDW8V5a/0Z+midEtMaCOaBLGVDD9097i++9FIZWmcaMkkNJYE8lYOOL9G8OrzrHStk0eEBlYneAYdIUN3cDiHSbEa5rfl3c3LdFGaqIw3VKFECKwg7xWWeeryMEWy+99puojwRW1xP8qKe0FIKzdp1OMgz+1kn3BJVXBrVUpeHUMjLLGkHqmhsCyb/S4w0Es4XB1abO/cG+zE6OK+kZv6PFZYPLFDmMN/Lx9BsAEu3TffflPO/XhXquERwRlJ3xB4Dw/hl9wBuVIXRs1AVAZr1SZquH3XSUOThcXYJsyfFnYTXClxPps7cxcBzrNPkU+3+QpnFbG7FJ4QPE3kvRaM7t6JHhdwyqmy2PFwaWGfPirlDjn/N0qsj/59j8Vhdm+BMLl6ogi3fUBdaUGA1CrEgORYeCn5I046ueI/F7dcklEei0k5fSOcJa/PZMB5W+jQZLLCYyQSLVrSzTT4Lw6qDqXz+5q7+yo1yx+3VoJNDuXI1YiOpabgSq0Ug7UtHl0TrdF0IHKKyfEtYMV6kIs7HFYqtuQBdQ3rsUSP9Cmp82xFFt/9PlKTRq8N60OSimYs/goPU72i/Jx4KB0UjpS2iSe2pD4jzKI0f35t6EfRxJIGd9pTLxvC2u3nCprJgppGg+VZCMSSt2T0xFs6x0N7BLJ/yqTt2U49b0tVZMri1iGViWAhaFuyH+7I1gc6KDyrrtQvlMmTcmjtOXk82m0te4hhD2wuzzw5QLeWh7lgb/nnnFXtWWeXamnjnuJrvL1gXNuf0RmUfKuFKgc9AXlXqz8uK9JNQ== 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)(396003)(346002)(376002)(136003)(39860400002)(366004)(8936002)(478600001)(52536014)(83380400001)(186003)(55016002)(26005)(122000001)(38100700002)(71200400001)(8676002)(66446008)(7696005)(5660300002)(38070700005)(6636002)(6506007)(966005)(110136005)(54906003)(53546011)(15650500001)(86362001)(2906002)(4326008)(66476007)(66556008)(64756008)(66946007)(76116006)(9686003)(316002)(33656002);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?fiVJJeSJH/RbGXymZdnozmietO6OLbHtCHFf0p9E+ASHcPvi5LdZ+dwv1kbL?= =?us-ascii?Q?lRqmYUVBigJjharU2twtRvMx6GlxewvLtws0HUG4TfDWhojJLOjubWocQDmO?= =?us-ascii?Q?nIdUaq3G4kHeb4swuncLRspYcrg1/LICvsG+IsYvDlBdpZKPFxy3OmePyQSA?= =?us-ascii?Q?1Tz8TIlQjApxpf+OOHO7shkfyChC9R0uCpemUuaDbbF7U1hPdRQr67vwy7LT?= =?us-ascii?Q?TzWQEkTPiu38SVFS3YXQIzg610FYoRBvl2r7XHVP6b5Ef7PzHuF2fAcqoVwj?= =?us-ascii?Q?lSL0546DfxUDZsm8yJqq3YrQDyfh9DDIGojF2khCU8Xn7oLF+rGeHA8PAxEJ?= =?us-ascii?Q?bBHi0/oFbPRgRroc686Vll24IyV2ettGAOR0TCE74KVuoiSglwGBJtG4Plz4?= =?us-ascii?Q?7iAHMTx+l+hNsO2K/RD+B0WCATtR009iuzH/j4RruosrQCxfZK4H2Mo7k6Hd?= =?us-ascii?Q?VEIizQV4OTSrlqQ3SupLGD5mIt7gvhrk3xSkWv410IgBVmzFqi7x7hrjHTKZ?= =?us-ascii?Q?0IRqzjT4eP24PgsNri0anmyF8Fv4ZIWg+E4G8rNLNzSYiuwY5S7oyDGalqN5?= =?us-ascii?Q?fc/whckjopJA2GOec952b1ATBOq5emfusYS8ac9gsOGYsswY+wPxDWPcR0k9?= =?us-ascii?Q?54gCRccaRWIuNbne8P+TuwJCceLQPSNZhsj+LZTVB6VkqiEsKNlDGOEjpyw9?= =?us-ascii?Q?LkUsFhE5jfRmKJ9n3mLMXSI2dYVJcBOI3Twe11R00IFfm81LPe2ADVzYZf1b?= =?us-ascii?Q?GApsuZccVIlkC4ZQxIuEMQ64s1b5urIQPe/VxinLSKiOubtcM/THulyyP0+N?= =?us-ascii?Q?IGN8FOz3s0hErtCACSpwPfKmVldZTZUrVnbEiZaS/q1p8a23iVTVRqqqGHck?= =?us-ascii?Q?L7Zron5RZH/QlawvJN/5Smzm8/7LRwvBdb/9fAvPW5qqI4NGKEonRlf5BJze?= =?us-ascii?Q?yty85FvciIzn95W3tgBn1y6Oktdj04ehVozDrcbMaoz40vWxhE2ZISNfgyop?= =?us-ascii?Q?Opdt+bot0/J3/pQ+HQOsJRcDhc4FFLZ8y9z/BvYJ0onwIjuMKAzXeYlTzdTK?= =?us-ascii?Q?RwjR45YcmLgd/5h9p8+6Rdz9mFYJd8mMfgoDBRUpk2SE38NjHmQUQIuhHuvA?= =?us-ascii?Q?RL0cYaYEdW+okP9sL0cjzJ89Yt4WDK5gHgQEnfem3onVufECguTQ8gLlTW8M?= =?us-ascii?Q?5IS58Odb2lUCbiiqoKT9U0V4juSgpo6LAd/AptJVGnx/RNd2tXsD/ObWmfSg?= =?us-ascii?Q?IIuGNrsvqKBTQw+wSUN37ow0T4zRBMcfSaSB0TXWEFgNEXv6NS3Q0H3ImyPi?= =?us-ascii?Q?sI7WGB9VqmthqjRrFqNla81F?= 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: 7ea533ff-5f09-4e6f-a1c0-08d97732a8ff X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Sep 2021 03:49:31.6274 (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: aJ9N6lRPxXTR43BPngAUdoeYC0zLrkkHLm6OMNbouQWcCSg2Lg5MhUdaQn82QgGn5WvkYJfTJMviQeFwRFwf8w== X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR11MB4982 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 I can explain why we prefer DQ instead of DD. You are right that current TD entrypoint is 32bit. However, we cannot predi= ct that is always TRUE for the future. Back to 16 bit machine, we have entrypoint at F000:FFF0. But in 32bit mode = we removed 1M limitation and move entrypoint to below 4G. There is no limitation that we move 64bit entrypoint above 4G for 64bit mac= hine. We still choose 4G for easy implementation and compatibility consideration. And we still leave room for extension in the future. For example, the firmw= are information table (FIT) defines 64bit address, although only 32bit is u= sed today. (https://software.intel.com/content/dam/develop/external/us/en/d= ocuments/firmware-interface-table-bios-specification-r1p2p1.pdf).=20 Thank you Yao Jiewen > -----Original Message----- > From: devel@edk2.groups.io On Behalf Of Gerd > Hoffmann > Sent: Tuesday, September 7, 2021 3:08 PM > To: Xu, Min M > Cc: devel@edk2.groups.io; Brijesh Singh ; James > Bottomley ; Yao, Jiewen ; Tom > Lendacky ; Justen, Jordan L > ; Ard Biesheuvel ; > Erdem Aktas ; Michael Roth > > Subject: Re: [edk2-devel] [PATCH v6 06/29] OvmfPkg/ResetVector: pre-valid= ate > the data pages used in SEC phase >=20 > Hi, >=20 > > > [ Looking at https://www.mail- > > > archive.com/devel@edk2.groups.io/msg33605.html ] > > > > > > So, there isn't much tdx-specific in tdx-metadata. Most ranges are > > > TDX_METADATA_SECTION_TYPE_TEMP_MEM which I think basically means > > > these ranges should be accepted by the hypervisor, which is pretty mu= ch the > > > same issue snp tries to solve with this pre-validation range. Then t= here are > > > the ranges for code (aka bfv), for vars (aka cfv) and td_hob. > > > > > > td_hob is the only tdx-specific item there, and even that concept (pa= ss > > > memory ranges as hob list from hypervisor to guest) might be useful o= utside > > > tdx. > > Mailbox is tdx-specific too. But Stack/Heap/OvmfWorkarea/OvmfPageTable > are > > common. BFV/CFV are common too. >=20 > Mailbox is tagged "TDX_METADATA_SECTION_TYPE_TEMP_MEM", so nothing > special to do when loading the firmware, right? >=20 > > > I'd suggest we generalize the tdx-metadata idea and define both gener= ic and > > > vmm-specific section types: > > > > > > enum { > > > OVMF_SECTION_TYPE_UNDEFINED =3D 0; > > > > > > /* generic */ > > > OVMF_SECTION_TYPE_CODE =3D 0x100, > > > OVMF_SECTION_TYPE_VARS > > > OVMF_SECTION_TYPE_SEC_MEM /* vmm should accept/validate this */ > > > > > > /* sev */ > > > OVMF_SECTION_TYPE_SEV_SECRETS =3D 0x200, > > > OVMF_SECTION_TYPE_SEV_CPUID /* or move to generic? */ > > > > > > /* tdx */ > > > OVMV_SECTION_TYPE_TDX_TD_HOB =3D 0x300, > > > }; > > > > > > Comments? > > TDX has similar section type. >=20 > Yes. Both TDX and SNP have simliar requirements, they want store memory > ranges in the firmware binary in a way that allows qemu finding them and > using them when initializing the guest. >=20 > SNP stores the ranges directly in the GUID-chained block in the reset > vector. The range types are implicit (first is pre-validate area, > second is cpuid page, ...). >=20 > TDX stores a pointer to tdx-metadata in the GUID-chained block, then the > tdx-metadata has a list of ranges. The ranges are explicitly typed > (section type field). >=20 > The indirection used by TDX keeps the reset vector small. Also the > explicit typing of the ranges makes it easier to extend later on if > needed. >=20 > IMHO SEV should at minimum add explicit types to the memory ranges in > the boot block, but I'd very much prefer it if SEV and TDX can agree > on a way to store the memory ranges. >=20 > > But I am not sure if SEV can use this metadata mechanism. > > Need SEV's comments. >=20 > Brijesh? >=20 > > > Looking at tdx-metadata I have a few questions: > > > > > > +_Bfv: > > > + DD TDX_BFV_RAW_DATA_OFFSET > > > + DD TDX_BFV_RAW_DATA_SIZE > > > > > > What is this and why is it needed? > > Host VMM need to measure the code part (BFV) to MRTD register > > (which is similar to TPM PCRs). >=20 > Sure, but why you can't use TDX_BFV_MEMORY_BASE + > TDX_BFV_MEMORY_SIZE > for that? The tdvf design guide says it is the file offset. The > firmware must be mapped right below 4G, which implies > RAW_DATA_OFFSET + (4G - FIRMWARE_SIZE) =3D=3D MEMORY_BASE. > So having both RAW_DATA_OFFSET and MEMORY_BASE looks redundant to me. >=20 > > > + DQ TDX_BFV_MEMORY_BASE > > > + DQ TDX_BFV_MEMORY_SIZE > > > > > > Why "DQ"? TDX is defined to start in 32bit mode, so you can hardly h= ave > > > addresses here which do not fit into "DD", correct? > > Those are the memory. TDX is running in long mode. So it is DQ. >=20 > Hmm? TDX entry vector is defined to be 32bit. Which pretty much > implies you can't map the firmware above 4G, even if one of the first > actions of the reset vector code is the switch to long mode. >=20 > take care, > Gerd >=20 >=20 >=20 >=20 >=20