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

[Stefano Babic]

Hi Tim,

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

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.

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

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