From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from NAM11-CO1-obe.outbound.protection.outlook.com (NAM11-CO1-obe.outbound.protection.outlook.com [40.107.220.43]) by mx.groups.io with SMTP id smtpd.web10.487.1619199681732251505 for ; Fri, 23 Apr 2021 10:41:22 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@amd.com header.s=selector1 header.b=Oj647ZcV; 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.220.43, mailfrom: thomas.lendacky@amd.com) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Dl10BR7Ql8Ckq4MjGdNBuCdobE45S6laPvHOwBLhcLz4y20H634BRyRrEa5p52tF0fCa+pKyV77/0imDkkjbn8+aW3eZmoctdu0HzsBvVlr3KQ0cKcLWwSrBvXmHG86guyeY5zeTAWcPXABK7xkZBiLLUH7A+WzkbxC9m4AhR8ONKeyIOptpg01wIBjx+VPH72AWlqOgRVkB2QobvRVRq5ZopWOW//GfsNrM0mRnYP8vRDfo8tOJn7G0NZyuei4xuXZhzfRvarz+/q+itZUC2q7lKY5ujxHsLQ4MDwOe8jmh+AZMoi8sb3+tEtyct3w+rB6qVgVIVG72t0j79lc1uw== 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=ycohwwaxHWoGoEei2BH7ai9TVYuLB+ycbxtCERF08eA=; b=QR1DerAdvOhTfGmoY1KL8DFnQm3xoTCwc7+8XwU87xnA9h9LPrzPjmnBXpvaDU/azbToTNncTNszEJTHl73tplcy2vAenm4/sdW265oK/5/aahus24/xoEiI0S67wNKSboQD9bgbkVlOZTb+eRBWlHtjBd7CQYGg6k+gKqym2nfZxrz4OYqEHKVgkkNqGfAXsDbBzzRs+QKAfaCEQrY2pEEd5vN37kjbTcTsJ5yYC3wS0uhn396NxhNSGItYYpITbjZVUndHBptIT0+CcjDdtNqs9i1twmPKD5uIZAdKjA21aVamIjVM0YISG+EA1vYT5L4w9c3ub5kd4Sk8zfI6Dw== 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=ycohwwaxHWoGoEei2BH7ai9TVYuLB+ycbxtCERF08eA=; b=Oj647ZcVuZKaITmE3joAU5UH30Wn02JcTF/u/cBoKnTi+o9ffssZPif5vRjuatjk9GPorGohVCe3STTczZQf+Gq979SBP4QiQWtAJ64sFvA7GiiWj76QYWOtMv1JJW6bpkdDfGaxIUdRU2+546S6x7waelwPldTk8B0odWVsiPQ= 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 DM6PR12MB2795.namprd12.prod.outlook.com (2603:10b6:5:41::32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4042.21; Fri, 23 Apr 2021 17:41:19 +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 17:41:18 +0000 Subject: Re: [edk2-devel] [PATCH 3/3] OvmfPkg/PlatformPei: Mark TPM MMIO range as unencrypted for SEV 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> From: "Lendacky, Thomas" Message-ID: <311cdc78-d818-bea4-16a1-01077bfc1140@amd.com> Date: Fri, 23 Apr 2021 12:41:16 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1 In-Reply-To: <4261e15a-84a0-11a7-2981-9eeb538f6da9@redhat.com> X-Originating-IP: [67.79.209.213] X-ClientProxiedBy: SN4PR0501CA0094.namprd05.prod.outlook.com (2603:10b6:803:22::32) 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 SN4PR0501CA0094.namprd05.prod.outlook.com (2603:10b6:803:22::32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4087.16 via Frontend Transport; Fri, 23 Apr 2021 17:41:18 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 76950bc4-1923-4233-79f9-08d9067f0076 X-MS-TrafficTypeDiagnostic: DM6PR12MB2795: 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: mD86jWi/ASqUnBtGtvHKEEtIt8Yyq9atpIgADAw8vqLFo+02WtPdDEJkC0mao5qHVAq/5p6I29SLIvRHtKE/nF+/7BawWZTFWhvArHJnYJ16Jjos25fSBh6fMj8ZEjSbBDgK2nWZX3mcd1kIl9aVR7Sbc//0jQ7EK8T0AXAp4sBnIq/4ysIK7Hj1p8zSe+W144oM1zOEQiHbDil4f1fszMEhKNvDAaElK6PA8JMyw6YjoN4i/hNH+24DYYeJjvKFbs1HBtWs299n+eL3eBuuu1hqrPTRssJPgC87BDw4ZYWXaF+4CnW8xTh3NVGfyTH5hqVklAPlahTCgvlZNF25gpg3133DQo6D+I5RCFSNj5OlrmzrxrPZdeRYf8WfmSFYmON03sBBA0jcWecH00te2RfYldr3bNZPJ0MZQf28QxAQ0QmWE/4QlmYCoNyngnv/GTs6Q2mcM5/IlEn2mf9GOgUoE56NuXJiZ0tMR/tCNqHuPnCE5ivKSJphm2u8fijbujLfP4TTkOW3pm9wbAI1vI3yFAL5/4Jj2uiV0jOUUNbGui37LVw+zBRS3OYO/Q4FN152wJ0O/mqx0FDQCRbVUVHr/F/Bi1F1DTF/SBV5ZcdYXtlrjFS7nIqq89bwtvP9VshK9rumsconocJM2TbnHU8sa0GUTFBKq8QZfEAJ207gROTa0FJ3Chly6zVpfMklXOy6s9H9KxpRfK77FuxY2nRohQCOzTNwddY1ccMqkGDFRM9YY9VbPGve4pG4xm2VAyev4s3rFPC3pJLt4G9oWg== 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)(39860400002)(376002)(136003)(396003)(346002)(66946007)(4326008)(6486002)(16526019)(26005)(316002)(186003)(36756003)(66556008)(6512007)(966005)(86362001)(66476007)(45080400002)(31696002)(478600001)(6506007)(956004)(83380400001)(38100700002)(54906003)(2906002)(31686004)(8936002)(53546011)(2616005)(5660300002)(8676002)(45980500001)(43740500002);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData: =?utf-8?B?LzAxMmF4SXNIZnYwT09BRjc1QTNxU3czTlhtSTl5TnRiL0h6WHF5UVNtQ1Rj?= =?utf-8?B?UTRPNkE0S2x0bmZSUXFvbzQ2eE0xRXhibjhxUUlaTzJhTU5uR0twclFuS3hV?= =?utf-8?B?Nm1QNTZTSG9zbFEzTnJjU3J0T0IrUCtTczhyNmVFbWp4MWRQNnpySW1zT3Ja?= =?utf-8?B?NU5YNmltSW1kSXBJeWIxWlRIdlgvYXMyd1A4ZENubFVlUmJlaWNwc1NjUXMy?= =?utf-8?B?MDJmQm5XQlRRYnN6NHVZdFJsZktNTUthMUY1OTd3aGJLT1ppRWFCMzkzNzZT?= =?utf-8?B?MUlSQWZhdEtJVXJRRGhLSE1jYm9QUHhXb1kvZEQyek5UOFcydE13SW96dHpL?= =?utf-8?B?TlhzQVRaOVhlYnEzUWtFNkZVMXJRZkUxYUd0VG85cUlPZnk2Tm9RMDY4Rk1m?= =?utf-8?B?cmN5V3BnVFRDS0MrMXNBUk56MHVyMVNHcUxwdnJlTk9hQnpjL1J0cm9sd2tE?= =?utf-8?B?SlpjVmZNWTZnTnpJc0JvNzVFVHBScTJ0TmdoK0liVG0wME9nTTFySGF0UlBu?= =?utf-8?B?eVZlenlWUzh6bGRaUlpjRmpCL3pyZlUyZHVuUTVmdktyeEVPV2M1UXFpK2kz?= =?utf-8?B?MXRPSXkxWjBzRzVqL1NkeG54R3doTWZSQkhxaGN3NHRrNmt0ZzRNZzhURnhB?= =?utf-8?B?R0xlNHprSW0yVy9JeWpwNVhwS1lmeVhjamVwbkUwbVczcExsNmQzYnovY2l0?= =?utf-8?B?OHhyUkxZTHRBNFJzTHdmVE9TQnhWY2NPbFF3M3N1UTVqSUdXQk5nVlJ1SFdj?= =?utf-8?B?TktLVVRGMDVyY0lFNUhOQlM4Z25ac1l5cEMyRi9MZmVnQjh1ZWlxay9yamRH?= =?utf-8?B?dEswTWpTSkVjUWxKZWFLL2xvZ2dRTEk1S3NmaVBSK2MzNmYxSWo4dE9ubWJC?= =?utf-8?B?SG5sVkRFN2hmUzQvQlpvZGFpa3BTVEhNbytaTTVmcW1UbWU2MThNeEo4Wjdp?= =?utf-8?B?ZUQyVGJQaDBnL3U1WExmcGJGU09PSExnc2xhZERiczg1b0JPWHpqaGxhdFBo?= =?utf-8?B?U0JtSzYyeGk1L01IcXBDaFhVSDFRY1BPTHVveXRWWmlyNGs3Y2RlV3pIR2oy?= =?utf-8?B?ZmVyMlBQd1lXaGZkN2g5Tm1WWloxY1RKMWZyd1dnbnhPeEVXN0xjUXJpN3FQ?= =?utf-8?B?eHFYMElsSlJ3UUcvNHlkcFJYOE5zM0V2bDdKdXVybDB3RGZyQlFVamNFWTRU?= =?utf-8?B?bjFUT2lJTTlZSHVoS0QzZ3dVZzU5N1hvR0VUU2F5RmxwRmdCRzJMdUtHa05o?= =?utf-8?B?THJOVERGSkNCdTBrTDJwUlRuYVNUQ1hnQlljQkgzYWFMWUFjYU1qTkdLK2wy?= =?utf-8?B?Q0JZSGx4U1BXYTEvRXpaWWd4SEVyL0FKVVBPc3JEMENNa0wzY0xUOC9IY3p4?= =?utf-8?B?dDVJeXhUY3RvSEJmQXJlZy9VTSt3WklIa1pGS0NJbng5MmlaY0llZVhLNmR6?= =?utf-8?B?UjNwVDAwU1o5Q0N4Qk4wUXpiOUh5TXAwMUZxaDZRWmwwdHArakpjRjh5UUtj?= =?utf-8?B?T3ArRXZmaWVsNjZ3WXU3MCtFL1FxamoyZEgvVi8veTNnUGY5NjFIaHRSTkcv?= =?utf-8?B?eDhLYjRSamRGOEFDbjQrN08yeTd4UmpWMlpWWi9LS2RabXN2Y0E2U05Tckdq?= =?utf-8?B?VFp2NjYvZTNMTHk4azZNcjBNV2lDYllvbnBXbnZJak0zajJKNUZDY3g4T09G?= =?utf-8?B?NC9rdll0cTliWXhVSDBGSWVGNlhLMkU4b25sOUI3MXMvNWw3ejBMNUljVVoy?= =?utf-8?Q?HK80YcmWPLSc1o5w3ObCOkQqmI/oyJoVSlNmXpk?= X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-Network-Message-Id: 76950bc4-1923-4233-79f9-08d9067f0076 X-MS-Exchange-CrossTenant-AuthSource: DM5PR12MB1355.namprd12.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Apr 2021 17:41:18.9203 (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: onek4tq2KkGCKxggY4ZivHotoPxCT268H1GxqDFjRDWA2dHbXRyhPNpudfJEpd7W7auDACxpU28MrPvp06tG7w== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR12MB2795 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit 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. 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 >