TPM 2.0 Linux sysfs interface

TPM 2.0 Linux sysfs interface

[Piotr Król]

Hi all,
I'm moving here discussion that I started with Jarkko and Peter on LinkedIn.

I'm preparing for 2 talks during LPC 2019 System Boot MC and one of it
will discuss TPM 2.0 sysfs support [1]. This was discussed couple times
[2] and explained why it is not done yet by Jarkko [3].

Why is this important?
- there seem to be no default method to distinguish if we dealing with
TPM 1.2 or 2.0 in the system
- distros use various tools to detect TPM based on sysfs (e.g. Qubes OS
scripts)
- tpm2-software has ton of dependencies, is not easy to build,
development is way faster then distros can manage and packages are often
out of date or even broken, so using it can be troublesome
- for deeply embedded systems adding fully-featured tpm2-software
doesn't make sense e.g. if we just need PCRs values

Jarkko comment on detecting 1.2 vs 2.0:
"Detecting TPM 2.0 is dead easy: send any idempotent TPM 2.0 command and
check if the tag field matches 0x8002 (TPM_NO_SESSIONS). The sysfs
features for TPM 1.2 are for the large part useless as you can get the
same data by using TPM commands."

Ok, but doesn't this mean I need TPM2 software stack?
Peter mentioned that it can be tricky to invoke such tools early in boot
process.

Finally, I do not feel expert in the field of Linux integrity and don't
want to argue for sysfs if it doesn't make sense for TPM 2.0, but if
that's the situation I would like to know what are the best practices to
solve above issues. If you think there is something important to be
discussed in above context please let me know.

[1] https://linuxplumbersconf.org/event/4/contributions/516/
[2]
https://patchwork.kernel.org/project/linux-integrity/list/?series=&submitter=&state=*&q=sysfs&archive=&delegate=
[3] https://lwn.net/Articles/624241/

Best Regards,
-- 
Piotr Król
Embedded Systems Consultant
GPG: B2EE71E967AA9E4C
https://3mdeb.com | @3mdeb_com

Re: TPM 2.0 Linux sysfs interface

[Jason Gunthorpe]

On Tue, Aug 27, 2019 at 01:24:55AM +0200, Piotr Król wrote:
> Hi all,
> I'm moving here discussion that I started with Jarkko and Peter on LinkedIn.
> 
> I'm preparing for 2 talks during LPC 2019 System Boot MC and one of it
> will discuss TPM 2.0 sysfs support [1]. This was discussed couple times
> [2] and explained why it is not done yet by Jarkko [3].
> 
> Why is this important?
> - there seem to be no default method to distinguish if we dealing with
> TPM 1.2 or 2.0 in the system
> - distros use various tools to detect TPM based on sysfs (e.g. Qubes OS
> scripts)
> - tpm2-software has ton of dependencies, is not easy to build,
> development is way faster then distros can manage and packages are often
> out of date or even broken, so using it can be troublesome
> - for deeply embedded systems adding fully-featured tpm2-software
> doesn't make sense e.g. if we just need PCRs values
> 
> Jarkko comment on detecting 1.2 vs 2.0:
> "Detecting TPM 2.0 is dead easy: send any idempotent TPM 2.0 command and
> check if the tag field matches 0x8002 (TPM_NO_SESSIONS). The sysfs
> features for TPM 1.2 are for the large part useless as you can get the
> same data by using TPM commands."
> 
> Ok, but doesn't this mean I need TPM2 software stack?
> Peter mentioned that it can be tricky to invoke such tools early in boot
> process.
> 
> Finally, I do not feel expert in the field of Linux integrity and don't
> want to argue for sysfs if it doesn't make sense for TPM 2.0, but if
> that's the situation I would like to know what are the best practices to
> solve above issues. If you think there is something important to be
> discussed in above context please let me know.

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.

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.

A good reason would be something like needing to trigger a systemd
unit from udev.

Jason

Re: TPM 2.0 Linux sysfs interface

[Mimi Zohar]

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

Re: TPM 2.0 Linux sysfs interface

[Jason Gunthorpe]

On Wed, Aug 28, 2019 at 11:53:12AM -0400, Mimi Zohar wrote:
> 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.

It was intentional.

> > 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.

Jason

Re: TPM 2.0 Linux sysfs interface

[Tadeusz Struk]

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.

Thanks,
-- 
Tadeusz

Re: TPM 2.0 Linux sysfs interface

[Jason Gunthorpe]

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?

Jason

Re: TPM 2.0 Linux sysfs interface

[Mimi Zohar]

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).

Mimi

Re: TPM 2.0 Linux sysfs interface

[Jason Gunthorpe]

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?

Jason

Re: TPM 2.0 Linux sysfs interface

[Mimi Zohar]

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?

Mimi

Re: TPM 2.0 Linux sysfs interface

[Jason Gunthorpe]

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

Re: TPM 2.0 Linux sysfs interface

[Mimi Zohar]

On Tue, 2019-09-03 at 10:07 -0300, Jason Gunthorpe wrote:
> 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

Jarkko, any comments/suggestions?

thanks,

Mimi

Re: TPM 2.0 Linux sysfs interface

[Jarkko Sakkinen]

On Tue, 2019-09-03 at 09:23 -0400, Mimi Zohar wrote:
> On Tue, 2019-09-03 at 10:07 -0300, Jason Gunthorpe wrote:
> > 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
> 
> Jarkko, any comments/suggestions?
 
On exactly what?

/Jarkko

Re: TPM 2.0 Linux sysfs interface

[Tadeusz Struk]

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>


Thanks,
-- 
Tadeusz

Re: TPM 2.0 Linux sysfs interface

[Jordan Hand]

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>
>
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.

Thanks,
Jordan

Re: TPM 2.0 Linux sysfs interface

[Mimi Zohar]

(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

Re: TPM 2.0 Linux sysfs interface

[Jason Gunthorpe]

On Tue, Sep 03, 2019 at 07:29:43PM -0400, Mimi Zohar wrote:

> 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.

A single version number could be appropriate for sysfs
 
> 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.

Why?

Jason

Re: TPM 2.0 Linux sysfs interface

[Mimi Zohar]

On Wed, 2019-09-04 at 02:58 -0300, Jason Gunthorpe wrote:
> On Tue, Sep 03, 2019 at 07:29:43PM -0400, Mimi Zohar wrote:
> 
> > 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.
> 
> A single version number could be appropriate for sysfs
>  
> > 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.
> 
> Why?

Being dependent on a userspace application implies a level of trust,
that might not be warranted, depending on the system's configuration.

Mimi

Re: TPM 2.0 Linux sysfs interface

[Jason Gunthorpe]

On Wed, Sep 04, 2019 at 07:30:58AM -0400, Mimi Zohar wrote:
> On Wed, 2019-09-04 at 02:58 -0300, Jason Gunthorpe wrote:
> > On Tue, Sep 03, 2019 at 07:29:43PM -0400, Mimi Zohar wrote:
> > 
> > > 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.
> > 
> > A single version number could be appropriate for sysfs
> >  
> > > 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.
> > 
> > Why?
> 
> Being dependent on a userspace application implies a level of trust,
> that might not be warranted, depending on the system's
> configuration.

Surely if you can trust 'cat' you can trust something that does ioctl?

Jason

Re: TPM 2.0 Linux sysfs interface

[Mimi Zohar]

On Wed, 2019-09-04 at 16:43 -0300, Jason Gunthorpe wrote:
> On Wed, Sep 04, 2019 at 07:30:58AM -0400, Mimi Zohar wrote:
> > On Wed, 2019-09-04 at 02:58 -0300, Jason Gunthorpe wrote:
> > > On Tue, Sep 03, 2019 at 07:29:43PM -0400, Mimi Zohar wrote:
> > > 
> > > > 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.
> > > 
> > > A single version number could be appropriate for sysfs
> > >  
> > > > 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.
> > > 
> > > Why?
> > 
> > Being dependent on a userspace application implies a level of trust,
> > that might not be warranted, depending on the system's
> > configuration.
> 
> Surely if you can trust 'cat' you can trust something that does ioctl?

Ok, you've agreed with the kernel exporting the TPM information.  How
it is exported remains to be defined.

Mimi

Re: TPM 2.0 Linux sysfs interface

[Serge E. Hallyn]

On Wed, Sep 04, 2019 at 04:43:48PM -0300, Jason Gunthorpe wrote:
> On Wed, Sep 04, 2019 at 07:30:58AM -0400, Mimi Zohar wrote:
> > On Wed, 2019-09-04 at 02:58 -0300, Jason Gunthorpe wrote:
> > > On Tue, Sep 03, 2019 at 07:29:43PM -0400, Mimi Zohar wrote:
> > > 
> > > > 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.
> > > 
> > > A single version number could be appropriate for sysfs
> > >  
> > > > 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.
> > > 
> > > Why?
> > 
> > Being dependent on a userspace application implies a level of trust,
> > that might not be warranted, depending on the system's
> > configuration.
> 
> Surely if you can trust 'cat' you can trust something that does ioctl?

Being dependent on a userspace application also means more to stuff into
an initramfs if you want to do this during dracut early boot.

Re: TPM 2.0 Linux sysfs interface

[Mimi Zohar]

[Cc'ing Petr Vorel]

Hi Piotr,

On Tue, 2019-08-27 at 01:24 +0200, Piotr Król wrote:
> Hi all,
> I'm moving here discussion that I started with Jarkko and Peter on LinkedIn.
> 
> I'm preparing for 2 talks during LPC 2019 System Boot MC and one of it
> will discuss TPM 2.0 sysfs support [1]. This was discussed couple times
> [2] and explained why it is not done yet by Jarkko [3].
> 
> Why is this important?
> - there seem to be no default method to distinguish if we dealing with
> TPM 1.2 or 2.0 in the system. 

Agreed, this affects both the LTP IMA tests and ima-evm-utils package,
which need to support both TPM 1.2 and 2.0 for the forseeable future.
The LTP IMA tests check different sysfs files to determine if it is
TPM 1.2 or TPM 2.0 (eg. /sys/class/tpm/tpm0/device/description,
/sys/class/tpm/tpm0/device/pcrs and /sys/class/misc/tpm0/device/pcrs),
but the "description" file is not defined by all TPM 2.0's.  It
shouldn't be that difficult to define a single common sysfs file.

> - distros use various tools to detect TPM based on sysfs (e.g. Qubes OS
> scripts)
> - tpm2-software has ton of dependencies, is not easy to build,
> development is way faster then distros can manage and packages are often
> out of date or even broken, so using it can be troublesome
> - for deeply embedded systems adding fully-featured tpm2-software
> doesn't make sense e.g. if we just need PCRs values
> 
> Jarkko comment on detecting 1.2 vs 2.0:
> "Detecting TPM 2.0 is dead easy: send any idempotent TPM 2.0 command and
> check if the tag field matches 0x8002 (TPM_NO_SESSIONS). The sysfs
> features for TPM 1.2 are for the large part useless as you can get the
> same data by using TPM commands."
> 
> Ok, but doesn't this mean I need TPM2 software stack?
> Peter mentioned that it can be tricky to invoke such tools early in boot
> process.

ima-evm-utils now uses the TPM 2.0 TSS[1] to read the PCRs.  I haven't
tried using it during boot, but I don't forsee a problem. I guess it
depends on how early you need to read the PCRs.

Mimi

[1] https://git.code.sf.net/p/ibmtpm20tss/tss

> 
> Finally, I do not feel expert in the field of Linux integrity and don't
> want to argue for sysfs if it doesn't make sense for TPM 2.0, but if
> that's the situation I would like to know what are the best practices to
> solve above issues. If you think there is something important to be
> discussed in above context please let me know.
> 
> [1] https://linuxplumbersconf.org/event/4/contributions/516/
> [2]
> https://patchwork.kernel.org/project/linux-integrity/list/?series=&submitter=&state=*&q=sysfs&archive=&delegate=
> [3] https://lwn.net/Articles/624241/
> 
> Best Regards,

Re: TPM 2.0 Linux sysfs interface

[Petr Vorel]

Hi Mimi, Piotr,

> [Cc'ing Petr Vorel]
Thanks Mimi.

> Hi Piotr,

> On Tue, 2019-08-27 at 01:24 +0200, Piotr Król wrote:
> > Hi all,
> > I'm moving here discussion that I started with Jarkko and Peter on LinkedIn.

> > I'm preparing for 2 talks during LPC 2019 System Boot MC and one of it
> > will discuss TPM 2.0 sysfs support [1]. This was discussed couple times
> > [2] and explained why it is not done yet by Jarkko [3].

> > Why is this important?
> > - there seem to be no default method to distinguish if we dealing with
> > TPM 1.2 or 2.0 in the system. 

> Agreed, this affects both the LTP IMA tests and ima-evm-utils package,
> which need to support both TPM 1.2 and 2.0 for the forseeable future.
> The LTP IMA tests check different sysfs files to determine if it is
> TPM 1.2 or TPM 2.0 (eg. /sys/class/tpm/tpm0/device/description,
> /sys/class/tpm/tpm0/device/pcrs and /sys/class/misc/tpm0/device/pcrs),
> but the "description" file is not defined by all TPM 2.0's.  It
> shouldn't be that difficult to define a single common sysfs file.
+1. I'd appreciate have simple /sys/class/tpm/tpm0/version file.

> > - distros use various tools to detect TPM based on sysfs (e.g. Qubes OS
> > scripts)
> > - tpm2-software has ton of dependencies, is not easy to build,
> > development is way faster then distros can manage and packages are often
> > out of date or even broken, so using it can be troublesome
> > - for deeply embedded systems adding fully-featured tpm2-software
> > doesn't make sense e.g. if we just need PCRs values

> > Jarkko comment on detecting 1.2 vs 2.0:
> > "Detecting TPM 2.0 is dead easy: send any idempotent TPM 2.0 command and
> > check if the tag field matches 0x8002 (TPM_NO_SESSIONS). The sysfs
> > features for TPM 1.2 are for the large part useless as you can get the
> > same data by using TPM commands."

> > Ok, but doesn't this mean I need TPM2 software stack?
> > Peter mentioned that it can be tricky to invoke such tools early in boot
> > process.

> ima-evm-utils now uses the TPM 2.0 TSS[1] to read the PCRs.  I haven't
> tried using it during boot, but I don't forsee a problem. I guess it
> depends on how early you need to read the PCRs.
I'd prefer using library instead of tsspcrread binary ("tsspcrread -halg sha1
-ha %d -ns 2> /dev/null"; better link to shared lib than depend on presence of
binary), but looking into ibmtpm20tss-tss git the functionality is really
provided only in tsspcrread (utils/pcrread.c).
I'd expect it'd be in libibmtss.so.0 or libibmtssutils.so.0, but it's not :(.

> Mimi

> [1] https://git.code.sf.net/p/ibmtpm20tss/tss

Kind regards,
Petr

Re: TPM 2.0 Linux sysfs interface

[Piotr Król]

On 8/28/19 5:03 PM, Mimi Zohar wrote:
> [Cc'ing Petr Vorel]
> 
> Hi Piotr,

Hi Mimi,

> 
> On Tue, 2019-08-27 at 01:24 +0200, Piotr Król wrote:
>> Hi all,
>> I'm moving here discussion that I started with Jarkko and Peter on LinkedIn.
>>
>> I'm preparing for 2 talks during LPC 2019 System Boot MC and one of it
>> will discuss TPM 2.0 sysfs support [1]. This was discussed couple times
>> [2] and explained why it is not done yet by Jarkko [3].
>>
>> Why is this important?
>> - there seem to be no default method to distinguish if we dealing with
>> TPM 1.2 or 2.0 in the system. 
> 
> Agreed, this affects both the LTP IMA tests and ima-evm-utils package,
> which need to support both TPM 1.2 and 2.0 for the forseeable future.
> The LTP IMA tests check different sysfs files to determine if it is
> TPM 1.2 or TPM 2.0 (eg. /sys/class/tpm/tpm0/device/description,
> /sys/class/tpm/tpm0/device/pcrs and /sys/class/misc/tpm0/device/pcrs),
> but the "description" file is not defined by all TPM 2.0's.  It
> shouldn't be that difficult to define a single common sysfs file.

Thank you for that use cases I will point to that during LPC discussion.

Jarkko said that what he potential can cope with is:
/sys/class/tpm/tpm0/protocol_major

But maybe version file is also good to go, depends what it should return
and how that information should be obtained for various TPM versions.

> 
>> - distros use various tools to detect TPM based on sysfs (e.g. Qubes OS
>> scripts)
>> - tpm2-software has ton of dependencies, is not easy to build,
>> development is way faster then distros can manage and packages are often
>> out of date or even broken, so using it can be troublesome
>> - for deeply embedded systems adding fully-featured tpm2-software
>> doesn't make sense e.g. if we just need PCRs values
>>
>> Jarkko comment on detecting 1.2 vs 2.0:
>> "Detecting TPM 2.0 is dead easy: send any idempotent TPM 2.0 command and
>> check if the tag field matches 0x8002 (TPM_NO_SESSIONS). The sysfs
>> features for TPM 1.2 are for the large part useless as you can get the
>> same data by using TPM commands."
>>
>> Ok, but doesn't this mean I need TPM2 software stack?
>> Peter mentioned that it can be tricky to invoke such tools early in boot
>> process.
> 
> ima-evm-utils now uses the TPM 2.0 TSS[1] to read the PCRs.  I haven't
> tried using it during boot, but I don't forsee a problem. I guess it
> depends on how early you need to read the PCRs.

I'm still looking into use case to provide correct examples. I'm
thinking about edge computing devices e.g. Azure IoT Edge, AWS IoT and
Greengrass and its ability to perform trusted boot, but do not have
something well exercised yet.

Definitely there is automatic validation of hardware modules which is
time sensitive and faster access to basic functions verification, then
more savings to manufacturer.

For research purposes I tried couple queries on GitHub to check who use
pcrs throughs sysfs [1][2]. Among others you can find CoreOS, Android,
already mentioned LTP, some google projects. Quite a lot of user space
code to be fixed. Maybe if I will have enough time I will prepare
statistics about usage of given endpoints to quantify how those affect
system.

[1]
https://github.com/search?q=%22%2Fsys%2Fclass%2Ftpm%2Ftpm0%2Fdevice%2Fpcrs%22&type=Code
[2]
https://github.com/search?q=%22%2Fsys%2Fclass%2Fmisc%2Ftpm0%2Fdevice%2Fpcrs%22&type=Code

Best Regards,
-- 
Piotr Król
Embedded Systems Consultant
GPG: B2EE71E967AA9E4C
https://3mdeb.com | @3mdeb_com

Re: TPM 2.0 Linux sysfs interface

[Petr Vorel]

Hi Piotr,

...
> >> Why is this important?
> >> - there seem to be no default method to distinguish if we dealing with
> >> TPM 1.2 or 2.0 in the system. 

> > Agreed, this affects both the LTP IMA tests and ima-evm-utils package,
> > which need to support both TPM 1.2 and 2.0 for the forseeable future.
> > The LTP IMA tests check different sysfs files to determine if it is
> > TPM 1.2 or TPM 2.0 (eg. /sys/class/tpm/tpm0/device/description,
> > /sys/class/tpm/tpm0/device/pcrs and /sys/class/misc/tpm0/device/pcrs),
> > but the "description" file is not defined by all TPM 2.0's.  It
> > shouldn't be that difficult to define a single common sysfs file.

> Thank you for that use cases I will point to that during LPC discussion.
Thanks.

> Jarkko said that what he potential can cope with is:
> /sys/class/tpm/tpm0/protocol_major

> But maybe version file is also good to go, depends what it should return
> and how that information should be obtained for various TPM versions.

...
> I'm still looking into use case to provide correct examples. I'm
> thinking about edge computing devices e.g. Azure IoT Edge, AWS IoT and
> Greengrass and its ability to perform trusted boot, but do not have
> something well exercised yet.

> Definitely there is automatic validation of hardware modules which is
> time sensitive and faster access to basic functions verification, then
> more savings to manufacturer.

> For research purposes I tried couple queries on GitHub to check who use
> pcrs throughs sysfs [1][2]. Among others you can find CoreOS, Android,
> already mentioned LTP, some google projects. Quite a lot of user space
> code to be fixed. Maybe if I will have enough time I will prepare
> statistics about usage of given endpoints to quantify how those affect
> system.
BTW: codesearch.debian.net shows nothing using pcrs in whole
Debian distro [3] [4], nothing is on gitlab either.

> [1]
> https://github.com/search?q=%22%2Fsys%2Fclass%2Ftpm%2Ftpm0%2Fdevice%2Fpcrs%22&type=Code
> [2]
> https://github.com/search?q=%22%2Fsys%2Fclass%2Fmisc%2Ftpm0%2Fdevice%2Fpcrs%22&type=Code
[3] https://codesearch.debian.net/search?q=%2Fsys%2Fclass%2Ftpm%2Ftpm0%2Fdevice%2Fpcrs&literal=1
[4] https://codesearch.debian.net/search?q=%2Fsys%2Fclass%2Fmisc%2Ftpm0%2Fdevice%2Fpcrs&literal=1

Kind regards,
Petr