Re: [U-Boot] U-Boot Digest, Vol 133, Issue 57
From: Wolfgang Denk wd@denx.de To: AKASHI Takahiro takahiro.akashi@linaro.org Cc: Heinrich Schuchardt xypron.glpk@gmx.de, Alexander Graf agraf@csgraf.de, sughosh.ganu@arm.com, U-Boot Mailing List u-boot@lists.denx.de Bcc: Date: Tue, 25 Jun 2019 08:33:30 +0200 Subject: Re: [U-Boot] efi_loader: implementing non-volatile UEFI variables Dear Takahiro,
In message 20190625011039.GO6610@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...
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.
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.
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". 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.
That said, enhancing the u-boot variable concept with persistent attribute is most certainly a good idea, independently from UEFI variables. And it may be a good idea to leverage that facility to implement "simple" persistence from the UEFI world.
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@denx.de There are no data that cannot be plotted on a straight line if the axis are chosen correctly.
U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Dear Francois,
it would have been _very_ helpful to keep the Subject: and the Cc: list in place.
In message CAHFG_=Vhn3YtyxOZQSMbG52Gp5wkfiAx1VguGC6XwishLN_zHg@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
participants (2)
-
Francois Ozog -
Wolfgang Denk