All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jason Gunthorpe <jgg@ziepe.ca>
To: Mimi Zohar <zohar@linux.ibm.com>
Cc: "Tadeusz Struk" <tadeusz.struk@intel.com>,
	"Piotr Król" <piotr.krol@3mdeb.com>,
	linux-integrity@vger.kernel.org
Subject: Re: TPM 2.0 Linux sysfs interface
Date: Tue, 3 Sep 2019 10:07:13 -0300	[thread overview]
Message-ID: <20190903130713.GA5851@ziepe.ca> (raw)
In-Reply-To: <1567511346.10024.365.camel@linux.ibm.com>

On Tue, Sep 03, 2019 at 07:49:06AM -0400, Mimi Zohar wrote:
> On Tue, 2019-09-03 at 02:55 -0300, Jason Gunthorpe wrote:
> > On Mon, Sep 02, 2019 at 05:35:18PM -0400, Mimi Zohar wrote:
> > > On Mon, 2019-09-02 at 16:26 -0300, Jason Gunthorpe wrote:
> > > > On Fri, Aug 30, 2019 at 02:20:54PM -0700, Tadeusz Struk wrote:
> > > > > On 8/28/19 9:15 AM, Jason Gunthorpe wrote:
> > > > > >>> 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.
> > > > > > Use the char dev, this is exactly what is is for.
> > > > > 
> > > > > What about a new /proc entry?
> > > > > Currently there are /proc/cpuinfo, /proc/meminfo, /proc/slabinfo...
> > > > > What about adding a new /proc/tpminfo that would print info like
> > > > > version, number of enabled PCR banks, physical interface [tis|crb],
> > > > > vendor, etc.
> > > > 
> > > > I thought we were not really doing new proc entries?
> > > > 
> > > > Why this focus on making some textual output?
> > > 
> > > I don't really care if we define procfs, sysfs, or securityfs file(s)
> > > or whether those files are ascii or binary.  Whatever is defined,
> > > should be defined for both TPM 1.2 and TPM 2.0 (eg. TPM version).
> > 
> > Use an ioctl on the char dev?
> 
> Both TPM 1.2 and TPM 2.0 export the TPM event log as
> security/tpmX/binary_bios_measurements.  Wouldn't it make more sense
> to group the TPM information together, exporting other TPM information
> as securityfs files?

I don't know anything about security_fs, sorry

Jason

  reply	other threads:[~2019-09-03 13:07 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
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 [this message]
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=20190903130713.GA5851@ziepe.ca \
    --to=jgg@ziepe.ca \
    --cc=linux-integrity@vger.kernel.org \
    --cc=piotr.krol@3mdeb.com \
    --cc=tadeusz.struk@intel.com \
    --cc=zohar@linux.ibm.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.