From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mga17.intel.com (mga17.intel.com [192.55.52.151]) by mx.groups.io with SMTP id smtpd.web11.7283.1634127203825243819 for ; Wed, 13 Oct 2021 05:13:24 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@intel.onmicrosoft.com header.s=selector2-intel-onmicrosoft-com header.b=Fax5XGFV; spf=pass (domain: intel.com, ip: 192.55.52.151, mailfrom: min.m.xu@intel.com) X-IronPort-AV: E=McAfee;i="6200,9189,10135"; a="208210613" X-IronPort-AV: E=Sophos;i="5.85,370,1624345200"; d="scan'208";a="208210613" Received: from orsmga002.jf.intel.com ([10.7.209.21]) by fmsmga107.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 13 Oct 2021 05:13:22 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.85,370,1624345200"; d="scan'208";a="460751325" Received: from fmsmsx604.amr.corp.intel.com ([10.18.126.84]) by orsmga002.jf.intel.com with ESMTP; 13 Oct 2021 05:13:22 -0700 Received: from fmsmsx608.amr.corp.intel.com (10.18.126.88) 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.12; Wed, 13 Oct 2021 05:13:21 -0700 Received: from fmsmsx602.amr.corp.intel.com (10.18.126.82) by fmsmsx608.amr.corp.intel.com (10.18.126.88) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2242.12; Wed, 13 Oct 2021 05:13:21 -0700 Received: from FMSEDG603.ED.cps.intel.com (10.1.192.133) 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 via Frontend Transport; Wed, 13 Oct 2021 05:13:21 -0700 Received: from NAM11-BN8-obe.outbound.protection.outlook.com (104.47.58.172) by edgegateway.intel.com (192.55.55.68) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2242.12; Wed, 13 Oct 2021 05:13:20 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=mqCtqouBMVsssJ5Vy/cq15Lfzt/xOczhfm2+uqva5HXcKJftrKETy/m7oJPfgU/X1sH6dpSOtdjc8Xlj1yjOyR1/msvB4JIFQev/L+di/40IyNcypIsgTtd35nXHL9jVGAh6/jO7hocGuEuQjFtl06cRODDYnKKcGRCm1QksUaL4I5N+CrAQglnN8ldsqWwAUMltZdrkAM/dqISwBY9wn2qvWT5mNO7utnTrGaOiQuDDfhkACNebtnNSKBfuOtpaY6Mqfs/DJJtqn+aqRFz+dci65Igeo8oWvdBrwJobjc5AUIHVuLOPVx5R0ofKxtx0du5A+jA0t4/8qznABGLa0A== 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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=R3eAlIRYk2BKjEoQCD5BIAANwXZK9bDtM0mZDXplzC0=; b=jPKDoaGOV7T6+Hkc3lgZJmmOpgDeHHJMJfXOi+1Y7FpkqvkMgQ2MhZPchMt3klS1r8J9XVc3+p31NTu2TkADJ5LaRM9PsZzkoYJTZYPfPKZMIVZa+H/Uqknm4O5kTPLmj+uZm/84zbszEbcHcBNa5twuQvBgT11sXj6YY1kp4sOBIkgU0YImdthWMeyENtfy2jkILhr4pMLOhDPoSdrJ4+MSLRfSnXuM6lLB0NL0jwu8/+WTf5FNUmFFTjiROR5wdLu9VQaEOyzl1TMpEAO1Xcwm4AaZAnAjugBvLShzlDeXPGAX6J41lKEErWAHa2MwuL73WxZLR3cH+GnmBzMs0A== 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=R3eAlIRYk2BKjEoQCD5BIAANwXZK9bDtM0mZDXplzC0=; b=Fax5XGFVMpQl2dbTcPAEMv86Asd9ijwCu+6X7we/E6pefizIZ/K8eZxgzKSVTIZ06bkoTWJHBHM95KRFhrhRApn8EKIuOr/zbLmUaH/+koghhpwF3YyOKpr/5OCqu41f4u5hqEbeo21kRZLT7SzjASnHCVnCPFFhxDF4YfCNxjg= Received: from PH0PR11MB5064.namprd11.prod.outlook.com (2603:10b6:510:3b::15) by PH0PR11MB5062.namprd11.prod.outlook.com (2603:10b6:510:3e::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4608.16; Wed, 13 Oct 2021 12:13:14 +0000 Received: from PH0PR11MB5064.namprd11.prod.outlook.com ([fe80::7deb:6c36:73c2:f0d4]) by PH0PR11MB5064.namprd11.prod.outlook.com ([fe80::7deb:6c36:73c2:f0d4%3]) with mapi id 15.20.4608.016; Wed, 13 Oct 2021 12:13:14 +0000 From: "Min Xu" To: Gerd Hoffmann , "devel@edk2.groups.io" CC: "Kinney, Michael D" , Liming Gao , "Liu, Zhiguang" , "Brijesh Singh" , Erdem Aktas , "James Bottomley" , "Yao, Jiewen" , "Tom Lendacky" Subject: Re: [edk2-devel] [PATCH V2 05/28] MdePkg: Add TdxLib to wrap Tdx operations Thread-Topic: [edk2-devel] [PATCH V2 05/28] MdePkg: Add TdxLib to wrap Tdx operations Thread-Index: AQHXuZq6srPDpOieLkegdvwUHsVUx6vPEUYAgAFyZkA= Date: Wed, 13 Oct 2021 12:13:14 +0000 Message-ID: References: <20211012082206.2j5eptadquhf3pmg@sirius.home.kraxel.org> In-Reply-To: <20211012082206.2j5eptadquhf3pmg@sirius.home.kraxel.org> Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-reaction: no-action dlp-version: 11.6.200.16 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: 8372f5ee-371f-4a57-c416-08d98e42d560 x-ms-traffictypediagnostic: PH0PR11MB5062: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: mkqaclv4qkC7RxL6cEKUQzhGwXK6UxnM23ai7Z+9FmKOuZgWmTBLiVcLAgfKTNWlbR3QroS9E4wDtSNrB4dcbam5dmfEn26WQRIIyXG4yNANjWidqrFZCs64iX12UtmhvfIqwpk0u1e4n9CUzhFifZivb6fcuVR964DfKt7eZmvBP8pWyvoa3nbgQWrOVBPNh1sHW/rrY4zitj9WmadtPkhn17A6GLsmn1x23mksV9OM74E27bbfrgdRD1q5rr7jP0wva/KTpCWF5WXnZBRlCL5+9NCe/7veEDRczDuuQKmED9rjBesgyJmCGXnyP4SVpetJEXKR4oz5ZxIxeCgfNmMhzjJtE86UcbrH90B79nWhT/m3Bqi/TZY7A9Z/BjtqQuNKKvUZac4U4OPeFsbZsNVQABoUk+VtdqPtYvliFq/vcEvCiBmB7I1214JqEJ+fO1oB6yYhbkVKGTZzHSKi00twQoAKVRMCq11dXpbskUUnYXrSK6Xa66tx6+V1bQPmGbz4lptGxAPNJyQyeJo0fiooOCCz7WaCp5EciEpBivHoKTVk9exjDdB5PKJukuZGVrlSYx8qJ4C2agLajte1p2dYYvJqPCOhAbkrhaJh6G3PWi6V1WJ2LobvVOtZ3W+32YP5QHi+QgsQPYuPgOFQ1l+bdW3Q5ukVhiHWQ9nnT/iMBBbTcML4EL434R0Ae6AQh2qm9LjSH/eVMXwBX4U53GfdhwCccvj8wa3FG/exraJHsjfCl9IRmfyK8YoN52eN9Jn2sSoyt7reFibgxLHx7AlXvUy7IEUN5Df3veXphd0= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PH0PR11MB5064.namprd11.prod.outlook.com;PTR:;CAT:NONE;SFS:(4636009)(366004)(66446008)(64756008)(66556008)(66476007)(508600001)(71200400001)(8936002)(316002)(2906002)(122000001)(38100700002)(8676002)(76116006)(66946007)(110136005)(4326008)(38070700005)(54906003)(82960400001)(5660300002)(52536014)(86362001)(83380400001)(7696005)(26005)(186003)(33656002)(966005)(55016002)(6506007)(9686003);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?qXl2C6beDUoEAJqySpc25tJ84KtBEXmTBLn375U6p8Y9Wpl9BALN57dngbPs?= =?us-ascii?Q?fxdN1tDiP5/13bHxmIgeBUlLdeIVQecUdFqm94RkuERot/e1uRB1A1lXSVxt?= =?us-ascii?Q?k/jU3FIHpbTW0NMP02p4xbFSPd5TIbPDYwfFWzek/JZYPO2QXXF0lMdgKDsv?= =?us-ascii?Q?2hRhW4G0V4lh721UDJt2AQR65DAzWPmbntcpAE4bznIPKaqw++jsLMnJ+na6?= =?us-ascii?Q?xZ7STLSIXvxJMNKiCjvc/iAaM3GphYmRi25HEKCqqRq3R47tBPV6AnS6Qv/d?= =?us-ascii?Q?9TAX0i1YDI62AznSOVU8Wut1hi/IMEfPvDEThjJJt+uPH69BThKilOIJC3CA?= =?us-ascii?Q?eiu2VCObzrlolri6bhHJ/efl+QTYyC+XNLwyGBbKic5QG/irNd9Ez4JEkIOk?= =?us-ascii?Q?QiEfXwf7s0qlVB5Vr+2E1wjQy3N1n7/OYyqHlvH9aWwXb1Y/wdNz9VmF7smR?= =?us-ascii?Q?ZPTvkF1HYVJ/oZHNWNFw9X2GpnkkXD+BFeOxyvXFtqpgjFRmE93pKgiO8sC9?= =?us-ascii?Q?QqK40u60QFwbhUNUwnPGp3X62sYWiqs5JdBZB5nIYJz0nWPiVFCOSEw7TaVH?= =?us-ascii?Q?w141XAfHqVI1ASownNjmHbqKDKHsg0AlE2NAtSt2H1fsoktELJvOTSXLSU4A?= =?us-ascii?Q?Y5TCgdGCafmoaAecY4pmZCRyI3o4ag6YAvAhp58hGAEJxb+941LHKD1aXGRc?= =?us-ascii?Q?CIIl9CVWpGaKBcM2R4gG8pw5PpzYo3WlhQHETyOJDHvfRpDdhScGsIG5EkjD?= =?us-ascii?Q?sQIjXzy1Z2twk+5FPBlxiEslJpVRf9o3cVHYLZI5U1V0gBIDZkhQuoCZg192?= =?us-ascii?Q?WbBH+4N08GxEP5elK7E1wyQzLwVD8/akMgS9XPn3fCK1OWkS0jWUcZkocz5A?= =?us-ascii?Q?YNCu0DcNUUIKmSzreENd2G3ZwweFqTJEVk86jVX8EceLGvN9TcgUYLEDetu+?= =?us-ascii?Q?gozIA/5AXC3nmrxvOyI2Z/wq4QvSFzq9Y3byoKLD1sGGR2w/Y2kF9GGddrmf?= =?us-ascii?Q?GHZezwuTsGFFeuZzr32jAMnqiVME574L9PTBcDz/u4/q1GWwvBKJhjQmRX8/?= =?us-ascii?Q?6uJbAN9k8fMilpIEQ9coegY0ALnvAJlBKWI9vRlTgN1jlRh8lVLdxu+LrtCO?= =?us-ascii?Q?7pOeG95ZararaVelQINCo/X0+9b7zlnhR+KH30sJWyibETGdp8P3kdTZnCkY?= =?us-ascii?Q?25QZ1MCBUvS2mWc/yp3BgEe+i1i7Tc+LS6LrAgCJq/OAu73yBpWE8mL5Dyzm?= =?us-ascii?Q?T1d8Q2d2TYb2AE7riFlGTGKTN96VoOC7iLpPlsjUZjviOMul9LqAYYTumZaP?= =?us-ascii?Q?ICwpVZYVZC2pvmxj5wIHEodC?= MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: PH0PR11MB5064.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 8372f5ee-371f-4a57-c416-08d98e42d560 X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Oct 2021 12:13:14.7245 (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: l6Uqj82ICCG6OahIb4kHOzXokZ0Nj3ucwFDWYU8pS6Cr7JADYrpPAftPX9khhQBMRUSWcXBDCyYE97umJYmWtA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR11MB5062 Return-Path: min.m.xu@intel.com X-OriginatorOrg: intel.com Content-Language: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On October 12, 2021 4:22 PM, Gerd Hoffmann wrote: > > +// PageSize is mapped to PageLevel like below: > > +// 4KB - 0, 2MB - 1 > > +UINT64 mTdxAcceptPageLevelMap[2] =3D { > > + SIZE_4KB, > > + SIZE_2MB >=20 > No 1G pages? TDX: https://software.intel.com/content/dam/develop/external/us/en/document= s/tdx-module-1.0-public-spec-v0.931.pdf=20 Theoretically there are 3 AcceptPageSize (4KB/2MB/1GB). But currently only = 4KB and 2MB are supported. See section 22.3.2. >=20 > > +UINTN > > +GetGpaPageLevel ( > > + UINT64 PageSize >=20 > Uh, UINT32 is not enough? Keep the door open for 512G pages? Thanks for reminder. UINT32 is enough. It will be updated in next version. >=20 > > +{ > > + UINTN Index; > > + > > + for (Index =3D 0; Index < sizeof (mTdxAcceptPageLevelMap) / sizeof > > + (mTdxAcceptPageLevelMap[0]); Index++) { >=20 > There is an ARRAY_SIZE() macro, no need to open code the sizeof() trick. Thanks for reminder. It will be updated in next version. >=20 > > + if (mTdxAcceptPageLevelMap[Index] =3D=3D PageSize) { > > + break; > > + } > > + } > > + > > + return Index; > > +} >=20 > No error handling (invalid PageSize) here? >=20 > > +/** > > + This function accept a pending private page, and initialize the > > +page to > > + all-0 using the TD ephemeral private key. > > + > > + Sometimes TDCALL [TDG.MEM.PAGE.ACCEPT] may return > > + TDX_EXIT_REASON_PAGE_SIZE_MISMATCH. It indicates the input PageLevel > > + is not workable. In this case we need to try to fallback to a > > + smaller PageLevel if possible. > > + > > + @param[in] StartAddress Guest physical address of the private > > + page to accept. > > + @param[in] NumberOfPages Number of the pages to be accepted. > > + @param[in] PageSize GPA page size. Only accept 1G/2M/4K si= ze. > > + > > + @return EFI_SUCCESS Accept successfully > > + @return others Indicate other errors > > +**/ > > +EFI_STATUS > > +EFIAPI > > +TdAcceptPages ( > > + IN UINT64 StartAddress, > > + IN UINT64 NumberOfPages, > > + IN UINT64 PageSize > > + ) > > +{ > > + EFI_STATUS Status; > > + UINT64 Address; > > + UINT64 TdxStatus; > > + UINT64 Index; > > + UINT64 GpaPageLevel; > > + UINT64 PageSize2; > > + > > + Address =3D StartAddress; > > + > > + GpaPageLevel =3D (UINT64) GetGpaPageLevel (PageSize); >=20 > Why cast? Thanks for reminder. The cast is not needed. It will be updated in next ver= sion. >=20 > > + if (GpaPageLevel > sizeof (mTdxAcceptPageLevelMap) / sizeof > (mTdxAcceptPageLevelMap[0])) { > > + DEBUG ((DEBUG_ERROR, "Accept page size must be 4K/2M. Invalid > > + page size - 0x%llx\n", PageSize)); >=20 > Ah. Errors are catched here. Well, no. The check is wrong, it should b= e ">=3D" not > ">". >=20 > Better would be GetGpaPageLevel explicitly returning a specific value (fo= r > example -1) on error. You're right. A dumb error ... It will be fixed in the next version. >=20 > > + Status =3D EFI_SUCCESS; > > + for (Index =3D 0; Index < NumberOfPages; Index++) { > > + TdxStatus =3D TdCall (TDCALL_TDACCEPTPAGE, Address | GpaPageLevel,= 0, 0, > 0); > > + if (TdxStatus !=3D TDX_EXIT_REASON_SUCCESS) { > > + if ((TdxStatus & ~0xFFFFULL) =3D=3D > TDX_EXIT_REASON_PAGE_ALREADY_ACCEPTED) { > > + // > > + // Already accepted > > + // > > + mNumberOfDuplicatedAcceptedPages++; >=20 > Hmm. When this happens we have a bug somewhere, right? > So should this be an assert()? > Or should we at least log the address? ASSERT() is not necessary because the code can still run. But we should log= the address which has been already accepted. It will be added in the next version. >=20 > > +#define RTMR_COUNT 4 > > +#define TD_EXTEND_BUFFER_LEN (64 + 64) > > +#define EXTEND_BUFFER_ADDRESS_MASK 0x3f > > + > > + > > +#pragma pack(16) > > +typedef struct { > > + UINT8 Buffer[TD_EXTEND_BUFFER_LEN]; > > +} TDX_EXTEND_BUFFER; > > +#pragma pack() > > + > > +UINT8 *mExtendBufferAddress =3D NULL; > > +TDX_EXTEND_BUFFER mExtendBuffer; > > + > > +/** > > + TD.RTMR.EXTEND requires 64B-aligned guest physical address of > > + 48B-extension data. In runtime we walk thru the Buffer to find > > + out a 64B-aligned start address. >=20 > Can't you just use __attribute__((aligned(64))) for that? >=20 In the PoC of TDVF I had thought about it. But at last I gave up such solut= ion. The reasons are: 1) OVMF/TDVF supports both GCC and VS2019 tool chain. __attribute__((aligne= d(64))) is for GCC. Its counterpart of VS2019 Tool chain is __declspec(alig= n(x)). 2) There is the limitation of /ALIGN:32 in the build scripts which means al= igned 64 exceeds the /ALIGN 32, unless /ALIGN is updated to 64. That's why the current solution is used. Thanks! Min