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

[Stefano Babic]

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 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).

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.

Best regards,
Stefano

--
=====================================================================
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=====================================================================

[Tim Harvey]

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

[Stefano Babic]

Hi Tim,

On 19.03.21 19:40, Tim Harvey wrote:
> 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.

If this can help...

Your setup forbids streaming (installed-directly = true for each
artifact), and the images are first extracted into /tmp before installing.

If this can help, I have recently exported a global "getroot" lua
function that can be called from sw-description.

Yes, only variables in the list can be modified.

>
> 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?

Right - you can write whatever you want via SWUpdate or fw_setenv, but
U-Boot takes just the variables in the list and discards the other ones.

>
>>
>> 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.
>

Best regards,
Stefano