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.
Created attachment 286939 [details]
dmesg when booting 5.5_rc7
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.
Created attachment 287315 [details]
Output from tpm2_getcap on 5.4.6
Created attachment 287317 [details]
Fixed capabilities only
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.
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.