Hi Grant
+Firmware shall return EFI_UNSUPPORTED for any call to GetVariable(), +GetNextVariableName() and SetVariable(). +Firmware shall not emulated non-volatile variables using volatile RAM cache.
IMHO, on such platforms GetVariable service should be allowed, whereas SetVariable can return EFI_UNSUPPORTED. AFAIK, edk2 implementation, does the caching of variables into DDR for Get service.
Regards Udit
-----Original Message----- From: arm.ebbr-discuss-bounces@arm.com <arm.ebbr-discuss- bounces@arm.com> On Behalf Of Grant Likely Sent: Monday, September 24, 2018 7:24 PM To: boot-architecture@lists.linaro.org; arm.ebbr-discuss@arm.com Cc: Grant Likely grant.likely@secretlab.ca; Peter Jones pjones@redhat.com; nd@arm.com Subject: [Arm.ebbr-discuss] [PATCH 7/7] Don't provide SetVariable() if GetVariable() doesn't work
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://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpjon es.fedorapeople.org%2Frt-unsupported-ecr- 0.txt&data=02%7C01%7Cudit.kumar%40nxp.com%7Cacac5e6b0f1d49fc e7be08d62225c672%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7 C636733942994509938&sdata=f3PD0y%2FupTTY0zCM%2BBLU5kEsCwz 3pHFDaNqRUPcfQUY%3D&reserved=0
Resolves: #22 Signed-off-by: Grant Likely grant.likely@secretlab.ca Cc: Peter Jones pjones@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 fromRuntime
Services then it must clear the EFI_VARIABLE_NON_VOLATILE attributefrom all
non-volatile variables when ExitBootServices() is called.An OS can discover that non-volatile variables cannot be updated atruntime 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 fromRuntime
Services then it will clear all variables and returnEFI_INVALID_PARAMETER
on all calls to SetVariable().SUSE in particular currently uses this behaviour to decide whether or notto 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://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith ub.com%2FOP- TEE%2Foptee_os%2Fblob%2Fmaster%2Fdocumentation%2Fsecure_storage. md&data=02%7C01%7Cudit.kumar%40nxp.com%7Cacac5e6b0f1d49fce 7be08d62225c672%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C 636733942994509938&sdata=%2FOQD5NE8hy6sh9uTGMYtimvw2Jf4Y MLf0cDBurCgMcM%3D&reserved=0 -- 2.13.0
Arm.ebbr-discuss mailing list Arm.ebbr-discuss@arm.com