[wiktor-k]

> but those have a downside of the TPM needing to be updated with every new kernel.

This depends on the configuration. If you don't bind the key to PCRs at key creation time kernel updates don't affect the workflow and you still will take advantage of other TPM features such as locking the key after several unsuccessful attempts.

Take a look at the systemd configuration: https://www.freedesktop.org/software/systemd/man/systemd-cry...

I'm using it on my laptop and it works well.

[jandrese]

IMHO the PCRs are way too much trouble and defend against attacks that are rare outside of extremely spooky circles. They were the biggest problem with Bitlocker too.

[alexeldeib]

Yeah, I recently went down this path. It’s all doable but frankly I’m not a nation state target and getting locked out after a kernel update or similar would be far more annoying.

Instead I’m leaning toward separate boot and root disks, with a root/data disk encrypted with LUKS with a detached header. dm verity on a read only root with a separate data partition also seems simple/appealing. Of course, these all allow attacks full secure boot/tpm/etc avoid, but it’s a balance.

[wiktor-k]

PCRs being problematic was actually one of the issues policy mechanism in TPM 2.0 was meant to resolve (see "Non-Brittle PCRs (New in 2.0)" in [0]).

Tldr version is that you'd authorize OS manufacturer's kernel signing key to use the TPM key so that each time your OS vendor signs the kernel it's OK for the TPM.

Sadly I don't think I've seen this deployed in the wild.

[0]: https://ebrary.net/24725/computer_science/quick_loading