Hi Patryk, On Wed, 31 Dec 2025 at 07:46, Patryk <[email protected]> wrote: > > Hello, > > wt., 16 gru 2025 o 15:59 Alexander Dahl <[email protected]> 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
