From: Mimi Zohar <zohar@linux.ibm.com>
To: "Jason Gunthorpe" <jgg@ziepe.ca>, "Piotr Król" <piotr.krol@3mdeb.com>
Cc: linux-integrity@vger.kernel.org
Subject: Re: TPM 2.0 Linux sysfs interface
Date: Wed, 28 Aug 2019 11:53:12 -0400 [thread overview]
Message-ID: <1567007592.6115.58.camel@linux.ibm.com> (raw)
In-Reply-To: <20190827010559.GA31752@ziepe.ca>
On Mon, 2019-08-26 at 22:05 -0300, Jason Gunthorpe wrote:
> The sysfs is not done, fundamentally, because the sysfs structure of
> the existing TPM1 stuff is grandfathered in, and doing anything like
> it for TPM2 is a complete NAK for not following the normal sysfs
> interface design rules, particularly of one value per file. This is a
> big part of why it was dropped for TPM2.
The original TPM 2.0 support was missing a lot of TPM 1.2
functionality, including exporting the TPM event log. So it wasn't
clear that leaving out the sysfs support was intentional or simply a
question of someone needing to implement it.
>
> So exposing PCRs and things through sysfs is not going to happen.
>
> If you had some very narrowly defined things like version, then
> *maybe* but I think a well defined use case is needed for why this
> needs to be sysfs and can't be done in C as Jarkko explained.
Piotr's request for a sysfs file to differentiate between TPM 1.2 and
TPM 2.0 is a reasonable request and probably could be implemented on
TPM registration.
If exposing the PCRs through sysfs is not acceptable, then perhaps
suggest an alternative.
Mimi
>
> A good reason would be something like needing to trigger a systemd
> unit from udev.
>
> Jason
next prev parent reply other threads:[~2019-08-28 15:53 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-08-26 23:24 TPM 2.0 Linux sysfs interface Piotr Król
2019-08-27 1:05 ` Jason Gunthorpe
2019-08-28 15:53 ` Mimi Zohar [this message]
2019-08-28 16:15 ` Jason Gunthorpe
2019-08-30 21:20 ` Tadeusz Struk
2019-09-02 19:26 ` Jason Gunthorpe
2019-09-02 21:35 ` Mimi Zohar
2019-09-03 5:55 ` Jason Gunthorpe
2019-09-03 11:49 ` Mimi Zohar
2019-09-03 13:07 ` Jason Gunthorpe
2019-09-03 13:23 ` Mimi Zohar
2019-09-03 16:21 ` Jarkko Sakkinen
2019-09-03 16:23 ` Tadeusz Struk
2019-09-03 22:40 ` Jordan Hand
2019-09-03 23:29 ` Mimi Zohar
2019-09-04 5:58 ` Jason Gunthorpe
2019-09-04 11:30 ` Mimi Zohar
2019-09-04 19:43 ` Jason Gunthorpe
2019-09-04 20:26 ` Mimi Zohar
2019-09-06 17:53 ` Serge E. Hallyn
2019-08-28 15:03 ` Mimi Zohar
2019-08-28 17:15 ` Petr Vorel
2019-08-28 23:22 ` Piotr Król
2019-08-29 7:32 ` Petr Vorel
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=1567007592.6115.58.camel@linux.ibm.com \
--to=zohar@linux.ibm.com \
--cc=jgg@ziepe.ca \
--cc=linux-integrity@vger.kernel.org \
--cc=piotr.krol@3mdeb.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.