In Fedora 35, I am able to use the tpm2 device to automatically unlock a LUKS volume on boot. Dracut 055 has a bug in the tpm2-tss module, requiring either applying https://github.com/dracutdevs/dracut/commit/8b17105bed69ed90582a13d97d95ee19... and then including the tpm2-tss module in dracut.conf, or including the library files directly.
device=/dev/nvme0n1p3 systemd-cryptenroll --tpm2-device=auto --tpm2-pcrs=7+8 $device sed -ie '/^luks-/s/$/,tpm2-device=auto/' /etc/crypttab # Either this: echo 'install_optional_items+=" /usr/lib64/libtss2* /usr/lib64/libfido2.so.* "' > /etc/dracut.conf.d/tss2.conf # Or apply the commit mentioned above and: echo 'add_dracutmodules+=" tpm2-tss "' > /etc/dracut.conf.d/tss2.conf dracut -f
However, this doesn't work in F36 beta, and there isn't much information logged to indicate why that is. The F36 beta initramfs generated by dracut appears to have all of the necessary components, but a passphrase is required to unlock the root LUKS volume.
On a F35 system, the journal will contain a couple of log entries like:
Mar 12 12:11:32 vagabond systemd-cryptsetup[542]: Set cipher aes, mode xts-plain64, key size 512 bits for device /dev/disk/by-uuid/888c26a9-936b-4377-97f9-612300cc2a8e. Mar 12 12:11:32 vagabond systemd-cryptsetup[542]: Automatically discovered security TPM2 token unlocks volume.
However, a F36 system will contain only the first of those two log entries, and no error.
Does anyone have suggestions for debugging this issue?
On 3/29/22 11:41, Gordon Messmer wrote:
Does anyone have suggestions for debugging this issue?
I've booted into a dracut shell and confirmed that the tpm device nodes are present...
Trying to manually attach the LUKS volume prints no error messages, but prompts for a passphrase rather than attaching using the TPM2 device.
# /usr/lib/systemd/systemd-cryptsetup attach luks-testvol /dev/disk/by-uuid/<the-device-uuid> - tpm2-device=auto
On 3/29/22 11:41, Gordon Messmer wrote:
In Fedora 35, I am able to use the tpm2 device to automatically unlock a LUKS volume on boot. Dracut 055 has a bug in the tpm2-tss module, requiring either applying https://github.com/dracutdevs/dracut/commit/8b17105bed69ed90582a13d97d95ee19... and then including the tpm2-tss module in dracut.conf, or including the library files directly.
First problem: systemd added cryptsetup modules, so in addition to that commit, you'd need both of these:
https://github.com/dracutdevs/dracut/commit/c656b612b101e4834e01f9841162e262... https://github.com/dracutdevs/dracut/commit/4753738b62d958955f50fb077ea21c56...
(I see dracut 056 in rawhide... I'm *real* sad that it didn't make it into F36, for this reason)
Second problem: when I was testing earlier, the cryptsetup modules appear to have been incorrectly packaged in the "systemd-devel" package. That problem was fixed in 250.3-7.
device=/dev/nvme0n1p3 systemd-cryptenroll --tpm2-device=auto --tpm2-pcrs=7+8 $device sed -ie '/^luks-/s/$/,tpm2-device=auto/' /etc/crypttab echo 'install_optional_items+=" /usr/lib64/libtss2* /usr/lib64/libfido2.so.* /usr/lib64/cryptsetup/libcryptsetup-token-systemd-tpm2.so "' > /etc/dracut.conf.d/tss2.conf dracut -f
Since dracut 055 requires several patches, the easiest way to restore working tpm2 support seems to be just bundling the libraries manually, as above.