You are not logged in.
Hey,
I'm trying to use the TPM in my Dell XPS 9560 to automatically unlock my LUKS-encrypted root volume on boot in a fresh install.
During the installation I was able to follow the linked instructions to list the TPM using systemd-cryptenroll, enroll a key for the LUKS device, and subsequently unlock the LUKS device using /usr/lib/systemd/systemd-cryptsetup.
I also updated /etc/mkinitcpio.conf per the wiki to use systemd-based initramfs with sd-encrypt and the HOOKS section now looks as follows:
HOOKS=(base systemd autodetect keyboard sd-vconsole modconf block sd-encrypt filesystems fsck)
Attempting to boot into the system after finishing up installation, the volume did not unlock as expected and I was prompted to provide a passphrase for the root volume. After some troubleshooting I discovered that the TPM isn't loading at all.
The systemd-cryptenroll command used during the installation to list TPM devices now shows the following:
$ systemd-cryptenroll --tpm2-device=list
No suitable TPM2 devices found.
The same TPM kernel modules are loaded as are loaded when using the installation media:
$ lsmod | grep tpm
tpm_crb 20480 0
tpm_tis 16384 0
tpm_tis_core 28672 1 tpm_tis
tpm 102400 4 tpm_tis,trusted,tpm_crb,tpm_tis_core
rng_core 16384 1 tpm
Checking kernel logs I see an error on boot relating to the TPM:
$ sudo dmesg | grep -i tpm
[ 0.000000] efi: ACPI=0x78750000 ACPI 2.0=0x78750000 SMBIOS=0xf0000 SMBIOS 3.0=0xf0020 TPMFinalLog=0x78e1d000 ESRT=0x792b9198 MEMATTR=0x75bc3018 TPMEventLog=0x647b6018
[ 0.009910] ACPI: TPM2 0x00000000787849F8 000034 (v03 Tpm2Tabl 00000001 AMI 00000000)
[ 0.009951] ACPI: Reserving TPM2 table memory at [mem 0x787849f8-0x78784a2b]
[ 6.497658] tpm_tis: probe of MSFT0101:00 failed with error -1
So far I have tried the following to no avail:
Adding the tpm and tpm_tis modules to the MODULES section of /etc/mkinitcpio.conf.
Downgrading to kernel version 5.17.5-arch1-1, which is the version used in the installation media.
Upgrading firmware with fwupd. Interestingly the TPM shows up here, but no update was available for it. A BIOS update was installed when updating firmware.
Clearing the TPM via BIOS settings.
Disabling "fastboot" in the BIOS settings.
Resetting the BIOS settings.
Using systemd-boot (to match the installation media).
I am booting using UEFI via EFISTUB, with a boot entry created as follows:
$ efibootmgr --disk /dev/nvme0n1 --part 1 \
--create --label "Arch Linux" \
--loader /vmlinuz-linux \
--unicode "root=/dev/mapper/ROOT rw initrd=\intel-ucode.img initrd=\initramfs-linux.img rw verbose" \
--verbose
Booting back into installation media, I can see the TPM loaded as expected:
# systemd-cryptenroll --tpm2-device=list
PATH DEVICE DRIVER
/dev/tpmrm0 MSFT0101:00 tpm_tis
# dmesg | grep -i tpm
[ 0.000000] efi: ACPI=0x78750000 ACPI 2.0=0x78750000 SMBIOS=0xf0000 SMBIOS 3.0=0xf0020 TPMFinalLog=0x78e1d000 ESRT=0x792b9198 MEMATTR=0x75bc3018 TPMEventLog=0x647b4018
[ 0.009729] ACPI: TPM2 0x00000000787849C0 000034 (v03 Tpm2Tabl 00000001 AMI 00000000)
[ 0.009772] ACPI: Reserving TPM2 table memory at [mem 0x787849c0-0x787849f3]
[ 15.204780] tpm_tis MSFT0101:00: 2.0 TPM (device-id 0xFE, rev-id 4)
# lsmod | grep tpm
tpm_crb 20480 0
tpm_tis 16384 0
tpm_tis_core 28672 1 tpm_tis
tpm 98304 4 tpm_tis,trusted,tpm_crb,tpm_tis_core
rng_core 16384 1 tpm
At this point I'm not sure what to try next and would appreciate any advice
Last edited by Ackmos (2025-03-11 20:59:42)
Offline
I haven't been able to resolve this, but I have noticed that removing and then reloading the tpm_tis module at runtime causes the TPM to load:
$ lsmod | grep tpm
tpm_crb 20480 0
tpm_tis 16384 0
tpm_tis_core 28672 1 tpm_tis
tpm 102400 4 tpm_tis,trusted,tpm_crb,tpm_tis_core
rng_core 16384 1 tpm
$ ls /dev/tpm*
ls: cannot access '/dev/tpm*': No such file or directory
$ sudo rmmod tpm_tis
$ sudo modprobe tpm_tis
$ ls /dev/tpm*
/dev/tpm0 /dev/tpmrm0
I need the TPM to load early in the boot process however to automatically unlock the LUKS volume.
Last edited by Ackmos (2022-05-18 14:50:16)
Offline
Hey Ackmos, did you ever solve this somehow? I'm experiencing the exact same situation. It worked well on version 5.15.12, the next update to 5.15.27 introduced this issue to me.
However, it does seem to occasionally work during boot, mostly however it doesn't. It's not easily reproducible since it does work after modprobing it again, which leads me to believe that there's a race condition in the probe code of the module.
What you're describing could be explained by a race condition as well, since booting from installation mediums typically takes longer than booting from an SSD and could possibly prevent such a race conditions between multiple modules.
If you find a solution please let us know.
Offline
Hey Ackmos, did you ever solve this somehow? I'm experiencing the exact same situation. It worked well on version 5.15.12, the next update to 5.15.27 introduced this issue to me.
However, it does seem to occasionally work during boot, mostly however it doesn't. It's not easily reproducible since it does work after modprobing it again, which leads me to believe that there's a race condition in the probe code of the module.
What you're describing could be explained by a race condition as well, since booting from installation mediums typically takes longer than booting from an SSD and could possibly prevent such a race conditions between multiple modules.If you find a solution please let us know.
Unfortunately not
I did explore adding a custom systemd service to initramfs to reload the TPM module right before attempting to unlock any disks, but saw the same probe failed message.
In the meantime I have added a key file to initramfs for my use case of unlocking the root volume at startup, although of course this is far less than ideal.
Offline
The issue is caused by this patch which was introduced with version 5.15.17. I can't say why, just that reverting that patch and recompiling the modules from source fixes the issue.
It also makes sense considering the error message received, request_locality is the only function in the probe mechanism that explicitly returns -1 without explicitly meaning operation not permitted (-1 maps to -EPERM in C world).
I'll report this to tpmdd, someone more familiar with the architecture and platform specific quirks might have an idea why it's happening and be able to provide a proper fix. Meanwhile you have two options if you need this to work soonish.
The first one is easy, revert to a previous Linux kernel, 5.15.13 is the last version before this was introduced and can be downloaded from the archive.
Second one is a bit tricky, and basically means to compile your own module from source and revert the above mentioned patch. The Wiki page on compiling kernel modules provides some insight, after compiling just install the modules to the updates directory that the Wiki page mentions.
I'd strongly suggest just downgrading, for now.
Offline
The issue is caused by this patch which was introduced with version 5.15.17. I can't say why, just that reverting that patch and recompiling the modules from source fixes the issue.
It also makes sense considering the error message received, request_locality is the only function in the probe mechanism that explicitly returns -1 without explicitly meaning operation not permitted (-1 maps to -EPERM in C world).I'll report this to tpmdd, someone more familiar with the architecture and platform specific quirks might have an idea why it's happening and be able to provide a proper fix. Meanwhile you have two options if you need this to work soonish.
The first one is easy, revert to a previous Linux kernel, 5.15.13 is the last version before this was introduced and can be downloaded from the archive.
Second one is a bit tricky, and basically means to compile your own module from source and revert the above mentioned patch. The Wiki page on compiling kernel modules provides some insight, after compiling just install the modules to the updates directory that the Wiki page mentions.I'd strongly suggest just downgrading, for now.
Thanks for the update! I'm not sure I would have been able to track the issue down to a single commit myself.
At the moment I'm happy to leave things as-is and wait for a fix in a future update.
Offline
Try setting tpm version to 1.2 in bios.
Offline
I was still experiencing this issue up until today with kernel version 6.13.5-arch1-1, but I was able to resolve it by updating the TPM firmware from 1.3.1.0 to 1.3.2.8 using "Dell TPM 2.0 Firmware Update Utility". Unfortunately I wasn't able to figure out how to do this update directly from Linux and despite the instructions stating that the Dell utility can be run from an MS-DOS environment, it does not seem to work and it exits with an error message explicitly stating that it does not support being run from DOS. I was however able to perform the update by creating a Windows to Go USB drive using Rufus on another Windows device, booting into it, disabling TPM auto provisioning as per the instructions on the download page and running the utility from there.
Last edited by Ackmos (2025-03-11 21:00:51)
Offline