verified boot (vboot) with secure U-Boot env for SWUpdate

[Tim Harvey]

On Fri, Mar 19, 2021 at 10:17 AM Stefano Babic <sbabic at 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