On Fri, 2025-11-14 at 05:43 -0700, Simon Glass wrote:
On Thu, 13 Nov 2025 at 01:34, Nussel, Ludwig <ludwig.nussel@siemens.com> wrote:
On Wed, 2025-11-12 at 09:44 -0700, Simon Glass wrote:
[...] Ideally Linux would boot so fast from the moment you press enter to the prompt of the initrd it shouldn't take much longer than the u-boot prompt itself ;) For such special use cases the initrd could be quite minimal and included in the kernel of course.
By the time you get to Linux you can't go back and try another OS if the key is wrong....
Sure but then is this optimization really worth the effort? :-)
To me it is, as I try to build a cohesive picture of the boot process where we have full knowledge of what is going on, even in firmware. Today's solution feels like a patchwork of pieces that happen to fit together, and not necessarily that well.
With that I agree. I never dared to really look under the rug that used to be EFI in my world. Now that I did, my stomach doesn't feel better ;-)
Grub was lagging behind with features. Even when Luks2 support arrived it lacked Argon2. So someone always has to keep up with changes on Linux side. Then one had to enter the passphrase twice. Once in grub and then again in the bootloader. To avoid that some key handover protocol had to be created.
Thanks for the info. From my limited view, it seems that Grub is not really suitable for the kind of active development that is needed to keep up with the world. As to entering it twice, I thought Grub was the bootloader? Do you mean that it needs to pass the key to Linux?
Hmm, yes? :-) Maybe we are talking about different setups. To clarify, I suppose the rootfs etc is inside an encrypted volume too. So even if it's the same volume as the one u-boot opened, Linux still needs set up device mapper with dmcrypt itself to be able to mount the rootfs, right?
Right, if the rootfs is encrypted then all bets are off.
You asking this question confuses me. If the purpose of LUKS support in U-Boot isn't to open a Linux rootfs, what else do you see it useful for?
I really don't think encrypting the boot partition has much value. It also makes it impossible for firmware to see what is booting. In fact I'm not even sure how this would work, unless you wanted to use EFI and put the kernel initrd in a FAT filesystem? Do you know the details on that?
As I understand it the recommended way to install a distro these days is to have an ext4 /boot partition.
Not in the model systemd favors¹. Kernel and initrd are supposed to be plain text in the boot partition. Since EFI only supports FAT, the boot partition has to be FAT on such systems. All fancy stuff including rootfs decryption has to be done in Linux userspace ie initrd. The same basic architecture works for non EFI systems too. The filesystem of the boot partition doesn't really matter. The point is that it's plain text with no special features. So nothing wrong just sticking to FAT. [1] https://uapi-group.org/specifications/specs/boot_loader_specification/ -- Ludwig Nussel Siemens AG www.siemens.com