Instead of masking out GetVariable() when SetVariable() isn't available during runtime services, simplify the requirements without losing the ability to read variables by using the RuntimeServicesSupported variable from UEFI v2.8.1 (unreleased); Mantis issue 1961.
Peter Jones's earlier patch also specified a Capsule-on-Disk format for updating variables that the OS could store in the ESP. I've not included that specification in this patch as it is logically a separate feature. It may reappear in a separate patch at a later date, or it may get proposed for inclusion in the UEFI spec proper.
Signed-off-by: Grant Likely grant.likely@arm.com Cc: Peter Jones pjones@redhat.com --- source/chapter2-uefi.rst | 17 ++++++++++------- 1 file changed, 10 insertions(+), 7 deletions(-)
diff --git a/source/chapter2-uefi.rst b/source/chapter2-uefi.rst index 379f0ca..4f74d43 100644 --- a/source/chapter2-uefi.rst +++ b/source/chapter2-uefi.rst @@ -201,14 +201,15 @@ variables stored on shared media. [#OPTEESupplicant]_
If a platform does not implement modifying non-volatile variables with SetVariable() after ExitBootServices(), -then it must not provide any variable operations after ExitBootServices(). -Firmware shall return EFI_UNSUPPORTED for any call to GetVariable(), -GetNextVariableName() and SetVariable(). -Firmware shall not emulated non-volatile variables using volatile RAM cache. +then firmware shall return EFI_UNSUPPORTED for any call to SetVariable(), +and must advertise that SetVariable() isn't available during runtime services +via the "RuntimeServicesSupported" variable as defined in UEFI version 2.8.1. +EFI applications can read RuntimeServicesSupported to determine if calls +to SetVariable() need to be performed before calling ExitBootServices().
-.. note:: The behaviour when SetVariable() is not supported during runtime - services is still under discussion and subject to change. - Do not make any firmware implementation decisions based on this text yet. +Even when SetVariable() is not supported during runtime services, firmware +should cache variable names and values in EfiRuntimeServicesData memory so +that GetVariable() and GetNextVeriableName() can behave as specified.
.. [#OPTEESupplicant] It is worth noting that OP-TEE has a similar problem regarding secure storage. @@ -216,5 +217,7 @@ Firmware shall not emulated non-volatile variables using volatile RAM cache. storage operations on behalf of OP-TEE. The same solution may be applicable to solving the UEFI non-volatile variable problem, but it requires additional OS support to work. + Regardless, EBBR compliance does not require SetVariable() support + during runtime services.
https://github.com/OP-TEE/optee_os/blob/master/documentation/secure_storage....