TPM unlocking fails: stat /dev/tpmrm0: no such file or directory

[movq]

I have used systemd-cryptenroll to add a TPM2 key. When I try to boot an image generated using booster (no arguments, empty /etc/booster.yaml), I get a password prompt instead of automatic TPM unlocking, and with booster.log=debug I see

Nov 26 21:11:56 mike-xps booster: recovering systemd-tpm2 token #1 failed: stat /dev/tpmrm0: no such file or directory
Nov 26 21:11:56 mike-xps kernel: fbcon: Taking over console
Nov 26 21:11:56 mike-xps kernel: Console: switching to colour frame buffer device 240x67
Nov 26 21:11:56 mike-xps booster: udev event {Header:add@/devices/virtual/vtconsole/vtcon1 Action:add Devpath:/devices/virtual/vtconsole/vtcon1 Subsystem:vtconsole Seqnum:1340 Vars:map[ACTION:add DEVPATH:/devices/virtual/vtconsole/vtcon1 SEQNUM:1340 SUBSYSTEM:vtconsole]}
Nov 26 21:11:56 mike-xps booster: udev event {Header:add@/devices/platform/MSFT0101:00/tpm/tpm0 Action:add Devpath:/devices/platform/MSFT0101:00/tpm/tpm0 Subsystem:tpm Seqnum:1341 Vars:map[ACTION:add DEVNAME:tpm0 DEVPATH:/devices/platform/MSFT0101:00/tpm/tpm0 MAJOR:10 MINOR:224 SEQNUM:1341 SUBSYSTEM:tpm]}
Nov 26 21:11:56 mike-xps booster: udev event {Header:add@/devices/platform/MSFT0101:00/tpmrm/tpmrm0 Action:add Devpath:/devices/platform/MSFT0101:00/tpmrm/tpmrm0 Subsystem:tpmrm Seqnum:1342 Vars:map[ACTION:add DEVNAME:tpmrm0 DEVPATH:/devices/platform/MSFT0101:00/tpmrm/tpmrm0 MAJOR:236 MINOR:65536 SEQNUM:1342 SUBSYSTEM:tpmrm]}

in the logs. It seems that the device node /dev/tpmrm0 is being created too late, after booster already tried to open it.

If I set booster.log=debug,console, the TPM unlock is successful. I'm guessing that all the text being printed slows things down so that things happen in the correct order, because in the logs I see that tpmrm0 is being created before the disk is unlocked.

This is happening with both booster-git and 0.7.

$ uname -r
5.15.5-arch1-1
$ pacman -Q booster
booster-git 0.7.r24.g754a0d3-1

[anatol]

Yes indeed it is a race condition between discovering required devices and processing LUKS partition. The LUKS partition is handled so fast that it happens before TPM driver initializes devices.

It belongs to the same bucket of problems as with other hardware dependencies:

• booster tries to unlock a tang binding before the network is available
• booster tries to unlock a Yubikey bound device before it is initialized (or if it was inserted later, after the boost process started)

I want to look at these issues before 0.8 release.

[Axelen123]

I was also having this issue on my laptop, so I made a pull request

[anatol]

@Axelen123 thank you very much for the fix. The code looks good. I ran integration tests for an hour and I do not see any errors with it. The PR is merged to wip branch.

FYI Here is a related ticket that aims to create an event synchronization mechanism that would handle hardware event like TPM chip is available, Network is available, Yubikey is inserted, ... #100

[anatol]

The fix has been merged to master