Linux-Integrity Archive on lore.kernel.org
 help / color / Atom feed
* TPM 2.0 Linux sysfs interface
@ 2019-08-26 23:24 Piotr Król
  2019-08-27  1:05 ` Jason Gunthorpe
  2019-08-28 15:03 ` Mimi Zohar
  0 siblings, 2 replies; 24+ messages in thread
From: Piotr Król @ 2019-08-26 23:24 UTC (permalink / raw)
  To: linux-integrity

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

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: TPM 2.0 Linux sysfs interface
  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 15:03 ` Mimi Zohar
  1 sibling, 1 reply; 24+ messages in thread
From: Jason Gunthorpe @ 2019-08-27  1:05 UTC (permalink / raw)
  To: Piotr Król; +Cc: linux-integrity

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

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: TPM 2.0 Linux sysfs interface
  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:03 ` Mimi Zohar
  2019-08-28 17:15   ` Petr Vorel
  2019-08-28 23:22   ` Piotr Król
  1 sibling, 2 replies; 24+ messages in thread
From: Mimi Zohar @ 2019-08-28 15:03 UTC (permalink / raw)
  To: Piotr Król, linux-integrity; +Cc: Petr Vorel, Ken Goldman

[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,


^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: TPM 2.0 Linux sysfs interface
  2019-08-27  1:05 ` Jason Gunthorpe
@ 2019-08-28 15:53   ` Mimi Zohar
  2019-08-28 16:15     ` Jason Gunthorpe
  0 siblings, 1 reply; 24+ messages in thread
From: Mimi Zohar @ 2019-08-28 15:53 UTC (permalink / raw)
  To: Jason Gunthorpe, Piotr Król; +Cc: linux-integrity

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


^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: TPM 2.0 Linux sysfs interface
  2019-08-28 15:53   ` Mimi Zohar
@ 2019-08-28 16:15     ` Jason Gunthorpe
  2019-08-30 21:20       ` Tadeusz Struk
  0 siblings, 1 reply; 24+ messages in thread
From: Jason Gunthorpe @ 2019-08-28 16:15 UTC (permalink / raw)
  To: Mimi Zohar; +Cc: Piotr Król, linux-integrity

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

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: TPM 2.0 Linux sysfs interface
  2019-08-28 15:03 ` Mimi Zohar
@ 2019-08-28 17:15   ` Petr Vorel
  2019-08-28 23:22   ` Piotr Król
  1 sibling, 0 replies; 24+ messages in thread
From: Petr Vorel @ 2019-08-28 17:15 UTC (permalink / raw)
  To: Mimi Zohar; +Cc: Piotr Król, linux-integrity, Ken Goldman

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

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: TPM 2.0 Linux sysfs interface
  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
  1 sibling, 1 reply; 24+ messages in thread
From: Piotr Król @ 2019-08-28 23:22 UTC (permalink / raw)
  To: Mimi Zohar, linux-integrity; +Cc: Petr Vorel, Ken Goldman



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

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: TPM 2.0 Linux sysfs interface
  2019-08-28 23:22   ` Piotr Król
@ 2019-08-29  7:32     ` Petr Vorel
  0 siblings, 0 replies; 24+ messages in thread
From: Petr Vorel @ 2019-08-29  7:32 UTC (permalink / raw)
  To: Piotr Król; +Cc: Mimi Zohar, linux-integrity, Ken Goldman

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

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: TPM 2.0 Linux sysfs interface
  2019-08-28 16:15     ` Jason Gunthorpe
@ 2019-08-30 21:20       ` Tadeusz Struk
  2019-09-02 19:26         ` Jason Gunthorpe
  0 siblings, 1 reply; 24+ messages in thread
From: Tadeusz Struk @ 2019-08-30 21:20 UTC (permalink / raw)
  To: Jason Gunthorpe, Mimi Zohar; +Cc: Piotr Król, linux-integrity

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

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: TPM 2.0 Linux sysfs interface
  2019-08-30 21:20       ` Tadeusz Struk
@ 2019-09-02 19:26         ` Jason Gunthorpe
  2019-09-02 21:35           ` Mimi Zohar
  0 siblings, 1 reply; 24+ messages in thread
From: Jason Gunthorpe @ 2019-09-02 19:26 UTC (permalink / raw)
  To: Tadeusz Struk; +Cc: Mimi Zohar, Piotr Król, linux-integrity

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

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: TPM 2.0 Linux sysfs interface
  2019-09-02 19:26         ` Jason Gunthorpe
@ 2019-09-02 21:35           ` Mimi Zohar
  2019-09-03  5:55             ` Jason Gunthorpe
  0 siblings, 1 reply; 24+ messages in thread
From: Mimi Zohar @ 2019-09-02 21:35 UTC (permalink / raw)
  To: Jason Gunthorpe, Tadeusz Struk; +Cc: Piotr Król, linux-integrity

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


^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: TPM 2.0 Linux sysfs interface
  2019-09-02 21:35           ` Mimi Zohar
@ 2019-09-03  5:55             ` Jason Gunthorpe
  2019-09-03 11:49               ` Mimi Zohar
  2019-09-03 16:23               ` Tadeusz Struk
  0 siblings, 2 replies; 24+ messages in thread
From: Jason Gunthorpe @ 2019-09-03  5:55 UTC (permalink / raw)
  To: Mimi Zohar; +Cc: Tadeusz Struk, Piotr Król, linux-integrity

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

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: TPM 2.0 Linux sysfs interface
  2019-09-03  5:55             ` Jason Gunthorpe
@ 2019-09-03 11:49               ` Mimi Zohar
  2019-09-03 13:07                 ` Jason Gunthorpe
  2019-09-03 16:23               ` Tadeusz Struk
  1 sibling, 1 reply; 24+ messages in thread
From: Mimi Zohar @ 2019-09-03 11:49 UTC (permalink / raw)
  To: Jason Gunthorpe; +Cc: Tadeusz Struk, Piotr Król, linux-integrity

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


^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: TPM 2.0 Linux sysfs interface
  2019-09-03 11:49               ` Mimi Zohar
@ 2019-09-03 13:07                 ` Jason Gunthorpe
  2019-09-03 13:23                   ` Mimi Zohar
  0 siblings, 1 reply; 24+ messages in thread
From: Jason Gunthorpe @ 2019-09-03 13:07 UTC (permalink / raw)
  To: Mimi Zohar; +Cc: Tadeusz Struk, Piotr Król, linux-integrity

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

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: TPM 2.0 Linux sysfs interface
  2019-09-03 13:07                 ` Jason Gunthorpe
@ 2019-09-03 13:23                   ` Mimi Zohar
  2019-09-03 16:21                     ` Jarkko Sakkinen
  0 siblings, 1 reply; 24+ messages in thread
From: Mimi Zohar @ 2019-09-03 13:23 UTC (permalink / raw)
  To: Jarkko Sakkinen
  Cc: Tadeusz Struk, Piotr Król, linux-integrity, Jason Gunthorpe

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


^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: TPM 2.0 Linux sysfs interface
  2019-09-03 13:23                   ` Mimi Zohar
@ 2019-09-03 16:21                     ` Jarkko Sakkinen
  0 siblings, 0 replies; 24+ messages in thread
From: Jarkko Sakkinen @ 2019-09-03 16:21 UTC (permalink / raw)
  To: Mimi Zohar
  Cc: Tadeusz Struk, Piotr Król, linux-integrity, Jason Gunthorpe

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


^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: TPM 2.0 Linux sysfs interface
  2019-09-03  5:55             ` Jason Gunthorpe
  2019-09-03 11:49               ` Mimi Zohar
@ 2019-09-03 16:23               ` Tadeusz Struk
  2019-09-03 22:40                 ` Jordan Hand
  1 sibling, 1 reply; 24+ messages in thread
From: Tadeusz Struk @ 2019-09-03 16:23 UTC (permalink / raw)
  To: Jason Gunthorpe, Mimi Zohar; +Cc: Piotr Król, linux-integrity

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

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: TPM 2.0 Linux sysfs interface
  2019-09-03 16:23               ` Tadeusz Struk
@ 2019-09-03 22:40                 ` Jordan Hand
  2019-09-03 23:29                   ` Mimi Zohar
  0 siblings, 1 reply; 24+ messages in thread
From: Jordan Hand @ 2019-09-03 22:40 UTC (permalink / raw)
  To: Tadeusz Struk, Jason Gunthorpe, Mimi Zohar
  Cc: Piotr Król, linux-integrity


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

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: TPM 2.0 Linux sysfs interface
  2019-09-03 22:40                 ` Jordan Hand
@ 2019-09-03 23:29                   ` Mimi Zohar
  2019-09-04  5:58                     ` Jason Gunthorpe
  0 siblings, 1 reply; 24+ messages in thread
From: Mimi Zohar @ 2019-09-03 23:29 UTC (permalink / raw)
  To: Jordan Hand, Tadeusz Struk, Jason Gunthorpe
  Cc: Piotr Król, linux-integrity, Alexey Dobriyan

(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


^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: TPM 2.0 Linux sysfs interface
  2019-09-03 23:29                   ` Mimi Zohar
@ 2019-09-04  5:58                     ` Jason Gunthorpe
  2019-09-04 11:30                       ` Mimi Zohar
  0 siblings, 1 reply; 24+ messages in thread
From: Jason Gunthorpe @ 2019-09-04  5:58 UTC (permalink / raw)
  To: Mimi Zohar
  Cc: Jordan Hand, Tadeusz Struk, Piotr Król, linux-integrity,
	Alexey Dobriyan

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

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: TPM 2.0 Linux sysfs interface
  2019-09-04  5:58                     ` Jason Gunthorpe
@ 2019-09-04 11:30                       ` Mimi Zohar
  2019-09-04 19:43                         ` Jason Gunthorpe
  0 siblings, 1 reply; 24+ messages in thread
From: Mimi Zohar @ 2019-09-04 11:30 UTC (permalink / raw)
  To: Jason Gunthorpe
  Cc: Jordan Hand, Tadeusz Struk, Piotr Król, linux-integrity,
	Alexey Dobriyan

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


^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: TPM 2.0 Linux sysfs interface
  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
  0 siblings, 2 replies; 24+ messages in thread
From: Jason Gunthorpe @ 2019-09-04 19:43 UTC (permalink / raw)
  To: Mimi Zohar
  Cc: Jordan Hand, Tadeusz Struk, Piotr Król, linux-integrity,
	Alexey Dobriyan

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

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: TPM 2.0 Linux sysfs interface
  2019-09-04 19:43                         ` Jason Gunthorpe
@ 2019-09-04 20:26                           ` Mimi Zohar
  2019-09-06 17:53                           ` Serge E. Hallyn
  1 sibling, 0 replies; 24+ messages in thread
From: Mimi Zohar @ 2019-09-04 20:26 UTC (permalink / raw)
  To: Jason Gunthorpe
  Cc: Jordan Hand, Tadeusz Struk, Piotr Król, linux-integrity,
	Alexey Dobriyan

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


^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: TPM 2.0 Linux sysfs interface
  2019-09-04 19:43                         ` Jason Gunthorpe
  2019-09-04 20:26                           ` Mimi Zohar
@ 2019-09-06 17:53                           ` Serge E. Hallyn
  1 sibling, 0 replies; 24+ messages in thread
From: Serge E. Hallyn @ 2019-09-06 17:53 UTC (permalink / raw)
  To: Jason Gunthorpe
  Cc: Mimi Zohar, Jordan Hand, Tadeusz Struk, Piotr Król,
	linux-integrity, Alexey Dobriyan

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.

^ permalink raw reply	[flat|nested] 24+ messages in thread

end of thread, back to index

Thread overview: 24+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
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
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

Linux-Integrity Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-integrity/0 linux-integrity/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-integrity linux-integrity/ https://lore.kernel.org/linux-integrity \
		linux-integrity@vger.kernel.org linux-integrity@archiver.kernel.org
	public-inbox-index linux-integrity


Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-integrity


AGPL code for this site: git clone https://public-inbox.org/ public-inbox