[U-Boot] efi_loader: implementing non-volatile UEFI variables -- was U-Boot Digest, Vol 133, Issue 57

Wolfgang Denk wd at denx.de
Wed Jun 26 08:42:50 UTC 2019


Dear Francois,

it would have been _very_ helpful to keep the Subject: and the Cc:
list in place.

In message <CAHFG_=Vhn3YtyxOZQSMbG52Gp5wkfiAx1VguGC6XwishLN_zHg at mail.gmail.com> you wrote:
>
> On one side we have UEFI have objects that can be persistent and/or
> secure. More importantly, a UEFI application can register a storage
> backend to perform
> UEFI variable persistence on specific hardware. This facility
> is used to manage persistent/secure variables in TrustZone.
> Verification of secure variables can also depend on application registered UEFI
> protocols: we would import the new security protocol, or the hardware
> accelerated protocol verification in the U-Boot UEFI environment
> rather than re-implement the U-Boot way.

I can understand yoiur argument, but I'm not happy about it.  Why
implement a UEFI only way, when it seems it would be possible to
have a slotion that is useful for others, too?  This is an
narrow-minded, sellfish approach and not commuinity-oriented.  And I
don;t think you can save any efforts that way.

> On the other side, U-Boot has a super lightweight variable system that
> is used to control boot sequence and hence variable performance has an
> impact on boot delay and jitter.

Ideed.

> Because the UEFI variables has additional dependencies on those other
> UEFI constructs (protocol registration for storage back end, crypto
> and signature stuff for secure variables) and its easier to allow code
> import from
> other UEFI implementations, I would tend to segregate
> u-boot variables from UEFI objects (I think the term object is more
> appropriate). In other words UEFI objects shall be say self-contained
> in the UEFI "subsystem".

Your decision, then.  But in this case the submitted pacches make no
sense either, and should be discarded.


> Combined with the performance goal, and code size (if we
> do not want the UEFI stuff), I have a second reason to keep them
> separate.

To be honest - fast boot times and UEFI have always been an
oxymoron to me.  What is the performance goal you mention?

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
Q: Why do PCs have a reset button on the front?
A: Because they are expected to run Microsoft operating systems.


More information about the U-Boot mailing list