Encrypted boot partition I'd guess? I tried that once with grub, but it was unbearingly slow, because grub did not / could not use modern x86 extensions to do the decryption. So not a common use case either, maybe a desirable one.
Encrypted boot partition I'd guess? I tried that once with grub, but it was unbearingly slow, because grub did not / could not use modern x86 extensions to do the decryption. So not a common use case either, maybe a desirable one.
Granted, prior to Debian Bookworm I had to roll my own initramfs- and kernel-hooks, but there were blog posts and I didn't need to develop them.
I even tried directly booting into Linux EFISTUB, but thats uselessly annoying compared to a proper bootloader.
it's a literal checkbox install option on Ubuntu at least a few versions back (i'm not up to date), so I wouldn't call it uncommon.
The theory is that messing with boot can compromise your system and leave you vupnarable despite encryption.
Isn't it deliberately slow to resist brute forcing? At least at one point, the default number of rounds in cryptsetup was decided by counting how many rounds it could do in 10s as part of the setup process on your specific machine