Re: TPM 2.0 Linux sysfs interface

[Mimi Zohar <zohar@linux.ibm.com>]

(Cc'ing Alexy)

On Tue, 2019-09-03 at 15:40 -0700, Jordan Hand wrote:
> On 9/3/19 9:23 AM, Tadeusz Struk wrote:
> > On 9/2/19 10:55 PM, 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?
> > 
> > The advantage of /proc/tpminfo would be that it can be a first
> > entry point on a system, that would give general overview of the
> > system TPM configuration, without the need of poking /dev/tpm<N>
> > files, only to find out that the TPM doesn't understand the
> > command, because it implements different version of TCG spec.
> > It would be a single point of information in case of multiple TPMs.
> > It can have some predefined format that could be read by a human
> > as well as a machine, e.g.
> > 
> > tpm0:
> >    version: 2.0
> >    physical interface: CRB
> >    supported PCR banks: SHA1, SHA256
> >    ...
> >    vendor: <Vendor Name>
> >    vendor specific: <Vendor specific output>

Agreed, but Alexey, the "proc" maintainer, and Jarrko need to agree. 

> >
> To me it still feels trivial write an application to do this same thing
> in userspace with ioctls to the char device (figure out what interface
> the TPM is using, get basic capabilities, etc.). There isn't anything
> here that the kernel can do that can't be done from userspace that I can
> see. Is this not true? Maybe its less code in the kernel but I don't
> know that that's a great reason.
> 
> I don't see a clear advantage to putting the code in the kernel, but I
> do see disadvantages. Interfaces between kernel and userspace need to be
> more rigid to avoid breakage.

This discussion is going around in circles.  There are enough people
asking that the kernel provide at least the TPM version (eg. TPM 1.2
or TPM 2.0).  Userspace applications/regression tests shouldn't have
to figure out the TPM version by sending a TPM command and seeing if
it fails.  That really isn't asking a lot.

I would also prefer not having to be dependent on a userspace
application to read the TPM PCRs in order to verify the IMA
measurement list.

Mimi