On Mon, 2025-11-17 at 10:38 -0700, Simon Glass wrote:
[...]
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?
Sorry, I meant an encrypted boot partition cannot be made to work.
Yes Linux needs to set up a device mapper. Even if U-Boot does it, Linux is going to have to do it again. But we could perhaps pass it the key.
Exactly.
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.
Yes and I'm not too keen on that approach: - we cannot have a system relying on FAT since it can become corrupted if the media is yanked out (power failure, etc.)
Certainly (V)FAT isn't the most beautiful nor most simple FS for the purpose. But then which one would you choose? I guess the hope is that since FAT is so widespread it's understood well enough so the code dealing with it can be reviewed and optimized for robustness as good as it can possibly get. Systemd uses automount for the boot partition so the time it's exposed writeable is limited. Lennart also keeps pointing out that the rename operations needed for the boot counting are designed so they could be achieved by single byte writes to the specific location in the file name on disk. So bootloaders don't even need to know how to fully write vfat and take a shortcut instead. IMO the exact FS is a detail of the EFI background anyway. The gist of the standard really is that kernel and initrd are on an unencrypted, simple file system that has no Linux features and expects very little from the bootloader. Ie no encryption, journaling, CoW, btrfs subvolumes, etc. That's basically the direct opposite of the way grub went.
- Type 1 is actually based on extlinux and has some benefits, but we cannot use that spec unless it supports FIT - Type 2 requires EFI so is a non-starter for systems that want to boot without it
I had a brief chat with Luca on all-systems-go, his concern with adding FIT to the official document was mostly that no other bootloader supports FIT. I found that at least barebox also supports it. So probably just a matter of coordination for broader support. Anyway U- Boot could just support FIT as extension from the standard while still following the general architecture and naming scheme. Another idea outlined in a talk about MBR booting at all-systems-go was to just treat the PE files as archive format. Ie don't execute a UKI but rather load it's kernel and initrd, then boot that without EFI. Either way another missing piece in the puzzle is an alternative method to pass information to Linux without EFI variables: https://systemd.io/BOOT_LOADER_INTERFACE/ Maybe entries in the /chosen node of the DT? cu Ludwig -- (o_ Ludwig Nussel //\ Siemens AG / SI E R&D IOT V_/_ www.siemens.com