Hi Simon, śr., 31 gru 2025 o 16:08 Simon Glass <[email protected]> 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
