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

Wolfgang Denk wd at denx.de
Tue Jun 25 05:56:20 UTC 2019

Dear Heinrich,

In message <63fcd992-2d43-d168-64e8-7058c3a244f8 at gmx.de> you wrote:
> > Oops?  Is it possible that you are not aware of the
> > tools/env/fw_env* code?
> I am fully aware of this.

OK, then why do you claim that U-Boot nvironment variables are not
"available to the operating system"?

> Think about secure boot. It is a bad idea to expose variables in this way.

Would you please be so kind to elucidate what the problem is?

> > 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?

Your way of replying is not very constructive.  You don't even try
to comment on my argument, but instead you bring up a completely new
thing, and without explaining why that would be a problem.

See above:

You claim U-Boot environment variables cannot be accessed by Linux.
I tell you they can. You say it's bad for secure boot, but fail to
explain why that would be tha case.

Here I argument that 4 different implementations of the same thing
are a bad idea.  You ignore that argument and jump to a new one,
about disabling UEFI variables.  Why do you need another variable
implementation for that?

Please try and be a bit more constructive and helpful in your
argumentation.  I don't doubt that you have spent a lot of thought
already on this, but then plase explain why you need this thing and
why something already existing cannot be used.  Explain it such that
someone without intimate UEFI knowledge can understand it, too.

> What Linaro is doing with OP-TEE makes sense to enable secure boot. But
> it will be an ARM64 specific solution.

What exactly do you want to tell us with that statement?

> > And if the "volatile" feature is all that is missing when using
> > environment variables, then this should be the road taken:
> >
> > - It avoids a complete new implementation
> > - It can be added witrh very little effort
> > - It would be just a minimal increase in memory footprinmt
> > - It is useful for a lot of other pirposes as well.
> >
> > What are your agruments for _not_ taking this approach?
> 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.

I don't care what other programs are doing.  But I do care what we
do in U-Boot.  And you talk about adding a ton of multi-redundant
( 4 times, as you said yourself) code to U-Boot, but the arguments
you bring up why exactly this is needed and why it cannot be done
the U-Boot way are pretty weak.

Sorry, but this is not really convincing.

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
Conscious is when you are aware of something, and conscience is  when
you wish you weren't.

More information about the U-Boot mailing list