3 ms·

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 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).

Leace 7y ago
> 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 https://wiki.gentoo.org/wiki/EFI_stub_kernel)
- e12e 7y ago
  But then you're loading the kernel from unencrypted fat32 partition?
  - Leace 7y ago
    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 https://github.com/andreyv/sbupdate
e12e 7y ago
You're right, it's been a while since I set up a luks+ext3/4 system - I'd forgotten about grub luks support. Certainly better than an unencrypted boot volume - but I'm uncertain if I'll consider it worth the extra hassle (I mostly view fde as a means to safeguard data on a machine that lost or stolen while off; the bar for meaningful improvement on that is pretty high, especially with Intel backdoors in the form of ime etc).

Leace 7y ago

> 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 https://wiki.gentoo.org/wiki/EFI_stub_kernel)

e12e 7y ago
But then you're loading the kernel from unencrypted fat32 partition?
- Leace 7y ago
  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 https://github.com/andreyv/sbupdate

e12e 7y ago

You're right, it's been a while since I set up a luks+ext3/4 system - I'd forgotten about grub luks support. Certainly better than an unencrypted boot volume - but I'm uncertain if I'll consider it worth the extra hassle (I mostly view fde as a means to safeguard data on a machine that lost or stolen while off; the bar for meaningful improvement on that is pretty high, especially with Intel backdoors in the form of ime etc).