/dev/tpm0 and /dev/tpmrm0 are not present in kernel: /boot/vmlinuz-6.4.11-200.fc38.x86_64 or /boot/vmlinuz-6.4.12-200.fc38.x86_64 I need to use an earlier kernel to use the TPM to decrypt my luks2 volume. Please fix and make sure the TPM devices exist in next kernel releases. Reproducible: Always Steps to Reproduce: 1.with new kernel: 2.sudo ls /dev/t* 3. you should see: dev/tpm0 /dev/tpmrm0 Actual Results: did not see the needed devices Expected Results: should see: dev/tpm0 /dev/tpmrm0 The problem is preventing clevis from working.
If it disappeared with a kernel upgrade why are you reporting the bug against the userspace libraries which have nothing to do with the creation of /dev/tpm* Also on 3 of my machines with TPM2 modules the devices are there on 6.4.11 kernels. You're also reporting against F-39 when your package versions are showing f38. Finally please provide details of the hardware, both the general HW vendor and the TPM2 module vendor.
The output of `dmesg` or `journalctl -k` would be useful to see as well. 6.4.11 had the following changes trying to deal with: d78177be9b01 tpm_tis: Opt-in interrupts | 2023-08-16 | (Jarkko Sakkinen) 27722a5a5c30 tpm: tpm_tis: Fix UPX-i11 DMI_MATCH condition | 2023-08-16 | (Peter Ujfalusi) d75c2b5e06bc tpm: Add a helper for checking hwrng enabled | 2023-08-16 | (Mario Limonciello) 6b718101cd99 tpm/tpm_tis: Disable interrupts for Lenovo P620 devices | 2023-08-16 | (Jonathan McDowell) 872fe964648c tpm: Disable RNG for all AMD fTPMs | 2023-08-16 | (Mario Limonciello) bc3d1e146f83 tpm/tpm_tis: Disable interrupts for TUXEDO InfinityBook S 15/17 Gen7 | 2023-08-16 | (Takashi Iwai) There are 2 other patches related to interrupts and the AMD fTPM issues currently on the integrity mailing lists. In particular there is one that is resolving a problem that crops up for some Intel fTPMs causing them to fail probing due to the commit 872fe964648c ("tpm: Disable RNG for all AMD fTPMs"): https://lore.kernel.org/linux-integrity/20230822231510.2263255-1-jarkko@kernel.org/ Without seeing any output from the kernel for the impacted systems, that would be my guess as to what the problem is.
I think this is a regression with some Intel fTPMs when they fixed an issue with AMD fTPMs: https://www.spinics.net/lists/linux-integrity/msg26755.html
For reference I believe this is going to be the one that lands upstream: https://lkml.org/lkml/2023/8/22/1197 Would affect Intel based fTPMs. Still awaiting clarification from the original reporter the details of his HW but it looks like we're seeing this on some IoT supported platforms.
Proposed as a Blocker for 39-beta by Fedora user pbrobinson using the blocker tracking app because: This is stopping some devices from booting.
Also breaks some suspend: https://www.spinics.net/lists/linux-integrity/msg26713.html U/S bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=217804
(In reply to Fedora Blocker Bugs Application from comment #5) > Proposed as a Blocker for 39-beta by Fedora user pbrobinson using the > blocker tracking app because: > > This is stopping some devices from booting. Hi Peter, please clarify - do you have some list of devices which fail to boot? Are you talking about just HW from comment 0 or some IoT devices as well? Does this really prevent boot, or does it just prevent unlocking LUKS using TPM? In the latter case, can LUKS still be unlocked manually by providing the password from the keyboard? And do we have some Fedora Edition where TPM is used for LUKS unlocking by default? Thanks.
See also https://bugzilla.redhat.com/show_bug.cgi?id=2232888 and https://github.com/coreos/fedora-coreos-tracker/issues/1555 They look related
> > This is stopping some devices from booting. > > Hi Peter, please clarify - do you have some list of devices which fail to > boot? Are you talking about just HW from comment 0 or some IoT devices as > well? Does this really prevent boot, or does it just prevent unlocking LUKS > using TPM? In the latter case, can LUKS still be unlocked manually by > providing the password from the keyboard? And do we have some Fedora Edition > where TPM is used for LUKS unlocking by default? Thanks. Any Intel based device with a fTPM will fail to boot, it's worse if the user is using the fTPM with clevis for disk decryption. In the Fedora IoT case this affects at least the Fitlet, which is a supported device, and the UpSquared and others are also affected.
(In reply to Peter Robinson from comment #4) > For reference I believe this is going to be the one that lands upstream: > > https://lkml.org/lkml/2023/8/22/1197 > > Would affect Intel based fTPMs. > > Still awaiting clarification from the original reporter the details of his > HW but it looks like we're seeing this on some IoT supported platforms. There is a v3 of the patch on the list, because Jarkko forgot to wrap the crb_acpi_add additions with #ifdef CONFIG_X86. Hopefully the discussion about Reported-by: lines is sorted now, and it will get merged soon.
v3: https://www.spinics.net/lists/linux-integrity/msg26786.html
Created attachment 1986320 [details] Hardware
I just tried 6.4.13 from koji and it has same rpm issue as 6.4.11 and 6.4.12. I am using the lasting working version, 6.4.10, for now.
TPM related lines from logs... Aug 31 06:41:54 machname kernel: efi: ACPI=0x45bfe000 ACPI 2.0=0x45bfe014 TPMFinalLog=0x45b32000 ESRT=0x43f91d18 SMBIOS=0x4376e000 SMBIOS 3.0=0x4376b000 MEMATTR=0x311bb118 MOKvar=0x43745000 RNG=0x45b93018 TPMEventLog=0x3118d018 Aug 31 06:41:54 machname kernel: ACPI: TPM2 0x0000000045BE5000 000034 (v04 HPQOEM 86AB 00000002 HP 00040000) Aug 31 06:41:54 machname kernel: ACPI: Reserving TPM2 table memory at [mem 0x45be5000-0x45be5033] Aug 31 06:41:54 machname kernel: tpma_crb: probe of INTC5000:00 failed with error 378 Aug 31 06:41:54 machname kernel: ima: No TPM chip found, activating TPM-bypass! Aug 31 06:41:54 machname systemd[1]: systemd 253.7-1.fc38 running in system mode (+PAM +AUDIT +SELINUX -APPARMOR +IMA +SMACK +SECCOMP -GCRYPT +GNUTLS +OPENSSL +ACL +BLKID +CURL +ELFUTILS +FIDO2 +IDN2 -IDN -IPTC +KMOD +LIBCRYPTSETUP +LIBFDISK +PCRE2 +PWQUALITY +P11KIT +QRENCODE +TPM2 +BZIP2 +LZ4 +XZ +ZLIB +ZSTD +BPF_FRAMEWORK +XKBCOMMON +UTMP +SYSVINIT default-hierarchy=unified) Aug 31 10:42:11 machname systemd[1]: systemd 253.7-1.fc38 running in system mode (+PAM +AUDIT +SELINUX -APPARMOR +IMA +SMACK +SECCOMP -GCRYPT +GNUTLS +OPENSSL +ACL +BLKID +CURL +ELFUTILS +FIDO2 +IDN2 -IDN -IPTC +KMOD +LIBCRYPTSETUP +LIBFDISK +PCRE2 +PWQUALITY +P11KIT +QRENCODE +TPM2 +BZIP2 +LZ4 +XZ +ZLIB +ZSTD +BPF_FRAMEWORK +XKBCOMMON +UTMP +SYSVINIT default-hierarchy=unified) Aug 31 10:42:11 machname systemd[1]: systemd-pcrmachine.service - TPM2 PCR Machine ID Measurement was skipped because of an unmet condition check (ConditionPathExists=/sys/firmware/efi/efivars/StubPcrKernelImage-4a67b082-0a4c-41cf-b6c7-440b29bb8c4f).
The same search from a working kernel (6.4.10): Aug 31 06:55:30 macname kernel: efi: ACPI=0x45bfe000 ACPI 2.0=0x45bfe014 TPMFinalLog=0x45b32000 ESRT=0x43f91d18 SMBIOS=0x4376e000 SMBIOS 3.0=0x4376b000 MEMATTR=0x311bb118 MOKvar=0x43745000 RNG=0x45b93018 TPMEventLog=0x3118d018 Aug 31 06:55:30 macname kernel: ACPI: TPM2 0x0000000045BE5000 000034 (v04 HPQOEM 86AB 00000002 HP 00040000) Aug 31 06:55:30 macname kernel: ACPI: Reserving TPM2 table memory at [mem 0x45be5000-0x45be5033] Aug 31 06:55:30 macname systemd[1]: systemd 253.7-1.fc38 running in system mode (+PAM +AUDIT +SELINUX -APPARMOR +IMA +SMACK +SECCOMP -GCRYPT +GNUTLS +OPENSSL +ACL +BLKID +CURL +ELFUTILS +FIDO2 +IDN2 -IDN -IPTC +KMOD +LIBCRYPTSETUP +LIBFDISK +PCRE2 +PWQUALITY +P11KIT +QRENCODE +TPM2 +BZIP2 +LZ4 +XZ +ZLIB +ZSTD +BPF_FRAMEWORK +XKBCOMMON +UTMP +SYSVINIT default-hierarchy=unified) Aug 31 10:55:34 macname systemd[1]: systemd 253.7-1.fc38 running in system mode (+PAM +AUDIT +SELINUX -APPARMOR +IMA +SMACK +SECCOMP -GCRYPT +GNUTLS +OPENSSL +ACL +BLKID +CURL +ELFUTILS +FIDO2 +IDN2 -IDN -IPTC +KMOD +LIBCRYPTSETUP +LIBFDISK +PCRE2 +PWQUALITY +P11KIT +QRENCODE +TPM2 +BZIP2 +LZ4 +XZ +ZLIB +ZSTD +BPF_FRAMEWORK +XKBCOMMON +UTMP +SYSVINIT default-hierarchy=unified) Aug 31 10:55:34 macname systemd[1]: systemd-pcrmachine.service - TPM2 PCR Machine ID Measurement was skipped because of an unmet condition check (ConditionPathExists=/sys/firmware/efi/efivars/StubPcrKernelImage-4a67b082-0a4c-41cf-b6c7-440b29bb8c4f).
+4 in https://pagure.io/fedora-qa/blocker-review/issue/1232 , marking accepted. Peter, could you backport the patch? As this is a Beta blocker we need the fix to build an RC or ship, and we are now very tight on time (go/no-go is next Thursday, and this is a holiday weeked for North America, so we'll only be back on Tuesday)...
i just saw 6.4.14 on koji. It has same issue, no /dev/tpm* devices. I reverted to 6.4.10 and all works fine.
You don't need to re-report for every new kernel version. We know what the bug is and what the fix is, and we'll know when it goes in where.
(In reply to Adam Williamson from comment #16) > +4 in https://pagure.io/fedora-qa/blocker-review/issue/1232 , marking > accepted. > > Peter, could you backport the patch? As this is a Beta blocker we need the > fix to build an RC or ship, and we are now very tight on time (go/no-go is > next Thursday, and this is a holiday weeked for North America, so we'll only > be back on Tuesday)... I intend to make a patch once it's accepted upstream, upstream still hasn't pulled it in although I think the concensus is basically there, was already planning a backport once it was accepted. I was delaying in the hope of upstream consensus.
FEDORA-2023-4d7e9e1dc5 has been submitted as an update to Fedora 37. https://bodhi.fedoraproject.org/updates/FEDORA-2023-4d7e9e1dc5
FEDORA-2023-775674d7f1 has been submitted as an update to Fedora 38. https://bodhi.fedoraproject.org/updates/FEDORA-2023-775674d7f1
I've set the F37 and F38 updates to *not* close bugs on stable push, so this doesn't inadvertently drop off F39 tracking. I sure wish that setting was per-bug, not per-update...
FEDORA-2023-221b03d9bf has been submitted as an update to Fedora 39. https://bodhi.fedoraproject.org/updates/FEDORA-2023-221b03d9bf
I can confirm the patched kernel has resolved the issue. FEDORA-2023-221b03d9bf has been submitted as an update to Fedora 39. https://bodhi.fedoraproject.org/updates/FEDORA-2023-221b03d9bf Thanks you very much.
FEDORA-2023-775674d7f1 has been pushed to the Fedora 38 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2023-775674d7f1` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2023-775674d7f1 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2023-4d7e9e1dc5 has been pushed to the Fedora 37 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2023-4d7e9e1dc5` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2023-4d7e9e1dc5 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2023-221b03d9bf has been pushed to the Fedora 39 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2023-221b03d9bf` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2023-221b03d9bf See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2023-221b03d9bf has been pushed to the Fedora 39 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2023-4d7e9e1dc5 has been pushed to the Fedora 37 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2023-775674d7f1 has been pushed to the Fedora 38 stable repository. If problem still persists, please make note of it in this bug report.