Dear Ilias,
In message <20190625091140.GA19606@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?
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?
> > 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.
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: w...@denx.de
To get something done, a committee should consist of no more than
three men, two of them absent.
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
