On Fri, Mar 19, 2021 at 10:17 AM Stefano Babic <sba...@denx.de> wrote: > > Hi Tim, > > On 19.03.21 16:50, Tim Harvey wrote: > > Greetings, > > > > I'm looking at using SWUpdate to facilitate an A/B ping-pong method of > > firmware updates where a state is stored in U-Boot env by the SWUpdate > > postinst script. > > You do not need a postinstall script, yoiu just add the environment to > the "bootenv" section in sw-description.
I'm using the postinst script to determine the root partition and write it, so there is some intelligence there. The generic instructions I put together to demonstrate this setup are at http://trac.gateworks.com/wiki/buildroot#SWUpdate which likely explains best what I'm doing. > > > > > I'm needing to use secure boot with U-Boot's verified boot support and > > am not clear how, if at all, the U-Boot env can be authenticated. > > > > Is there any authentication support within a flash stored U-boot > > environment that is supported by fw_setenv and if not what is the > > recommendation for removing environment and are there any other > > suggestions for an SWUpdate postinstall script to select the OS image > > to boot after an update? > > There is no authentication in U-Boot - I supposed to add a signed > environment to U-Boot, but then U-Boot won't be able save the env > because a "saveenv" requires a private key. > > The current solution is to use CONFIG_ENV_WRITEABLE_LIST. You have a > short list (I use just one) of variables that are allowed to be changed, > while the complete environment is added via CONFIG_EXTRA_ENV and, > because it is linked to u-boot, is signed as well. If you set your > script to depend on just one variable to select if A or B can run, you > can be sure that the rest of environment cannot be compromised. You > should also set flags for the variable to be sure that it is not changed > to be a script (just integer are accepted). Thanks - I was not aware of this feature. This looks like it would work well. So for my case I'm toggling 'mmcbootpart' from a '2' to a '3' in postinst so I suppose in U-Boot I would: CONFIG_ENV_WRITEABLE_LIST=y CONFIG_ENV_FLAGS_LIST_DEFAULT=mmcbootpart:d and make sure my compiled in env a minimal bootcmd that uses mmcbootpart as the only variable. when CONFIG_ENV_WRITEABLE_LIST=y do all other env vars defined in built-in-env get automatically flagged as non-writable? and regardless of what modifications are done to the flash backed env (via something like fw_setenv for example) are the only vars that get merged into the runtime env hashtable those defined in CONFIG_ENV_FLAGS_LIST_DEFAULT? > > Another solution is to use CONFIG_ENV_EMBEDDED and to switch via the > ssbl_hanlder in SWUpdate. Anyway, support for this easy "switcher" is > not present in U-Boot and should be added. This left the whole > environment untouched, and the selection between A/B is done via an > external structure. Sounds like your previous solution works well enough. Thanks! Tim
