On Nov 20, 2018, at 6:58 PM, James Bottomley [off-list ref] wrote:

quoted

On Wed, 2018-11-21 at 01:13 +0200, Jarkko Sakkinen wrote:

quoted

On Tue, Nov 20, 2018 at 09:25:43AM -0800, James Bottomley wrote:

quoted

On Tue, 2018-11-20 at 14:41 +0200, Jarkko Sakkinen wrote:

quoted

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?

You mean from a plugin on the TPM bus? most of the buses the TPM is on
don't get DMA access.  Some of them barely get interrupts, which is why
we waste a lot of time polling in TPM drivers.

You can do DMA over the LPC bus if you pull down the LDRQ pin. But typically that pin isn’t populated on the TPM header on mainboards. I suppose this may be intentional. 

James