From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from NAM12-MW2-obe.outbound.protection.outlook.com (NAM12-MW2-obe.outbound.protection.outlook.com [40.107.244.78]) by mx.groups.io with SMTP id smtpd.web12.754.1619107490071100324 for ; Thu, 22 Apr 2021 09:04:50 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@amd.com header.s=selector1 header.b=ra2fNBXl; 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.244.78, mailfrom: thomas.lendacky@amd.com) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=CG7VgeA1IgpfrRNUXZiT/fyzsNbuk6W6Rd6+78MzFDze9JW3fa0qVGHckAg4AfI8Gji3Ubuw9zMArzpjif7chBpipe/DYPCV0ZVSoyPszRmzQyFpB7uHfAjcsOYA8r/w7pUfWse4eG/6lEdjSSJeDbKS8FZoM1fMUk6MTQ71IrBdFwBdH/rY18M/fcLwnnoHB7okW3nDIRlwUc55+fEkECxG07+GeWTzGkchP1JXdJBWSnPU+qrG/swmHswHToHmVeEHI07qp1KAPcTqAV8V8Yt75fBRS9V2dQcA0gR8BfmxvvCEgyqmpAIcQGTryqxk45GNrNn+R69eceGRLDfUWQ== 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=SzRuEXtMIPxPmFZ2icv16VPdstGuFngRXyShuXdPaCQ=; b=RGXdGgHruqiNCRxyz0S8G8EiFGv3pztlmterb5f88Ksvzum09Z2o/eCtSfXp9/sw7H/9/DaUr60c6Jjsl05sF3p2Q8i6nlBhsTtlci5BG6vnXyK49DB4zyv1UesG5UZlBqb8kYsSNbcm7QzVUbBXwNvYFLBxh9QcbOqqNk5lTo2v4pS3nTdgM9umk0De11M4ddQGw2NtxdHDuesZwtHvL8H7e6rqTK1BPKR7KRB0XiBlV4XJU+XVn0dvB/zc27nfAXERIAEe1RNpvJI5VEQFx99L/HmyNJ77R5qaw2NCS1keXD4xarvphp0cBg+NSlQ/uRuZmRMxacw7RSJyoF+7ow== 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=SzRuEXtMIPxPmFZ2icv16VPdstGuFngRXyShuXdPaCQ=; b=ra2fNBXlyZngidLweIpOBS9+lYnaUA7g2bhi4KuHhrLDeX/+514o84tT+xv5hZC0NJ4xZzImPigrBLnfNUlfnm6l48EBYDP68bmC4D6BYUHp3XS2aoKhl9C9pkrdxM1fIlf75rQXZJjwlWe8wsUjonXwPqDjsdpoW1EnMY2kyzc= 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 DM6PR12MB3580.namprd12.prod.outlook.com (2603:10b6:5:11e::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4042.24; Thu, 22 Apr 2021 16:04:48 +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; Thu, 22 Apr 2021 16:04:48 +0000 Subject: Re: [edk2-devel] [PATCH 3/3] OvmfPkg/PlatformPei: Mark TPM MMIO range as unencrypted for SEV From: "Lendacky, Thomas" To: Laszlo Ersek , devel@edk2.groups.io Cc: Joerg Roedel , Borislav Petkov , Ard Biesheuvel , Jordan Justen , Brijesh Singh , James Bottomley , Jiewen Yao , Min Xu References: <1677B2EC90F30786.1355@groups.io> <007e59ea-3933-7b93-afff-4023f3111558@amd.com> <08f723a5-9883-7785-91c0-9e5627836288@redhat.com> <372353dd-f6d3-9fa2-f79a-16840822c43b@amd.com> Message-ID: <14c7f8b7-4ea7-e04e-b786-c12d57117211@amd.com> Date: Thu, 22 Apr 2021 11:04:45 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1 In-Reply-To: <372353dd-f6d3-9fa2-f79a-16840822c43b@amd.com> X-Originating-IP: [67.79.209.213] X-ClientProxiedBy: SA9PR03CA0001.namprd03.prod.outlook.com (2603:10b6:806:20::6) 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 SA9PR03CA0001.namprd03.prod.outlook.com (2603:10b6:806:20::6) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4065.20 via Frontend Transport; Thu, 22 Apr 2021 16:04:47 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 8d3b5049-1b2c-4bb2-00bf-08d905a85a6d X-MS-TrafficTypeDiagnostic: DM6PR12MB3580: 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: LrH1UF3T4pJXhyHbmZ40zz+6cH7AwhGrfn1+MbWDFVaknFUsNho6stzkJV/AqmaF8svHyMaslQlPB3u9WGbcaMusbXnsPDTQij43rM1/FUxXOVup07+JS3GGVwexoKz3SCe7tWIFclwj4hT9RlL4NnRFpOiCfOtrKcOgZ1Y6+74NKsUmu2cLlebnhdr5oFP9XBmRe0ivDh8bmUOwyOrZ8vY3/os6pw26vc0Cfh/kY3sdrPeRHWAdpYuemkbD2RRzxN4ibO5pBFPrnyKojUMpgxprA0SHoq6ecppg3Gl8IhLZUsO2DJdofFbB+qsb5aQpAdu4a/NZ7gI33BRFsSPU9vjb4Sv4LC35GBi318ShuCm5CYsH+hrOn57f2VVIUvvvgnbG255hCLotm56Sy0eQtRpd8+vrXNtpB8p3eOH8mVpLjX2vSMXN3ordFoEUL5ccXjUjcg/UulNGndk618xsPEAKyfxU88DBLnPYRNafYenk5SW+xu0BvBOWwr+bD7Wc9VYG/pSGBYS8rBZ4naVTbMQBRxxcERhTjZWRlnqpGxDvB9PqMbepivwyBllJeiZqbvPgOk1TCKq4NPT85nEVPgGeIusDeWJ8hxvlLDkVec9he/8PawYlXYucxVerXARiq044K9iirr8RPjlB5dDLRiQl2XJ7MXIoE3V1Fyy0nbsGUik4s3r/76uIp+K3n1kW0X62UcPxMjurR2h2jBXtVy+50B7Rq7B4472QrtkkAQ5fH1F5+bq+b1hpEz5cSMA/v4ncvN/RaMuqqTDWNMpPKg== 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)(346002)(396003)(136003)(376002)(39860400002)(366004)(66556008)(66946007)(66476007)(36756003)(4001150100001)(31686004)(83380400001)(31696002)(4326008)(45080400002)(16526019)(38100700002)(6506007)(53546011)(19627235002)(8936002)(6512007)(966005)(86362001)(186003)(6486002)(956004)(478600001)(316002)(8676002)(5660300002)(2906002)(26005)(2616005)(54906003)(43740500002)(45980500001);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData: =?utf-8?B?L3Uxa1I0VXpkUHg5L1hSRi91eklVNWlWZ0c3cmt4UjFDUHZsSVJyRkFFRGsv?= =?utf-8?B?dm83M0VuMWY1MTRFam1WZDBDQTVVa09kVkZHWFZqQ0Q1Rk1La0loTWdCRmx5?= =?utf-8?B?eW5ZWHJ5aXlTWHYxNlBRcUVkc0VKVlVSQ0p2VHNiY2NwZjlGWGRlQktROEFp?= =?utf-8?B?NU1XTUduWHpDZTdnUWN3UjA3MU9rTUFaK21tL2R6U2c3N1BXeVlaRG9Ga1Zj?= =?utf-8?B?alhUa001Y3FUeEFPZ2NTSVJTbWd2S1ZxT1FDWXhwTWJDQmJNUlpHREhkTU93?= =?utf-8?B?UlpMeHNEOXBWcHNNdU1kZU85N0hqT0xBZ0puSkpFYlVWZGdvNlBJRDkrNFpj?= =?utf-8?B?ZXd5YU1IcGhYRXRVQkxHRk9FbTdRNzhxVjhxQ3hWcUo3TkVqS09SQWxWc3Uv?= =?utf-8?B?MTZQRzY1cTkwZWM4NEhRdDZxbHpSRmFWeXdmOTB2OGxKVWJZY1J2NWJTRDZJ?= =?utf-8?B?aUNWcDM2TUZLN2thMHY2eloxK3ZHVzNlbVVyZjBGWUVzRTZCNVVRWWg4S3hZ?= =?utf-8?B?UGZhQ2ZiQ3hFQlVkdEQ5bXM2dWZqY0ZnbkJjWHNGYkZHSXZDbktkWkVYQzBI?= =?utf-8?B?ZS9ZVmw2SWlody93NEVNeGp5c3AybGN0d09BWUxYeTRRNG84bjRUU3RVaFhj?= =?utf-8?B?d3kxR1lXWmtMbkZrTG9tbkdVcnQwSHhLQ1pCWkZ2aEJrSGN1VkIra3JXUnpj?= =?utf-8?B?aGNKZjdOUlhBVXlhVUpTSTZXYXgrRHlBOWVWT1B5a0I3L3RDTmZQUlRsRTkr?= =?utf-8?B?enpvaWZxaCtnNzVnbHQrNE9BSlRHRmM0aDBZTVRGY3NZUEZVZWd2U1R0VTJ5?= =?utf-8?B?UzRuakpYNnNQS21oNXZ1WVpudGpxWGlOK2pDTmRlNGUzV1dmSjhYWmg3QXJR?= =?utf-8?B?Q1l5ZG5TNFY1KytZUStkTjk5UXNmWUNGSGJFdVFnV2pwc1RmVmNBSW5US0hp?= =?utf-8?B?YlhodFpQQklTTlcxdkU5bUxrTktPZFV6ZXhyL0ZtbUpJa1FkQ0tNTFZSQ0hj?= =?utf-8?B?ck5jb1VCcmFQaWpMOHpKR0pybWdIMlFuWjY4aWk0T2lhVW1hemhEa3RweTlN?= =?utf-8?B?YjBGZy8wNWs0RkZ2dERpV3FxeEpCYjRPTGhmaSsxbTZDSXB1YTdMY1VyYktH?= =?utf-8?B?UllWUEx2ZURDSHBMMWdTbHFLRWhYK0k2aXJmUzEyL2tVMGVYeStWd0pFMDVE?= =?utf-8?B?ZnpEbnRFNVR3TGZkbWpwdkdtNi9sd3I5VWhzU3JKd1J4a1F4bFQ4aHM2QmFm?= =?utf-8?B?TFpEangvV0UyQzg0dmdHSlFrQVJhUmxuR3NsdG9VNGJoUHNsenN0WG1iNUxJ?= =?utf-8?B?bllReVc4bmh1YlRQQmdyTXllNEtzQTBzMVk0TENGUDZxWDJzU3N5c3o1Rzl4?= =?utf-8?B?bXpBdWNzMUtkUzlWYnJsd2orMXVaWFpJZFVwWEExdlhycDhxVVlSVWU5YU1l?= =?utf-8?B?K1JPUkV6eUVMK1NCYVgveXg3Y3hsRzN4Q2sxQVhMM1VCU2h0bjNOZzhHUmRY?= =?utf-8?B?RkRlazlGMGtKUzBENE15cDBmRUlHSWUrNUZyQnhKS1Rna21EV2x4QTVEanhF?= =?utf-8?B?ZFBuWmNxcVVvRS90NUJackZvdE5pSHFvK050K1JrWThHWnRKTWtTTmNkcTBv?= =?utf-8?B?U0xtcXcvWm4reWh3MFcvbzhPa3JyaEYvd0dtSGxoQlRQN0gwaWxFY1dGSFBX?= =?utf-8?B?ZnNRUnFYSkxrZExFY2ZiUEl6U1VJZTBNMmUreDJxd3lWYVdwbUJpVDN6RFNV?= =?utf-8?Q?3BVdEa84X9c8dyjgkbxBmcyc/brzwIEpCe2gY9e?= X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-Network-Message-Id: 8d3b5049-1b2c-4bb2-00bf-08d905a85a6d X-MS-Exchange-CrossTenant-AuthSource: DM5PR12MB1355.namprd12.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 Apr 2021 16:04:48.0632 (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: Aj7I6VwdbgDV7CslOcBILKHH8swjd4dbU98wTktjCt+l6VuJzyDNuS5qhvQ2ChQ8XZ77yUxAY4cKXGeqxvdIrg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR12MB3580 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit On 4/22/21 9:51 AM, Tom Lendacky wrote: > On 4/22/21 2:34 AM, Laszlo Ersek wrote: >> On 04/21/21 01:13, Lendacky, Thomas wrote: >>> On 4/20/21 5:54 PM, Lendacky, Thomas via groups.io 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%7C6b8da1f9a3bf4fb5f01e08d905613998%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637546737416495415%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=5vPlHPzGlS2%2Bqu3U4RPMITpyY%2F2ZxKJlaVYfFZItONQ%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) The subject says SEV, not SEV-ES, and the code in the patch too >> suggests SEV, not SEV-ES. If that's correct, can you please update the >> commit message? > > Yes, I'll update the commit message. The action is correct for all SEV > guests in general, but it is only with SEV-ES, where the tighter MMIO > checks can be performed, that an actual issue shows up. > >> >>>> >>>> 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) { >>>> + RETURN_STATUS DecryptStatus; >>>> + >>>> + DecryptStatus = MemEncryptSevClearPageEncMask ( >>>> + 0, >>>> + TpmBaseAddress, >>>> + EFI_SIZE_TO_PAGES (0x5000), >>>> + FALSE >>>> + ); >>>> + >>>> + ASSERT_RETURN_ERROR (DecryptStatus); >>>> + } >>>> + >>> >>> Laszlo, I'm not sure if this is the best way to approach this. It is >>> simple and straight forward and the TCG/TPM support is one of the few >>> (only?) pieces of code that does actual MMIO during PEI that is bitten >>> by not having the address marked as shared/unencrypted. >> >> In SEC, I think we have MMIO access too (LAPIC -- >> InitializeApicTimer()); why does that work? >> >> Hmm... Is that because we're immediately in x2apic mode, and that means >> CPUID plus MSR accesses, and not MMIO? (I'm reminded of commit >> decb365b0016 ("OvmfPkg: select LocalApicLib instance with x2apic >> support", 2015-11-30).) And, we have #VC handling in SEC too. Missed this question in my earlier reply... LAPIC access has a dedicated check in ValidateMmioMemory() to allow access in this case. Thanks, Tom >> >> Anyway: I think the TPM (MMIO) access you see comes from this PEIM: >> >> OvmfPkg/Tcg/Tcg2Config/Tcg2ConfigPei.inf >> >> The driver uses the following library instance: >> >> SecurityPkg/Library/Tpm2DeviceLibDTpm/Tpm2DeviceLibDTpm.inf >> >> This library instance is what depends on "PcdTpmBaseAddress". >> >> And it's not just that decrypting the TPM MMIO range in PlatformPei >> "looks awkward", but I don't even see it immediately why PlatformPei is >> guaranteed to be dispatched before Tcg2ConfigPei. The effective depex of >> Tcg2ConfigPei is just "gEfiPeiPcdPpiGuid" (on X64), according to the >> build report file. If Tcg2ConfigPei runs first, whatever we do in >> PlatformPei is too late. >> >> I also don't like that, with this patch, we'd decrypt the TPM range even >> if OVMF weren't built with "-D TPM_ENABLE". Namely, OVMF uses >> "PcdTpmBaseAddress" as fixed (not dynamic), inheriting the nonzero >> default from "SecurityPkg.dec". (In ArmVirtQemu, PcdTpmBaseAddress is >> set dynamically, which is why Tcg2ConfigPei has an ARM-specific depex >> too.) >> >> >> (2) So, can you please try the following, in the >> "OvmfPkg/Tcg/Tcg2Config/Tcg2ConfigPei.inf" module: > > I'll take the input from each of your emails on this and see how that all > works. Thanks for the insight and knowledge! > > Tom > >> >>> diff --git a/OvmfPkg/Tcg/Tcg2Config/Tcg2ConfigPei.inf b/OvmfPkg/Tcg/Tcg2Config/Tcg2ConfigPei.inf >>> index 6776ec931ce0..0d0572b83599 100644 >>> --- a/OvmfPkg/Tcg/Tcg2Config/Tcg2ConfigPei.inf >>> +++ b/OvmfPkg/Tcg/Tcg2Config/Tcg2ConfigPei.inf >>> @@ -20,13 +20,16 @@ [Defines] >>> ENTRY_POINT = Tcg2ConfigPeimEntryPoint >>> >>> [Sources] >>> + MemEncrypt.h >>> Tcg2ConfigPeim.c >>> Tpm12Support.h >>> >>> [Sources.IA32, Sources.X64] >>> + MemEncryptSev.c >>> Tpm12Support.c >>> >>> [Sources.ARM, Sources.AARCH64] >>> + MemEncryptNull.c >>> Tpm12SupportNull.c >>> >>> [Packages] >>> @@ -43,6 +46,7 @@ [LibraryClasses] >>> >>> [LibraryClasses.IA32, LibraryClasses.X64] >>> BaseLib >>> + MemEncryptSevLib >>> Tpm12DeviceLib >>> >>> [Guids] >>> @@ -56,6 +60,9 @@ [Ppis] >>> [Pcd] >>> gEfiSecurityPkgTokenSpaceGuid.PcdTpmInstanceGuid ## PRODUCES >>> >>> +[Pcd.IA32, Pcd.X64] >>> + gEfiSecurityPkgTokenSpaceGuid.PcdTpmBaseAddress ## SOMETIMES_CONSUMES >>> + >>> [Depex.IA32, Depex.X64] >>> TRUE >>> >> >> In the "MemEncrypt.h" file, declare a function called >> InternalTpmDecryptAddressRange(). The function definition in >> "MemEncryptNull.c" should do nothing, while the one in "MemEncryptSev.c" >> should check MemEncryptSevIsEnabled(), and then make the above-seen >> MemEncryptSevClearPageEncMask() call. >> >> The new InternalTpmDecryptAddressRange() function should be called from >> Tcg2ConfigPeimEntryPoint(), before the latter calls >> InternalTpm12Detect(). Regarding error checking... if >> InternalTpmDecryptAddressRange() fails, I think we can log an error >> message, and hang with CpuDeadLoop(). >> >> (An alternative approach would be to call MemEncryptSevIsEnabled() and >> MemEncryptSevClearPageEncMask() regardless of architecture, i.e., also >> on ARM / AARCH64. In addition to that, we'd have to implement a Null >> instance of MemEncryptSevLib, and resolve MemEncryptSevLib to the Null >> instance in the ArmVirtPkg DSC files. But I don't like that: the library >> *class* carries SEV in the name, which is inherently X64-specific, thus >> I wouldn't even like the lib *class* to leak into ArmVirtPkg.) >> >> >> (3) If the approach in (2) works, then please don't forget to update the >> patch subject (it currently refers to PlatformPei). >> >> >> (4) The argument of the EFI_SIZE_TO_PAGES() function-like macro should >> have type UINTN. The constant 0x5000 has type "int" (INT32); please cast >> it to UINTN. >> >> (In fact I would prefer a new macro for 0x5000, somewhere in the >> "MdePkg/Include/IndustryStandard/Tpm*.h" files; but I can see that >> SecurityPkg already open-codes the 0x5000 constant in >> "Tcg/Tcg2Acpi/Tpm.asl" and "Tcg/TcgSmm/Tpm.asl", so meh.) >> >> Thanks >> Laszlo >>