Finally native encryption! Might still be a bit of a dance to boot - but I'd much rather have small ext3 /boot and let zfs do disk/volume/encryption/compression on the rest. Oh, and while swap on a zvol is possible - I regret setting that up on my laptop. Traditional encrypted swap makes more sense for hibernation.

In ideal world, zfs would do all, and we'd boot straight in - but as far as I can figure out that'll require a new bootloader project. And I'm not sure how I feel about (full) zfs support in my bootloader anyway.

I currently have all my ZFS drives on top of LUKS for my storage disks. I don't have the disks to shuffle things around at this point, but when I need to expand, I'm sure I'll use the native encryption on new disks! This is pretty big.

On my boot volume, I run full disk encryption (luks+ext4 for everything including /boot). Grub has built-in support for luks type 1 (do not use luks version 2! Grub can't unlock those yet. I learned that the hard way :-P).

If you have a signed Grub EFI loader, remove the default secure boot keys and add in just the CA/certs for your system and password your BIOS/setup, you have the potential for a very secure system (ignoring the Intel/AMD management systems that are difficult or impossible to disable).

> If you have a signed Grub EFI loader, remove the default secure boot keys and add in just the CA/certs for your system and password your BIOS/setup, you have the potential for a very secure system (ignoring the Intel/AMD management systems that are difficult or impossible to disable).

Or just dump Grub altogether and boot kernel directly as an UEFI image. No need for middle-man!

(Instructions vary by distro but see this for example: https://wiki.gentoo.org/wiki/EFI_stub_kernel)

But then you're loading the kernel from unencrypted fat32 partition?

If it's signed with Secure Boot keys it's no different for loading signed Grub image. Grub would also need to be unencrypted to work.

As for signing kernel: https://github.com/andreyv/sbupdate