Bug 206275 - [bisected] tpm_tis broken for XPS 9560
Summary: [bisected] tpm_tis broken for XPS 9560
Status: NEW
Alias: None
Product: Drivers
Classification: Unclassified
Component: Other (show other bugs)
Hardware: x86-64 Linux
: P1 normal
Assignee: drivers_other
Depends on:
Reported: 2020-01-22 03:15 UTC by Alex Guzman
Modified: 2020-05-27 20:01 UTC (History)
3 users (show)

See Also:
Kernel Version: 5.4.6+, 5.5-rc7
Tree: Mainline
Regression: No

dmesg when booting the first broken commit (89.84 KB, text/plain)
2020-01-22 03:15 UTC, Alex Guzman
dmesg when booting 5.5_rc7 (65.50 KB, text/plain)
2020-01-22 03:49 UTC, Alex Guzman
Output from tpm2_getcap on 5.4.6 (29.26 KB, text/plain)
2020-02-11 23:05 UTC, Alex Guzman
Fixed capabilities only (1.64 KB, text/plain)
2020-02-11 23:07 UTC, Alex Guzman

Description Alex Guzman 2020-01-22 03:15:04 UTC
Created attachment 286937 [details]
dmesg when booting the first broken commit

I noted this recently after updating to a recent kernel. In the latest kernels, all operations using tpm2 commands will fail like so:

  ERROR:tcti:src/tss2-tcti/tcti-device.c:290:tcti_device_receive() Failed to read response from fd 3, got errno 1: Operation not permitted 

I bisected the issue back to commit 4d6ebc4c4950595414722dfadd0b361f5a05d37e as the first commit to break things. It's worth noting that that commit results in this error:

  ERROR:tcti:src/tss2-tcti/tcti-device.c:290:tcti_device_receive() Failed to read response from fd 3, got errno 14: Bad address 

Prior to this commit, everything works fine. I'm using the latest commited versions of tpm2-tss and tpm2-tools to test this.
Comment 1 Alex Guzman 2020-01-22 03:49:55 UTC
Created attachment 286939 [details]
dmesg when booting 5.5_rc7
Comment 2 Mario Limonciello 2020-02-11 21:43:42 UTC
Can you please confirm the TPM details in this notebook?
If you can share the fixed properties output from tpm2_getcap (from tpm2-tools), that would be useful for isolation.
It will capture the TPM manufacturer and the firmware version.
Comment 3 Alex Guzman 2020-02-11 23:05:38 UTC
Created attachment 287315 [details]
Output from tpm2_getcap on 5.4.6
Comment 4 Alex Guzman 2020-02-11 23:07:25 UTC
Created attachment 287317 [details]
Fixed capabilities only
Comment 5 Alex Guzman 2020-02-12 23:50:46 UTC
I just noticed that I can get the getcap command to succeed occasionally on the latest kernel by running it repeatedly. Most attempts fail, but it does occasionally return the info.
Comment 6 Mario Limonciello 2020-02-14 18:11:27 UTC
I would raise this again on linux-integrity ML.  This sounds like it's firmly in the camp of regression and should be reverted if it's not fixed.
Comment 7 Alex Guzman 2020-05-26 08:50:58 UTC
I raised this on the mailing list a while back and heard nothing. I've also tried with the latest stable + RC releases and they continue to return the same error.
Comment 8 Mario Limonciello 2020-05-26 15:17:38 UTC
Can you double check the commit ID from your bisect?  I checked in my local kernel history and didn't see 4d6ebc4c4950595414722dfadd0b361f5a05d37e.

I think that if you're not getting a response back in a timely fashion the right thing is to send a revert.  That will jump start the conversation to getting this fixed.
Comment 9 Mario Limonciello 2020-05-26 15:19:06 UTC
Perhaps do you mean d23d12484307b40eea549b8a858f5fffad913897 ?
Comment 10 jarkko.sakkinen 2020-05-27 20:01:35 UTC
Have you CC'd me to those emails? Have not seen any. Might have missed of course by mistake.

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