+Poonam Aggrwal <[email protected]> On Thu, 19 Mar 2020 at 17:42, Heinrich Schuchardt <[email protected]> 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/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. > > -- François-Frédéric Ozog | *Director Linaro Edge & Fog Computing Group* T: +33.67221.6485 [email protected] | Skype: ffozog _______________________________________________ boot-architecture mailing list [email protected] https://lists.linaro.org/mailman/listinfo/boot-architecture
