From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from NAM02-SN1-obe.outbound.protection.outlook.com (NAM02-SN1-obe.outbound.protection.outlook.com [40.107.77.54]) by mx.groups.io with SMTP id smtpd.web08.4.1619208132604458907 for ; Fri, 23 Apr 2021 13:02:13 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@amd.com header.s=selector1 header.b=wEkCglIl; spf=permerror, err=parse error for token &{10 18 %{i}._ip.%{h}._ehlo.%{d}._spf.vali.email}: invalid domain name (domain: amd.com, ip: 40.107.77.54, mailfrom: thomas.lendacky@amd.com) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=JPzcwf3eOkNUMazjhxRvyXHAPSvzeC7foG4aq2MZG8Wt32rFmiz3HA5H6tlkDP+dQeskkJVmoJu6ir5wOWgIqRuANKGzPECRbQhK9S3hYgYF1/dVnGi0FriDF5mkucDCWVgZyTtvGxou6EcVsKKkPgGDrVd4n2CPmMGyWMYZlx8YLOez8MfMiRy64ikP84NvExjeLTMK3ApB1bUuFRF5g5gLhmhSPTdcySWysBHMmnm7e6ols7a2ANAuJ703Fp4qnartFn4dlHg5t7WpJPAJeOD6/FEo/D6RPjCGeJZkCjnK66VZpZB74pvYmPH0rzeteTL7D9eVT7m6z4jYttTrDQ== 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=kxNO66ewmJ6cpM0LPGvEhhMNEJ3BnOr9nbgiZ4yl/v4=; b=QLZC03Uh97rJtRerL9XhQARUJq8LW1VorWDSsCOGkrCHNjqnGbPTODLsEtXwdeFuv4mSBqla1YfTAW5+KQX5O9ei9t/06RDVn0BjDkf7dDjXpQU4Lfo1XTvNG9ZIylfDA8HxKWUTtmj3Ot8WRDFoUwIxjXg8FBVwQib5Xkyt7breIcZusVELziVAEQmCfRV0iS03HBwuW9+6Q8RVASQy5jXqDBjGuBbSkTOFhGcxQrguGZfaeqCstiHXrOzuBWWt7uwHAP5x7ePhKdshdoSt99ZGQU4o91JrmwgxluDstikZFSP7d8npMr6m30zlN+IJnI9ZZhonPM8KH6qoTb7sCw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=amd.com; dmarc=pass action=none header.from=amd.com; dkim=pass header.d=amd.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=kxNO66ewmJ6cpM0LPGvEhhMNEJ3BnOr9nbgiZ4yl/v4=; b=wEkCglIluhRx9sePYr+wLaEyOFxB5r7P8Kndl9znDWHe2TVPbBvlpKMl7lJhvusBA3iwdqbiB1tnYYTDJpLIJdwKR3US+pTWjJpOXvATYty6o2ekFhVO/BEB+8VePfrKWKlUEGbZKIr/FEeh5LfBnw0xM3JRseU0bBH6w2oDEhs= Authentication-Results: intel.com; dkim=none (message not signed) header.d=none;intel.com; dmarc=none action=none header.from=amd.com; Received: from DM5PR12MB1355.namprd12.prod.outlook.com (2603:10b6:3:6e::7) by DM5PR12MB1450.namprd12.prod.outlook.com (2603:10b6:4:3::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4065.23; Fri, 23 Apr 2021 20:02:10 +0000 Received: from DM5PR12MB1355.namprd12.prod.outlook.com ([fe80::b914:4704:ad6f:aba9]) by DM5PR12MB1355.namprd12.prod.outlook.com ([fe80::b914:4704:ad6f:aba9%12]) with mapi id 15.20.4065.023; Fri, 23 Apr 2021 20:02:10 +0000 Subject: Re: [edk2-devel] [PATCH 3/3] OvmfPkg/PlatformPei: Mark TPM MMIO range as unencrypted for SEV From: "Lendacky, Thomas" To: devel@edk2.groups.io, lersek@redhat.com Cc: Joerg Roedel , Borislav Petkov , Ard Biesheuvel , Jordan Justen , Brijesh Singh , James Bottomley , Jiewen Yao , Min Xu References: <1f64ca5689ec86c427e4db8c41da598896dca4ba.1618959281.git.thomas.lendacky@amd.com> <8417023b-b3d6-5268-e92a-0c6f5ebfff6b@redhat.com> <4261e15a-84a0-11a7-2981-9eeb538f6da9@redhat.com> <311cdc78-d818-bea4-16a1-01077bfc1140@amd.com> Message-ID: <21f40236-88f6-5886-1345-5a8b9ac1f732@amd.com> Date: Fri, 23 Apr 2021 15:02:07 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1 In-Reply-To: <311cdc78-d818-bea4-16a1-01077bfc1140@amd.com> X-Originating-IP: [67.79.209.213] X-ClientProxiedBy: SN7PR04CA0231.namprd04.prod.outlook.com (2603:10b6:806:127::26) To DM5PR12MB1355.namprd12.prod.outlook.com (2603:10b6:3:6e::7) Return-Path: thomas.lendacky@amd.com MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from office-linux.texastahm.com (67.79.209.213) by SN7PR04CA0231.namprd04.prod.outlook.com (2603:10b6:806:127::26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4065.21 via Frontend Transport; Fri, 23 Apr 2021 20:02:09 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 2bd1d1d1-b8de-458a-86b3-08d90692add9 X-MS-TrafficTypeDiagnostic: DM5PR12MB1450: X-MS-Exchange-Transport-Forked: True X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:9508; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: DYO6LVgNtr3WJMR/wx3rcyBTyza5FrFH/oZbUTBnH5CDQCCc2u8q+jI6rnHBj+HqIaqjC8qxB5nsBXdBTKI+9aZY+6UxtgYsowj7w50WcnMJQ1zfgvz8bQoYAQSKIvLS8483eRp8FbCU3b3x6pNCqn0CvLRzW74gaN199VAo/zNqhO7a8oTnTF5PLtXlLe9uLZoxiYdKbNEOsibferTogmZMHfEgX5+zBbb6yMH+G7gufZ5gpkfE3bIUTgyGpMwmU7IonxTaSaQGPLa85bmpK10IGKylXNoWFRXFPXldMWoRk1bAe5U5/Mqd8RWO3GpsGcYcSj7F8DCIlE/QXJUnHepcBjEYU0Qj7b9AUXJtj8yn11BdJ8yhL2xyqTvENX3uYWGWLDAT8E5Owh8OTiwlbxdQ3puAVcV3+wbHrd0DsnheNqf1DV0mYSQFuXMkNfdKbs+yFMhkdT9ISyhezY45rEliem3G1CYI0apBGNg/f2vj+5bHz3iEvLL2mRZ2X5AQeC03NeR7E6vTDYVkHF5BqgKakQUzO26YFG/3cxerxRlZJq8spUL/bD3fUbdoySUsrtaRKL6XsgMIrXHeO9ppnCmg8W0ExNQtrvKezJtpqqWQDsbxCdSkNvGmCcyFXh2qOnFnc0xaqjsVeydTp0EqqDM/oUKRrVe1w0P9zzblxSOle6QVE7YPb0omCQnLrYXGoXqms5qcjRrnfL5uzAbiXpqnBjdLmvR2k7myeQ5mPM4TjcEeiq/ag0222U6zjj5pypziqOemxbPaYefExPm2Hg== X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DM5PR12MB1355.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(4636009)(366004)(136003)(376002)(39860400002)(396003)(346002)(6486002)(6506007)(53546011)(83380400001)(86362001)(31696002)(36756003)(26005)(478600001)(316002)(2906002)(38100700002)(8936002)(2616005)(4326008)(66476007)(30864003)(8676002)(66556008)(66946007)(54906003)(186003)(6512007)(45080400002)(5660300002)(16526019)(966005)(31686004)(956004)(43740500002)(45980500001);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData: =?utf-8?B?U2lwOTJaWDVSaVZGT28rSXJIbHBTeEthMTArWkgvVXhkUVg1TXNXR05QVzdU?= =?utf-8?B?ZTB2SXFVak4xZkJJWStVc0lpYmtUYnd0ZFZnQUp6elZmRy9rWk9aaFBqQjlD?= =?utf-8?B?K1lrYlpIOEx0UVJSWitnbHJJeUJib3RVZG9aUXhQbmFZSXJ0VWMzaFNlUUtj?= =?utf-8?B?M3U3YmlySkpzL3RIU3V6YnRzUGhvSWFuTGlLMTlNUi9MWWl1RjdPM1hkbERL?= =?utf-8?B?NTVaWUVEMEJMRDRaa0hCQ1ltd2hLNitFMnNVTmlzMnhkTWhpZDVQVWJES3JW?= =?utf-8?B?M0ZpSENMaDF5RjR3ZCtRd1lHVzR0MnU3aHM3a01ONWhpaSsxRDQ1YUVhVndH?= =?utf-8?B?MEt0UU5YMUZ2Vmp4KzNhdGRzM2VsTG1udTJkT1Bjc2FMNHlKMytORkFaMzlq?= =?utf-8?B?QUQ3ZEpsc1E2M2RuRHk5azZOKzc3TGdQLzhLLzNNSUVSSXo5MytaaTdCelFr?= =?utf-8?B?UzhoTmRPd0c3dlA2RmVVWmJnQTNyT3VEeTMyQzdxalJzWWwrQTdYQjk4S29F?= =?utf-8?B?ZmtYQnRLTFB6M1lGWGF3UWExWExiQXZ2c2VVWGdqUDdQc3VDWDJPMVFnQjQ4?= =?utf-8?B?N0NaZWNTT3Yrb1BiRmhhbm5lMnMzRzRwcG1tM2RMZ1NBalRWQXBoWVJlTW5o?= =?utf-8?B?K3ZXcDlNTUR6UllsbXA2bkoyanJGN3ZBOC9HWi9xRDgwN2p2VlBodDluT1Zo?= =?utf-8?B?a3dzWC84VzRxblJWUVFxSFVZZDVQWHdBclFSdHI1Z2d4N3RGWklHMnE0aHNm?= =?utf-8?B?V2RuaEV1dmxtS0JhdCttRnAxdXcvcDNBcVplN0NFN2hpc2F0YVRMV1dFN3c1?= =?utf-8?B?bHdJUzZ3T1JUbzRja2EzcjBCbWNFUlJ6UENJZmIveWhDbHh3eUJrdXFXQTQ4?= =?utf-8?B?NTJCc1F6dnJZM2xSOHdHckVhdzFzSWJNazNocTJOWk9kMEs5MUplc3RoQVp0?= =?utf-8?B?OVhHeGZFZHNlZ2dVZHZOSXVjOWwwdk1ISUwvcU1EeHJrZFErWURLN1o5STIy?= =?utf-8?B?YUx0T1d0UTJRc1FIMDBVVzFQSEJabWNHaG9iQit6ZXlNTDVsOEJ0d1A0TXhh?= =?utf-8?B?aXBIU0EzSzVOa05WUjZqcXM4ZDQveG5jcktmSjdhVlk1NGNxOUhtV3RFcG5G?= =?utf-8?B?RzJ1OUw1K2JpbFk3T0pyMUs4VzhJYWlCd0lIMTRDdWwrQm1ZeUducmRmbWhV?= =?utf-8?B?c3EvYWQ1VjRkMUo5QkVNQXV5OVJiWkQ5K0tPRmFCdWxiVm1QeWloUEYwY1FV?= =?utf-8?B?UFRpN3h3YUFFVnJ2NHhmY3ZraVFxc052RHNTakpBaDhEcGxMSHJZejQ3NTFY?= =?utf-8?B?UkJjcDVaWTl2b1VYZmNUUXRndHdZYUlLbnZVNnFGZUs1K3g0TUh0Q3J2eGZG?= =?utf-8?B?M2dWeXdyU3ZZcVlaK2VnVm9tYmtUbU9NcEQ3ZTNxQ0g2VjZlenZCS1BFekpH?= =?utf-8?B?Vno3bzZMeGlMVlFBQzhDd0I4cUEyWGt2MkUyV01HVzA4NTFLNytZbnlvN0Zm?= =?utf-8?B?V05NS0lYS2RWQXAvZDUrUmNKNko0di9FdVZKWFN3K1ZTbXpPSmEySnc2WCtU?= =?utf-8?B?Q21pMVdCVnFtaUpTdUliMUZJeUdEM3JCWlUxTjlaTWRKNTNRQTdxM0Ridzkz?= =?utf-8?B?QmVFRXYvTFAzM0IyR1hFM2QrVG42aFhrckl6eHhZR1FFb0ttdVVhRTdIL1o2?= =?utf-8?B?SVZNYUdPSjlOZDZRb2oySU5wN1QxeG5hTFlmWncxMVZxQjI0Z1VFZTVwMGpz?= =?utf-8?Q?k9eJLWp5rgYNa7lVASrj2NNlMQdQ9vauVSQ9Fyx?= X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-Network-Message-Id: 2bd1d1d1-b8de-458a-86b3-08d90692add9 X-MS-Exchange-CrossTenant-AuthSource: DM5PR12MB1355.namprd12.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Apr 2021 20:02:10.2721 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: SKMsH5qajU6Lnmbuz4PVwORKvoBEn9EDJmWDoWoZZROKNkdgoDBNn9GN4oGHfFh0lDL0yrl99HXlEM4Dn8d5vQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR12MB1450 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit On 4/23/21 12:41 PM, Tom Lendacky wrote: > On 4/23/21 8:04 AM, Laszlo Ersek wrote: >> On 04/23/21 12:26, Laszlo Ersek wrote: >>> review#2 from scratch: >>> >>> On 04/21/21 00:54, Tom Lendacky wrote: >>>> From: Tom Lendacky >>>> >>>> BZ: https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugzilla.tianocore.org%2Fshow_bug.cgi%3Fid%3D3345&data=04%7C01%7Cthomas.lendacky%40amd.com%7Ca24cbb3f52404e466fe808d906585034%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637547798659640707%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=o2rAydWG7jenRhqbZx3oDffZhlCUimJL9f9Tpmy4etk%3D&reserved=0 >>>> >>>> The TPM support in OVMF performs MMIO accesses during the PEI phase. At >>>> this point, MMIO ranges have not been marked un-encyrpted, so an SEV-ES >>>> guest will fail attempting to perform MMIO to an encrypted address. >>> >>> (1) As discussed, please update the commit message, for more clarify >>> about SEV vs. SEV-ES. >>> >>>> >>>> Read the PcdTpmBaseAddress and mark the specification defined range >>>> (0x5000 in length) as un-encrypted, to allow an SEV-ES guest to process >>>> the MMIO requests. >>>> >>>> Cc: Laszlo Ersek >>>> Cc: Ard Biesheuvel >>>> Cc: Jordan Justen >>>> Cc: Brijesh Singh >>>> Cc: James Bottomley >>>> Cc: Jiewen Yao >>>> Cc: Min Xu >>>> Signed-off-by: Tom Lendacky >>>> --- >>>> OvmfPkg/PlatformPei/PlatformPei.inf | 1 + >>>> OvmfPkg/PlatformPei/AmdSev.c | 19 +++++++++++++++++++ >>>> 2 files changed, 20 insertions(+) >>>> >>>> diff --git a/OvmfPkg/PlatformPei/PlatformPei.inf b/OvmfPkg/PlatformPei/PlatformPei.inf >>>> index 6ef77ba7bb21..de60332e9390 100644 >>>> --- a/OvmfPkg/PlatformPei/PlatformPei.inf >>>> +++ b/OvmfPkg/PlatformPei/PlatformPei.inf >>>> @@ -113,6 +113,7 @@ [Pcd] >>>> >>>> [FixedPcd] >>>> gEfiMdePkgTokenSpaceGuid.PcdPciExpressBaseAddress >>>> + gEfiSecurityPkgTokenSpaceGuid.PcdTpmBaseAddress >>>> gEmbeddedTokenSpaceGuid.PcdMemoryTypeEfiACPIMemoryNVS >>>> gEmbeddedTokenSpaceGuid.PcdMemoryTypeEfiACPIReclaimMemory >>>> gEmbeddedTokenSpaceGuid.PcdMemoryTypeEfiReservedMemoryType >>>> diff --git a/OvmfPkg/PlatformPei/AmdSev.c b/OvmfPkg/PlatformPei/AmdSev.c >>>> index dddffdebda4b..d524929f9e10 100644 >>>> --- a/OvmfPkg/PlatformPei/AmdSev.c >>>> +++ b/OvmfPkg/PlatformPei/AmdSev.c >>>> @@ -141,6 +141,7 @@ AmdSevInitialize ( >>>> ) >>>> { >>>> UINT64 EncryptionMask; >>>> + UINT64 TpmBaseAddress; >>>> RETURN_STATUS PcdStatus; >>>> >>>> // >>>> @@ -206,6 +207,24 @@ AmdSevInitialize ( >>>> } >>>> } >>>> >>>> + // >>>> + // PEI TPM support will perform MMIO accesses, be sure this range is not >>>> + // marked encrypted. >>>> + // >>>> + TpmBaseAddress = PcdGet64 (PcdTpmBaseAddress); >>>> + if (TpmBaseAddress != 0) { >>> >>> It's OK to keep this as a sanity check, yes. >>> >>>> + RETURN_STATUS DecryptStatus; >>>> + >>>> + DecryptStatus = MemEncryptSevClearPageEncMask ( >>>> + 0, >>>> + TpmBaseAddress, >>>> + EFI_SIZE_TO_PAGES (0x5000), >>> >>> (2) Should be (UINTN)0x5000, as discussed earlier. >>> >>>> + FALSE >>>> + ); >>>> + >>>> + ASSERT_RETURN_ERROR (DecryptStatus); >>> >>> (3) So this is where the mess begins. >>> >>> The idea is to delay the dispatch of Tcg2ConfigPei until after >>> PlatformPei determines if SEV is active, and (in case SEV is active) >>> PlatformPei decrypts the MMIO range of the TPM. >>> >>> For this, we need to change the IA32 / X64 DEPEX of Tcg2ConfigPei, from >>> the current TRUE, to some PPI GUID. >>> >>> There are two choices for that PPI: >>> >>> (a) gEfiPeiMemoryDiscoveredPpiGuid >>> >>> Advantages: >>> >>> - no new PPI definition needed, >>> >>> - no new PPI installation needed, >>> >>> - OvmfPkg/Bhyve/PlatformPei needs no separate change >>> >>> Disadvantages: >>> >>> - total abuse of gEfiPeiMemoryDiscoveredPpiGuid >>> >>> >>> (b) gOvmfTpmMmioAccessiblePpiGuid >>> >>> Disadvantages: >>> >>> - this new GUID must be defined in "OvmfPkg.dec", in the [Ppis] section, >>> in a separate patch; its comment should say "this PPI signals that >>> accessing the MMIO range of the TPM is possible in the PEI phase, >>> regardless of memory encryption". The PPI definitions should be kept >>> alphabetically ordered. >>> >>> - OvmfPkg/PlatformPei must install this new PPI, with a NULL interface. >>> (See "mPpiBootMode" as a technical example.) OvmfPkg/PlatformPei must >>> install this new PPI either when the SEV check at the top of >>> AmdSevInitialize() fails, or when MemEncryptSevClearPageEncMask() succeeds. >>> >>> - OvmfPkg/Bhyve/PlatformPei must receive the same update, in a separate >>> patch. That's because "OvmfPkg/Bhyve/BhyveX64.fdf" includes the same >>> "Tcg2ConfigPei", but consumes "OvmfPkg/Bhyve/PlatformPei" rather than >>> "OvmfPkg/PlatformPei". Tcg2ConfigPei will receive the same >>> stricter-than-before depex, so something on the bhyve platform too must >>> produce the new PPI. >>> >>> Advantages: >>> >>> - more or less palatable as a concept, with the new PPI precisely >>> expressing the dependency we have. >>> >>> >>> In approach (b), the "OvmfPkg/Bhyve/PlatformPei" patch needs to be CC'd >>> to the Bhyve reviewers. If the Bhyve reviewers determine that such an >>> update is actually unnecessary, because on Bhyve, there is no TPM >>> support and/or no SEV support in fact, then *first* we have to create an >>> independent Bhyve cleanup series, that rips out the TPM and/or SEV >>> remnants from the OvmfPkg/Bhyve sub-tree. >>> >>> >>> I prefer approach (b). I'm sorry that it means extra work wrt. Bhyve, >>> but I strongly believe in keeping all platforms in the tree, and that >>> means we need to spend time on such changes. >>> >>> I'm not CC'ing Rebecca and Peter on this message -- we're deep into this >>> patch review thread, and they'd have no useful context. I suggest simply >>> including the "OvmfPkg/Bhyve/PlatformPei" patch in the next version of >>> this series, with a proper explanation in the blurb (patch#0) and on the >>> "OvmfPkg/Bhyve/PlatformPei" patch. That should give them enough context >>> to evaluate whether the change is necessary, or whether we should purge >>> the TPM and/or the SEV bits from Bhyve. You could also ask them just >>> this question in advance, in a separate email on the list (with >>> distilled context). Personally I'm unsure if the TPM and SEV bits >>> survived into Bhyve because those bits are actually put to use there, or >>> because the initial platform creation / cloning wasn't as minimal as it >>> could have been. >>> >>> Note that in case TPM makes sense on bhyve but SEV doesn't, then >>> "OvmfPkg/Bhyve/PlatformPei" will have to install the new PPI >>> unconditionally. >> >> I've had a further idea on this. >> >> You could add an entirely new PEIM just for this. The entry point >> function of the PEIM would check for SEV, decrypt the TPM range if SEV >> were active, and then install gOvmfTpmMmioAccessiblePpiGuid >> (unconditionally). The exit status of the PEIM would always be >> EFI_ABORTED, because there would be no need to keep the PEIM resident. >> >> The new PEIM would have a DEPEX on gEfiPeiMemoryDiscoveredPpiGuid, to >> make sure that potential page table splitting for the potential MMIO >> range decryption could be satisfied from permanent PEI RAM. >> >> The new PEIM would be included in the DSC and FDF files of the usual >> three OVMF platforms, and in the Bhyve platform -- dependent on the >> TPM_ENABLE build flag. >> >> There are several advantages to such a separate PEIM: >> >> - For Bhyve, the update is minimal. Just include one line in each of the >> FDF and the DSC files. No need to customize an existent >> platform-specific PEIM, no code duplication between two PlatformPei modules. >> >> - The new PEIM would depend on the TPM_ENABLE build flag, so it would >> only be included in the firmware binaries if and only if Tcg2ConfigPei >> were. No useless PPI installation would occur in the absence of TPM_ENABLE. >> >> - No need to check PcdTpmBaseAddress for nullity in the new PEIM, before >> the decryption, as TPM_ENABLE guarantees (on IA32/X64) that the PCD >> already has the right value. >> >> - The new logic would be properly ordered between PlatformPei and >> Tcg2ConfigPei, namely due to the use of two such PPI GUIDs in DEPEXes >> that actually make sense. PlatformPei -> TPM MMIO decryptor PEIM ordered >> via "memory discovered" (needed for potential page table splitting), TPM >> MMIO decryptor PEIM -> Tcg2ConfigPei ordered via "TPM MMIO decrypted". >> >> You could place the new PEIM at: >> >> OvmfPkg/Tcg/TpmMmioSevDecryptPei >> >> If you haven't lost your patience with me yet, I'd really appreciate if >> you could investigate this! >> > > So far, this appears to be working nicely. I'm new at the whole PEIM > thing, so hopefully I haven't missed anything. I should be submitting the > patches soon for review. So one thing I failed to do before submitting my previous patch was to complete my testing against the IA32 and X64 combination build. In this build, PEI is built as Ia32, and MemEncryptSevClearPageEncMask() will return UNSUPPORTED causing an ASSERT (since I check the return code). So there are a few options: 1. SEV works with the current encrypted mapping, it is only the SEV-ES support that fails because of the ValidateMmioMemory() check. I can do the mapping change just for SEV-ES since it is X64 only. This works, because MemEncryptSevClearPageEncMask() will not return UNSUPPORTED when running in 64-bit. 2. Call MemEncryptSevClearPageEncMask() for SEV or SEV-ES, but don't check the return status. 3. Create Ia32 and X64 versions of internal functions, where the Ia32 version simply returns SUCCESS because it can't do anything and the X64 version calls MemEncryptSevClearPageEncMask(), allowing the main code to ASSERT on any errors. I'm leaning towards #1, because this is an SEV-ES only issue. Thoughts? Thanks, Tom > > One thing I found is that the Bhyve package makes reference to the > OvmfPkg/Bhyve/Tcg directory, but that directory does not exist. So I don't > think that TPM enablement has been tested. I didn't update the Bhyve > support for that reason. > > Thanks, > Tom > >> Thanks! >> Laszlo >>