Bug 206275

Summary: [bisected] tpm_tis broken for XPS 9560
Product: Drivers Reporter: Alex Guzman (alex)
Component: OtherAssignee: drivers_other
Status: NEW ---    
Severity: normal CC: jarkko.sakkinen, superm1, tstruk
Priority: P1    
Hardware: x86-64   
OS: Linux   
Kernel Version: 5.4.6+, 5.5-rc7 Subsystem:
Regression: No Bisected commit-id:
Attachments: dmesg when booting the first broken commit
dmesg when booting 5.5_rc7
Output from tpm2_getcap on 5.4.6
Fixed capabilities only

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.