linux-api.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Mimi Zohar <zohar@linux.ibm.com>
To: Greg KH <greg@kroah.com>,
	James Bottomley <James.Bottomley@hansenpartnership.com>
Cc: linux-integrity@vger.kernel.org,
	Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>,
	linux-api@vger.kernel.org
Subject: Re: [PATCH RESEND v4 0/1] add sysfs exports for TPM 2 PCR registers
Date: Mon, 30 Nov 2020 10:21:02 -0500	[thread overview]
Message-ID: <ee9428f8a4259a86ad331ff169f98c4e8e090d6d.camel@linux.ibm.com> (raw)
In-Reply-To: <X8Sq6VPMtOxPAi3N@kroah.com>

On Mon, 2020-11-30 at 09:18 +0100, Greg KH wrote:
> On Sun, Nov 29, 2020 at 02:30:21PM -0800, James Bottomley wrote:
> > Cc to linux-api to get an opinion on two issues.  First the background:
> > 
> > We've had a fairly extensive discussion over on linux-integrity and
> > iterated to the conclusion that the kernel does need to export TPM 2.0
> > PCR values for use by a variety of userspace integrity programmes
> > including early boot.  The principle clinching argument seems to be
> > that these values are required by non-root systems, but in a default
> > Linux set up the packet marshalled communication device: /dev/tpmrm0,
> > is by default only usable by root.  Historically, TPM 1.2 exported
> > these values via sysfs in a single file containing all 24 values:
> > 
> >   /sys/class/tpm/tpm0/pcrs
> > 
> > with the format
> > 
> >   PCR-00: 7D 29 CB 08 0C 0F C4 16 7A 0E 9A F7 C6 D3 97 CD C1 21 A7 69 
> >   PCR-01: 9C B6 79 4C E4 4B 62 97 4C AB 55 13 1A 2F 7E AE 09 B3 30 BE 
> >   ...
> 
> As you know, this breaks the "one value per file" for sysfs, so please,
> do not add more files that do this.
> 
> > TPM 2.0 adds more complexity: because of it's "agile" format, each TPM
> > 2.0 is required to support a set of hashes (of which at least sha1 and
> > sha256 are required but quite a few TPM 2.0s have at least two or
> > three more) and maintain 24 PCR registers for each supported hash.
> > The current patch exports each PCR bank under the directory
> > 
> >   /sys/class/tpm/tpm0/pcr-<hash>/<bank>
> > 
> > So the sha256 bank value of PCR 7 can be obtained as
> > 
> >   cat /sys/class/tpm/tpm0/pcr-sha256/7
> >   2ED93F199692DC6788EFA6A1FE74514AB9760B2A6CEEAEF6C808C13E4ABB0D42
> > 
> > And the output is a single non-space separated ascii hex value of the
> > hash.
> > 
> > The issues we'd like input on are:
> > 
> >  1. Should this be in sysfs or securityfs?
> 
> If you want to use sysfs, use one value per file please.
> 
> >   2. Should we export the values as one value per file (current patch)
> >      or as a binary blob of all 24?
> 
> Binary sysfs files are for "pass-through" mode where the kernel is not
> parsing/manipulating the data at all.  Do these values come straight
> from the hardware?  If so, sure, use a binary blob.  If not, then no, do
> not use that in sysfs as sysfs is to be in text format.

The data is coming from the hardware, but not the result of a single
TPM command.  Each TPM bank PCR has to be queried individually.  The
question is whether the result should be exported separately (via
sysfs) or aggregated as a single binary blob (via securityfs).

thanks,

Mimi


  reply	other threads:[~2020-11-30 15:22 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-29 22:30 [PATCH RESEND v4 0/1] add sysfs exports for TPM 2 PCR registers James Bottomley
2020-11-29 22:30 ` [PATCH RESEND v4 1/1] tpm: add sysfs exports for all banks of " James Bottomley
2020-11-30  8:17   ` Greg KH
2020-11-30 19:00   ` Elliott, Robert (Servers)
2020-11-30 19:53     ` James Bottomley
2020-11-30 22:50       ` Elliott, Robert (Servers)
2020-11-30 22:57         ` James Bottomley
2020-12-23 15:58         ` Ken Goldman
2020-12-04  4:55   ` Jarkko Sakkinen
2020-11-30  8:18 ` [PATCH RESEND v4 0/1] add sysfs exports for TPM 2 " Greg KH
2020-11-30 15:21   ` Mimi Zohar [this message]
2020-11-30 15:26   ` James Bottomley
  -- strict thread matches above, loose matches on Subject: below --
2020-09-06 20:32 James Bottomley
2020-09-07  5:38 ` Greg KH
2020-09-07 13:23   ` Jarkko Sakkinen
2020-09-07 13:36     ` Greg KH
2020-09-07 21:52     ` James Bottomley
2020-09-08  5:45       ` Greg KH
2020-09-08 18:05         ` Jarkko Sakkinen
2020-09-08 18:14           ` James Bottomley
2020-09-09  7:07             ` Greg KH
2020-09-11 11:48               ` Jarkko Sakkinen
2020-09-11 11:47             ` Jarkko Sakkinen

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=ee9428f8a4259a86ad331ff169f98c4e8e090d6d.camel@linux.ibm.com \
    --to=zohar@linux.ibm.com \
    --cc=James.Bottomley@hansenpartnership.com \
    --cc=greg@kroah.com \
    --cc=jarkko.sakkinen@linux.intel.com \
    --cc=linux-api@vger.kernel.org \
    --cc=linux-integrity@vger.kernel.org \
    /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).