clevis icon indicating copy to clipboard operation
clevis copied to clipboard

clevis-luks-askpass does not wait for tpm device to appear

Open dadevel opened this issue 3 years ago • 1 comments

While booting the kernel takes longer than expected to initialize my TPM. Relevant dmesg log entries:

tpm0: tpm_try_transmit: send(): error -62
tpm0: [Firmware Bug]: TPM interrupt not working, polling instead

The TPM is fully functional afterwards, but this leads to the peculiar problem that clevis-luks-askpass tries to find a TPM before the kernel is done initializing it. So /dev/tpm0 doesn't exist at this point. At least I think that's what happens.

Relevant journalctl excerpt:

systemd[1]: Started Forward Password Requests to Clevis.
systemd[1]: clevis-luks-askpass.service: Succeeded.
systemd[1]: Started Forward Password Requests to Clevis.
systemd[1]: clevis-luks-askpass.service: Succeeded.
systemd[1]: Started Forward Password Requests to Clevis.
systemd[1]: clevis-luks-askpass.service: Succeeded.
systemd[1]: Started Forward Password Requests to Clevis.
systemd[1]: clevis-luks-askpass.service: Succeeded.
systemd[1]: clevis-luks-askpass.service: Start request repeated to quickly.
systemd[1]: clevis-luks-askpass.service: Failed with result 'start-limit-hit'.
systemd[1]: Failed to start Forward Password Requests to Clevis.

So my workaround is this clevis-luks-askpass.patch:

--- a/clevis-luks-askpass
+++ b/clevis-luks-askpass
@@ -35,6 +35,10 @@
     esac
 done
 
+until [ -c /dev/tpm0 ]; do
+    sleep 1
+done
+
 while true; do
     for question in "${path}"/ask.*; do
         # question will expand to itself, in case no files match, so we verify

I know that this is a bad solution. How can this case be handled properly?

dadevel avatar Jan 17 '21 00:01 dadevel