From: "Lendacky, Thomas" <thomas.lendacky@amd.com>
To: devel@edk2.groups.io, lersek@redhat.com
Cc: Joerg Roedel <joro@8bytes.org>, Borislav Petkov <bp@alien8.de>,
Ard Biesheuvel <ardb+tianocore@kernel.org>,
Jordan Justen <jordan.l.justen@intel.com>,
Brijesh Singh <brijesh.singh@amd.com>,
James Bottomley <jejb@linux.ibm.com>,
Jiewen Yao <jiewen.yao@intel.com>, Min Xu <min.m.xu@intel.com>
Subject: Re: [edk2-devel] [PATCH 3/3] OvmfPkg/PlatformPei: Mark TPM MMIO range as unencrypted for SEV
Date: Fri, 23 Apr 2021 12:41:16 -0500 [thread overview]
Message-ID: <311cdc78-d818-bea4-16a1-01077bfc1140@amd.com> (raw)
In-Reply-To: <4261e15a-84a0-11a7-2981-9eeb538f6da9@redhat.com>
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 <thomas.lendacky@amd.com>
>>>
>>> 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 <lersek@redhat.com>
>>> Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
>>> Cc: Jordan Justen <jordan.l.justen@intel.com>
>>> Cc: Brijesh Singh <brijesh.singh@amd.com>
>>> Cc: James Bottomley <jejb@linux.ibm.com>
>>> Cc: Jiewen Yao <jiewen.yao@intel.com>
>>> Cc: Min Xu <min.m.xu@intel.com>
>>> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
>>> ---
>>> 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
>
next prev parent reply other threads:[~2021-04-23 17:41 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-04-20 22:54 [PATCH 0/3] SEV-ES TPM enablement fixes Lendacky, Thomas
2021-04-20 22:54 ` [PATCH 1/3] OvfmPkg/VmgExitLib: Properly decode MMIO MOVZX and MOVSX opcodes Lendacky, Thomas
2021-04-22 5:28 ` [edk2-devel] " Laszlo Ersek
2021-04-22 13:35 ` Lendacky, Thomas
2021-04-23 9:07 ` Laszlo Ersek
2021-04-20 22:54 ` [PATCH 2/3] OvmfPkg/VmgExitLib: Add support for new MMIO MOV opcodes Lendacky, Thomas
2021-04-22 5:50 ` [edk2-devel] " Laszlo Ersek
2021-04-22 14:15 ` Lendacky, Thomas
2021-04-22 15:42 ` Lendacky, Thomas
2021-04-23 9:10 ` Laszlo Ersek
2021-04-23 13:24 ` Lendacky, Thomas
2021-04-20 22:54 ` [PATCH 3/3] OvmfPkg/PlatformPei: Mark TPM MMIO range as unencrypted for SEV Lendacky, Thomas
2021-04-20 23:17 ` Eric van Tassell
2021-04-21 14:09 ` [edk2-devel] " Andrew Fish
[not found] ` <1677E4DA25FD7265.31957@groups.io>
2021-04-21 17:20 ` Andrew Fish
2021-04-21 17:45 ` Lendacky, Thomas
2021-04-21 22:24 ` Andrew Fish
2021-04-22 6:07 ` Laszlo Ersek
2021-04-23 10:26 ` Laszlo Ersek
2021-04-23 13:04 ` [edk2-devel] " Laszlo Ersek
2021-04-23 13:09 ` Laszlo Ersek
2021-04-23 17:41 ` Lendacky, Thomas [this message]
2021-04-23 20:02 ` Lendacky, Thomas
2021-04-26 12:07 ` Laszlo Ersek
2021-04-26 14:21 ` Lendacky, Thomas
2021-04-27 14:58 ` Lendacky, Thomas
2021-04-28 16:12 ` Laszlo Ersek
2021-04-28 19:09 ` Lendacky, Thomas
2021-04-30 15:39 ` Laszlo Ersek
2021-04-30 17:37 ` Lendacky, Thomas
2021-04-26 11:08 ` Laszlo Ersek
[not found] ` <1677B2EC90F30786.1355@groups.io>
2021-04-20 23:13 ` Lendacky, Thomas
2021-04-22 7:34 ` Laszlo Ersek
2021-04-22 8:31 ` Laszlo Ersek
2021-04-22 8:39 ` Laszlo Ersek
2021-04-22 19:10 ` Lendacky, Thomas
2021-04-23 9:28 ` Laszlo Ersek
2021-04-22 14:51 ` Lendacky, Thomas
2021-04-22 16:04 ` Lendacky, Thomas
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-list from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=311cdc78-d818-bea4-16a1-01077bfc1140@amd.com \
--to=devel@edk2.groups.io \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox