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

[Wolfgang Denk]

Dear Ilias,

In message <CAC_iWjLqouCEb=kcpomhHwDiM9Cdb_mOQDMTUAZ0G_dP9SuDxg at mail.gmail.com> you wrote:
>
> > 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.

Do you think this will work?  When people who don;t know about
U-Boot features and limitations try to come up with a solution it
may simply not fit.

And the problem is a generic one: if you want to use secure boot
with signed images (including the environment), you must make sure
the device cannot be used to create new valid signed images, i. e.
you must keep your private key strictly protectd and definitely not
on the device.  But then - how do you sign a new environment copy?

> 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".

Ok - but the patches that have been submitted modify (heavily) the
U-Boot environment code.

So I see two options: a) we emulate UEFI variables using the
existing U-Boot environment code to the extend possible; in this
case I would prefer my proposal over the patches that have been
submitted. Or b) UEFI data is handled completely separately, within
it's own code base; in that case the patches should be ignored.

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

Thanks - that would be case a).

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

That would be b) - in this case UEFI has to provide it's own code
base, and no UEFI specific patches should impact the U-Boot
environment handling.

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

I think so - if my a) / b) separation above matches your
understanding.

Thanks.

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
NOTE: The  Most  Fundamental  Particles  in  This  Product  Are  Held
Together  by  a  "Gluing" Force About Which Little is Currently Known
and Whose Adhesive Power Can Therefore Not Be Permanently Guaranteed.