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

[Jason Gunthorpe]

On Wed, Nov 21, 2018 at 01:13:20AM +0200, Jarkko Sakkinen wrote:
> On Tue, Nov 20, 2018 at 09:25:43AM -0800, James Bottomley wrote:
> > On Tue, 2018-11-20 at 14:41 +0200, Jarkko Sakkinen wrote:
> > > On Tue, Nov 20, 2018 at 01:10:49PM +0200, Jarkko Sakkinen wrote:
> > > > This is basically rewrite of TPM genie paper with extras. Maybe
> > > > just shorten it to include the proposed architecture and point to
> > > > the TPM Genie paper (which is not in the references at all ATM).
> > > > 
> > > > The way I see it the data validation is way more important than
> > > > protecting against physical interposer to be frank.
> > > > 
> > > > The attack scenario would require to open the damn device. For
> > > > laptop that would leave physical marks (i.e. evil maid). In a data
> > > > center with armed guards I would wish you good luck accomplishing
> > > > it. It is not anything like sticking a USB stick and run.
> > > > 
> > > > We can take a fix into Linux with a clean implementation but it
> > > > needs to be an opt-in feature because not all users will want to
> > > > use it.
> > > 
> > > Someone (might have been either Mimi or David Howells but cannot
> > > recall) correctly pointed out at LSS 2018 that you could just as
> > > easily spy and corrupt RAM if you have a time window to perform this
> > > type of attack.
> > 
> > Not using the simple plug in on the TPM bus, you can't.  The point is
> > basically the difference in the technology: the interposer is a simple,
> > easy to construct, plugin; a RAM spy is a huge JTAG thing that would be
> > hard even to fit into a modern thin laptop, let alone extremely
> > difficult to build.
> 
> 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.

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

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.

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...

Jason