4 ms·

AFAIK some bootloader versions do not support LUKS2 format; this could make for a bad day for some people. Don't blindly follow blogs on a critical topic withou

AFAIK some bootloader versions do not support LUKS2 format; this could make for a bad day for some people. Don't blindly follow blogs on a critical topic without more research

josephcsible 4y ago
Your bootloader doesn't need to support it unless you insist on encrypting /boot.
- deleted 4y ago
  [deleted]
- usr1106 4y ago
  I tried encrypting /boot once, but grub2 is painfully slow to do the key derivation that Linux does in a couple of seconds. I understood vectorization makes the difference. The better approach seems to use dm-verity to make sure it's not been manipulated and store any secrets it might need in the TPM. Just for the design. I am not an anarchist or similar target, so I still live with just an encrypted rootfs which should be good enough against a random laptop thief.
  - Arnavion 4y ago
    Or use UEFI + Secure Boot instead if your motherboard lets you.
    - usr1106 4y ago
      Does that support verification of the initramfs? I have the feeling no it doesn't, but I am not sure. (Yes you can build the initramfs into the kernel. But I don't think that's commonly done. And UEFI implementations have undocumented size limits of what they can boot. So even if you are willing to spend the effort to configure that the image might not boot in the end.
      - Arnavion 4y ago
        >Does that support verification of the initramfs? https://news.ycombinator.com/item?id=35615911 https://news.ycombinator.com/item?id=35615911 >And UEFI implementations have undocumented size limits of what they can boot. If the problem is that the ESP is too small, you can put systemd-boot or similar in there and make a XBOOTLDR partition to store the actual UKI ("UKI" == the output of "the second method" in the comment I linked). If the problem is literally that the firmware can't execute a .efi bigger than a certain size, and if that extends to the UKI even if there's a bootloader in between, then I guess you're out of luck.
        usr1106 4y ago
        The ESP too small? It's just a partition and filesystem. Of course an ancient filesystem, but I don't think there are any relevant limits. I routinely use ESPs of 1 GB on my R&D systems so it can hold enough images for testing purposes. I had the problem on NUC10 that it doesn't want to boot images around 100 MB. No problem with around 70 MB. Figures from memory, could be slightly lower. We routinely use systemd-boot, I'd guess it was also in that experiment. Or maybe not? Good point, I would need to try again. Either way we did not end up buying NUC10 for production, so I just made a note to myself that UEFI implementations might have size limits. On another implementation we boot the same size without issues. Yes, I read the UKI postings when they came. And Lennart spoke about it at FOSDEM again this year, IIRC. Certainly something to look into "when I have time".
        Arnavion 4y ago
        >The ESP too small? It's just a partition and filesystem. I was just relaying what I've read about the reason that the concept of the XBOOTLDR partition was invented in the first place. Eg: https://wiki.archlinux.org/title/systemd-boot#Installation_using_XBOOTLDR https://wiki.archlinux.org/title/systemd-boot#Installation_u... >A separate /boot partition of type "Linux extended boot" (XBOOTLDR) can be created to keep the kernel and initramfs separate from the ESP. This is particularly helpful to dual boot with Windows with an existing ESP that is too small. I have no idea why it's not possible to just resize the ESP and move the partitions around. Maybe the Windows install doesn't like being moved? I don't use Windows so I don't know. On all my machines I have full freedom to make the ESP as big as I want and move partitions around as I want.
tgflynn 4y ago
The article warns against doing this if your /boot filesystem is encrypted.
forbiddenlake 4y ago
Can you expand on "some"? The article mentions grub2.
- ijlx 4y ago
  I'm not aware of any bootloaders that support encrypted /boot with LUKS2 aside from GRUB. GRUB itself didn't support LUKS2 until 2021, I believe; I imagine there are many people using versions older than that.
  - Arnavion 4y ago
    Even with newer versions, some (many?) distro installers still default to using LUKS 1 for the root partition anyway. As the article also says, while grub2 does support LUKS 2 now it still only supports pbkdf2, so having root be LUKS 1 makes it harder to accidentally switch away from pbkdf2.
kiririn 4y ago
Bootloader not really, main problem for me has been server providers with outdated rescue/live images. Everything is fine until you need to use rescue mode and can’t decrypt your root fs

AFAIK some bootloader versions do not support LUKS2 format; this could make for a bad day for some people. Don't blindly follow blogs on a critical topic without more research

josephcsible 4y ago

Your bootloader doesn't need to support it unless you insist on encrypting /boot.

deleted 4y ago
[deleted]
usr1106 4y ago
I tried encrypting /boot once, but grub2 is painfully slow to do the key derivation that Linux does in a couple of seconds. I understood vectorization makes the difference. The better approach seems to use dm-verity to make sure it's not been manipulated and store any secrets it might need in the TPM. Just for the design. I am not an anarchist or similar target, so I still live with just an encrypted rootfs which should be good enough against a random laptop thief.
- Arnavion 4y ago
  Or use UEFI + Secure Boot instead if your motherboard lets you.
  - usr1106 4y ago
    Does that support verification of the initramfs? I have the feeling no it doesn't, but I am not sure. (Yes you can build the initramfs into the kernel. But I don't think that's commonly done. And UEFI implementations have undocumented size limits of what they can boot. So even if you are willing to spend the effort to configure that the image might not boot in the end.
    - Arnavion 4y ago
      >Does that support verification of the initramfs? https://news.ycombinator.com/item?id=35615911 https://news.ycombinator.com/item?id=35615911 >And UEFI implementations have undocumented size limits of what they can boot. If the problem is that the ESP is too small, you can put systemd-boot or similar in there and make a XBOOTLDR partition to store the actual UKI ("UKI" == the output of "the second method" in the comment I linked). If the problem is literally that the firmware can't execute a .efi bigger than a certain size, and if that extends to the UKI even if there's a bootloader in between, then I guess you're out of luck.
      - usr1106 4y ago
        The ESP too small? It's just a partition and filesystem. Of course an ancient filesystem, but I don't think there are any relevant limits. I routinely use ESPs of 1 GB on my R&D systems so it can hold enough images for testing purposes. I had the problem on NUC10 that it doesn't want to boot images around 100 MB. No problem with around 70 MB. Figures from memory, could be slightly lower. We routinely use systemd-boot, I'd guess it was also in that experiment. Or maybe not? Good point, I would need to try again. Either way we did not end up buying NUC10 for production, so I just made a note to myself that UEFI implementations might have size limits. On another implementation we boot the same size without issues. Yes, I read the UKI postings when they came. And Lennart spoke about it at FOSDEM again this year, IIRC. Certainly something to look into "when I have time".
        Arnavion 4y ago
        >The ESP too small? It's just a partition and filesystem. I was just relaying what I've read about the reason that the concept of the XBOOTLDR partition was invented in the first place. Eg: https://wiki.archlinux.org/title/systemd-boot#Installation_using_XBOOTLDR https://wiki.archlinux.org/title/systemd-boot#Installation_u... >A separate /boot partition of type "Linux extended boot" (XBOOTLDR) can be created to keep the kernel and initramfs separate from the ESP. This is particularly helpful to dual boot with Windows with an existing ESP that is too small. I have no idea why it's not possible to just resize the ESP and move the partitions around. Maybe the Windows install doesn't like being moved? I don't use Windows so I don't know. On all my machines I have full freedom to make the ESP as big as I want and move partitions around as I want.

tgflynn 4y ago

The article warns against doing this if your /boot filesystem is encrypted.

forbiddenlake 4y ago

Can you expand on "some"? The article mentions grub2.

ijlx 4y ago
I'm not aware of any bootloaders that support encrypted /boot with LUKS2 aside from GRUB. GRUB itself didn't support LUKS2 until 2021, I believe; I imagine there are many people using versions older than that.
- Arnavion 4y ago
  Even with newer versions, some (many?) distro installers still default to using LUKS 1 for the root partition anyway. As the article also says, while grub2 does support LUKS 2 now it still only supports pbkdf2, so having root be LUKS 1 makes it harder to accidentally switch away from pbkdf2.

kiririn 4y ago

Bootloader not really, main problem for me has been server providers with outdated rescue/live images. Everything is fine until you need to use rescue mode and can’t decrypt your root fs