Bug 1415263 - Missing info about active TPM2 module, cannot search machines with enabled TPM2. [NEEDINFO]
Summary: Missing info about active TPM2 module, cannot search machines with enabled TPM2.
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Beaker
Classification: Community
Component: inventory
Version: 26
Hardware: Unspecified
OS: Unspecified
unspecified
high
Target Milestone: future_maint
Assignee: beaker-dev-list
QA Contact: tools-bugs
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-01-20 17:03 UTC by Vilém Maršík
Modified: 2020-10-21 14:14 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-10-21 14:14:02 UTC
vmarsik: needinfo? (beaker-dev-list)


Attachments (Terms of Use)

Description Vilém Maršík 2017-01-20 17:03:10 UTC
Description of problem: Need a way to find machines with enabled TPM2 in Beaker. There are multiple bugreports / feature requests on TPM2 that should be tested.


Version-Release number of selected component (if applicable):
*

How reproducible:
always

Steps to Reproduce:
1. try to find a machine with active TPM2 in Beaker
2.
3.

Actual results:
The only known usable thing is TBOOT, working for TPM1. If I am looking correctly, this key is not set on any known TPM2 machine in Beaker -> no way to find them, unless you already know their hostname.

Expected results:
Stored info if a machine has TPM2 or TPM1. Frontend searching for TPM2 and TPM1 machines.

Additional info:

Comment 1 Jeff Bastian 2017-01-20 19:55:14 UTC
I enabled TPM 2.0 on my Lenovo T460s laptop (in the BIOS/UEFI settings) and lshw does not see it:

$ sudo lshw | grep -i tpm
$ 


The device is visible to the kernel though:

$ cat /sys/class/tpm/tpm0/device/description
TPM 2.0 Device

Comment 2 Dan Callaghan 2017-02-23 15:34:11 UTC
First step would be to get lshw reporting the TPM as a device, that would be enough to get it appearing in Beaker's list of devices for a system, which is already searchable.

Comment 3 Vilém Maršík 2018-08-29 09:14:53 UTC
Any progress here? It's blocking me more and more, as there is increasing number of TPM2 bugs on non-x86_64 architectures, and I cannot even tell if we have the HW.

Comment 4 Roman Joost 2018-08-29 23:57:58 UTC
Dear Vilém, 

there has been no progress so far on this item, since we're concentrating on RHEL8. Unless it's a real blocker for RHEL8 we currently won't have any capacity to work on this.

However, if you're interested and keen, any patches for lshw would be appreciated and getting this item moving.

Comment 5 Jeff Bastian 2018-08-30 21:04:10 UTC
I haven't looked at the lshw source code in a while, but it should be fairly simple to get lshw to report the contents of
   /sys/class/tpm/tpm0/device/description
(if the file exists).  That would be a huge step to making Beaker more searchable for systems with TPMs.

Checking if /dev/tpm0 (or /dev/tpm*) exists might be useful too.

Comment 6 Jeff Bastian 2018-08-30 21:07:54 UTC
The description text is nothing fancy; on my laptop it just reports:

$ cat /sys/class/tpm/tpm0/device/description 
TPM 2.0 Device

Comment 7 Dan Callaghan 2018-08-30 22:47:13 UTC
These tpm devices are probably on the "platform" bus from kernel/lshw PoV which means lshw cannot, or does not know how to, magically enumerate them in the same way it does for PCI and USB etc. It might just need a tiny bit of code added to lshw to look in the right part of /sys.

Comment 8 Jeff Bastian 2018-08-31 16:10:04 UTC
Yeah, the TPM is usually on the LPC (Low Pin Count) or SPI (Serial Peripheral Interface) bus.  The LPC bus is attached to PCI as a pseudo-ISA bus.  From my laptop:

$ lspci | grep LPC
00:1f.0 ISA bridge: Intel Corporation Sunrise Point-LP LPC Controller (rev 21)

I haven't found an equivalent to lscpi, though, for the LPC bus.


But poking around sysfs, the kernel shows the TPM on the "acpi" bus:

$ ls -l /sys/class/tpm/tpm0
lrwxrwxrwx. 1 root root 0 Aug 27 07:12 /sys/class/tpm/tpm0 -> ../../devices/LNXSYSTM:00/LNXSYBUS:00/MSFT0101:00/tpm/tpm0

$ ls -l /sys/devices/LNXSYSTM:00/subsystem
lrwxrwxrwx. 1 root root 0 Aug 27 07:12 /sys/devices/LNXSYSTM:00/subsystem -> ../../bus/acpi

$ cat /sys/bus/acpi/devices/MSFT0101:00/description 
TPM 2.0 Device


It's a tangled mess of symlinks, but you get there eventually.

Comment 9 Vilém Maršík 2018-10-26 14:03:46 UTC
Hi,

now this really started to block the TPM2 testing - one of the two known machines with working TPM2 does not boot, and the other is long-term loaned. No remaining good TPM2 for RHEL8 testing.

Implementing this would now be more than appreciated. There are a few ideas how to detect TPM2 in the discussion above. What I was using:
* checking for existence of /dev/tpm0 (I guess this also succeeds for TPM1.2)
* running commands from tpm2-tools (but you probably don't want lshw to depend on this package)
* /sys/class/tpm/tpm0/device/description looked promising, but some HW/SW combinations I had were missing this file
* using interface of /sys/devices/pnp0/00:0d/tpm/tpm0/ppi (or alike) was mostly working

Anyway, I was only able to test two or three machines with active TPM2. Now I have access just to one with TPM2 module rather non-working. Under these circumstances, I cannot develop any usable detection code.

What looks very strange to me is that none in RH - including TPM2 developers and lab admins - knows about more machines with working TPM2, while it should be more or less standard HW nowadays. Do we have all the chips disabled or what?

Without being able to find TPM2 machines I cannot test our TPM2 support. Can you  implement something to find it?

(In reply to Roman Joost from comment #4)
> Dear Vilém, 
> 
> there has been no progress so far on this item, since we're concentrating on
> RHEL8. Unless it's a real blocker for RHEL8 we currently won't have any
> capacity to work on this.
> 
> However, if you're interested and keen, any patches for lshw would be
> appreciated and getting this item moving.

Comment 10 Vilém Maršík 2018-10-26 14:56:00 UTC
Checking for TPM2 kernel modules loaded would be helpful, but only when running new products with sufficient TPM2 support.

Comment 11 Vilém Maršík 2018-10-27 07:58:44 UTC
Grepped through all machines' latest Beaker installation logs, and found some TPM2 devices by identified as "tpm_tis XXX: 2.0 TPM (device-id YYY, rev-id ZZ)" in kernel messages. TPM1.2 devices can be identified similarly as "tpm_tis XXX: 1.2 TPM (device-id YYY, rev-id ZZ)" . This is the best I have at the moment, but am not sure how much this will work for future HW/SW.

Comment 12 Karel Srot 2018-11-22 11:47:41 UTC
Would it be suitable at least to label known systems _manually_ using some specific key/value pair so they can be easily queried?

Comment 13 Javier Martinez Canillas 2018-11-22 15:38:36 UTC
Having a way to filter those machines on Beaker will indeed be very useful for testing purposes. I think that as Vilém mentions in Comment 9, grep -sq 2.0 /sys/class/tpm/tpm?/device/description should be good enough.

Even if it causes some false negatives, since he mentions that the sysfs entry isn't present in some machines, it will be better than the current situation.

Comment 14 Russell Doty 2018-11-27 16:44:21 UTC
It may be tangential to this discussion, but all desktop class systems made within the last 3 years or so include TPM 2.0 support - Microsoft requires this for Windows 10 certification.

Many desktop/laptop systems use the Intel Firmware TPM. This must be enabled in BIOS before it can be used.

Three questions:

* Do we have desktop class systems in Beaker?

* Can we get the TPM 2.0 support enabled in BIOS on at least some of these machines?

* How can these systems be identified? If nothing else, can a key/value pair be added when the TPM is enabled in BIOS?


Note You need to log in before you can comment on or make changes to this bug.