Documenting the proposal for TPM 2.0 security in the face of bus interposer attacks

[Jarkko Sakkinen]

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