I’m happily running TW as my daily, but would like to improve my experience by switching to FDE as described here:
Right now I did my own partitioning with / and /home on two different partitions (both btrfs), with only /home being LUKs encrypted.
This forces me to enter my encryption password at every boot, when /home gets mounted, which is a bit of an inconvenience.
If I understand well, with FDE based on systemd, I could skip this prompt (unless some changes are detected), since my board comes with a TPM2.0 chip.
I’m therefore considering a new install of my system.
My questions before proceeding would be:
is this reasonably stable, viable for my main gear, or still a WIP and therefore not recommended yet?
even though it’s called Full Disk Encryption, could someone confirm that I could still dedicate only PART of my disk to the FDE TW install and leave something aside for a second distro to dual boot in the future?
does this work well with snapshots? Snapshots on / are one of the killer features of this distro and something I don’t want to lose
Of course. How is obtaining LUKS key using TPM different to obtaining LUKS key using passphrase?
I do not know. Internet search is the usual place to find such information assuming it exists.
The challenge is not to add TPM - this is just one command - but to decide what you are protecting from. It is trivial to bind LUKS key to some static information that does not change with kernel update.
and add tpm2-device=auto to the device options in /etc/crypttab.
I intentionally avoid the actual PCR numbers because it will end up blindly copied by somebody. You need to decide which PCRs you want to use. There is no one size fits all solution.
Using PCRs that do not change with kernel update or kernel command line means that anyone having physical access to your system can boot it and unlock your LUKS device using TPM. To protect against this you need to use PCRs that do measure kernel/initrd/command line, but then you also need to update this information every time any of these change. openSUSE supports it for UEFI systems using systemd-boot (or grub2-bls … probably, it is recent enough) using sdbootutil. It still has rough edges (like race condition on boot) and is still work in progress. If you are using normal grub2 or are on a legacy BIOS - I do not know if something ready to use is available.
There are other projects that integrate TPM like clevis. You can look at it too.
TPM auto-unlock might be more trouble that it’s worth at this point.
You can put the root partition into a LUKS volume and have grub ask the passphrase for it (which includes the initramfs image) on cold boot.
All other LUKS volumes can be decrypted by keys inside the initramfs, it also means you do not need to enter a passphrase when hot rebooting using kexec:
Do note you need a key to unlock the root partition even though you entered the passphrase for it as the boot process needs to remount the root fs when the initramfs is done doing its thing.
Yes, normally it would but when updating initramfs using dracut and then cold booting for example it would ask for the password twice (don’t know if still an issue). It also wouldn’t work when hot rebooting using kexec. Better to have a key for the root fs as well.
With this setup, I only enter the password when cold booting once every few months. Very convenient
This is incorrect as the very article you yourself referenced shows. SUSE grub2 supports unlocking LUKS key using TPM2. AFAICT this key is not forwarded to the initrd (so, you need to additionally configure initrd to auto-unlock root using whatever method you prefer) and grub2 should disable editing menu entries or entering command line if key was recovered using TPM2. You still should be able to boot any existing menu entry including snapshots.
Then I am not sure why you needed a separate /boot.
Out of curiosity I installed Tumbleweed with separate encrypted physical partitions for root and swap (and changed passphrases to be different to make sure they are not reused during boot). After installation I followed your article to enable TPM2 unlock in grub2. Which worked just fine. I did not use LUKS key embedded in initrd as suggested by this article, rather I setup both root and swap for TPM2 unlock.
So, now I have completely unattended boot with both grub2 and systemd-cryptsetup using TPM2 together with normal snapshot support, I can boot into a previous snapshot as usual.
I was wrong earlier. grub2 does not completely disable menu editing or command line - rather you need to provide LUKS password for root device to do it.
LUKS password request from Plymouth is entirely useless as no device name or any other hint what this password is requested for is shown. I do not know if this is Plymouth or systemd issue.
Of course, there could be some additional bad interaction with resume in initrd. Unfortunately, I never managed to hibernate and resume a QEMU VM, so I cannot test it.
Well, it gets as far as attempting to resume from the encrypted swap (it fails, but that is not related to encryption). This can be counted as successful test in this case.
Nov 17 16:52:01 localhost systemd[1]: Starting Resume from hibernation...
Nov 17 16:52:01 localhost kernel: PM: Image signature found, resuming
Nov 17 16:52:01 localhost kernel: PM: hibernation: resume from hibernation
Nov 17 16:52:01 localhost kernel: random: crng reseeded on system resumption
Nov 17 16:52:01 localhost kernel: Freezing user space processes
Nov 17 16:52:01 localhost kernel: Freezing user space processes completed (elapsed 0.001 seconds)
Nov 17 16:52:01 localhost kernel: OOM killer disabled.
Nov 17 16:52:01 localhost kernel: Freezing remaining freezable tasks
Nov 17 16:52:01 localhost kernel: Freezing remaining freezable tasks completed (elapsed 0.001 seconds)
Nov 17 16:52:01 localhost kernel: PM: hibernation: Marking nosave pages: [mem 0x00000000-0x00000fff]
...
Nov 17 16:52:01 localhost kernel: PM: hibernation: Basic memory bitmaps created
Nov 17 16:52:01 localhost kernel: PM: Using 1 thread(s) for lzo decompression
Nov 17 16:52:01 localhost kernel: PM: Loading and decompressing image data (76718 pages)...
Nov 17 16:52:01 localhost kernel: Hibernate inconsistent memory map detected!
Nov 17 16:52:01 localhost kernel: PM: hibernation: Image mismatch: architecture specific data
Nov 17 16:52:01 localhost kernel: PM: hibernation: Read 306872 kbytes in 0.01 seconds (30687.20 MB/s)
Nov 17 16:52:01 localhost kernel: PM: Error -1 resuming
Nov 17 16:52:01 localhost kernel: PM: hibernation: Failed to load image, recovering.
And while playing with it it demonstrated yet again how brittle all this is. When you rebuild initrd from within live image the resume dracut module will most likely be skipped and system will not attempt to resume. Yet another manual step that needs attention.
