Hi Ludwig, On Wed, 12 Nov 2025 at 09:22, Nussel, Ludwig <ludwig.nussel@siemens.com> wrote:
On Wed, 2025-11-12 at 08:37 -0700, Simon Glass wrote:
On Wed, 12 Nov 2025 at 05:56, Nussel, Ludwig via Concept <concept@u-boot.org> wrote:
On Tue, 2025-11-11 at 05:41 -0700, Simon Glass wrote:
From: Simon Glass <simon.glass@canonical.com>
Modern systems mostly use LUKSv2 as it is more secure that v1. This series provides an implementation of this feature, making use of the existing 'luks unlock' command.
Are you sure adding luks to u-boot is a good idea? I'm curious about your use case as seeing the patches brings up bad memories of grub for me :-) I thought the learning from that was to reduce duplicating code in the bootloader and leave fancy stuff like disk encryption and advanced file system features to Linux. IOW load signed but unencrypted kernel and initrd and handle the rest in Linux userspace.
The use case is really just trying to avoid needing to start an initrd just to unlock the disk. It means that people select the OS and then (later) have to enter the key in a very different context. With the unlock in firmware we can start Linux without an initrd. We can also provide a unified UI, e.g. enter the unlock key directly in the boot menu.
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....other than rebooting. Linux does boot fairly quickly, but U-Boot can bring up a display in the hundreds of milliseconds...
It isn't for everyone, but I believe it has value.
For advanced filesystems, yes we should leave that to Linux. We have an ext4 boot partition with the OS, so that should be enough.
I actually don't know much about the grub issue (more a user than a developer on that!) Can you give a few details?
When disk decryption was moved down to grub in openSUSE there were several issues that I am not sure are actually solved yet. For one it was dog slow. I guess the bootloader at least on PCs runs with limited resources, like not all CPUs and memory, probably even in real mode still for mbr boot.
Yes, this is one of the challenges, IMO. The firmware environment is pretty primitive. We should be able to run at full speed. Not sure about multiple CPUs, though, and that might have some bearing on disk-unlock.
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? Regards, Simon