On Tue, May 12, 2020 at 06:15:26PM +0100, Grant Likely wrote: > [...]
> > > For the other variable services the patch series provides a compliant > > solution. > > > > Ilias Apalodimas has a draft patch series for using OP-TEE and MM for > > managing variables. But storage in the RPMB partition of an eMMC device > > would only work at boottime. Just what you described at last years > > Embedded Linux conference (https://www.youtube.com/watch?v=VnsF3uRZzNk). > > There are paths for making it work. Could use the OP-Tee supplicant to get > Linux to do the RPMB writes. Both Get/Setvariable return EFI_UNSUPPORTED for now in my patchset. As you suggest this is probably fixable, but we'll have to take into account what happens if someone requests a variable and the supplicant is not up yet. A cached copy would solve that for GetVariable. The writes, if we have any during boot (do we?), are going to be a problem though since the spec says: "The only rules the firmware must implement when saving a nonvolatile variable is that it has actually been saved to nonvolatile storage before returning EFI_SUCCESS". I'll have a closer look once I manage to merge all the required patches. > Alternately, could store the variable updates > in SRAM and require a warm reboot of the normal world to persist changes. > > > Takahiro Akashi last year presented alternative patches that would > > enable reading variables at runtime. He recently suggested to use > > capsule updates to update variables and has submitted patches for > > capsule updates > > (https://patchwork.ozlabs.org/project/uboot/list/?series=172907). > > > > If we do not have SetVariable() at runtime, I do not see much value in > > QueryVariableInfo(). So we shouldn't make that service compulsory. > > Agreed > > Okay, I'm leaning toward making GetVariable()/GetNextVariableName() at some > point in the future, but leaving SetVariable()/QueryVariableInfo() optional. > However, I won't do anything in this direction for the point release later > this month. I'll just clean up the text to be a bit clearer. > > g. Regards /Ilias _______________________________________________ boot-architecture mailing list [email protected] https://lists.linaro.org/mailman/listinfo/boot-architecture
