UPDATE: as of Fedora 36, the below doesn’t seem to work correctly. You’ll want to remove the /etc/dracut.conf.d/tss2.conf file, and the tpm2-device=auto,discard from /etc/crypttab, or the initrd build will not work, and your Fedora 36 kernel won’t boot. I was able to boot into one of my old Fedora 35 kernels, make the above changes, and then run sudo dracut -f --kver 5.17.6-300.fc36.x86_64 (check, as that specific version may change by the time you read this) to get things bootable. This loses the TPM based decryption.

I recently picked up a new Framework laptop to replace my aging Chromebook, so I’m back on a “real” Linux laptop for the first time in nearly a decade.

That meant it was time to revisit a few old blog posts.

This time, though, I’m running Fedora, so all the work above gets replaced with a single checkbox in the installer!

But my new laptop has a TPM chip, so I can make this even more painless using systemd-cryptenroll. The Fedora installer prompts for a passphrase which I have to enter at every boot. But, if the system hasn’t changed significantly (e.g. from UEFI firmware or Linux kernel updates), then the TPM chip can handle unlocking things on my behalf.

I found a fedora-users mailing list post that gave me the most succinct version of things to get working. Key parts:

  • Use systemd-cryptenroll --tpm2-device=auto -tpm2-pcrs=0+7 /dev/$DEVICE to enroll an additional token to unlock the LUKS volume. In my case, $DEVICE was /dev/nvme0n1p3, but your mileage may vary. This would be the block device backing your LUKS volume. lsblk should make it clear.
  • Edit /etc/crypttab, and change the end of the one line (starting with luks-$UUID) to tpm2-device=auto,discard
  • Until Fedora uses Dracut 056 (see #1976462), you need to create a file called /etc/dracut.conf.d/tss2.conf, with this in it: 
    install_optional_items+=" /usr/lib64/libtss2* /usr/lib64/libfido2.so.* "

    then run sudo dracut -f

  • Reboot, and enjoy a fancy secure boot experience!

Of course, if your threat model includes state actors or the like, this may not be the right choice to make, but if you’re just wanting to make sure that your system is relatively secure if stolen, and that your boot disk is basically gibberish whenever you dispose of it some day, then I think this is a pretty good compromise.