On Tue, Nov 20, 2018 at 10:42:01PM -0700, Jason Gunthorpe wrote:

quoted

Why you wouldn't use DMA to spy the RAM?

The platform has to use IOMMU to prevent improper DMA access from
places like PCI-E slots if you are using measured boot and want to
defend against HW tampering.

Yes. This is what I wanted to point out. Windows 10 has VBS to
achieve something like this.

https://docs.microsoft.com/en-us/windows-hardware/design/device-experiences/oem-vbs

The BIOS has to sequence things so that at least pluggable PCI-E slots
cannot do DMA until the IOMMU is enabled.

Yep.

Honestly not sure if we do this all correctly in Linux, or if BIOS
vendors even implemented this level of protection. The BIOS would have
to leave the PCI-E root port slots disabled, and configure the ports
to reject config TLPs from the hostile PCI-E device, and probably a
big bunch of other stuff.. Then Linux would have to enable the IOMMU
and then enable the PCI-E ports for operation.

Linux should have something like VBS. Like James' proposal it does not
solve the puzzle but is one step forward...

Pretty subtle and tricky stuff.

Without IOMMU it would be trivial to plug a card in an open PCI-E slot
(or M.2 slot on a laptop) and breach all measured boot guarantees via
DMA. For instance, if IOMMU is not enabled during grub then I could
overwrite the trusted grub with DMA and cleverly make it jump to my
hostile code, then I can replay PCR extends to the TPM and
seal/unseal/attest using the PCRs set to a trusted sytem when running
hostile code. Oopsie.

This is a much easier attack than inserting a TPM interposer or
messing with the TPM reset line...

But again, measured boot does not protect against HW tampering, so
this is probably not included in the threat model the BIOS uses...

/Jarkko