[U-Boot] efi_loader: implementing non-volatile UEFI variables

[Ilias Apalodimas <ilias.apalodimas@linaro.org>]

Dear Wolfgang,
> > 
> > thanks a lot for the good online meeting this morning together with your
> > colleague Suggan where we discussed the requirements for the
> > implementation of non-volatile variables in U-Boot.
> > 
> > Currently UEFI variables are stored in U-Boot variables. Saving the
> > U-Boot variables will persist all UEFI variables in the environment both
> > volatile and non-volatile. This does not conform the the UEFI standard.
> 
> Is this the only problem of using the environment as storage?
> 
No it's not. For UEFI secure variables you need authentication, signature checks
amongst other things. 
> > To provide a secure storage Linaro is considering to implement an OP-TEE
> > module for variable storage and as alternative to this OP-TEE module a
> > standalone MM service which will be a BL32 ATF module.
> > 
> > So in future we will have possibly three alternative drivers for UEFI
> > variables:
> > 
> > - U-Boot only implementation
> >   (what is now in lib/efi_loader/efi_variable.c)
> > - OP-TEE module
> > - standalone MM service
> > 
> > And maybe a fourth dummy one implementing no variable service at all.
> 
> Is this really a good idea?
> 
> 
> If the volatile / non-volatile behaviour is the onlyh problem you
> see with using environment variables, would it then not make much
> more sense to extend the environment flags concept by adding a
> "volatile" flag, with the meaing that such variables don;t get
> written by "env save"?
Yes but the volatile/non-volatile is the least of our problems

> 
> This would also make sense in some other places - for example, the
> "filesize" variable is a perfect candidate to be flagged as
> "volatile".  There is absolutely no use in saving it persistently.
> 
> 
> So such an extension would be useful for others, too, and might
> eventually avoid so many different implementations for the same
> task?  Also, the implementation should be straightforward...
You need Secure variables. That implies they should live in Non-Secure world nor
you should store them is some NOr//NAND flash that you can manipulate under
linux with fw_setenv.


I personally think storing UEFI and U-Boot env variables in the *same* storage
partition a bad idea. I also considering mixing apples and oranges. They are two
completely different things. The fact that it was easy to use existing U-Boot
primitives to make that happen does not make the approach correct. It just makes
it easier.

Rergards
/Ilias