On Thu, Jul 12, 2018 at 11:41:08AM +0100, Grant Likely wrote:

Add details on what to do if the platform is unable to set persistent variables in runtime services. The idea here is that the GetVariable() and SetVariable() APIs should continue to work, and the OS can obtain all the variable settings, but if it cannot be written then the NON_VOLATILE attribute is cleared so the OS knows that persistence is not available.

I'm really struggling to wrap my head around this one.

How does incorrectly describing a non-volatile but non-modifiable variable as volatile help the OS do the right thing?

The OS will discover the variable is non-modifiable when it tried to set it. Won't the current proposal mislead standards compliant use of GetVariable()? For example does it it makes standards compliant code *more* likely to call SetVariable() in order to fix up a variable that it thinks was incorrectly set with the NON_VOLATILE attribute.

Daniel.

Cc: Dong Wei dong.wei@arm.com Cc: Alexander Graf agraf@suse.de Cc: Peter Robinson pbrobinson@redhat.com Signed-off-by: Grant Likely grant.likely@arm.com

---

Alex/Peter: Does this approach work for you? I tried to come up with something that is faithful to the spec, gives the OS information that non-volatile variables aren't available, but still have the ability to query the boot environment.

Dong: Is this an appropriate way to use {Get,Set}Variable()?

Cheers, g.

---

source/chapter2-uefi.rst | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/source/chapter2-uefi.rst b/source/chapter2-uefi.rst index 7b6843e..57594bc 100644 --- a/source/chapter2-uefi.rst +++ b/source/chapter2-uefi.rst @@ -197,13 +197,13 @@ command: Operating Systems calls to reset the system will go via Runtime Services and not directly to PSCI.

-Set Variable

-Non-volatile UEFI variables must persist across reset, and emulated variables -in RAM are not permitted. -The UEFI Runtime Services must be able to update the variables directly without -the aid of the Operating System. +Runtime Variable Access +----------------------- -.. note:: This normally requires dedicated storage for UEFI variables that is

• not directly accessible from the Operating System.

+Non-volatile UEFI variables must persist across reset. +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. +Similarly, if non-volatile variables cannot be set from Runtime Services, then +SetVariable() must return EFI_INVALID_PARAMETER if the

+EFI_VARIABLE_NON_VOLATILE attribute is set.

2.13.0

---

Arm.ebbr-discuss mailing list Arm.ebbr-discuss@arm.com

Grant,

I think the variables are defined by the specs as either non-volatile or volatile. It should not be changing.

- DW - -----Original Message----- From: Grant Likely Sent: Thursday, July 12, 2018 3:41 AM To: boot-architecture@lists.linaro.org; arm.ebbr-discuss arm.ebbr-discuss@arm.com Cc: nd nd@arm.com; Grant Likely Grant.Likely@arm.com; Dong Wei Dong.Wei@arm.com; Alexander Graf agraf@suse.de; Peter Robinson pbrobinson@redhat.com Subject: [RFC] uefi: Account for SetVariable() not working at runtime

Add details on what to do if the platform is unable to set persistent variables in runtime services. The idea here is that the GetVariable() and SetVariable() APIs should continue to work, and the OS can obtain all the variable settings, but if it cannot be written then the NON_VOLATILE attribute is cleared so the OS knows that persistence is not available.

Cc: Dong Wei dong.wei@arm.com Cc: Alexander Graf agraf@suse.de Cc: Peter Robinson pbrobinson@redhat.com Signed-off-by: Grant Likely grant.likely@arm.com ---

Alex/Peter: Does this approach work for you? I tried to come up with something that is faithful to the spec, gives the OS information that non-volatile variables aren't available, but still have the ability to query the boot environment.

Dong: Is this an appropriate way to use {Get,Set}Variable()?

Cheers, g.

--- source/chapter2-uefi.rst | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/source/chapter2-uefi.rst b/source/chapter2-uefi.rst index 7b6843e..57594bc 100644 --- a/source/chapter2-uefi.rst +++ b/source/chapter2-uefi.rst @@ -197,13 +197,13 @@ command: Operating Systems calls to reset the system will go via Runtime Services and not directly to PSCI.

-Set Variable ------------- - -Non-volatile UEFI variables must persist across reset, and emulated variables -in RAM are not permitted. -The UEFI Runtime Services must be able to update the variables directly without -the aid of the Operating System. +Runtime Variable Access +-----------------------

-.. note:: This normally requires dedicated storage for UEFI variables that is - not directly accessible from the Operating System. +Non-volatile UEFI variables must persist across reset. +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. +Similarly, if non-volatile variables cannot be set from Runtime +Services, then +SetVariable() must return EFI_INVALID_PARAMETER if the +EFI_VARIABLE_NON_VOLATILE attribute is set. -- 2.13.0

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.