After face to face meeting at Linaro Connect YVR18, the decision was made to keep variable services very simple. Either fully provide SetVariable/GetVariable during runtime services, or don't provide them at all.
This is an RFC patch. In the process of writing it, and after looking at the ECR submitted by Peter Jones[1], I started having doubts. I no longer think this is the right decision. Since the ECR now provides a mechanism for reporting which runtime services can be called, it should be just fine to provide GetVariable() even if SetVariable() returns EFI_UNSUPPORTED. There is a note added to the document to this effect. I will remove the note after committing the final version of the patch, and depending on mailing list discussion. [1] https://pjones.fedorapeople.org/rt-unsupported-ecr-0.txt Resolves: #22 Signed-off-by: Grant Likely <grant.lik...@secretlab.ca> Cc: Peter Jones <pjo...@redhat.com> --- source/chapter2-uefi.rst | 113 ++++++++++++++++++++++++----------------------- 1 file changed, 58 insertions(+), 55 deletions(-) diff --git a/source/chapter2-uefi.rst b/source/chapter2-uefi.rst index cbf1529..72b3d59 100644 --- a/source/chapter2-uefi.rst +++ b/source/chapter2-uefi.rst @@ -197,66 +197,69 @@ unless a specific reset is required after a call to UpdateCapsule(). Runtime Variable Access ----------------------- -.. todo:: - - There are many platforms where it is difficult to support SetVariable() for - non-volatile variables because the firmware cannot access storage after - ExitBootServices() is called. - e.g., If firmware accesses an eMMC device directly at runtime, it will - collide with transactions initiated by the OS. - Neither U-Boot nor Tianocore have a solution for accessing shared media for - variable updates. [#OPTEESupplicant]_ - - In these platforms SetVariable() calls with the EFI_VARIABLE_NON_VOLATILE - attribute set will work in boot services, but will fail in runtime services. - The [UEFI]_ specification doesn't address what to do in this situation. - We need feedback on options before writing this section of EBBR, or making a - proposal to modify UEFI. - - We need a solution that communicates to the OS that non-volatile variable - updates are not supported at runtime, and that defines the behaviour when - SetVariable() is called with the EFI_VARIABLE_NON_VOLATILE attribute. - - Presumably, the solution will require SetVariable() to return - EFI_INVALID_PARAMETER if called with the EFI_VARIABLE_NON_VOLATILE - attribute, but beyond that there are a number of options: - - #. Clear EFI_VARIABLE_NON_VOLATILE from all variables at ExitBootServices() - - If the platform is incapable of updating non-volatile variables from Runtime - Services then it must clear the EFI_VARIABLE_NON_VOLATILE attribute from all - non-volatile variables when ExitBootServices() is called. - - An OS can discover that non-volatile variables cannot be updated at - runtime by noticing that the NON_VOLATILE attribute is not set. - - #. Clear all variables at ExitBootServices() - - If the platform is incapable of updating non-volatile variables from Runtime - Services then it will clear all variables and return EFI_INVALID_PARAMETER - on all calls to SetVariable(). - - SUSE in particular currently uses this behaviour to decide whether or not - to treat the ESP as removable media. - - #. Advertise that SetVariable() doesn't work at runtime with another variable - - Platforms can check another variable to determine if they have this quirk, - perhaps by adding a new BootOptionSupport flag. - - This is not a complete list, and other options can still be proposed. We're - looking for feedback on what would be most faithful to the UEFI spec, and - would work for the OS distributions before filling out this section of the - specification. - - Comments can be sent to the boot-architecture@lists.linaro.org mailing list. +There are many platforms where it is difficult to implement SetVariable() for +non-volatile variables during runtime services because the firmware cannot +access storage after ExitBootServices() is called. + +e.g., If firmware accesses an eMMC device directly at runtime, it will +collide with transactions initiated by the OS. +Neither U-Boot nor Tianocore have a generic solution for accessing or updating +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. + +.. note:: I'm still not sold on this. Can we simply advertise that SetVariable() + doesn't work via the `RuntimeServicesSupported` variable? + RuntimeServicesSupported is a proposed ECR to the UEFI spec. + + If we say here that GetVariable() must be disabled if SetVariable() doesn't + work, then that precludes all the RT but !NV global varibles, including all + the secure boot variables. + It also potentially means distros will depend on the + "no SetVariable == no GetVariable" behaviour, meaning it will be difficult + re-enable GetVariable() without SetVariable(). + + Looking at section 3.3, the folloing EFI_GLOBAL_VARIABLEs are RT but not NV: + + - AuditMode BS, RT + - BootCurrent BS, RT + - BootOptionSupport BS,RT, + - ConInDev BS, RT + - ConOutDev BS, RT + - dbDefault BS, RT + - dbrDefault BS, RT + - dbtDefault BS, RT + - dbxDefault BS, RT + - DeployedMode BS, RT + - ErrOutDev BS, RT + - KEKDefault BS, RT + - LangCodes BS, RT + - OsIndicationsSupported BS, RT + - PKDefault BS, RT + - PlatformLangCodes BS, RT + - PlatformRecovery#### BS, RT + - SignatureSupport BS, RT + - SecureBoot BS, RT + - SetupMode BS, RT + - VendorKeys BS, RT + + In related news, I'm considering proposing a "SetVariable on Disk" analogous + to the current Capsule on Disk [UEFI]_ 8.5.5. + That would allow the OS to write a standard format variable update file to + the ESP that firmware can read, update, and clear at boot time. + However, this could also be implemented using an OS provided variable-update + UEFI application. .. [#OPTEESupplicant] It is worth noting that OP-TEE has a similar problem regarding secure storage. OP-TEE's chosen solution is to rely on an OS supplicant agent to perform storage operations on behalf of OP-TEE. The same solution may be applicable to solving the UEFI non-volatile - variable problem, but that approach is also not entirely UEFI compliant - because it requires additional OS support to work. + variable problem, but it requires additional OS support to work. https://github.com/OP-TEE/optee_os/blob/master/documentation/secure_storage.md -- 2.13.0 _______________________________________________ boot-architecture mailing list boot-architecture@lists.linaro.org https://lists.linaro.org/mailman/listinfo/boot-architecture
