From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mga05.intel.com (mga05.intel.com [192.55.52.43]) by mx.groups.io with SMTP id smtpd.web11.78089.1673581600450087625 for ; Thu, 12 Jan 2023 19:46:40 -0800 Authentication-Results: mx.groups.io; dkim=fail reason="unable to parse pub key" header.i=@intel.com header.s=intel header.b=hr4XNzVh; spf=pass (domain: intel.com, ip: 192.55.52.43, mailfrom: jiewen.yao@intel.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1673581600; x=1705117600; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=TNaSS8cv9QydZWbpksIegPZCXN7Gmpd/zZUilZPK9GI=; b=hr4XNzVhV4ct3nYg4HUouzY9a2wvv9+OwYZmlmeEynHYSOdxSzu/2S76 9+pFBMpUc+ZJyfrHXQJ4bIx94KRpzjsk4R3UTJLDLcMvzgPvCudEizxog fBxMjQjRXRoLzgvayvCDhwpp8jfs8dQAv6kMAtB96DPPRU0pyLUQPxzGU s7YOnpuY+3Zok18MGVxMWEch5tug1xAyME4C5XjNsFYWH7SgWU0Dk40AV ISsEBnlSHdCC/gPu0TIat4Qmrcjk/9hjFYAn4vsuAomHHcqa6F1pAEjZO 5cg4+lciSeGnxEpw+yHB6R9DqWoQLjuSAqEFVxJMZ3lzespapTHWZ+WtL w==; X-IronPort-AV: E=McAfee;i="6500,9779,10588"; a="410141435" X-IronPort-AV: E=Sophos;i="5.97,212,1669104000"; d="scan'208";a="410141435" Received: from orsmga007.jf.intel.com ([10.7.209.58]) by fmsmga105.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 12 Jan 2023 19:46:39 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6500,9779,10588"; a="651389881" X-IronPort-AV: E=Sophos;i="5.97,212,1669104000"; d="scan'208";a="651389881" Received: from fmsmsx603.amr.corp.intel.com ([10.18.126.83]) by orsmga007.jf.intel.com with ESMTP; 12 Jan 2023 19:46:39 -0800 Received: from fmsmsx612.amr.corp.intel.com (10.18.126.92) by fmsmsx603.amr.corp.intel.com (10.18.126.83) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.16; Thu, 12 Jan 2023 19:46:38 -0800 Received: from fmsedg602.ED.cps.intel.com (10.1.192.136) by fmsmsx612.amr.corp.intel.com (10.18.126.92) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.16 via Frontend Transport; Thu, 12 Jan 2023 19:46:38 -0800 Received: from NAM12-DM6-obe.outbound.protection.outlook.com (104.47.59.170) 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.2507.16; Thu, 12 Jan 2023 19:46:37 -0800 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=WQxa8uXbQ+YYh4T1UyX76uEK8sTkfrWdbYaTOihvbV91Z3COF44+aLzdhX6+N0bsgMUQNM2766pdZDRU2KFl1ILaGeNWGJiweReNv2u6rIlBvMtzsBZcloF9K/qlmyjucrLFDzwA/D4gZzR01ymDMXAM03RAkMjh3dTHvircqQc/ssdV2bhYwJNZT9SklIB94IYVQnnRjwrGZD08KlY8dESmSWvnI7B/nkFuUmjBTUoRne3fhO9KO2UK74XCsGr6kcKn/GZov15SbJgaXjiwNOLNTUXnfdqds3s8Ml1x7DPdNfNPJmksMyQCU25b+QINpbrkkunLferBfjg7/VtMSw== 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=XeHEepCL39ChLkW/7xuvGbktFLOJy2T7Tx9xJjTy5iA=; b=a7HnvCMXsTKgVQyTgCRnzC8tAI845krIJ84fY3/wnpIN5kQYA68CIJrH6UJL+dzYvrr7gByd6ltvffHiODystBslJhC8EDrEyCYVJiPV/h8m3/wV8J1rQSrS9s8lwjntMeu0G8fi0WFtt2poSEZrNbboja8OdojzDxWSN2FJ5LWcLeT2sFDT8Cu4Jmco0T1OIvnAGnCneejK50st9ifwVANqTcnbJvyZqQ2NfrGIKX/DB4kkW8+stmRReo9Cnn4h7xyLcUcv8iEVr1CwHa/Po9rTii0Kf4qe0B6Wz70cm8MLPGHVmrkIV4tAuQbv7YuRdc8uhueUXbhQl/r4cQxkHQ== 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 Received: from MW4PR11MB5872.namprd11.prod.outlook.com (2603:10b6:303:169::14) by PH7PR11MB8124.namprd11.prod.outlook.com (2603:10b6:510:237::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5986.18; Fri, 13 Jan 2023 03:46:35 +0000 Received: from MW4PR11MB5872.namprd11.prod.outlook.com ([fe80::5f56:1bdc:2eae:c041]) by MW4PR11MB5872.namprd11.prod.outlook.com ([fe80::5f56:1bdc:2eae:c041%7]) with mapi id 15.20.6002.013; Fri, 13 Jan 2023 03:46:35 +0000 From: "Yao, Jiewen" To: Dionna Glaze , "devel@edk2.groups.io" CC: Ard Biescheuvel , "Xu, Min M" , "Gerd Hoffmann" , James Bottomley , "Tom Lendacky" , "Aktas, Erdem" , Andrew Fish , "Kinney, Michael D" Subject: Re: [PATCH v9 0/4] Add safe unaccepted memory behavior Thread-Topic: [PATCH v9 0/4] Add safe unaccepted memory behavior Thread-Index: AQHZJuQPN86jGv9UBEmQR3NHUb19x66bsq8w Date: Fri, 13 Jan 2023 03:46:34 +0000 Message-ID: References: <20230113001419.2519031-1-dionnaglaze@google.com> In-Reply-To: <20230113001419.2519031-1-dionnaglaze@google.com> Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=intel.com; x-ms-publictraffictype: Email x-ms-traffictypediagnostic: MW4PR11MB5872:EE_|PH7PR11MB8124:EE_ x-ms-office365-filtering-correlation-id: f67038da-f6d8-4daa-6b86-08daf518c461 x-ld-processed: 46c98d88-e344-4ed4-8496-4ed7712e255d,ExtAddr x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: HUTrKFoejxTqQWqsu5N3J80ZQZUKhB2z4XFEfwZCfmBoAwwqagw89gySoFPXwHcqTFlQ/yioEKuc2nr8Dk1Ooq/P6fFy7ERRoupFzx2pisNs/gywDAfCvbvD2Dmi/80TMNVagGJatvOxDxKda4AsZfigOcg6BMmOxz3p2+DEmAtHb5bsBzTFQFHhXOcG4EnjfqOhjQB3hf2ni/aoe0j7vIB/bFomeIl1J0MvuUebXJMUOfAdVmLPlVD10RViAtwPw8F8hxLd3Aqbiz+fKAnIVaRJylNa83P6ANJuQYPxLfQjXlw/WJ2gEdhzL0MLY+gopiaXuqnAXWX1fj4VvC7bNEQNQTn0xPMomhswMXBsgsRccr5kFPC1mZHhc0eJZl4Vt2h5rd90usGazN4g8QaWPlSIVVtcLr9DHyZridXnTAFIHXKIKzEs1IlmnTN0NuqrzA4OpphghDJoblGI7jMmltqpjx9zyMopoT0ycIbfR9rXaIbrGtkWm6ngu9ys9d1eUuIZdwMfgccyPWvctz/EiM2IHUY6oFznkB6ouAht/WV3gZsZyeEBw7HT5YtltjDyNplE/iQU0bqqRMo+RCCnX8hzVU9K217sFibR8kmgtKWC1Dpowko252laxsYML0awJuGNRUZNnl8pj5QO4hCeKv98AsLyu1WRx2aFvxO5pZUnqUJ9TrVTH0t89OvGx5gG8nNHF15Tn03trQ1X+rB3kR2OumlJAOk58uvz0b1uBbM= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:MW4PR11MB5872.namprd11.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230022)(346002)(396003)(376002)(366004)(136003)(39860400002)(451199015)(19627235002)(316002)(38070700005)(6506007)(53546011)(186003)(82960400001)(66446008)(71200400001)(4326008)(26005)(38100700002)(5660300002)(52536014)(478600001)(8936002)(966005)(33656002)(7696005)(107886003)(64756008)(110136005)(8676002)(86362001)(66476007)(66946007)(66556008)(76116006)(54906003)(122000001)(41300700001)(9686003)(83380400001)(55016003)(2906002);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?lZzPY2O67U/U7fpq5XQe1N3xTBtgM8zeFMK0mj3pN/adMmsW93kNrBhAuEJh?= =?us-ascii?Q?ht7kXo4oS4Yo7gxq01LDJpA1GDIztIMcJeuT4f/Zsy3HwKJf2Z3QsZnjy7/q?= =?us-ascii?Q?wmdtduVqVmg/EgwJTRWxsQltN6nUo9Bt1/kTMsC6VznYaDAWvMk1vpVZ2mNZ?= =?us-ascii?Q?iHqlcUFuF2exZdBs8KN4tGdq3mM2xbG+zzr8cHlFpuGoa3memqMKuj0xKAwP?= =?us-ascii?Q?652Weov2iWTlyJkMxF2Yi2oYHV8hRPBfWtjK5RUUqDIhbAiWuiPP++BlUSsy?= =?us-ascii?Q?TPhcaXZNujvXkSayIqJDHw/FTChsjIA49w53l4axfZgGqyVPo5NAEanBJrpL?= =?us-ascii?Q?kQXYBYMYUUCacTipIVduyBialubwlHM9/eN4Zkv2KAEFUbB6UPy4VtaGGhvz?= =?us-ascii?Q?AYHz33yXEnT1iSv2cLHplU/AWogrnGWprA+/davCbsRD/SE/1GeXGLRW6AM6?= =?us-ascii?Q?9G6n1xxZnRZZgitsQxW50sEtZ+CZBPYb0gbIlfivzbBjo2X63y74kYZ7CyLB?= =?us-ascii?Q?f0A2dNUlgZRAsNKOW4g/DMRWxWNh1TuQp42HokG38/ooGtqYze7UHJY5uHGO?= =?us-ascii?Q?8EBtfgfIwf2IWtiCOnLBYeV3JIbbyohYcpUyYNtFPD29jRaa4og3dzaSnvm7?= =?us-ascii?Q?E3n/mO4aUtkS0/MvotcLTdi4qJmx55jSCPRwVDJZrWq40UdqLovEL9Kb+ZWq?= =?us-ascii?Q?7Fj4NdpwuyBXjUX5OBJ2GJi54enORJ3r55h9s7KPtSzG6AgV8jMCkv+JMTUw?= =?us-ascii?Q?CdAt3AW0K6gPjxW5SOHCEHY4KS2W+NHwE/rjrfuLJvQlPuEGF5uqIhCx6Nhl?= =?us-ascii?Q?IZjJka8YRYiVaAhWZ9fWzlRrkWBDNXJPjY8G6fPo0tgmRP9xgzo+gZigT5v5?= =?us-ascii?Q?v6QHN17fpdIfdrutWoJRSGGw0QtpWyS3ALr64GuoFwErcfzLiqFCmLQOCHW3?= =?us-ascii?Q?97R59QrG0z750cs+DvsiZnB4DgxuYF1F/re3pLvOYeCETAPvGF9m2koIYsJO?= =?us-ascii?Q?DYKaldUrnTur0zia2NQKQQvPGzPMdH04xyRrvHL5y+PYGMDgjck7bSE3awfs?= =?us-ascii?Q?0JMYjLp2h81vKT4dpxx90beMTkXcwRdU/fWoSmDLxeShHAjKMQXws4NhIe8x?= =?us-ascii?Q?aaztCkmkc4Jy8cMn6022EyZonKDPuzFHJPWDqr6y6rGVJiU8DP0PAuTx/N18?= =?us-ascii?Q?9pohyw2Hh3JiREY5784Nd9JBGc/7tv7tkEXy55LNgsC67IZemLPVRFDeQqF9?= =?us-ascii?Q?bAA/2EcizNApJRhwbXjiqRN73KR5pQCOdAFu3BA5kSYLu6S485xd22RBYSjq?= =?us-ascii?Q?V90cG5sAUg0VAY9Yim4rTdZtdzA7U2MOhVDI6HAf88zpzmnX3rO0at/XbjAf?= =?us-ascii?Q?/+PIvDHR1ZJM2PhxashEGyz3S60EPPv4ig1AxKa+cpmjngqpXarP0OxylSRh?= =?us-ascii?Q?Acjc78QfvtAnGKK3xZ4tfhXZg5xm+Gd4vk0ox2+AxU0NRwu/ODWfgNZj3yRy?= =?us-ascii?Q?8zmmX7LEWM99gXpJd4U9Oo0W2VsI2khm2BWtNXNe151NH9CqJRaZOMDuhNZw?= =?us-ascii?Q?7KR76mmqhCiNTsLEuM6ORegfZOsBi+Tk5+Knuf+5?= MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MW4PR11MB5872.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: f67038da-f6d8-4daa-6b86-08daf518c461 X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Jan 2023 03:46:34.8616 (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: rqGCq6bi4QeL0VGY/GUlEwq9T87MjnOwYiz1rR9R/ssldhnpKwrXbij5Hg7ao7jFYXyZIbhmgfbtJmqgiy7wJA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH7PR11MB8124 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 Hi Dionna I think I understand your intention. I believe we need OS side and UEFI standard sign-off for this *BZ3987_MEMOR= Y_ACCEPTANCE_PROTOCOL*, because OS is the consumer, right? If so, I suggest you maintain the work in a edk2-stage area for https://git= hub.com/tianocore/edk2-staging. EDKII main branch is for production. MdePkg can only include the API defini= tion approved by UEFI standard. EDK2 staging is a place for POC / collaboration. That is why I think edk2 s= taging is more proper place for this feature. Without OS and UEFI standard sign-off, I don't think this BZ3987_MEMORY_ACC= EPTANCE_PROTOCOL can be integrated to EDKII main branch, especially in MdeP= kg/Include/Protocol/MemoryAcceptance.h. Thank you Yao, Jiewen > -----Original Message----- > From: Dionna Glaze > Sent: Friday, January 13, 2023 8:14 AM > To: devel@edk2.groups.io > Cc: Dionna Glaze ; Ard Biescheuvel > ; Xu, Min M ; Gerd Hoffmann > ; James Bottomley ; Tom > Lendacky ; Yao, Jiewen > ; Aktas, Erdem ; Andrew > Fish ; Kinney, Michael D > Subject: [PATCH v9 0/4] Add safe unaccepted memory behavior >=20 > We make eager memory acceptance the default behavior at ExitBootServices > by using the standard-enforced behavior that if the call returns an > error code, then the map key is incorrect and the caller must re-call > GetMemoryMap to ensure the contents are correct. >=20 > Eager memory acceptance is implemented by using the UEFI v2.9-added > EFI_EVENT_GROUP_BEFORE_EXIT_BOOT_SERVICES to check a support > condition > before changing all unaccepted memory type regions to conventional > memory after first using the MemoryAccept protocol to accept all memory > in each region. This update to the memory map only happens once, since > there are no extra unaccepted memory regions to change on the forced > second call to ExitBootServices. >=20 > The new acceptance logic is technology-agnostic and usable across TEE > technologies, so this patch series introduces a Confidenial Compute DXE > driver called CocoDxe. >=20 > To allow the OS loader to prevent the eager acceptance, and thus pass > the before-mentioned "support condition", we add a new protocol, up for > standardization, AcceptAllUnacceptedMemoryProtocol. > This protocol has one interface, Disable(). The OS loader can inform the > UEFI that it supports the unaccepted memory type and accepts the > responsibility to accept it. >=20 > The MemoryAcceptance protocol is necessary for safe rollout of the > unaccepted memory type, given the gradual update of guest OS kernels. > OVMF cannot rely on the following implication >=20 > (MemEncryptSevIsEnabled () || MemEncryptTdxIsEnabled ()) >=20 > implies >=20 > unaccepted memory is supported by the guest >=20 > This implication does not hold for e.g., upstream Linux, and will not > hold generally since both SEV-SNP and TDX define unaccepted memory > support as optional rather than required. >=20 > All images that support unaccepted memory must now locate and call this > new BZ3987_ACCEPT_ALL_UNACCEPTED_MEMORY_PROTOCOL and call the > Disable > function. >=20 > Changes since v8: > - First 3 patches removed since they were submitted separately. > - Later patches rebased on edk2/master and modified to work with the > current locations and namings of the unaccepted memory constants. > Changes since v7: > - Rebased onto lazy accept v4 patch series, so memory accept protocol > has the EDKII prefix, and the unaccepted memory type has the BZ3937 > prefix. > - Removed a bad #include to a header removed in v7. > - Renamed the protocol to BZ3987_MEMORY_ACCEPTANCE_PROTOCOL as > per the > discussion on the buganizer issue. > - Uncrustify formatting >=20 > Changes since v6: > - Added implementation of > EFI_EVENT_GROUP_BEFORE_EXIT_BOOT_SERVICES. > - Changed callback protocol of v5 to instead use the standardized event > group for before_exit_boot_services. >=20 > Changes since v5: > - Generic callback protocol moved to MdeModulePkg > - Removed use of EFI_WARN_STALE_DATA and added comment that the > callback > should only return EFI_SUCCESS or EFI_INVALID_PARAMETER. > - Removed errant log statement and fixed formatting. >=20 > Changes since v4: > - Commit message wording > - Replaced direct change to DxeMain with a more generic callback > protocol. > - Implemented the direct change as an instance of the callback protocol > from a new CocoDxe driver. > - Replaced "enable" protocol with a "disable" protocol, since the name > was confusing. The AcceptAllUnacceptedMemory protocol directly names > the behavior that is disabling. >=20 > Changes since v3: > - "DxeMain accepts all memory" patch split into 3 to make each patch > affect only one package at a time. >=20 > Changes since v2: > - Removed the redundant memory accept interface and added the accept > behavior to the DXE implementation of > MemEncryptSevSnpPreValidateSystemRam. > - Fixed missing #include in >=3D4GB patch. >=20 > Changes since v1: > - Added a patch to classify SEV-SNP memory above 4GB unaccepted. > - Fixed style problems in EfiMemoryAcceptProtocol implementation. >=20 > Cc: Ard Biescheuvel > Cc: "Min M. Xu" > Cc: Gerd Hoffmann > Cc: James Bottomley > Cc: Tom Lendacky > Cc: Jiewen Yao > Cc: Erdem Aktas > Cc: Andrew Fish > Cc: "Michael D. Kinney" >=20 > Signed-off-by: Dionna Glaze >=20 > Dionna Glaze (4): > OvmfPkg: Introduce CocoDxe driver > MdePkg: Introduce the MemoryAcceptance protocol > OvmfPkg: Implement AcceptAllUnacceptedMemory in CocoDxe > OvmfPkg/PlatformPei: SEV-SNP make >=3D4GB unaccepted >=20 > MdePkg/Include/Protocol/MemoryAcceptance.h | 40 +++++ > MdePkg/MdePkg.dec | 3 + > OvmfPkg/AmdSev/AmdSevX64.dsc | 1 + > OvmfPkg/AmdSev/AmdSevX64.fdf | 1 + > OvmfPkg/CocoDxe/CocoDxe.c | 175 +++++++++++++++++++++ > OvmfPkg/CocoDxe/CocoDxe.inf | 46 ++++++ > OvmfPkg/IntelTdx/IntelTdxX64.dsc | 1 + > OvmfPkg/IntelTdx/IntelTdxX64.fdf | 1 + > OvmfPkg/OvmfPkgIa32X64.dsc | 1 + > OvmfPkg/OvmfPkgIa32X64.fdf | 1 + > OvmfPkg/OvmfPkgX64.dsc | 1 + > OvmfPkg/OvmfPkgX64.fdf | 1 + > OvmfPkg/PlatformPei/AmdSev.c | 5 + > 13 files changed, 277 insertions(+) > create mode 100644 MdePkg/Include/Protocol/MemoryAcceptance.h > create mode 100644 OvmfPkg/CocoDxe/CocoDxe.c > create mode 100644 OvmfPkg/CocoDxe/CocoDxe.inf >=20 > -- > 2.39.0.314.g84b9a713c41-goog