[Concept,00/15] luks: Provide support for LUKSv2

  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.

One interesting part of this series is a converter from JSON to FDT, so
that U-Boot's existing ofnode interface can be used to access the
hierarchical data in JSON text. This obviously results in quite a bit
of new code, but it is more robust than trying to parse the text
directly using strstr(), etc. The choice of JSON for LUKS was presumably
made with larger code bases in mind, rather than a firmware
implementation.


Simon Glass (15):
  mbedtls: Allow use of XTS functions
  mbedtls: Allow use of base64
  test: Check for null string in assert functions
  json: Provide a way to convert JSON to FDT
  lib: Bring in argon2 library
  lib: Adapt argon2 library for U-Boot
  lib: Plumb in argon2 library
  test: Shorten the encrypt_passphrase parameter for FsHelper
  test: Add a way to create a LUKS2 partition with XTS
  test: Switch mmc12 over to use argon2id
  luks: Export the af_merge() function
  luks: Tidy up the code style in the block driver
  luks: Provide an implementation of luks2
  luks: Enable LUKSv2 support in the luks command
  luks: Update docs and tests for LUKSv2

 cmd/luks.c                           |   5 +-
 configs/sandbox_defconfig            |   4 +-
 doc/usage/cmd/luks.rst               |  42 +-
 doc/usage/luks.rst                   | 302 +++++++--
 drivers/block/Makefile               |   2 +-
 drivers/block/luks.c                 | 233 +++++--
 drivers/block/luks2.c                | 974 +++++++++++++++++++++++++++
 drivers/block/luks_internal.h        |  43 ++
 drivers/misc/Kconfig                 |   2 +-
 fs/btrfs/Kconfig                     |   2 +-
 include/argon2.h                     | 448 ++++++++++++
 include/json.h                       |  34 +
 include/luks.h                       |   4 +-
 include/test/ut.h                    |  28 +-
 lib/Kconfig                          |  14 +-
 lib/Makefile                         |   4 +
 lib/argon2/Makefile                  |  10 +
 lib/argon2/argon2_wrapper.c          | 469 +++++++++++++
 lib/argon2/blake2/blake2-impl.h      | 156 +++++
 lib/argon2/blake2/blake2.h           |  90 +++
 lib/argon2/blake2/blake2b.c          | 391 +++++++++++
 lib/argon2/blake2/blamka-round-ref.h |  57 ++
 lib/argon2/core.c                    | 616 +++++++++++++++++
 lib/argon2/core.h                    | 229 +++++++
 lib/argon2/ref.c                     | 195 ++++++
 lib/json.c                           | 612 ++++++++++++++++-
 lib/mbedtls/Makefile                 |   5 +
 lib/mbedtls/mbedtls_def_config.h     |   8 +
 test/boot/luks.c                     |  29 +
 test/lib/json.c                      | 337 ++++++++-
 test/py/img/common.py                |   9 +-
 test/py/img/ubuntu.py                |   6 +-
 test/py/tests/fs_helper.py           |  52 +-
 test/py/tests/test_ut.py             |   3 +-
 34 files changed, 5256 insertions(+), 159 deletions(-)
 create mode 100644 drivers/block/luks2.c
 create mode 100644 drivers/block/luks_internal.h
 create mode 100644 include/argon2.h
 create mode 100644 lib/argon2/Makefile
 create mode 100644 lib/argon2/argon2_wrapper.c
 create mode 100644 lib/argon2/blake2/blake2-impl.h
 create mode 100644 lib/argon2/blake2/blake2.h
 create mode 100644 lib/argon2/blake2/blake2b.c
 create mode 100644 lib/argon2/blake2/blamka-round-ref.h
 create mode 100644 lib/argon2/core.c
 create mode 100644 lib/argon2/core.h
 create mode 100644 lib/argon2/ref.c
  

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.

cu
Ludwig
  

Hi Ludwig,

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.

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?

Regards,
Simon


>
> cu
> Ludwig
>
> --
> (o_  Ludwig Nussel
> //\  Siemens AG / SI E R&D IOT
> V_/_ www.siemens.com
>
>
>
>
>
>
>
>
> _______________________________________________
> Concept mailing list -- concept@u-boot.org
> To unsubscribe send an email to concept-leave@u-boot.org
  

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.

> 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.
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.

cu
Ludwig
  

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
  

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? :-)

> 
> > 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?

cu
Ludwig
  

Hi Ludwig,

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.

>
> >
> > > 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.

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.

Regards,
Simon
  

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
  

Hi Ludwig,

On Mon, 17 Nov 2025 at 01:51, Nussel, Ludwig <ludwig.nussel@siemens.com> wrote:
>
> 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?

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.

>
> > 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.)
- 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

>
> [1]
> https://uapi-group.org/specifications/specs/boot_loader_specification/

Regards,
Simon
  

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
  

Hi Ludwig,

On Tue, 18 Nov 2025 at 02:41, Nussel, Ludwig <ludwig.nussel@siemens.com> wrote:
>
> 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?

ext4 as it can survive power failure and is relatively simple
(compared to some).

>
> 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.

Yes, when you have to use FAT you can try to minimise the risk with
all sorts of hacks. But really, we should not be using FAT for
anything that can change.

>
> 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.

OK.

>
> > - 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.

Well, also Tianocore[1] and coreboot (for many years) at least. What
other bootloaders are there, actually?

The response I received on FIT was unfortunate, to say the least. To
me it actually came across more as ignorance than anything else. I
would love to see that issue reopened for some discussion. Please see
if Luca might be open to that.

>
> 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.

Sure, but why? Using an EFI executable file as a container format is
just not a good idea. FIT has a proper schema and is much more
extensible.

>
> 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?

Yes, that would be the easiest.

Regards,
Simon

>
> cu
> Ludwig
>
> --
> (o_  Ludwig Nussel
> //\  Siemens AG / SI E R&D IOT
> V_/_ www.siemens.com
>
>
>

[1] https://github.com/tianocore/edk2/releases/tag/edk2-stable202311
[2] https://github.com/uapi-group/specifications/issues/138
  

On Tue, 2025-11-18 at 11:55 -0700, Simon Glass wrote:
> > > [...]
> > > 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?
> 
> ext4 as it can survive power failure and is relatively simple
> (compared to some).

Hmm, that means the bootloader has to deal with the complexity of also
handling the journal though.

> 
> 
> > > - 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.
> 
> Well, also Tianocore[1] and coreboot (for many years) at least. What
> other bootloaders are there, actually?

Ok, cool. I didn't know that.

> The response I received on FIT was unfortunate, to say the least. To
> me it actually came across more as ignorance than anything else. I
> would love to see that issue reopened for some discussion. Please see
> if Luca might be open to that.
> > 

I do have the impression that the embedded, potentially non-EFI use
case is a separate world that is not really that visible on the radar
on systemd side indeed. The next chance to meet the group in person
might be at FOSDEM. Unfortunately no dedicated devroom this year. Are
you going there?

> > 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.
> 
> Sure, but why? Using an EFI executable file as a container format is
> just not a good idea. FIT has a proper schema and is much more
> extensible.

I too find this abuse of PE stuff disturbing :-) It's just taking ties
to EFI a bit too far IMO. Nevertheless the ability to read those files
is a way to deal with the currently used formats.

> 
cu
Ludwig
  

Hi Ludwig,

On Mon, 24 Nov 2025 at 02:21, Nussel, Ludwig <ludwig.nussel@siemens.com> wrote:
>
> On Tue, 2025-11-18 at 11:55 -0700, Simon Glass wrote:
> > > > [...]
> > > > 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?
> >
> > ext4 as it can survive power failure and is relatively simple
> > (compared to some).
>
> Hmm, that means the bootloader has to deal with the complexity of also
> handling the journal though.

Yes, that's right. We discussed this a bit in the U-Boot call today.
Tom suggested pulling in ext4 from Linux somehow.

>
> >
> >
> > > > - 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.
> >
> > Well, also Tianocore[1] and coreboot (for many years) at least. What
> > other bootloaders are there, actually?
>
> Ok, cool. I didn't know that.

Universal Payload Specification uses FIT as the file format and device
tree (with some schema additions) as the handoff format.

>
> > The response I received on FIT was unfortunate, to say the least. To
> > me it actually came across more as ignorance than anything else. I
> > would love to see that issue reopened for some discussion. Please see
> > if Luca might be open to that.
> > >
>
> I do have the impression that the embedded, potentially non-EFI use
> case is a separate world that is not really that visible on the radar
> on systemd side indeed. The next chance to meet the group in person
> might be at FOSDEM. Unfortunately no dedicated devroom this year. Are
> you going there?

We definitely have two separate worlds, but I would like to bring them
together. At present I'm in NZ at the end of January, so FOSDEM is
unlikely. What else is on the calendar next year?

>
> > > 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.
> >
> > Sure, but why? Using an EFI executable file as a container format is
> > just not a good idea. FIT has a proper schema and is much more
> > extensible.
>
> I too find this abuse of PE stuff disturbing :-) It's just taking ties
> to EFI a bit too far IMO. Nevertheless the ability to read those files
> is a way to deal with the currently used formats.

Yes, it is a pragmatic solution within the limitations of EFI (FAT,
EFI apps). But we should not build the world on it.

Regards,
Simon
  

On Tue, 2025-11-25 at 15:14 -0700, Simon Glass wrote:
> On Mon, 24 Nov 2025 at 02:21, Nussel, Ludwig <ludwig.nussel@siemens.com> wrote:
> > 
> > On Tue, 2025-11-18 at 11:55 -0700, Simon Glass wrote:
> > > > > [...]
> > > > > 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?
> > > 
> > > ext4 as it can survive power failure and is relatively simple
> > > (compared to some).
> > 
> > Hmm, that means the bootloader has to deal with the complexity of also
> > handling the journal though.
> 
> Yes, that's right. We discussed this a bit in the U-Boot call today.
> Tom suggested pulling in ext4 from Linux somehow.
> > 

Uh, are you sure that's a good idea? ext4 is almost eight times as big
as FAT in terms of lines in the Linux kernel. There has to be some fs
more suitable for this very special and limited use case of the boot
volume.
But then if FAT is not robust enough for some really sensitive use
cases I'd guess that one would just dump the the fit image raw into
some a/b boot partitions instead?

> > > > > - 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.
> > > 
> > > Well, also Tianocore[1] and coreboot (for many years) at least. What
> > > other bootloaders are there, actually?
> > 
> > Ok, cool. I didn't know that.
> 
> Universal Payload Specification uses FIT as the file format and device
> tree (with some schema additions) as the handoff format.
> 

Good arguments IMO. Esp when the intention is to allow for really fast
boots hat EFI may not be able to provide. Booting fast was one of
systemd's original motivations.

> > > The response I received on FIT was unfortunate, to say the least. To
> > > me it actually came across more as ignorance than anything else. I
> > > would love to see that issue reopened for some discussion. Please see
> > > if Luca might be open to that.
> > > > 
> > 
> > I do have the impression that the embedded, potentially non-EFI use
> > case is a separate world that is not really that visible on the radar
> > on systemd side indeed. The next chance to meet the group in person
> > might be at FOSDEM. Unfortunately no dedicated devroom this year. Are
> > you going there?
> 
> We definitely have two separate worlds, but I would like to bring them
> together. At present I'm in NZ at the end of January, so FOSDEM is
> unlikely. What else is on the calendar next year?
> 

That's certainly a more pleasant place to be at that time of the year
:-) I'm probably not aware of all events, a very good one is all-
systems-go for sure. It's usually end of September in Berlin.

> > > 
cu
Ludwig