- use a unified kernel image (UKI) which means I directly boot the kernel from efi (and place it in the efi partition)
- sign the image with that platform key (I use sbctrl)
- have every thing else including swap partition for hybernation fully disk encrypted, I could set it up to auto unlock using TPM2 but I would recommend using a long password. TPM2+password would be optimal. There had been too many cases of leaky TPMs and especially on a laptop you don't want to fully rely on it (through you in turn could decide to auto login if PCRs are unchanged, or login using only the (often not so secure) fingerprint reader etc.)
- efi password, I mean if you don't set that you lose most secure boot benefits... EDIT: Not really most, there is still a bunch of ways it helps but it's anyway a bad idea to rely on secure boot and not have a efi password
As bonus tip:
- include the vfat in your initramfs (i.e. `MODULES=(vfat)` in `/etc/mkinitcpio.conf`) if your booting kernel and installed kernel modules ever mismatch that is nice to have to fix the issue
> I could set it up to auto unlock using TPM2 but I would recommend using a long password. TPM2+password would be optimal.
Personally, I trust LUKS with passphrases far more than I trust some random proprietary hardware implementation nobody can audit...
It's also important to me to be able to recover the disk contents with the passphrase on another machine if the motherboard dies. Maybe that's what you meant (backup passphrase), but I think you meant requiring both?
In case of systemd-cryptenroll (and other LUKS-related systemd infra, even without TPM) it's systemd that handles the passphrase to generate a key to unlock LUKS device - possibly combining with a PIN or passphrase or also a FIDO-compatible device or a smartcard.
- but it would be optimal to require PCR values and password
Note that in any case where you use PCR values you always should setup a secondary way to unlock the partition. Or else you will lose your data if some of your hardware measured into a PCR breaks.
Requiring both is optimal as it 1. doesn't rely on TPM/PCRs but 2. prevent certain attack vectors possible with password only but not possible with PCRs. Through you now also have to manage a backup unlock method. Which is annoying. And the security benefits are negligible/irrelevant for most people. Which is why I don't use it.
Nit: It's useful to distinguish between passwords (checked against a hash for auth) and passphrases (used for decryption). It's an important practical distinction because a lost password can in general be bypassed out-of-band somehow while a backup strategy for passphrases is essential.
A more common definition of passphrase is a a password which is a phrase which makes it longer but also more predictable in it's structure.
Similar prompts for decryption will ask you for passwords in most cases as non technical users shouldn't need to understand the underlying technical differences (nor do they normally want to, or do).
sbctl with package manager hook for automatically signing on updates etc.
keys are just stored on the device, for the typical laptop use-case this is good enough (platform key only used by a single device, no MDA or anything like that)
- have custom secure boot platform key
- use a unified kernel image (UKI) which means I directly boot the kernel from efi (and place it in the efi partition)
- sign the image with that platform key (I use sbctrl)
- have every thing else including swap partition for hybernation fully disk encrypted, I could set it up to auto unlock using TPM2 but I would recommend using a long password. TPM2+password would be optimal. There had been too many cases of leaky TPMs and especially on a laptop you don't want to fully rely on it (through you in turn could decide to auto login if PCRs are unchanged, or login using only the (often not so secure) fingerprint reader etc.)
- efi password, I mean if you don't set that you lose most secure boot benefits... EDIT: Not really most, there is still a bunch of ways it helps but it's anyway a bad idea to rely on secure boot and not have a efi password
As bonus tip:
- include the vfat in your initramfs (i.e. `MODULES=(vfat)` in `/etc/mkinitcpio.conf`) if your booting kernel and installed kernel modules ever mismatch that is nice to have to fix the issue