From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by mx.groups.io with SMTP id smtpd.web09.11564.1623155251672500876 for ; Tue, 08 Jun 2021 05:27:32 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@intel.onmicrosoft.com header.s=selector2-intel-onmicrosoft-com header.b=GD4bFHDn; spf=pass (domain: intel.com, ip: 192.55.52.115, mailfrom: min.m.xu@intel.com) IronPort-SDR: TlEb/P2nUZ79ZGfPJa1hNJ6mH1LAApNctTdR1k8pgmZp1zDia2jZUahu62TWsw+adfnIzrkqkd JAracfYFRvAg== X-IronPort-AV: E=McAfee;i="6200,9189,10008"; a="204647722" X-IronPort-AV: E=Sophos;i="5.83,258,1616482800"; d="scan'208";a="204647722" Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga103.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 08 Jun 2021 05:27:30 -0700 IronPort-SDR: uq5rFF+oFls04y9+uDETvftV82XCnJXi3hqTwI5OeaancXkTJISpk5l70QyTsKrSRAqN4Q55gN +Mq0dokzzu4Q== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.83,258,1616482800"; d="scan'208";a="552263257" Received: from orsmsx602.amr.corp.intel.com ([10.22.229.15]) by fmsmga001.fm.intel.com with ESMTP; 08 Jun 2021 05:27:29 -0700 Received: from orsmsx610.amr.corp.intel.com (10.22.229.23) by ORSMSX602.amr.corp.intel.com (10.22.229.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2242.4; Tue, 8 Jun 2021 05:27:29 -0700 Received: from orsmsx602.amr.corp.intel.com (10.22.229.15) by ORSMSX610.amr.corp.intel.com (10.22.229.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2242.4; Tue, 8 Jun 2021 05:27:28 -0700 Received: from ORSEDG602.ED.cps.intel.com (10.7.248.7) by orsmsx602.amr.corp.intel.com (10.22.229.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2242.4 via Frontend Transport; Tue, 8 Jun 2021 05:27:28 -0700 Received: from NAM04-MW2-obe.outbound.protection.outlook.com (104.47.73.169) by edgegateway.intel.com (134.134.137.103) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2242.4; Tue, 8 Jun 2021 05:27:28 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Hz2eESvEDazGSzTs1WUejF5d3H9IPwHT+UhAoPN8b2GPWckwrEHzE55sct4Eh2KoBvEwszJvYR/MzfY16ZlmScPcSFWMlI//iEG7m8AkfBo2Qa964rwMmD5CkAZTs6zpUeCbw3zqG3Y5YWZLskVLdnn/9CbfYKjsYh2bIj1y5Ab2zJxsF3SDTGHvXl/Hr5ZBTR60Oi8DEIRBeaspwFlY4ZNDBcW9QrEMOUMQC9jEymRlEDSr4Yeas3VA31aLXr8HGJKnUlE31hG0KXsALVnoXMCHzjdxba9VkHfK1Q8rvqtW3sX3bE4y/pkpFQ+oCwFuBv7WRof1GDecL6rMu95kUw== 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=NExVi+9DOVTuIsCcaBUYoXU5/VzGuweCMUjaSzps7DY=; b=EXU3bp81zBqzJN/e0+uRQ81LJub0OUYfJ/hAnJwn1009liyH6dmXtRdF49ieZ/ZrYA2/ZYHJW0oRwWaFj++wv3h5RCjx0saB+DM1WycqSn7QY3cbWlIJw2dsdBOXHF0AVJK+0fPw1lF1+DQtre9v+SCO1qy3akx0WansREaoPF5Wv1Na+ogKotNM+yD8EezR0lUdzcycxbQ71HJy9UURLj5VG86KAF9tc2+OW+n+ujBrT/U0AEtVd1Ig0fFUko14VwjhfvBI3+I7NBas//vtWdPOfyPpnEnFfoNaMTb4RVu+DrVOcmQ7yDEqTaOIWKml5jPskcnERv+qU5tPh1qFIQ== 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=NExVi+9DOVTuIsCcaBUYoXU5/VzGuweCMUjaSzps7DY=; b=GD4bFHDn7rnMI7tG3opckKcWAqF2VOQKQe5Aw/L5UwL+4N1wCSc7g+Wu0SSrv9U93G6ooMwCN2xIn2pDnQHvrFW2LNWl/hY8v0Vxx4V8DV35CGjIKG/hEPhFqtqNFiHOI9kG3f9Kk7podajUvOJV/3T0ZqtUWSn08U4OX3VMJKI= Received: from PH0PR11MB5064.namprd11.prod.outlook.com (2603:10b6:510:3b::15) by PH0PR11MB4888.namprd11.prod.outlook.com (2603:10b6:510:32::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4195.24; Tue, 8 Jun 2021 12:27:28 +0000 Received: from PH0PR11MB5064.namprd11.prod.outlook.com ([fe80::b4be:3994:dd4d:7b9d]) by PH0PR11MB5064.namprd11.prod.outlook.com ([fe80::b4be:3994:dd4d:7b9d%8]) with mapi id 15.20.4195.030; Tue, 8 Jun 2021 12:27:27 +0000 From: "Min Xu" To: "devel@edk2.groups.io" , "lersek@redhat.com" , "Yao, Jiewen" , "rfc@edk2.groups.io" CC: "jejb@linux.ibm.com" , Brijesh Singh , Tom Lendacky , "erdemaktas@google.com" , "cho@microsoft.com" , "bret.barkelew@microsoft.com" , Jon Lange , Karen Noel , Paolo Bonzini , Nathaniel McCallum , "Dr. David Alan Gilbert" , Ademar de Souza Reis Jr. Subject: Re: [edk2-rfc] [edk2-devel] RFC: design review for TDVF in OVMF Thread-Topic: [edk2-rfc] [edk2-devel] RFC: design review for TDVF in OVMF Thread-Index: AddYf4DUPECuZ9ubQaOwhq0M0PgYbAAE6sKAAPJOLIA= Date: Tue, 8 Jun 2021 12:27:27 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-reaction: no-action dlp-version: 11.5.1.3 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-originating-ip: [192.198.142.20] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 754f2d52-f755-4b84-f30d-08d92a78c76b x-ms-traffictypediagnostic: PH0PR11MB4888: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7219; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: ZjKaZtWJhbh27Pk/wbuEyd49H8c1jY3vSKs5KWfsAYfjvj/XuNCp6ZTifiytLbAPw1VBpNkTC1hNKkpPC1SNCU8HBnheiPqqY8v1h2q7hsztvQJFb4hUpo+XqvKhG8thfXM7SAHD9+HeM52adcwOMmaVoL3K0rIL6bXwfSuIWTPbnFzOPWg9LsshIsOiM0vAEnEOPfbetj13lud5ZEGS8KGUyMKRlBq3Xxhmms/PPvwcJfgcuWm5YduG033+g9YykO23Wx+IpdGpml6ckc1BQCWoTsatT+ajA7/80VT6MKPAZiZ7HCHBEKO8OxxoDv5jEvuSXENFFvTIQsjOGuCvF/Da7wf9ezWWw1QSafmAPp77gPwlP2ujOFEUl3Rig7qx1jJ19O91uuzkYVYbur6k6rcCWWa5O+kOStaRQgKJXO5IOgcugZzDDlSajTG1V/TP3Ve0gmeZB9WJsJdXKyycE7evnyDh0Zs1wMshArAEkb3Pn2Iylx08u1E6kt0e+Z43uumBzknhzIrWoUyqE6V6kZn/TjU9z15PCFJVx3gZlV8rS6jAujDopvEpt+m+UrYlYD82Htt+QSy837Bo5SzH21Orne3i9AsG9R8pieSeW6I= 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:(366004)(39860400002)(346002)(396003)(376002)(136003)(66476007)(38100700002)(66446008)(9686003)(5660300002)(64756008)(66556008)(71200400001)(76116006)(2906002)(55016002)(6506007)(53546011)(52536014)(66946007)(8936002)(7416002)(7696005)(54906003)(33656002)(86362001)(316002)(122000001)(478600001)(4326008)(83380400001)(26005)(110136005)(8676002)(186003);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?msSd9DLdFhFBpwv/kTz9Y2mYqUGaOCtWdx+IY726XEfJXXZlTsUDVYnEmxaR?= =?us-ascii?Q?Mso4n6+eaF5oqP5eg1AK/YVgi0nMGl1oQCA5DwDSwlX0ORz38vG0oMyHLFon?= =?us-ascii?Q?gcAD2TjPxWmMVkubCE4+0xZ6f7Mju0XztGlxn4QZGj9a/4eVFxcvHF9fQA39?= =?us-ascii?Q?XJOC9jaWzTQQm+dCD9dVprPI3NTM09i9m8sZqD4LfMOz4YO/xDk1AXk5NgI1?= =?us-ascii?Q?j5yYPCLxgur15UtdgzWi1Z06YV1FxNdVkpzO6KLh4u+2CnLQQHlDhYeZWpUQ?= =?us-ascii?Q?wmLsn4ka1X9OGWGgt6fbv1tvvaw1AY9pxdOkbANrxdWVpFtRqB9TpOu2qTvG?= =?us-ascii?Q?v3Aut5OOFKIVd+zhIV2NMRYTi8dT2qGuV97pmPs0I1bbUbbVJdnPFjbcJEbN?= =?us-ascii?Q?fmlM1u0huMxM+EHVGCVyB8lNnohaXgpxkNnnu++negXScuDxLfnTSXX3kMXt?= =?us-ascii?Q?b5StauWxuHzhg/qWxOOXyNSY8rQKSdPowOYHb+kLJ1un+xAXJhWVAb312mHI?= =?us-ascii?Q?+PzEmJ1N9Hc2Z2hHOhUwy11WNQey/ljbQdX8UiQ2BX8cLVss2fzzG5v+z7Ny?= =?us-ascii?Q?e0BljeJ0aAnoUhY+DH7PYLzJzlEVgi14cwG7Db48WohV83xHy58i6ysMg7ev?= =?us-ascii?Q?xmOqUhFFS/GNhyTYsu3jk1F6UpK8DvQfMekvY0qwlVzg699mCq/7GGwlTOE4?= =?us-ascii?Q?LH2eINnHfKwgWBnALUKFziDVsTy7d4i6xx18gmKaC8byVvYGEllYo/KPx9HE?= =?us-ascii?Q?WlFsYKbvqFg0gPyqdL8Gr1AkparNRaATUtESxJGWXDHzCF1qO1t7WE3JNUnX?= =?us-ascii?Q?g7RORIVKp6+NLTcgUE6CQCaroFRoi4bEnhhOJEV/WeJHrKBZmk1j48CaYDmR?= =?us-ascii?Q?J1zsvKiJC3jNbSBg+3ZBL9v0BRIiQfoSXnOabAWZvV/0AvlNtYFbFcJ6Rys1?= =?us-ascii?Q?DuLUg0rUPyXc+cn3bC8uSpXxJTjy07iy4lE6G6iE8C9IkGj5WIgKiRmKv6rG?= =?us-ascii?Q?U/zuuLYselYwYDQ/Tqwv71QaPJliGieJ3MiJL3Ed0vozHU6l+AFYwvQPdIIf?= =?us-ascii?Q?dp7kTIiuBTPBN45/XycYnElxsihSGwfZcYugehfSTLd2r3KULIXT878S/eQr?= =?us-ascii?Q?CbN0fuWLmwaksa4hPH2KTu8wjwk4NwFDMqByeuJI+kaAjJFHXpvKtQSn92TG?= =?us-ascii?Q?bWYamYbLw5p/TVbyvZtceXBdik9yUv4cO7H45zokt2NJpqzgrxIzTh6bnwqT?= =?us-ascii?Q?AV5wcGhJkemjGai15fnCR/0P+SfBLCasjb+Gv6Q5QaNO768KJhdQnvPvf3i/?= =?us-ascii?Q?+HW+U4NrkA0eI4Nvi0ibFc69?= 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: 754f2d52-f755-4b84-f30d-08d92a78c76b X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Jun 2021 12:27:27.8464 (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: KOOrzIeW0y4fPSOWLYZWFl1Gm2XsgA/87aRbFHgaw93dK8pUxDwhH+YD0/qQ+F10ViG7cqS2ssPLpMGrI4eRlw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR11MB4888 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 06/04/2021 12:12 AM, Laszlo wrote: > (22) EmuVariableFvbRuntimeDxe >=20 > Ouch, this is an unpleasant surprise. >=20 > First, if you know for a fact that pflash is not part of the *board* in a= ny TDX > setup, then pulling >=20 > OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbServicesRuntimeDxe.inf >=20 > into the firmware platform is useless, as it is mutually exclusive with >=20 > OvmfPkg/EmuVariableFvbRuntimeDxe/Fvb.inf >=20 > (via dynamic means -- a dynamic PCD). >=20 > Note that the FDF file places QemuFlashFvbServicesRuntimeDxe in APRIORI > DXE when SMM_REQUIRE is FALSE. This driver checks for pflash presence, > and lets EmuVariableFvbRuntimeDxe perform its in-RAM flash emulation > only in case pflash is not found. >=20 Right, pflash is not part of the *board* in any TDX setup. This is a limitation from the Qemu (the tdx-qemu) side. TDVF is copied into RAM. Generic loader is the one for it. In this case (pflash is not found), FvbServiceRuntimeDxe.inf will return EFI_WRITE_PROTECTED in its FvbInitialize(). EmuVariableFvbRuntimeDxe will then perform its in-RAM flash emulation. > So this is again in favor of a separate platform -- if we know pflash is = never > part of the board, then QemuFlashFvbServicesRuntimeDxe is never needed, > but you cannot remove it from the traditional DSC/FDF files. >=20 Yes, if TDVF is a separate DSD/FDF, QemuFlashFvbServicesRuntimeDxe will be removed from the image. > Second, EmuVariableFvbRuntimeDxe consumes the PlatformFvbLib class, for > the PlatformFvbDataWritten() API (among other things). This lib class is > implemented by two instances in OvmfPkg, PlatformFvbLibNull and > EmuVariableFvbLib. The latter instance allows Platform BDS to hook an eve= nt > (for signaling) via "PcdEmuVariableEvent" into the > EmuVariableFvbRuntimeDxe driver. >=20 > In old (very old) QEMU board configurations, namely those without pflash, > this (mis)feature is used by OVMF's PlatformBootManagerLib to write out a= ll > variables to the EFI system partition in a regular file called \NvVars, w= ith the > help of NvVarsFileLib, whenever EmuVariableFvbRuntimeDxe writes out an > emulated "flash" block. For this purpose, the traditional OVMF DSC files = link > EmuVariableFvbLib into EmuVariableFvbRuntimeDxe. >=20 Thanks for the explanation. It's very helpful for me to understand the code= . > But it counts as an absolute disaster nowadays, and should not be revived= in > any platform. If you don't have pflash in TDX guests, just accept that yo= u > won't have non-volatile variables. And link PlatformFvbLibNull into > EmuVariableFvbRuntimeDxe. You're going to need a separate > PlatformBootManagerLib instance anyway. > I have a question here, that if PlatformFvbLibNull is linked into EmuVaiabl= eFvRuntimeDxe, Does it mean it cannot write to the in-RAM variable store? >=20 > (We should have removed EmuVariableFvbRuntimeDxe a long time ago from > the traditional OVMF platforms, i.e. made pflash a hard requirement, even > when SMM is not built into the platform -- but whenever I tried that, Jor= dan > always shot me down.) > I am afraid in TDVF we have to use EmuVariableFvRuntimeDxe to emulate the in-RAM, as I explained pflash is not part of the *board* in TDX setup. In the traditional EmuVariableFvRuntimeDxe, the FV contents will be initial= ized. But TDVF has its own requirement, that the SB keys in CFV need to be copied into the FV contents. That's why EmuVariableFvRuntimeDxe is updated in TDVF project. >=20 > My point is: using EmuVariableFvbRuntimeDxe in the TDX platform may be > defensible per se, but we must be very clear that it will never provide a > standards-conformant service for non-volatile UEFI variables, and we must > keep as much of the \NvVars mess out of EmuVariableFvbRuntimeDxe as > possible. This will require a separate PlatformBootManagerLib instance fo= r > TDX anyway (or maybe share PlatformBootManagerLibGrub with > "OvmfPkg/AmdSev/AmdSevX64.dsc"). >=20 > Apart from the volatility aspect, let's assume we have this in-RAM emulat= ed > "flash device", storing authenticated UEFI variables for Secure Boot purp= oses. > And we don't have SMM. >=20 > What protects this in-RAM variable store from tampering by the guest OS? > It's all guest RAM only, after all. What provides the privilege barrier b= etween > the guest firmware and the guest OS? A good question and we will answer it a bit later. Thanks for your patience= . > Thanks > Laszlo