[U-Boot] Using CONFIG_ENV_FLAGS_LIST

[Claudius Heine]

Hi Stefano,

On 09/09/2019 13.26, Stefano Babic wrote:
> Hi Claudius,
> 
> On 02/09/19 16:02, Claudius Heine wrote:
>> Hi,
>>
>> I am currently looking into variable flags in order to make some
>> variables read-only for secure boot.
>>
>> The idea is that the u-boot binary is signed, while the environment
>> file/partition is not. So the built-in default environment of u-boot can
>> be trusted, while the external environment cannot. The assumption is
>> that those flags can be used to customize the validation when the
>> external environment is loaded or scripts/commands are executed.
>>
>> From the '/README' I gather that the access attributes can be any of
>> "any", "read-only", "write-once" or "change-default".
>>
>> I first tried to restrict the variables by choosing 'read-only', but
>> apparently this applies to the internal environment as well, and now
>> those variables are not loaded from the internal environment.
>>
>> Then I tried 'write-once', this worked now as expected from within
>> u-boot, but I could modify the environment from the linux userspace via
>> fw_setenv and those changes appear in u-boot as well. The same for
>> 'change-default'.
>>
>> Is there another way to fill the internal environment variable hash
>> table, so that 'read-only' works as expected?
>>
>> Heiko wrote some patches that change the behavior of the environment
>> loading so that the internal environment is loaded first before the
>> external environment.
> 
> But I think this is not mainlined.

Correct.

> 
>> This way 'write-once' should work as expected, but
>> I think 'read-only' should work that way already and we are missing
>> something here.
> 
> But '.flags' shoudl also be set as write once, else it is possible to
> rewrite the .flags variable making all environment read-write.
> 
> Heiko's patch is a work-around to get a signed environment. What I had
> for is to provide a signed environment (outside U-Boot with
> libubootenv), and U-Boot just verifies as it does for a kernel image -
> U-Boot does not need a private key, but U-Boot loses "saveenv" and the
> environment can be changed only from user space.

Interesting, however loosing 'saveenv' from within u-boot would very
inconvenient though. If the environment signature is invalid, would you
end up without one or load the internal one as fallback? If you load the
internal environment, can it query the external environment verification
state to handle this case and restore the external environment somehow?

regards,
Claudius

-- 
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-54 Fax: (+49)-8142-66989-80 Email: ch at denx.de

           PGP key: 6FF2 E59F 00C6 BC28 31D8 64C1 1173 CB19 9808 B153
                             Keyserver: hkp://pool.sks-keyservers.net

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20190909/ead19236/attachment.sig>