linux-integrity.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
To: "David R. Bild" <david.bild@xaptum.com>,
	James Bottomley <James.Bottomley@HansenPartnership.com>,
	philip.b.tricca@intel.com
Cc: Jason Gunthorpe <jgg@ziepe.ca>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Peter Huewe <peterhuewe@gmx.de>,
	linux-usb@vger.kernel.org, linux-integrity@vger.kernel.org
Subject: Re: [PATCH v3 2/2] usb: misc: xapea00x: perform platform initialization of TPM
Date: Tue, 8 May 2018 13:55:15 +0300	[thread overview]
Message-ID: <20180508105515.GB6132@linux.intel.com> (raw)
In-Reply-To: <CAAi9uDvyzk1vnQVXkJxRCATy85g4nwMLJjqu6rr1YZn9NV_TYw@mail.gmail.com>

On Fri, May 04, 2018 at 02:56:25PM -0500, David R. Bild wrote:
> On Fri, May 4, 2018 at 2:06 PM, Jason Gunthorpe <jgg@ziepe.ca> wrote:
> >
> > On Fri, May 04, 2018 at 08:00:22AM -0500, David R. Bild wrote:
> > > Normally the system platform (i.e., BIOS/UEFI for x86) is responsible
> > > for performing initialization of the TPM.  For these modules, the host
> > > kernel is the platform, so we perform the initialization in the driver
> > > before registering the TPM with the kernel TPM subsystem.
> >
> > The tpm driver already does most of this stuff automatically, why
> > duplicate it there and why is it coded in a way that doesn't use the
> > existing TPM services to do it?
> 
> I didn't want to have to duplicate all that functionality and was
> disappointed when that became the only option (due to the two reasons
> outlined below) for supporting existing kernels with an out-of-tree
> module.
> 
> Bringing the module in-tree opens the option of reworking some of the
> TPM subsystem to support this use case.  I'm open to concrete
> suggestions on how to do so.
> 
> 1) The first reason is that I don't think the necessary pieces are
> currently made available for reuse. I'd love to not repeat that code,
> but
> 
> - some required structs and functions are declared in private headers
> (drivers/char/tpm/*.h instead of include/linux/tpm.h).
> - many of the required functions are not exported.
> 
> If the TPM maintainers are open to more of the API being "public", I
> can look into preparing patches that export the necessary operations.
> 
> 2) The second reason is that the initialization done by the driver is
> work that should be done by platform, before the kernel ever sees the
> TPM.

This is too speculative to give any confirmitive promises. Do not fully
understand the reasoning. For example: why should I care about
out-of-tree modules? I can look code changes but the text above contains
too many words to nail anything down. I'm confused.

> In particular, it sets the credentials for the platform hierarchy.
> The platform hierarchy is essentially the "root" account of the TPM,
> so it's critical that those credentials be set before the TPM is
> exposed to user-space.  (The platform credentials aren't persisted in
> the TPM and must be set by the platform on every boot.)  If the driver
> registers the TPM before doing initialization, there's a chance that
> something else could access the TPM before the platform credentials
> get set.

Maybe. Not sure yet where to draw the line eg should TSS2 daemon to do
it for example.

James? Philip?

/Jarkko

  parent reply	other threads:[~2018-05-08 10:55 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20180430125418.31344-1-david.bild@xaptum.com>
2018-05-04 13:00 ` [PATCH v3 0/2] Add driver for Xaptum ENF Access card (XAP-EA-00x) David R. Bild
2018-05-04 13:00 ` [PATCH v3 1/2] usb: misc: xapea00x: add driver for Xaptum ENF Access Card David R. Bild
2018-05-07  9:58   ` Oliver Neukum
2018-05-07 13:31     ` David R. Bild
2018-05-08  9:09       ` Oliver Neukum
2018-05-04 13:00 ` [PATCH v3 2/2] usb: misc: xapea00x: perform platform initialization of TPM David R. Bild
2018-05-04 19:06   ` Jason Gunthorpe
2018-05-04 19:56     ` David R. Bild
2018-05-04 20:19       ` David R. Bild
2018-05-06 15:02         ` Jason Gunthorpe
2018-05-10  1:42           ` Jarkko Sakkinen
2018-05-08 10:55       ` Jarkko Sakkinen [this message]
2018-05-08 15:25         ` James Bottomley
2018-05-08 15:29           ` David R. Bild
2018-05-08 15:36             ` James Bottomley
2018-05-10  1:59               ` Jarkko Sakkinen
2018-05-10 14:31                 ` David R. Bild
2018-05-13  8:51                   ` Jarkko Sakkinen
2018-05-25 20:31                   ` Ken Goldman
2018-05-10 14:25               ` David R. Bild
2018-05-10 14:47                 ` James Bottomley
2018-05-10 15:17                   ` David R. Bild
2018-05-25 20:23               ` Ken Goldman
2018-05-10  1:44             ` Jarkko Sakkinen
2018-05-10 14:29               ` David R. Bild
2018-05-10  1:42           ` Jarkko Sakkinen
2018-05-10 14:41         ` David R. Bild
2018-05-13  8:46           ` Jarkko Sakkinen
2018-05-14 19:31           ` Jason Gunthorpe
2018-05-14 19:59             ` David R. Bild
2018-05-14 20:08               ` Jason Gunthorpe
2018-05-14 20:12                 ` David R. Bild
2018-05-07 14:12   ` EXTERNAL: " Jeremy Boone
2018-05-08 10:47   ` Jarkko Sakkinen
2018-05-10 14:09     ` David R. Bild

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=20180508105515.GB6132@linux.intel.com \
    --to=jarkko.sakkinen@linux.intel.com \
    --cc=James.Bottomley@HansenPartnership.com \
    --cc=david.bild@xaptum.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=jgg@ziepe.ca \
    --cc=linux-integrity@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=peterhuewe@gmx.de \
    --cc=philip.b.tricca@intel.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).