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