On 12/07/2018 14:12, Mark Brown wrote:

On Thu, Jul 12, 2018 at 01:50:45PM +0100, Daniel Thompson wrote:

...

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?

I took a read through section 8.2 of the UEFI spec (Variable services) before drafting the proposal.

UEFI doesn't define a "read-only" attribute for variables. It has a non-volatile attribute that says a variable change will be persistant. My thought here was that clearing the non-volatile flag will indicate that making a change to that variable will not be saved, and so won't change the boot order.

If an OS tries to modify a variable without using the exact same attributes, then SetVariable() will fail. e.g., If the OS tries to set EFI_VARIABLE_NON_VOLATILE on a veriable without that attribute, then it will fail with EFI_INVALID_PARAMETER (See description of SetVariable()).

With my proposed text, if the OS tries to set a new variable with the EFI_VARIABLE_NON_VOLATILE attribute set, then SetVariable() will also fail. (At runtime only; boot time SetVariable() should work as defined).

An OS can determine in two ways if variable writes are allowed. 1) If the BOOT* varilables don't have the NON_VOLATILE attribute. 2) A EFI_INVALID_PARAMETER return code when attempting to create an non-volatile variable, or set the NON_VOLATILE attribute.

...

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.

If it tried to, the call to SetVariable() will fail.

Do any existing implementations change variables from non-volatile to volatile?

I don't know. That's part of why this is an RFC. I'm looking for the most spec-compatible way to deal with platforms that cannot set non-volatile variables at runtime. The UEFI spec is written with the assumption that non-volatile variables can be written at runtime. EBBR encompases platforms that cannot (yet?) do that, so we're in new territory.

There are other approaches that could be taken too. - Alex said a while back that if UEFI doesn't provide any variables at runtime, then it assumes non-volatile variables aren't available and will treat the ESP as if it were removable media. - The problem with this approach is it is a very blunt hammer. It eliminates all possible users of variables at runtime.

- We could add an EBBR_FLAGS variable or something similar to indicate EBBR style quirks, like non-volatile variables cannot be written at runtime.

Let's talk about this in the weekly meeting later today.

g.