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

[Ilias Apalodimas]

Dear Wolfgang,

On Tue, 25 Jun 2019 at 12:27, Wolfgang Denk <wd at denx.de> wrote:
>
> Dear Ilias,
>
> In message <20190625091140.GA19606 at apalos> you wrote:
> >
> > > > 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.
>
> There have been thoughts about using signed environment storage
> before.  This is manageable as long as your environment is read-only.
> But for writing ("env save") you need access to the private key to
> sign the new data.  Do you have a good solution for this?
Not really, not anything secure anyway
That's we we suggested letting the secure world deal with it.

>
> Except for this problem, I see no reason why my proposal of adding a
> "UEFI" flag (or context, if you prefer this word) would not be a
> solution for this requiremnt?

I think the argument is orthogonal to what we are discussing.
I understand the need for U-Boot to deal with volatile and
non-volatile variables. I also know use-cases that would benefit from
it (i.e the filesize you mentioned)

Adding that attribute on the the variables is fine. What is not fine
is trying to apply UEFI semantics on the projects environmental
variable subsystem, just because the volatile/non-volatile happens to
be 'ok' for both UEFI/ENV variables.
The attribute will only offer you some kind of UEFI variable "emulation".
So what i'd ideally love to see is something like:
1. UEFI variables get stored *somewhere* if a secure OS does not exist
and can't deal with Secure UEFI variables. We can then emulate the
UEFI behavior with 0 security. In this scenario i can justify your
proposal, which in fact makes sense.
2. If A Secure OS runs (whether it's Arm/Intel/Whatever), we can
replace the read/store callbacks and have proper UEFI variables with
full semantics for which, a secure world application will be
responsible (and will be responsible for the storage as well)

>
> > > 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
>
> Agreed - and it's trivial to solve.
>
> > > 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.
>
> Secure variables is a completely new topic actually.  It has not
> been mentioned before.  It would have been nice if someone had
> listed all teh requirements before...
>
> And I think I should point out that the suggested patch does not
> address this requirement either.
>
> > 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.
>
> I can understand that you want to have separate storage, and indeed
> it makes sense in other use cases as well.  And actually I see this
> as one of the advantages of my proposal: you can have this as well
> easily, less intrusive and with less effort than the submitted
> patches.  And with the additional benefit that it is usefoul for
> others as well.
Does my answer above cover this as well?

Regards
/Ilias

>
> Best regards,
>
> Wolfgang Denk
>
> --
> DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
> To get something done, a committee should consist  of  no  more  than
> three men, two of them absent.