Standard Boot integration - script validation before execution

Standard Boot integration - script validation before execution

[Patryk]

Hi
I would like to integrate Standard Boot on our custom board based on
NXP LS1028a, as it currently uses a so-called distro boot.
Normally I would just follow the instructions in the doc about
converting from distro boot to standard boot, but things are in fact a
bit more complicated. My board supports dual rootfs following the A/B
update scheme, so I need a place where I can check the boot state,
boot counter and so on, so as to set the final rootfs partition to
pass to the kernel. That's actually not a problem - I can just use the
bootmeth script and put all the logic there. The problem is that on a
production system, the devics will be protected by the Secure Boot
procedure, so the script to be executed should also be verified before
the execution. In the current solution (distro boot), the boot
command, first loads the script, then calls esbc_validate over the
script header and if the validation passes it sources the script so
the OS can be loaded. In current bootmeth_script there is no place (or
I'm not aware of) that would allow me to do vendor-specific validation
over the script. What would you advise in this case? Is there any way
to "inject" some plugins into the existing boot methods, like  e.g. a
plugin that would be overriding or adding some functionalities to
existing bootmeth_script? I can of course patch the existing
bootmeth_script with a command that would perform the validation but
this would no longer be a generic boot method. Or perhaps should I
create my own boot method?

I would be grateful for any suggestion
Best regards
Patryk

Re: Standard Boot integration - script validation before execution

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 1824 bytes --]

On Tue, Dec 16, 2025 at 03:13:59PM +0100, Patryk wrote:

> Hi
> I would like to integrate Standard Boot on our custom board based on
> NXP LS1028a, as it currently uses a so-called distro boot.
> Normally I would just follow the instructions in the doc about
> converting from distro boot to standard boot, but things are in fact a
> bit more complicated. My board supports dual rootfs following the A/B
> update scheme, so I need a place where I can check the boot state,
> boot counter and so on, so as to set the final rootfs partition to
> pass to the kernel. That's actually not a problem - I can just use the
> bootmeth script and put all the logic there. The problem is that on a
> production system, the devics will be protected by the Secure Boot
> procedure, so the script to be executed should also be verified before
> the execution. In the current solution (distro boot), the boot
> command, first loads the script, then calls esbc_validate over the
> script header and if the validation passes it sources the script so
> the OS can be loaded. In current bootmeth_script there is no place (or
> I'm not aware of) that would allow me to do vendor-specific validation
> over the script. What would you advise in this case? Is there any way
> to "inject" some plugins into the existing boot methods, like  e.g. a
> plugin that would be overriding or adding some functionalities to
> existing bootmeth_script? I can of course patch the existing
> bootmeth_script with a command that would perform the validation but
> this would no longer be a generic boot method. Or perhaps should I
> create my own boot method?

I think, given how RAUC has been implemented (which in the "distro boot"
days was a complex boot script), you're likely best off making a custom
boot method.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: Standard Boot integration - script validation before execution

[Alexander Dahl]

Hello Patryk,

disclaimer: migrating from distro boot to standard boot for our boards
is on my todo list, but I have not looked into standard boot, yet.

Am Tue, Dec 16, 2025 at 03:13:59PM +0100 schrieb Patryk:
> Hi
> I would like to integrate Standard Boot on our custom board based on
> NXP LS1028a, as it currently uses a so-called distro boot.
> Normally I would just follow the instructions in the doc about
> converting from distro boot to standard boot, but things are in fact a
> bit more complicated. My board supports dual rootfs following the A/B
> update scheme, so I need a place where I can check the boot state,
> boot counter and so on, so as to set the final rootfs partition to
> pass to the kernel. That's actually not a problem - I can just use the
> bootmeth script and put all the logic there. The problem is that on a
> production system, the devics will be protected by the Secure Boot
> procedure, so the script to be executed should also be verified before
> the execution. 

Reminds me on the problems I faced when trying to implement Secure
Boot with A/B rootfs.  IIRC there were two things I ended up doing:

1. putting the boot script in a separate volume outside of rootfs and
the A/B scheme.

2. use signed FIT image for the boot script instead of the old
fashioned U-Boot script, enable CONFIG_FIT_SIGNATURE, and disable (!)
CONFIG_LEGACY_IMAGE_FORMAT.

Not sure how this plays together with standard boot, but once you
instruct U-Boot to only accept signed FIT images, that also applies
for scripts put into a FIT image.

Greets
Alex

> In the current solution (distro boot), the boot
> command, first loads the script, then calls esbc_validate over the
> script header and if the validation passes it sources the script so
> the OS can be loaded. In current bootmeth_script there is no place (or
> I'm not aware of) that would allow me to do vendor-specific validation
> over the script. What would you advise in this case? Is there any way
> to "inject" some plugins into the existing boot methods, like  e.g. a
> plugin that would be overriding or adding some functionalities to
> existing bootmeth_script? I can of course patch the existing
> bootmeth_script with a command that would perform the validation but
> this would no longer be a generic boot method. Or perhaps should I
> create my own boot method?
> 
> I would be grateful for any suggestion
> Best regards
> Patryk

Re: Standard Boot integration - script validation before execution

[Patryk]

Hello,

wt., 16 gru 2025 o 15:59 Alexander Dahl <ada@thorsis.com> napisał(a):
> Reminds me on the problems I faced when trying to implement Secure
> Boot with A/B rootfs.  IIRC there were two things I ended up doing:
>
> 1. putting the boot script in a separate volume outside of rootfs and
> the A/B scheme.
>
> 2. use signed FIT image for the boot script instead of the old
> fashioned U-Boot script, enable CONFIG_FIT_SIGNATURE, and disable (!)
> CONFIG_LEGACY_IMAGE_FORMAT.
>
> Not sure how this plays together with standard boot, but once you
> instruct U-Boot to only accept signed FIT images, that also applies
> for scripts put into a FIT image.
>
> Greets
> Alex

As you suggested, I played a bit with the boot script and fit image
and indeed it's possible to include bootscript only in the fit image
thus verifying it using a verified boot mechanism. It can also be
loaded by the bootmeth_script. That solves part of my problem. Thanks
for that suggestion. I didn't know about it before. However this is
only part of the problem I'm trying to solve as I said and would be
grateful for other suggestions as well, but first I will outline what
I actually want to achieve.

I'm trying to implement firmware and software updates for my board,
but have some problems on how to approach it.
As a second stage bootloader (that gets loaded by the BootROM) I'm
using BL2 from TF-A. Its purpose is to load FIP (Firmware Image
Package) that contains BL31 (EL3 Runtime Services), BL32 (OPTEE), BL33
(U-BOOT). Then, once the u-boot is loaded it is supposed to load the
Linux kernel. Following my requirements I need to be able to update
almost all components namely: FIP (thus BL31, BL32, BL33), kernel
image (including bootscript) and rootfs.

TF-A supports something called PSA Firmware Update that allows the
selection of a FIP bank, just an ordinary A/B scheme where there are
FIP-A and FIP-B copies, and the selection happens through so-called
metadata. It also supports a boot counter that allows it to roll back
when the boot counter reaches max boot attempt. Up to this point
everything is quite straightforward.

Things get more complicated when the boot process reaches the u-boot
stage. As I pointed out I need to have two copies of kernel image and
boot script thus I need the following:
- bootscript-a
- fitImage-a (kernel image)
- bootscript-b
- fitImage-b (kernel image)
I am aware that I can embed the bootscript in the fitImage however, as
I said before my fitImage is stored on the disk in the encrypted form,
so the bootscript is used to decrypt the kernel image before loading.
I decided to follow A/B paths for each component thus the TF-A is the
source of the boot index.
The information about the boot index selected by TF-A (A or B) is
propagated to u-boot, so u-boot indeed has such information. The boot
index can be then used to select bootscript-a/fitImage-a or
bootscript-b/fitImage-b. However I'm not sure how to do this. I mean
it's not technically difficult, it's rather a matter of "how it should
be done correctly". What's more I want to make use of Standard Boot
instead of old distro boot. Looking at the Standard Boot methods there
is e.g. bootmeth_script available however I don't see how this could
work in my case. This bootmeth_script just simply looks for a
bootscript and if it finds it, then it loads it. As I said in my case
I have bootscript-a/b, not just a single bootscript. What's even worse
I cannot make separate boot partitions for boot-a and boot-b as the
only partitioning scheme available on my SoC is MBR which allows you
to create up to 4 partitions. I already reached this limit (boot,
root-a, root-b, data), so the only reasonable solution for me would be
to put the A/B artifacts in subdirectories under /boot part. To sum
this up - the only sensible solution that comes to my mind is to
create my own boot method that will use the TF-A provided boot index,
then will scan /boot partition looking for e.g. boot-a/boot-b
subdirectories (depending on the boot index) and the required
bootscript (wrapped into fit Image so that it can be verified by the
verified boot mechanism).
However, to be honest I'm not sure if this is the right solution.
Would be grateful for some suggestions.

BR
Patryk

Re: Standard Boot integration - script validation before execution

[Simon Glass]

Hi Patryk,

On Wed, 31 Dec 2025 at 07:46, Patryk <pbiel7@gmail.com> wrote:
>
> Hello,
>
> wt., 16 gru 2025 o 15:59 Alexander Dahl <ada@thorsis.com> napisał(a):
> > Reminds me on the problems I faced when trying to implement Secure
> > Boot with A/B rootfs.  IIRC there were two things I ended up doing:
> >
> > 1. putting the boot script in a separate volume outside of rootfs and
> > the A/B scheme.
> >
> > 2. use signed FIT image for the boot script instead of the old
> > fashioned U-Boot script, enable CONFIG_FIT_SIGNATURE, and disable (!)
> > CONFIG_LEGACY_IMAGE_FORMAT.
> >
> > Not sure how this plays together with standard boot, but once you
> > instruct U-Boot to only accept signed FIT images, that also applies
> > for scripts put into a FIT image.
> >
> > Greets
> > Alex
>
> As you suggested, I played a bit with the boot script and fit image
> and indeed it's possible to include bootscript only in the fit image
> thus verifying it using a verified boot mechanism. It can also be
> loaded by the bootmeth_script. That solves part of my problem. Thanks
> for that suggestion. I didn't know about it before. However this is
> only part of the problem I'm trying to solve as I said and would be
> grateful for other suggestions as well, but first I will outline what
> I actually want to achieve.
>
> I'm trying to implement firmware and software updates for my board,
> but have some problems on how to approach it.
> As a second stage bootloader (that gets loaded by the BootROM) I'm
> using BL2 from TF-A. Its purpose is to load FIP (Firmware Image
> Package) that contains BL31 (EL3 Runtime Services), BL32 (OPTEE), BL33
> (U-BOOT). Then, once the u-boot is loaded it is supposed to load the
> Linux kernel. Following my requirements I need to be able to update
> almost all components namely: FIP (thus BL31, BL32, BL33), kernel
> image (including bootscript) and rootfs.
>
> TF-A supports something called PSA Firmware Update that allows the
> selection of a FIP bank, just an ordinary A/B scheme where there are
> FIP-A and FIP-B copies, and the selection happens through so-called
> metadata. It also supports a boot counter that allows it to roll back
> when the boot counter reaches max boot attempt. Up to this point
> everything is quite straightforward.
>
> Things get more complicated when the boot process reaches the u-boot
> stage. As I pointed out I need to have two copies of kernel image and
> boot script thus I need the following:
> - bootscript-a
> - fitImage-a (kernel image)
> - bootscript-b
> - fitImage-b (kernel image)
> I am aware that I can embed the bootscript in the fitImage however, as
> I said before my fitImage is stored on the disk in the encrypted form,
> so the bootscript is used to decrypt the kernel image before loading.
> I decided to follow A/B paths for each component thus the TF-A is the
> source of the boot index.
> The information about the boot index selected by TF-A (A or B) is
> propagated to u-boot, so u-boot indeed has such information. The boot
> index can be then used to select bootscript-a/fitImage-a or
> bootscript-b/fitImage-b. However I'm not sure how to do this. I mean
> it's not technically difficult, it's rather a matter of "how it should
> be done correctly". What's more I want to make use of Standard Boot
> instead of old distro boot. Looking at the Standard Boot methods there
> is e.g. bootmeth_script available however I don't see how this could
> work in my case. This bootmeth_script just simply looks for a
> bootscript and if it finds it, then it loads it. As I said in my case
> I have bootscript-a/b, not just a single bootscript. What's even worse
> I cannot make separate boot partitions for boot-a and boot-b as the
> only partitioning scheme available on my SoC is MBR which allows you
> to create up to 4 partitions. I already reached this limit (boot,
> root-a, root-b, data), so the only reasonable solution for me would be
> to put the A/B artifacts in subdirectories under /boot part. To sum
> this up - the only sensible solution that comes to my mind is to
> create my own boot method that will use the TF-A provided boot index,
> then will scan /boot partition looking for e.g. boot-a/boot-b
> subdirectories (depending on the boot index) and the required
> bootscript (wrapped into fit Image so that it can be verified by the
> verified boot mechanism).
> However, to be honest I'm not sure if this is the right solution.
> Would be grateful for some suggestions.

I'm not sure if this will help or not, but there is VBE (Verified Boot
for Embedded) which uses a new phase (VPL) to verify things before
SPL, TF-A, etc. are loaded. It has an A/B/recovery bootmeth. Various
things have been written about it (e.g. [1]) and the docs landing page
is [2]. There is also a conference talk at [3].

While bootstd[4] was about 5 years late, VBE is a little ahead of its
time, but I believe something like it (everything in FIT, a VPL phase)
is where we will land eventually. As you say, you want to update
everything possible - I would add that you cannot update something
which might allow the device to be bricked.

For security I would advise to eventually move away from using scripts
(perhaps in a second generation as it is challenging today). Yes they
can be signed, but there is a lot of code involved in running
them...turning off CMDLINE almost halves the size of U-Boot and
therefore the attack surface.

Regards,
Simon

[1] https://u-boot.org/blog/verified-boot-for-embedded-on-rk3399/?print=print
[2] https://docs.u-boot.org/en/latest/develop/vbe.html
[3] https://elinux.org/Boot_Loaders#U-Boot
[4] https://docs.u-boot.org/en/latest/develop/bootstd/index.html

Re: Standard Boot integration - script validation before execution

[Patryk]

Hi Simon,

śr., 31 gru 2025 o 16:08 Simon Glass <sjg@chromium.org> napisał(a):
> I'm not sure if this will help or not, but there is VBE (Verified Boot
> for Embedded) which uses a new phase (VPL) to verify things before
> SPL, TF-A, etc. are loaded. It has an A/B/recovery bootmeth. Various
> things have been written about it (e.g. [1]) and the docs landing page
> is [2]. There is also a conference talk at [3].
>
> While bootstd[4] was about 5 years late, VBE is a little ahead of its
> time, but I believe something like it (everything in FIT, a VPL phase)
> is where we will land eventually. As you say, you want to update
> everything possible - I would add that you cannot update something
> which might allow the device to be bricked.

I have already seen this and it looks interesting but I need to dig
into it more to have a better understanding but I'm just afraid that
I'll not make it until my current deadline, so if we decide to use it,
it will most probably be in gen 2.
Just out of curiosity - does vbe support the boot process where the
second stage bootloader (the one that gets loaded usually by boot ROM)
is TF-A not the U-BOOT? On our SoC TF-A BL2 is loaded by BootROM and
then BL2 loads the u-boot (contained in FIP).

> For security I would advise to eventually move away from using scripts
> (perhaps in a second generation as it is challenging today). Yes they
> can be signed, but there is a lot of code involved in running
> them...turning off CMDLINE almost halves the size of U-Boot and
> therefore the attack surface.

Regarding my question: the more I think about it, the more I am
inclined to implement my own boot method, although I am still not
entirely convinced this is the right approach. If I were to rely on a
boot script, I would most likely need to introduce bootscript-a and
bootscript-b, along with a mechanism to select the appropriate one.
This is clearly not supported out of the box by bootmeth_script, so I
would end up implementing custom logic anyway.
I looked at bootmeth_android as a reference, and it appears to provide
the following features:
- slot selection based on the BCB (in my case, the boot index is
passed to U-Boot from TF-A),
- support for booting in an unlocked mode (I will also need a way to
unlock the device to allow booting a customer-provided image, should
that be required).

In addition, my use case requires:
- decrypting the image containing the kernel (a FIT image, decrypted
using the SoC vendor-specific mechanism),
- image verification (handled out of the box via Verified Boot),
- rollback protection (validating the image against a minimum allowed version).

Of course, I do not intend to use this method to boot my distro, but
my reasoning is as follows: if someone decided to implement a custom
boot method for Android, why wouldn’t I implement my own boot method
for my distro when none of the existing solutions fully meet my
requirements? As mentioned earlier, I could move most of this logic
into a boot script; however, first I would still need a way to decide
which boot script to use (bootscr-a vs. bootscr-b), and second, as you
pointed out, this would increase the attack surface.

That said, I still have a question: does this align with the
recommended U-Boot design approach, or is there a more idiomatic way
to implement this?

Would be grateful for some guidance.
Best regards,
Patryk

Re: Standard Boot integration - script validation before execution

[Rasmus Villemoes]

On Mon, Jan 05 2026, Patryk <pbiel7@gmail.com> wrote:

> Regarding my question: the more I think about it, the more I am
> inclined to implement my own boot method, although I am still not
> entirely convinced this is the right approach. If I were to rely on a
> boot script, I would most likely need to introduce bootscript-a and
> bootscript-b, along with a mechanism to select the appropriate one.

FWIW, what we do is to embed the bootscript in the u-boot binary
(actually, in the control dtb via the -u-boot.dtsi mechanism). That way,
the script is automatically verified as part of whatever mechanism
verifies U-Boot, and it gets updated in tandem with U-Boot, so no need
for having it lying around somewhere separately and having to pick the
right one and verify it. Running that script is then exactly as
trustworthy as running the U-Boot C code.

Rasmus