+Poonam Aggrwal poonam.aggrwal@nxp.com
On Thu, 19 Mar 2020 at 17:42, Heinrich Schuchardt xypron.glpk@gmx.de wrote:
On 3/19/20 1:21 PM, Grant Likely wrote:
On 19/03/2020 12:03, Heinrich Schuchardt wrote:
On 3/19/20 12:31 PM, François Ozog wrote:
I haven't followed the technical discussion. following is the original intent behind the changes requested for variable handling:
- runtime services are not the best things and even EDK2 are probably
moving away from this (Grant told us that at a design sprint a year
ago)
Operating systems like Windows rely on setting Boot* variables. Do you plan to break them?
If Windows is the goal, then SBSA/SBBR/ServerReady is the interface. I don't think it is valuable to touch this use case with EBBR. Rather, the primary use case for EBBR is embedded and community Linux distros on embedded devices. Boot* variables are important, but hard to set at runtime; therefore the question is "is setting Boot* variables only at boot time suitable for EBBR use cases?"
Windows IoT Core is addressing the same class of boards as EBBR and relies on UEFI:
https://docs.microsoft.com/en-us/windows/iot-core/tutorials/quickstarter/Pro...
https://docs.microsoft.com/en-us/windows/iot-core/commercialize-your-device/...
Best regards
Heinrich
(U-Boot could theoretically implement full SBBR on some platforms, but that is different than what the EBBR requirements are)
- "system administrator" is not the trusted party that has authority to
change a variable, a "platform administrator" has the authority and is the signing party of variable updates.
Not all variables are signed. Especially Boot* variables are managed by users with access to efibootmgr.
- UEFI variables interface for tools/kernel must not change: get/set
variable
- implementation of getVariable accesses a copy/shadow version of the
UEFI variable
- implementation of setVariable actually generates an update capsule so
that the variable update is seen at next reboot
The discussion as far as I understood it centered on the question how a firmware that has no access to persistent memory at runtime can handle non-volatile variable updates.
A capsule is only a possible encoding of information but does not answer the question in which medium the information from before the reboot shall be conveyed to after the reboot.
Putting the information into RAM and hoping it survives a reboot is feasible but will not work during a system shutdown. Letting the operating system write the information to disk seems to be the easiest thing to do.
Indeed, this debate always cycles back to this point. How does firmware reliably persist a SetVariable() operation when it doesn't control the storage, and the OS might not have a suitable storage proxy
g.