Re: [edk2-devel] RFC: design review for TDVF in OVMF
(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 andGreat idea, in my opinion.
On your slide 13 Question: "Open: How will the QEMU find the metadataI think I made the same comment, in different words. (Point (12) at
On slide 19, the mucking with the reset vector really worries meWhat'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 thatI 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 forYes, 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,Effectively, yes. (Your summary corresponds to a BusMasterRead
Given that SEV operates quite happily with always in the clear DMAI 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
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,
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
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 whatWe 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",
- 97353a9c914d ("OvmfPkg: Update dsc to use IoLib from
- 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