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.
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.
>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.
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".
>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.
True. I don't use Windows either normally. I have one R&D system which has Windows installed, and of course installed first because I would never trust the Windows installer to leave a Linux installation untouched. It has a disturbingly small ESP. I could just fit 2 kernels + initramfs there. I did not even try to repartition it because I would not be surprised Windows either breaking or reverting some changes at next boot. For me that system is not important and I did not want to spend a single extra minute on it. But obviously someone had to spend a lot of time to cope with that unfriendly system.
