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.web12.1611.1623180807390640564 for ; Tue, 08 Jun 2021 12:33:27 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=g58sJDQm; 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=1623180806; 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=dZBPHnYLIcsMMlBT0pEt457O6ZxTZ58az7TDKh7HfvM=; b=g58sJDQmJwyRZUzXqFtDzEKarDUZOvCAIV6iCiHuxuJ/uv9A2N+Ly7pbmrQgh6YV9KWezs L/4h7iApmg1hAx2a/mRSHSxSWvot5vWZ1UuR0vyArFdIJCKCAmekyUInXYghmro8nm6sZa bpiiPRjKFKairOW6lDAz4rm+c4/cwd0= 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-473-HXNlt9euPZu_3EGe9iN67w-1; Tue, 08 Jun 2021 15:33:22 -0400 X-MC-Unique: HXNlt9euPZu_3EGe9iN67w-1 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 2510E8B0582; Tue, 8 Jun 2021 19:33:19 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-112-124.ams2.redhat.com [10.36.112.124]) by smtp.corp.redhat.com (Postfix) with ESMTPS id ADB705D9C6; Tue, 8 Jun 2021 19:33:12 +0000 (UTC) Subject: Re: [edk2-rfc] [edk2-devel] RFC: design review for TDVF in OVMF To: jejb@linux.ibm.com, "Yao, Jiewen" , "rfc@edk2.groups.io" , "devel@edk2.groups.io" Cc: Brijesh Singh , Tom Lendacky , "erdemaktas@google.com" , "cho@microsoft.com" , "bret.barkelew@microsoft.com" , Jon Lange , Karen Noel , Paolo Bonzini , Nathaniel McCallum , "Dr. David Alan Gilbert" , "Ademar de Souza Reis Jr." , Min Xu References: From: "Laszlo Ersek" Message-ID: Date: Tue, 8 Jun 2021 21:33:11 +0200 MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 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 (Min Xu got dropped from the CC list for some reason, at *some* point in this sub-thread! Not sure when. Re-adding him.) Commenting on excerpts: On 06/08/21 18:01, James Bottomley wrote: > On TdMailbox and TdHob, we already have two SEV pages in the MEMFD and > since TDX and SEV is an either/or, could we simply not rename both > pages and use them for either boot depending on what CPU type is > detected, so we only have two MEMFD pages, not four? Great idea, in my opinion. > On your slide 13 Question: "Open: How will the QEMU find the metadata > location?" can't you just use the mechanism for SEV that's already > upstream in both QEMU and OVMF? I think I made the same comment, in different words. (Point (12) at .) > On slide 19, the mucking with the reset vector really worries me > because we don't have that much space to play with. Given that you're > starting in 32 bit mode and can thus enter anywhere in the lower 4GB, > why not simply use a different and TDX specific entry point? What's more, we should use a dedicated ResetVector (through a DSC+FDF dedicated solely to TDX). > On all the Tcg2 changes: what about installing a vTPM driver that > simply translates to your MSRs? That way we can use all the standard > TCG code as is? I believe I made the same comment in point (20) (see URL above). > Slide 41: IOMMU operation. That's more like slides 40 and 42, no? > The implication is that you only transition to unencrypted memory for > DMA during the actual operation, Yes, this is the idea behind EDKII_IOMMU_PROTOCOL, which OvmfPkg/IoMmuDxe implements (for SEV only, currently). > so do I have it correct that the guest writes DMA to encrypted memory, > then the iommu marks the region as unencrypted and transforms the > memory to be in the clear and then transforms it back after the DMA > operation completes? Effectively, yes. (Your summary corresponds to a BusMasterRead operation.) > Given that SEV operates quite happily with always in the clear DMA > buffers, I don't understand this comment -- is it a statement about SEV as a technology, or about OvmfPkg/IoMmuDxe? Specifically in the context of OvmfPkg/IoMmuDxe, there is no "always-in-the-clear DMA". EDKII_IOMMU_PROTOCOL was designed to fit cleanly into the Map(), Unmap(), AllocateBuffer(), FreeBuffer() terminology of the UEFI standard EFI_PCI_ROOT_BRIDGE_IO_PROTOCOL and EFI_PCI_IO_PROTOCOL. As far as I can tell, the original use case for EDKII_IOMMU_PROTOCOL was VT-d on bare metal, but the protocol proved a good match for SEV too. VIRTIO_DEVICE_PROTOCOL has similar member functions (AllocateSharedPages, FreeSharedPages, MapSharedBuffer, UnmapSharedBuffer). As long as a PCI device driver (or virtio driver) uses these member functions judiciously, only "BusMasterCommonBuffer" operations will be backed by long-term plaintext (decrypted) pages. One-shot read and write transactions will be backed by plaintext (decrypted) pages only as long as necessary. The transitions you outline already happen in any plain SEV guest that uses PCI DMA or virtio. > this seems to have the potential to be a performance problem, but what > security does it gain? We have not experienced performance problems due to this kind of IOMMU protocol usage, when booting SEV guests. The basic goal was to keep everything as tightly encrypted as possible (as permitted by the individual PCI or Virtio driver, through its conservative usage of BusMasterCommonBuffer operations). I won't claim that it has zero performance impact, but we should remember the purpose that firmware serves (namely, "booting an operating system"). Really -- I don't recall any performance issues. This applies to such virtio devices & drivers too that aren't "bootable", such as virtio-gpu-pci (VirtioGpuDxe) and virtio-rng-pci (VirtioRngDxe). ( If you enable verbose logs, OvmfPkg/IoMmuDxe does produce an immense amount of messages (with the express purpose of a human reading through them, and matching up decryption and re-encryption actions -- I've done it, likely with some ad-hoc scripts). *This* does slow down the boot considerably (if you actually enable the QEMU debug console), but for a different reason: producing debug logs through the QEMU debug console (IO Port) is very-very costly in a SEV guest. Not just because an IO port trap may be more expensive in a SEV guest, but because SEV does not support REP OUTSB, so every debug character written traps separately, as opposed to every line written. See the following commits: - b6d11d7c4678 ("MdePkg: BaseIoLibIntrinsic (IoLib class) library", 2017-04-13), - 97353a9c914d ("OvmfPkg: Update dsc to use IoLib from BaseIoLibIntrinsicSev.inf", 2017-07-10), - 98a4d04e8fda ("MdePkg/BaseIoLibIntrinsic: fix SEV (=unrolled) variants of IoWriteFifoXX()", 2017-09-11), - c09d9571300a ("OvmfPkg: save on I/O port accesses when the debug port is not in use", 2017-11-17). ) >>From my perspective, I find the changes proposed for OvmfPkg/IoMmuDxe to be among the least intrusive of the whole slide deck (after Min Xu confirmed that the intent was really only to customize the page decryption / encryption primitives in the driver, and to leave the general logic untouched). That's not to say that I'm unhappy about this topic being raised. To the contrary! Thanks Laszlo