From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) by mx.groups.io with SMTP id smtpd.web11.5401.1619435325328506003 for ; Mon, 26 Apr 2021 04:08:46 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=E8uCqICL; spf=pass (domain: redhat.com, ip: 216.205.24.124, mailfrom: lersek@redhat.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1619435324; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=p7g9BDlImNgmVTSQtOTyQBHxnmz+o9Zx28n+Q1ySSqg=; b=E8uCqICL3EkTX/J9YKW0zcm5eAR9G0Fa9h8Bcpgr8iyQvJwTiHXhy728xs3lBQ8xE3Oyi5 nrf7pai08P+17aGV9XGm3kk0ZJ6K3on6KpwFNoomkTOr5JLEwlBpAD6vAxeFyNbLpKcUpx dNVCn6RXdAbEBfOuXKnxYJpD068LhPo= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-319-2TE5Q6IEPOCM8fbCEH7w-A-1; Mon, 26 Apr 2021 07:08:40 -0400 X-MC-Unique: 2TE5Q6IEPOCM8fbCEH7w-A-1 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id DE0A6107ACE4; Mon, 26 Apr 2021 11:08:37 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-115-153.ams2.redhat.com [10.36.115.153]) by smtp.corp.redhat.com (Postfix) with ESMTP id E84086A037; Mon, 26 Apr 2021 11:08:34 +0000 (UTC) Subject: Re: [edk2-devel] [PATCH 3/3] OvmfPkg/PlatformPei: Mark TPM MMIO range as unencrypted for SEV To: Tom Lendacky , 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> From: "Laszlo Ersek" Message-ID: <7ba5fe65-b8bf-c269-b943-fdffd1fdc576@redhat.com> Date: Mon, 26 Apr 2021 13:08:33 +0200 MIME-Version: 1.0 In-Reply-To: <311cdc78-d818-bea4-16a1-01077bfc1140@amd.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=lersek@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit On 04/23/21 19:41, Tom Lendacky wrote: > On 4/23/21 8:04 AM, Laszlo Ersek wrote: >> 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. Thanks! > > 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. That's good to know; thanks for reporting this. I've turned it now into a BZ ticket (assigned to Rebecca): https://bugzilla.tianocore.org/show_bug.cgi?id=3354 Thanks! Laszlo