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
next prev 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).