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.83]) by mx.groups.io with SMTP id smtpd.web09.845.1619804259472251004 for ; Fri, 30 Apr 2021 10:37:39 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@amd.com header.s=selector1 header.b=dzSq1utH; 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.83, mailfrom: thomas.lendacky@amd.com) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=MoUQUlP5pV7a2s+16exd9pa+KlZgLcz4PV8OdjUlAwCzascVkevMD2P/4iRSBpKqquacxfOO+nkXjHc6gK1u/pq0NH2i7AxF0QzfyzIiYiyVwmu/x/dohOXl91EcKRK0XNBp/v1ykHYthYv/LmmOjDgcV9v9zxjTXGLV02vH7/ZZVk7c/C4Oz8tqcyNRicCPb5Dg7V3j0I59R4ZqXVASMnBszP6SaqmcG82dqulXdKe1bvYIxr1M+WoicbNl9l4AFEVrPZH2QL+3dLNrdsKxy5qNqNkaGkdsA8s3YCCtADtx8VuWyh+/mu43ywlt7NsVNr9wJd5wrmsSlJJH4brrPg== 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=r3xECuYcBe23a7BuSoM6h8iYPhOuj1w9sucuK0j7UmA=; b=OC4wt/vnG6F0QOyIotDnoESrQKOEPZ7SAiLJHN9Ucoq+R/7rlKNPKv6MujWuirzjXXklDR9YnbZp/7366/KGooyk0pZelEiD/dx7CzIXrTZz+yiXKyHL4MnHBEmjuzkGNb8UMz65opgofhX6idEaGcbhIR+dW45+d9yWTyePsy+UA6MykP9fsI/JvoDkeEv0ncUYvkWlLvJXJAedM3D6nms4L50g5exAOKQCkYFxKC/E71efNFEF4FWsohKbYM8XbzjSbpEE3tS9W4BgGAOhG5uHQI2YLRUTKU2pxirV2rsQpYc5OIzT4NJNF8nDCZe9KQqktG3JdHos7w7hsTCM3g== 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=r3xECuYcBe23a7BuSoM6h8iYPhOuj1w9sucuK0j7UmA=; b=dzSq1utHNEvHbNkzqrMIlTzKbXmOuZVpkDFatFQiYg/+aGqHrNklihX0caf1QO9LZ9JoLiDOTM7Pv7st5Su8/d1ZsAB9RlHJPEGZZrOuQKVhFyrW798p4BrBckOdRKH85QhWo3iiCWPUvR9df85ao/L1xiXLH4B1lZ2CaGjMOIM= 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 DM6PR12MB4353.namprd12.prod.outlook.com (2603:10b6:5:2a6::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4065.25; Fri, 30 Apr 2021 17:37:37 +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.033; Fri, 30 Apr 2021 17:37:37 +0000 Subject: Re: [edk2-devel] [PATCH 3/3] OvmfPkg/PlatformPei: Mark TPM MMIO range as unencrypted for SEV 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: <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> <21f40236-88f6-5886-1345-5a8b9ac1f732@amd.com> <0ad9369d-d863-5bfc-1326-ff4b631bd04e@amd.com> <3f2e589d-7258-c372-c1ab-60992351dbde@redhat.com> <5051e966-f47a-3a19-6523-2a536d236505@redhat.com> From: "Lendacky, Thomas" Message-ID: Date: Fri, 30 Apr 2021 12:37:34 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1 In-Reply-To: <5051e966-f47a-3a19-6523-2a536d236505@redhat.com> X-Originating-IP: [67.79.209.213] X-ClientProxiedBy: SA0PR11CA0074.namprd11.prod.outlook.com (2603:10b6:806:d2::19) 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 SA0PR11CA0074.namprd11.prod.outlook.com (2603:10b6:806:d2::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4087.28 via Frontend Transport; Fri, 30 Apr 2021 17:37:35 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 34ee6d08-efb5-41bd-2163-08d90bfea4f6 X-MS-TrafficTypeDiagnostic: DM6PR12MB4353: X-MS-Exchange-Transport-Forked: True X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: sOOpsCmIWjTrubac2YcIrXOjDILldOEz8vGucDcm0ZDJnewgJUkGG7728QUZcBXb1BXcsyPCjVIPqK/zw4UV/99YLnAWR7xvQlMnuyo42QTgdnPLPEiW8dDu0GHj7lgSnY2eZPWy/769DaHTgsZqiAao78abZy2p/jJknYr+uZ7tB+bnWc2yUiTfFGR6mknB2MBcJAZN/gZ3k7reeLrJOO8el5w0wA+JoygZ74VcCip7/yb1ul3Z5FvMdP8uyzm+8uKs5ADJgRzkQowhbaAy7f4fKxWF26doBFqrtQbuvMLHmqEhCf/O/q2sGJHKLrFFJlqKQBl4dvq2me1sHGraM4HbKiP8KKm6VvsvTZpMbK3JBlrTCE6nThn1ICUSm9Tkww34aQAbmeePR5U695hbkWXAsLlmrpDCUzmp+4UBWGeBb1q0rY8BrELODae7Dv+84FJrniTRQa579KejI6+aNgTmaAZ+1eEQ7EkHoQuBEQckQGKJx0S6vrqTODt/dBiWL53Ad5VajBJ8FpvWTZhoCaEjws68gGM5v2hzUR/dlYujaLHzRcvg+tBeZAK/wMiWatbAwAcIne6xBiQDYc+B263gi+22IECy3lhNFXLrI01pjlTYMWP3ERPZRoLwt/yypDPoFQ2LyZZIQzmjLKb83EHeAtcJ2ERYifxQDxN2vYp6+TkGnr1VvHulLp1lcAjw 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)(39860400002)(376002)(366004)(136003)(4326008)(53546011)(8676002)(2906002)(8936002)(478600001)(30864003)(16526019)(54906003)(31696002)(316002)(956004)(6506007)(66556008)(38100700002)(66476007)(86362001)(186003)(2616005)(36756003)(83380400001)(5660300002)(26005)(6486002)(6512007)(66946007)(31686004)(43740500002)(45980500001);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData: =?utf-8?B?R05qMFE1UkZlYXZ1bEt1RVprbVFGbEVlYlhMSW5MSWtiZ3NseXhsVFMzNlp2?= =?utf-8?B?ajlCNFFjMXBxWHpEMXF0eWZpd1RQby9RQ2xyekh6T3dFOThhVW9yVDZBTUxN?= =?utf-8?B?eG92WGpIQ04wb1I1anB4NzFUcjl5VzRoNGV1b1BITTZBYmE1OXA4b0p0eWNw?= =?utf-8?B?bEcrdXUzVWl1S0FaSVAwb0h3RzV2ZmhTc2NqTzVkczl2aFIxNWlRbGZwVlZL?= =?utf-8?B?NVhidVNnTHZCMmdPdmZ0N2pEbmZBZ2lMQ1JqaU95cHREWDIyTlFUaWlNUHlJ?= =?utf-8?B?aUI4b1h4eUpRSllNU0hrQ0lJeEtURHJPVDB6ZjRMc3BzN0RlN1dhRmRMVkhM?= =?utf-8?B?VkJML3JoY1RxdEx6K2U0OFRLRk4wdHdwVzM5SE5qWGV6UjRQWE1wTERrdjlS?= =?utf-8?B?V0tkSmV3QkFHbGFqbndzOHE4UWk4M0Q4MHArc0FtajhJWVF0S29oaUlSQll4?= =?utf-8?B?enlvRTZadXcxMkp4NTVRd0UrWGNlL3ExS2pTSThJRkYwTE5GK2JaZ0FpL3Q1?= =?utf-8?B?a21yeWxuMk1HMkR0N0MxTkpZTmdzcEFENldZMG1XM2QwLy9EdFVoUEp1QzdM?= =?utf-8?B?aFRGbnBtZmZTSXo3aGdDREF1MUtobnJ5WVhoc3FLejFhS1VBTXFhbWtWa29Y?= =?utf-8?B?aVJWcGlXSTZ3bndnZHdFMVhlVVBta0VmL3RTNG9CbnlFV3lPcWU5cWpkeFFy?= =?utf-8?B?RG11TlRZenV0K1M3NmtwNVhMWHRXZDNYMFJwV2k0RVNGQ1pqeW51aTVpWHVG?= =?utf-8?B?YmpxeXhIdCtyN0MwRzlrLzBaajFOT1k1VXdwZGRIak5uK0Q1cVY0UHpoanBz?= =?utf-8?B?T0NhWEo5SWQwS3Vzb0t2dkhIRU4xLzRkU2I1SXlhdktqSWhET0NLQ0dLSTJk?= =?utf-8?B?T0dWZWs2cjd4ME94cXpyeDI0L3Rqa2l4eFJqbFBUMzVNbEtRak5tZVlvd0Q2?= =?utf-8?B?dDU1N3JlMnRSOHdocmFtOStLeEIrUEpkcjVudGh5dCtnR3JSREk2c0xwNkJZ?= =?utf-8?B?anJiWk9KK1lNbEtiWFRTbjNGV21LeE1COUpGb3pxeWVtRlVXajhkK05XUDVV?= =?utf-8?B?cm5waHVvQk1ZVUZMNmg5VWVQc2hvdndvZXllMmtNTlJtVjdQQWIrOW1SVFA0?= =?utf-8?B?VldrQm9MbU1YRjVTTUY2bXhQWkQxT2VUOFY0T2FueXhqazRvaUJuRWZpYk1z?= =?utf-8?B?cHU4VnNVK3Y2S3BRNWQ4V1JhakNoa0UycVlUNDlwOTl2VDdCUU1oclRXUGJY?= =?utf-8?B?am9tckhVWjlCOFJqU25KUndSbnFPZy9vODVmVnJzWUFUbzYvbUk1aTdxRzNL?= =?utf-8?B?UGlIeU5YbEFFNTByY25XRDM2cis3Zis0b2JoM1JxdkNMUXhJQ0RJYWZwU2g1?= =?utf-8?B?YkU5T3hTRUJLay9TQkZFSURWRFV3L21JYytlYW5ZdVF4d25vdk1wU25vd3M2?= =?utf-8?B?QmJBMjVkT2dLM2pIalkrQWUzczFVOFFMWVJpbTVlNUtMK0Zza1lCd0g5Szlw?= =?utf-8?B?YkMvSE13SlhtVXlNYzhVNjJvd2UyekY3QVBjQmFvWTZndW9keHI4ajhqKzZX?= =?utf-8?B?L3QycjBKK2NWV3VHSTdvT25JUHJhc0NWRnJUblFlSmZINm90WkI3eTR5U2Jr?= =?utf-8?B?TjE2U0ZUaGpKenJFQUZlbmlzSWRnVnNRUWk4a1NHc0YrckdRS2ltckMxa1B6?= =?utf-8?B?RUlyZDA0aVRHVzlrZlRrRDdsOEVjVFlCSkV3WFQzbW9vUlQ5RE1ZNTgwR2Zv?= =?utf-8?Q?DzsLQt0oo71XkfAASUrbFxFy7498IV5Er4Tjpek?= X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-Network-Message-Id: 34ee6d08-efb5-41bd-2163-08d90bfea4f6 X-MS-Exchange-CrossTenant-AuthSource: DM5PR12MB1355.namprd12.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 30 Apr 2021 17:37:36.9477 (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: wrFUUAsMaTrLTNacZ/mU3aHX4HLL+wJKDlUS6pajhOI7LAxzehddrFbpXYmrywpk3M1Vw1H0MZplnr4vUG4E0Q== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR12MB4353 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit On 4/30/21 10:39 AM, Laszlo Ersek wrote: > On 04/28/21 21:09, Tom Lendacky wrote: >> On 4/28/21 11:12 AM, Laszlo Ersek wrote: >>> On 04/27/21 16:58, Tom Lendacky wrote: >>>> On 4/26/21 9:21 AM, Tom Lendacky wrote: >>>>> On 4/26/21 7:07 AM, Laszlo Ersek wrote: >>>>>> On 04/23/21 22:02, Tom Lendacky wrote: >>> >>>>>>> 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. >>>>>> >>>>>> Can we really say "SEV works" though? Because, even using an X64 PEI >>>>>> phase, and enabling only SEV (not SEV-ES), TPM access will be broken in >>>>>> the PEI phase. Is my understanding correct? >>>>> >>>>> Because the memory range is marked as MMIO, we'll take a nested page fault >>>>> (NPF). The GPA passed as part of the NPF does not include the c-bit. So we >>>>> do in fact work properly with a TPM in SEV. >>> >>> Thanks for the explanation. >>> >>> Here's what bothers me about it: >>> >>> In AmdSevDxe, we clear the C-bit from MMIO and NonExistent areas in the >>> GCD memory space map. This occurs early in the DXE phase (see "APRIORI >>> DXE" in the FDF files). The justification is that we want the flash and >>> (for example) the PCI MMIO apertures decrypted. >>> >>> Now, I realize there is a difference between flash and TPM. TPM is >>> purely MMIO (no KVM memslot), but flash (when it is not in programming >>> mode) is backed by a read-only KVM memslot. IOW, flash is "actual >>> memory", and so it is affected by SEV. TPM is never "actual memory", so >>> (according to your explanation, AIUI) it always traps to QEMU, per >>> access, and the C-bit doesn't interfere with that. >>> >>> This is consistent with two facts about OVMF's PEI phase: >>> >>> - We use IO Port-based fw_cfg (never DMA), if SEV is enabled (see >>> "QemuFwCfgPei.c"). >>> >>> - We access PCI config space via IO Ports (0xCF8, 0xCFC), never ECAM. >>> (This was not motivated by SEV, see commit 7523788faa51, but it does >>> play nice with SEV, in the PEI phase -- I think?) >>> >>> What I'm confused about, now, in retrospect, is the reference to the PCI >>> MMIO aperture, in AmdSevDxe. If that area isn't backed by a KVM memslot >>> *either* -- similarly to the TPM area --, then decrypting *that* in >>> AmdSevDxe (via "nonexistent") is not strictly necessary. Is that correct? >> >> It is necessary for (and was added for) SEV-ES. The explicit mapping of >> the PCI MMCONFIG range as unencrypted was added for SEV-ES so that the >> SEV-ES mitigation would not terminate the guest because MMIO was being >> performed against an encrypted address. >> >> There's a nice comment in OvmfPkg/PlatformPei/Platform.c that talks about >> how the MMCONFIG range is not added as MMIO, but instead as reserved >> memory. Because of that, the loop through the memory space map in >> AmdSevDxe.c does not mark the MMCONFIG range as unencrypted. > > I didn't mean commit 84cddd70820f ("OvmfPkg/AmdSevDxe: Clear encryption > bit on PCIe MMCONFIG range", 2021-01-07) -- I didn't mean PCI config space. > > I meant commit 24e4ad75546b ("OvmfPkg: Add AmdSevDxe driver", > 2017-07-10) -- I wrote "PCI MMIO aperture". > > So, to repeat my question: when 24e4ad75546b3 was implemented (which > happened just for SEV), then (apparently) clearing the C-bit on the PCI > MMIO aperture (where PCI MMIO BARs were going to be allocated from) > wasn't strictly necessary *at the time*; correct? Because that area > isn't backed by RAM, accesses trap to QEMU directly, and the C bit does > not make a difference there. (IIUC). Does this make sense or am I wrong? Ah, sorry, I misunderstood. For the most part, that is true. Not clearing the c-bit from an area where the PCI MMIO BARs are going to be allocated would not necessarily cause a problem. However, clearing the c-bit for non-existent areas was needed for other reasons. It would result in NVRAM variable corruption because of the way that area is represented in OVMF and how it is mapped by the hypervisor. For example, if the clearing of the c-bit for the address at 0xfef00000, which is marked as EfiGcdMemoryTypeNonExistent, isn't done, then using the same nvram FD file in an SEV guest results in the following: Variable FV header is not valid. It will be reinitialized. because a different encryption key is used on each launch of the guest. And attempting to use the same nvram FD file for a non-SEV guest, after running as an SEV guest, causes an ASSERT: ASSERT [VariableRuntimeDxe] /root/kernels/ovmf-build-X64/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableNonVolatile.c(218): VariableStore->Size == VariableStoreLength because the contents have been encrypted. The video buffer suffers from a similar problem in that the video buffer contents end up containing data that appears encrypted to the hypervisor and results in corruption of the screen contents when attaching, e.g., via VNC. Although, that area is marked as EfiGcdMemoryTypeMemoryMappedIo. Thanks, Tom > > >> >>> >>> I'm not asking for any code changes, just trying to form a consistent view. >>> >>> Another question (still for "base SEV"): when OVMF is built with >>> SMM_REQUIRE, PlatformPei performs a (read-only) variable access. See the >>> ReadOnlyVariable2->GetVariable() call in the RefreshMemTypeInfo() >>> function. When SEV is active, does control reach RefreshMemTypeInfo() on >>> your end? And does ReadOnlyVariable2->GetVariable() succeed for you? >>> >>> (There is a DEBUG_VERBOSE message in OnReadOnlyVariable2Available(), and >>> a DEBUG_ERROR in RefreshMemTypeInfo(), so the above questions can be >>> answered just from the log; no need to modify the code for that.) >> >> Yes, control reaches that point. But, notably, with a legacy VM I see the >> following messages: >> RefreshMemTypeInfo: GetVariable(): Not Found >> >> But with an SEV VM I see: >> Firmware Volume for Variable Store is corrupted >> RefreshMemTypeInfo: GetVariable(): Not Found >> >> So I get the "Not Found" in both cases. But with SEV, I see the >> "corrupted" message from InitRealNonVolatileVariableStore() in >> MdeModulePkg/Universal/Variable/RuntimeDxe/VariableNonVolatile.c. I >> imagine that since the range is marked encrypted, it reads the header >> incorrectly and fails. > > Thank you for confirming! I don't think we need to sweat this symptom. > I'm just glad my hunch wasn't wrong. > > Thanks, > Laszlo > >> >> Thanks, >> Tom >> >>> >>> Basically, with SEV enabled, I expect ReadOnlyVariable2->GetVariable() >>> to fail -- or even to remain unreached, as FaultTolerantWritePei and >>> VariablePei could bail out earlier (before installing the Variable PPI), >>> due to failing flash accesses. In case I'm *not* wrong -- it's not the >>> end of the world, I'm only asking this question too for the sake of >>> clarifying "C-bit vs. MMIO". >>> >>> More or less it seems to boil down to whether there is a KVM memslot or >>> not -- which is *not* equivalent to OVMF considering the area MMIO or not. >>> >>> >>>>> SEV-ES would also work >>>>> properly if the mitigation for accessing an encrypted address was removed >>>>> from the #VC handler. It is only this added mitigation to protect MMIO >>>>> that results in an issue with the TPM in PEI. >>>> >>>> So I'm thinking that I can have TpmMmioSevDecryptPeim.c do this: >>>> >>>> // >>>> // If SEV or SEV-ES is active, MMIO succeeds against an encrypted physical >>>> // address because the nested page fault (NPF) that occurs on access does not >>>> // include the encryption bit in the guest physical address provided to the >>>> // hypervisor. >>>> // >>>> // However, if SEV-ES is active, before performing the actual MMIO, an >>>> // additional MMIO mitigation check is performed in the #VC handler to ensure >>>> // that MMIO is being done to an unencrypted address. To prevent guest >>>> // termination in this scenario, mark the range unencrypted ahead of access. >>>> // >>>> if (MemEncryptSevEsIsEnabled ()) { >>>> // Do MemEncryptSevClearPageEncMask() ... >>>> } >>>> >>>> Let me submit the next version with this and see what you think. >>> >>> Yep, I'll review that now. >>> >>> Thanks >>> Laszlo >>> >>>> >>>> Thanks, >>>> Tom >>>> >>>>> >>>>>> >>>>>> I think the behavior you currently see is actually what we want, we >>>>>> should double down on it -- if MemEncryptSevClearPageEncMask() fails, >>>>>> report an explicit DEBUG_ERROR, and call CpuDeadLoop(). If the firmware >>>>>> is built with TPM_ENABLE, and SEV is active, then an IA32 PEI phase is >>>>>> simply unusable. Silently pretending that the TPM is not there, even >>>>>> though it may have been configured on the QEMU command line, we just >>>>>> failed to communicate with it, is not a good idea, IMO. >>>>> >>>>> However, because the c-bit is not part of the NPF, we do communicate >>>>> successfully with the TPM. >>>>> >>>>> So we could actually do following: >>>>> - For IA32: >>>>> - Remove the Depex on gOvmfTpmMmioAccessiblePpiGuid >>>>> - Do not add OvmfPkg/Tcg/TpmMmioSevDecryptPei/TpmMmioSevDecryptPei.inf >>>>> >>>>> - For X64: >>>>> - Add the Depex on gOvmfTpmMmioAccessiblePpiGuid >>>>> - Add OvmfPkg/Tcg/TpmMmioSevDecryptPei/TpmMmioSevDecryptPei.inf >>>>> >>>>> That might be confusing, though. So we could just do option #3 below. >>>>> >>>>> Thanks, >>>>> Tom >>>>> >>>>>> >>>>>> This is somewhat similar IMO to the S3Verification() function in >>>>>> "OvmfPkg/PlatformPei/Platform.c". >>>>>> >>>>>> TPM_ENABLE, SEV, IA32 PEI phase: pick any two. >>>>>> >>>>>> Thanks, >>>>>> Laszlo >>>>>> >>>>>>> >>>>>>> 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 >>>>>>>>> >>>>>>> >>>>>> >>>> >>> >> >