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-boun...@arm.com <arm.ebbr-discuss- > boun...@arm.com> On Behalf Of Grant Likely > Sent: Monday, September 24, 2018 7:24 PM > To: boot-architecture@lists.linaro.org; arm.ebbr-disc...@arm.com > Cc: Grant Likely <grant.lik...@secretlab.ca>; Peter Jones > <pjo...@redhat.com>; n...@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.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://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-disc...@arm.com _______________________________________________ boot-architecture mailing list boot-architecture@lists.linaro.org https://lists.linaro.org/mailman/listinfo/boot-architecture
