linux-security-module.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
To: James Bottomley <James.Bottomley@HansenPartnership.com>
Cc: linux-integrity@vger.kernel.org,
	linux-security-module@vger.kernel.org, monty.wiseman@ge.com,
	Monty Wiseman <montywiseman32@gmail.com>,
	Matthew Garrett <mjg59@google.com>
Subject: Re: Documenting the proposal for TPM 2.0 security in the face of bus interposer attacks
Date: Wed, 21 Nov 2018 08:37:57 +0200	[thread overview]
Message-ID: <20181121063757.GA3640@linux.intel.com> (raw)
In-Reply-To: <1542758331.2814.48.camel@HansenPartnership.com>

On Tue, Nov 20, 2018 at 03:58:51PM -0800, James Bottomley wrote:
> On Wed, 2018-11-21 at 01:13 +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?
> 
> 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.

No. I that if you get physical access you can do all sorts of other
stuff in the host side. It doesn't matter how secure the path between
the host and TPM is.

/Jarkko

  parent reply	other threads:[~2018-11-21  6:38 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-11-19 17:34 Documenting the proposal for TPM 2.0 security in the face of bus interposer attacks James Bottomley
2018-11-19 20:05 ` Jason Gunthorpe
2018-11-19 20:20   ` James Bottomley
2018-11-19 21:19     ` Jason Gunthorpe
2018-11-19 21:34       ` James Bottomley
2018-11-19 21:44         ` Jason Gunthorpe
2018-11-19 22:36           ` James Bottomley
2018-11-19 23:08             ` Jason Gunthorpe
2018-11-20  0:54               ` James Bottomley
2018-11-20  3:05                 ` Jason Gunthorpe
2018-11-20 17:17                   ` James Bottomley
2018-11-20 21:33                     ` Jason Gunthorpe
2018-11-20 22:34                       ` James Bottomley
2018-11-20 23:39                         ` Jason Gunthorpe
2018-11-21  2:24                           ` EXTERNAL: " Jeremy Boone
2018-11-21  5:16                             ` Jason Gunthorpe
2018-11-20 23:52                       ` Jarkko Sakkinen
2018-11-20 23:41                     ` Jarkko Sakkinen
2018-11-20 11:10 ` Jarkko Sakkinen
2018-11-20 12:41   ` Jarkko Sakkinen
2018-11-20 17:25     ` James Bottomley
2018-11-20 23:13       ` Jarkko Sakkinen
2018-11-20 23:58         ` James Bottomley
2018-11-21  0:33           ` EXTERNAL: " Jeremy Boone
2018-11-21  6:37           ` Jarkko Sakkinen [this message]
2018-11-21  5:42         ` Jason Gunthorpe
2018-11-21  7:18           ` Jarkko Sakkinen
     [not found]             ` <F10185EF-C618-45DC-B1F3-0053B8FE417F@gmail.com>
2018-11-21  9:07               ` Jarkko Sakkinen
2018-11-21  9:14             ` Jarkko Sakkinen
2018-11-20 17:23   ` James Bottomley
2018-11-20 23:12     ` Jarkko Sakkinen
2018-12-10 16:33 ` Ken Goldman
2018-12-10 17:30   ` James Bottomley
2018-12-11 21:47     ` Ken Goldman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20181121063757.GA3640@linux.intel.com \
    --to=jarkko.sakkinen@linux.intel.com \
    --cc=James.Bottomley@HansenPartnership.com \
    --cc=linux-integrity@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=mjg59@google.com \
    --cc=monty.wiseman@ge.com \
    --cc=montywiseman32@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).