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

[Wolfgang Denk]

Dear Takahiro,

In message <20190625011039.GO6610 at linaro.org> you wrote:
>
> > Think about secure boot. It is a bad idea to expose variables in this way.
>
> Actually, we are thinking of disabling U-Boot environment (I mean,
> ENV_IS_NOWHERE) still allowing for UEFI variables for security reason.

OK.  I know of systems that have passed security audits with
U-Boot environment enabled.  In those cases it as sufficient to make
a certain set of variables immutable.

Also, adding the new "volatile" attribute to the environment flags
as I suggested would allow to fine-tune which variables get stored
in the persistent nvironment copy at all.

> One of the differences between U-Boot env and UEFI variables
> is that the former can and should be saved to backing storage
> only with explicit "saveenv" command, while the latter are
> expected to be saved immediately.

OK - but this does not conflict in any way with the U-Boot
environment concept.  In the same way we can add a "volatile"
property to the flags, we can add something like an "autosave"
property which would cause that aany modification of the variable
value would automatically run "env save".

Once you think about more generic features of the property flags you
can implement all kinds of clever/useful/fancy things.  For example,
one could think of a "protected" property, which would require
password entry to change the value, etc.

Of course you could also flag variables with an "UEFI" attribute and
add all kinds of wanted behaviour.

> Preserving respective semantics simultaneously would be possible, but
> it would make the implementation a bit complicated and ugly.

It does not have to be ugly, and I think it is also not so
complicatred.  In any case it seems more attractive to me than
adding a completly separate, new implementation for variable
storage.

> Instead, I believe that it will be a clever idea that we should have
> separate contexts for them as I showed in my non-volatile support patch[1].
>
> [1] https://lists.denx.de/pipermail/u-boot/2019-June/371601.html

To be honest: I thinkt his is not really a clever approach.  it
would be _much_ easier to add a "volatile" property to the U-Boot
variable flags.  Your patch modifies 12 files, and adds more than
600 lines of code.  And since you're modifying   env/fat.c  I have
the impression that this is not even universally usable - does it
really work only when storing the environment in a FAT file system?
Not with ext4? Or any other storage? And it works only for UEFI, but
"normal" environment variables do not benefit from this?

Note that my suggested extension of the variable flags would be
completely agnostic of this...

> One of possible improvements here is to refactor the env code and
> parameterize "contexts" at env_save()/env_load().

Contexts, or flags.  But this does not require much refactoring.  It
should be a straighforward extension.

> > >And I agree on that.  But even if it was not the case, having four
> > >different implementations for the same thing is .... sub-optiman.
> > 
> > We have a lot of things that can be disabled in U-Boot. Why should we
> > not be able to disable UEFI variables?
>
> To be honest, I'm a bit doubtful about practical meaning of
> disabling UEFI variables for UEFI execution environment.

This was Heinrich's argument, and I admit that I didn't understandit
either.

> > UEFI variables should be accessible via the UEFI runtime API and not via
> > some U-Boot specific hack which no other program but U-Boot cares about.
>
> Please notice that one of the reasons that prevents UEFI variables
> from being accessed by OS is a real hardware(device/controller) may be
> shared between firmware(i.e. UEFI runtime) and OS and mutually exclusive
> access must be ensured.

Again, this was Heinrich's argument.

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
There are no data that cannot be plotted on a straight  line  if  the
axis are chosen correctly.