On Tue, Nov 20, 2018 at 10:42:01PM -0700, Jason Gunthorpe wrote: > > 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
