4 ms·

Regarding dropping support for a LUKS encrypted /boot, one of the comments chimes in with “[but] full disk encryption is mandatory in many environments in Europ

Regarding dropping support for a LUKS encrypted /boot, one of the comments chimes in with “[but] full disk encryption is mandatory in many environments in Europe for security conformity”. Surely some user editable data has to be stored in plaintext to be able to boot a system? Does grub.cfg need to be signed by the trust chain to be able to boot?

ahartmetz 7mo ago
When I hear full disk encryption, I think of what I'm using: Using the encryption feature of the disk with a password / keyphrase prompt built into the system firmware (UEFI). It is 100% transparent to any software. The only major downside is that you need to trust the hardware manufacturer (and their FIPS certification), which is fine for my purposes, but might not be fine for state secrets or extremely valuable trade secrets.
- pona-a 7mo ago
  I don't know if FIPS standards have improved, but combining my priors about products boasting FIPS and manufacturer code quality in general, I would actively not trust it with any data, full expecting it either leaks them, corrupts them, or somehow both.
  - ahartmetz 7mo ago
    Works just fine for legal ass coverage
NekkoDroid 7mo ago
Unless your UEFI supports reading from an encrypted drive you will at minimum have part of GRUB unencrypted up until the point where you enter a decryption key. so at least initialization, cryptography and filesystem drivers (or module loading) are unencrypted. I hope they are at least secure boot signed else the entire thing is security theater. But at that point why even encrypt boot and not use something like a signed UKI for decrypting the rest of the disk? That way at least you only have the kernel, its modules and userspace (the initrd usually being a subset of the actual system) as bug/exploit surface instead of also including GRUB and all its modules ontop of that.

ahartmetz 7mo ago

When I hear full disk encryption, I think of what I'm using: Using the encryption feature of the disk with a password / keyphrase prompt built into the system firmware (UEFI). It is 100% transparent to any software. The only major downside is that you need to trust the hardware manufacturer (and their FIPS certification), which is fine for my purposes, but might not be fine for state secrets or extremely valuable trade secrets.

pona-a 7mo ago
I don't know if FIPS standards have improved, but combining my priors about products boasting FIPS and manufacturer code quality in general, I would actively not trust it with any data, full expecting it either leaks them, corrupts them, or somehow both.
- ahartmetz 7mo ago
  Works just fine for legal ass coverage

NekkoDroid 7mo ago

Unless your UEFI supports reading from an encrypted drive you will at minimum have part of GRUB unencrypted up until the point where you enter a decryption key. so at least initialization, cryptography and filesystem drivers (or module loading) are unencrypted. I hope they are at least secure boot signed else the entire thing is security theater. But at that point why even encrypt boot and not use something like a signed UKI for decrypting the rest of the disk? That way at least you only have the kernel, its modules and userspace (the initrd usually being a subset of the actual system) as bug/exploit surface instead of also including GRUB and all its modules ontop of that.