From: James Bottomley <James.Bottomley@HansenPartnership.com>
To: linux-integrity@vger.kernel.org
Cc: Mimi Zohar <zohar@linux.ibm.com>,
Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>,
linux-api@vger.kernel.org
Subject: [PATCH RESEND v4 0/1] add sysfs exports for TPM 2 PCR registers
Date: Sun, 6 Sep 2020 13:32:44 -0700 [thread overview]
Message-ID: <20200906203245.18429-1-James.Bottomley@HansenPartnership.com> (raw)
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
...
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?
2. Should we export the values as one value per file (current patch)
or as a binary blob of all 24?
I'm largely ambivalent about 1. I can easily do securityfs output, it
is more work than sysfs largely because securityfs lacks most of the
features of sysfs, including the groups one that this patch uses
heavily, but that can all be open coded (as most other securityfs
consumers do).
I'm less ambivalent about the binary blob idea: pretty much every use
case we have requires a set of PCRs which are fewer than the 24 and a
lot only require a single PCR, so providing all 24 in a format that
has to be parsed seems to make life more difficult for the consuming
program. The argument, at least, for providing the PCRs in binary
form is that most of the consuming programs, once they've selected
their set, tend to need the hash value of the set, which necessitates
converting from ascii to binary. I do this by the simple script (for
PCRs say 1,6,7) as:
cat /sys/class/tpm/tpm0/pcr-sha256/{1,6,7}|xxd -r -p|sha256sum
I've cc'd Jarkko, who's the main proponent of the binary blob use case
because he can make better arguments than I can.
Regards,
James
---
James Bottomley (1):
tpm: add sysfs exports for all banks of PCR registers
drivers/char/tpm/tpm-sysfs.c | 178 +++++++++++++++++++++++++++++++++++
include/linux/tpm.h | 9 +-
2 files changed, 186 insertions(+), 1 deletion(-)
--
2.26.2
next reply other threads:[~2020-09-06 20:32 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-06 20:32 James Bottomley [this message]
2020-09-06 20:32 ` [PATCH RESEND v4 1/1] tpm: add sysfs exports for all banks of PCR registers James Bottomley
2020-09-07 5:39 ` Greg KH
2020-09-07 5:59 ` James Bottomley
2020-09-07 13:21 ` Jarkko Sakkinen
2020-09-07 17:37 ` Greg KH
2020-09-08 17:39 ` Jarkko Sakkinen
2020-09-07 5:38 ` [PATCH RESEND v4 0/1] add sysfs exports for TPM 2 " 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
2020-11-29 22:30 James Bottomley
2020-11-30 8:18 ` Greg KH
2020-11-30 15:21 ` Mimi Zohar
2020-11-30 15:26 ` James Bottomley
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=20200906203245.18429-1-James.Bottomley@HansenPartnership.com \
--to=james.bottomley@hansenpartnership.com \
--cc=jarkko.sakkinen@linux.intel.com \
--cc=linux-api@vger.kernel.org \
--cc=linux-integrity@vger.kernel.org \
--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.