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/PrototypeBoards https://docs.microsoft.com/en-us/windows/iot-core/commercialize-your-device/uefirequirements 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. _______________________________________________ boot-architecture mailing list [email protected] https://lists.linaro.org/mailman/listinfo/boot-architecture
