Re: [Arm.ebbr-discuss] [RFC] uefi: Account for SetVariable() not working at runtime
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
> Cc: Alexander Graf
> Cc: Peter Robinson
> Signed-off-by: Grant Likely
> ---
>
> 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-disc...@arm.com
___
boot-architecture mailing list
boot-architecture@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/boot-architecture
Re: [Arm.ebbr-discuss] [RFC] uefi: Account for SetVariable() not working at runtime
On 12 July 2018 at 15:12, Mark Brown wrote: > On Thu, Jul 12, 2018 at 01:50:45PM +0100, Daniel Thompson wrote: > >> 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. > > Do any existing implementations change variables from non-volatile to > volatile? > The UEFI spec is explicit about which variables are volatile and which are not. Simply relaxing non-volatile to volatile in the general case doesn't seem like a useful approach to me. ___ boot-architecture mailing list boot-architecture@lists.linaro.org https://lists.linaro.org/mailman/listinfo/boot-architecture
RE: [Arm.ebbr-discuss] [RFC] uefi: Account for SetVariable() not working at runtime
My 2 cents
> -Original Message-
> From: arm.ebbr-discuss-boun...@arm.com [mailto:arm.ebbr-discuss-
> boun...@arm.com] On Behalf Of Grant Likely
> Sent: Thursday, July 12, 2018 4:11 PM
> To: boot-architecture@lists.linaro.org; arm.ebbr-disc...@arm.com
> Cc: n...@arm.com
> Subject: [Arm.ebbr-discuss] [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
> Cc: Alexander Graf
> Cc: Peter Robinson
> Signed-off-by: Grant Likely
> ---
>
> 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.
This is really good statement for specification.
I believe this will solve the problem of shared storage too.
> +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.
You meant EFI_VARIABLE_NON_VOLATILE is reset ?
Also I am not sure, if UEFI specs says return error EFI_INVALID_PARAMETER
if variable is volatile
Can we add statement for GetVariable too,
UEFI Specs says
" Variables that have runtime access but that are not nonvolatile are read-only
data variables once ExitBootServices() is performed."
So this means, firmware (edk2 or u-boot) needs to take care of this.
Simply caching variables in RAM could solve the purpose as SetVariable is not
allowed.
> --
> 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
RE: [Arm.ebbr-discuss] [RFC] uefi: Account for SetVariable() not working at runtime
Hi Ard > > Do any existing implementations change variables from non-volatile to > > volatile? > > > > The UEFI spec is explicit about which variables are volatile and which are > not. > Simply relaxing non-volatile to volatile in the general case doesn't seem > like a > useful approach to me. I believe at boot-time, UEFI specs will be followed for volatile and non-volatile variables. Having this in statement EBBR, will help those platform, which cannot expose non-volatile variables at runtime. Regards Udit ___ boot-architecture mailing list boot-architecture@lists.linaro.org https://lists.linaro.org/mailman/listinfo/boot-architecture
Re: [Arm.ebbr-discuss] [RFC] uefi: Account for SetVariable() not working at runtime
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. ___ boot-architecture mailing list boot-architecture@lists.linaro.org https://lists.linaro.org/mailman/listinfo/boot-architecture
Re: [Arm.ebbr-discuss] [RFC] uefi: Account for SetVariable() not working at runtime
On 12/07/2018 15:50, Mark Brown wrote: On Thu, Jul 12, 2018 at 02:19:49PM +, Udit Kumar wrote: Do any existing implementations change variables from non-volatile to volatile? The UEFI spec is explicit about which variables are volatile and which are not. Simply relaxing non-volatile to volatile in the general case doesn't seem like a useful approach to me. I believe at boot-time, UEFI specs will be followed for volatile and non-volatile variables. Having this in statement EBBR, will help those platform, which cannot expose non-volatile variables at runtime. If nothing currently does it the chances that anything will actually cope well seem minimal. Like Daniel said it seems more likely to break things - if the variables are defined as being non-volatile then the OS is unlikely to be checking at runtime if that's the case or not unless it's explicitly written to work with EBBR. If an error is generated because a non-volatile variable can't be set then that should at least fall into whatever error handling code is there to cover normal rutime failures which has some chance of doing something sensible. There is a hard break at least between when variables are used in boot services, and when they are used at runtime. For Linux, only the UEFI stub will read the variables at boot time (if at all) before calling exitBootServices(). By the time the kernel starts, runtime services are the only way to access variables. There is no caching of variables from the stub to the kernel as far as I can tell. As far as the kernel and userspace are concerned, all the variables will have only ever been volatile. g. ___ 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
RE: [Arm.ebbr-discuss] [RFC] uefi: Account for SetVariable() not working at runtime
Hi Mark > -Original Message- > From: Mark Brown [mailto:broo...@kernel.org] > Sent: Thursday, July 12, 2018 8:20 PM > To: Udit Kumar > Cc: Ard Biesheuvel ; Architecture Mailman List > ; nd ; arm.ebbr-discuss > > Subject: Re: [Arm.ebbr-discuss] [RFC] uefi: Account for SetVariable() not > working > at runtime > > On Thu, Jul 12, 2018 at 02:19:49PM +, Udit Kumar wrote: > > > > > Do any existing implementations change variables from non-volatile > > > > to volatile? > > > > The UEFI spec is explicit about which variables are volatile and which > > > are not. > > > Simply relaxing non-volatile to volatile in the general case doesn't > > > seem like a useful approach to me. > > > I believe at boot-time, UEFI specs will be followed for volatile and > > non-volatile > variables. > > Having this in statement EBBR, will help those platform, which cannot expose > non-volatile variables at runtime. > > If nothing currently does it the chances that anything will actually cope well > seem minimal. Like Daniel said it seems more likely to break things - if the > variables are defined as being non-volatile then the OS is unlikely to be > checking > at runtime if that's the case or not unless it's explicitly written to work > with > EBBR. If an error is generated because a non-volatile variable can't be set > then > that should at least fall into whatever error handling code is there to cover > normal rutime failures which has some chance of doing something sensible. Right, There will be some breaks or say diversion from UEFI specs. If we need to follow UEFI specs 'Table 10. Global Variables' on such platform where we cannot write to NV storage at runtime, then in either case 1/ passing OS as no-efi-runtime or 2/ Returning errors/not saving to NV storage is violation of UEFI spec. Which divergence is acceptable ? Regards Udit ___ boot-architecture mailing list boot-architecture@lists.linaro.org https://lists.linaro.org/mailman/listinfo/boot-architecture
Re: [Arm.ebbr-discuss] [RFC] uefi: Account for SetVariable() not working at runtime
On Thu, 12 Jul 2018 at 16:30, Udit Kumar wrote: > > Hi Mark > > > -Original Message- > > From: Mark Brown [mailto:broo...@kernel.org] > > Sent: Thursday, July 12, 2018 8:20 PM > > To: Udit Kumar > > Cc: Ard Biesheuvel ; Architecture Mailman List > > ; nd ; arm.ebbr-discuss > > > > Subject: Re: [Arm.ebbr-discuss] [RFC] uefi: Account for SetVariable() not > > working > > at runtime > > > > On Thu, Jul 12, 2018 at 02:19:49PM +, Udit Kumar wrote: > > > > > > > Do any existing implementations change variables from non-volatile > > > > > to volatile? > > > > > > The UEFI spec is explicit about which variables are volatile and which > > > > are not. > > > > Simply relaxing non-volatile to volatile in the general case doesn't > > > > seem like a useful approach to me. > > > > > I believe at boot-time, UEFI specs will be followed for volatile and > > > non-volatile > > variables. > > > Having this in statement EBBR, will help those platform, which cannot > > > expose > > non-volatile variables at runtime. > > > > If nothing currently does it the chances that anything will actually cope > > well > > seem minimal. Like Daniel said it seems more likely to break things - if > > the > > variables are defined as being non-volatile then the OS is unlikely to be > > checking > > at runtime if that's the case or not unless it's explicitly written to work > > with > > EBBR. If an error is generated because a non-volatile variable can't be > > set then > > that should at least fall into whatever error handling code is there to > > cover > > normal rutime failures which has some chance of doing something sensible. > > Right, > There will be some breaks or say diversion from UEFI specs. > If we need to follow UEFI specs 'Table 10. Global Variables' on such platform > where we cannot write to NV storage at runtime, then in either case > 1/ passing OS as no-efi-runtime or > 2/ Returning errors/not saving to NV storage > is violation of UEFI spec. > > Which divergence is acceptable ? > Neither, fix the specs with proper updates to support your use-case. Or fix your platform to obey the specs you have chosen. Don't write a spec to bend another spec that way leads to chaos. Graeme ___ boot-architecture mailing list boot-architecture@lists.linaro.org https://lists.linaro.org/mailman/listinfo/boot-architecture
Re: [Arm.ebbr-discuss] [RFC] uefi: Account for SetVariable() not working at runtime
On Thu, Jul 12, 2018 at 9:37 AM Graeme Gregory wrote: > > On Thu, 12 Jul 2018 at 16:30, Udit Kumar wrote: > > > > Hi Mark > > > > > -Original Message- > > > From: Mark Brown [mailto:broo...@kernel.org] > > > Sent: Thursday, July 12, 2018 8:20 PM > > > To: Udit Kumar > > > Cc: Ard Biesheuvel ; Architecture Mailman List > > > ; nd ; arm.ebbr-discuss > > > > > > Subject: Re: [Arm.ebbr-discuss] [RFC] uefi: Account for SetVariable() not > > > working > > > at runtime > > > > > > On Thu, Jul 12, 2018 at 02:19:49PM +, Udit Kumar wrote: > > > > > > > > > Do any existing implementations change variables from non-volatile > > > > > > to volatile? > > > > > > > > The UEFI spec is explicit about which variables are volatile and > > > > > which are not. > > > > > Simply relaxing non-volatile to volatile in the general case doesn't > > > > > seem like a useful approach to me. > > > > > > > I believe at boot-time, UEFI specs will be followed for volatile and > > > > non-volatile > > > variables. > > > > Having this in statement EBBR, will help those platform, which cannot > > > > expose > > > non-volatile variables at runtime. > > > > > > If nothing currently does it the chances that anything will actually cope > > > well > > > seem minimal. Like Daniel said it seems more likely to break things - if > > > the > > > variables are defined as being non-volatile then the OS is unlikely to be > > > checking > > > at runtime if that's the case or not unless it's explicitly written to > > > work with > > > EBBR. If an error is generated because a non-volatile variable can't be > > > set then > > > that should at least fall into whatever error handling code is there to > > > cover > > > normal rutime failures which has some chance of doing something sensible. > > > > Right, > > There will be some breaks or say diversion from UEFI specs. > > If we need to follow UEFI specs 'Table 10. Global Variables' on such > > platform > > where we cannot write to NV storage at runtime, then in either case > > 1/ passing OS as no-efi-runtime or > > 2/ Returning errors/not saving to NV storage > > is violation of UEFI spec. > > > > Which divergence is acceptable ? > > > Neither, fix the specs with proper updates to support your use-case. > > Or fix your platform to obey the specs you have chosen. How do you add firmware storage to existing platforms? > Don't write a spec to bend another spec that way leads to chaos. Well, EBBR is such a spec. The chaos is already there and EBBR attempts to apply some amount of order to the chaos. Rob ___ boot-architecture mailing list boot-architecture@lists.linaro.org https://lists.linaro.org/mailman/listinfo/boot-architecture
Re: [Arm.ebbr-discuss] [RFC] uefi: Account for SetVariable() not working at runtime
On Thu, 12 Jul 2018 at 16:50, Rob Herring wrote: > > On Thu, Jul 12, 2018 at 9:37 AM Graeme Gregory > wrote: > > > > On Thu, 12 Jul 2018 at 16:30, Udit Kumar wrote: > > > > > > Hi Mark > > > > > > > -Original Message- > > > > From: Mark Brown [mailto:broo...@kernel.org] > > > > Sent: Thursday, July 12, 2018 8:20 PM > > > > To: Udit Kumar > > > > Cc: Ard Biesheuvel ; Architecture Mailman > > > > List > > > > ; nd ; > > > > arm.ebbr-discuss > > > > > > > > Subject: Re: [Arm.ebbr-discuss] [RFC] uefi: Account for SetVariable() > > > > not working > > > > at runtime > > > > > > > > On Thu, Jul 12, 2018 at 02:19:49PM +, Udit Kumar wrote: > > > > > > > > > > > Do any existing implementations change variables from non-volatile > > > > > > > to volatile? > > > > > > > > > > The UEFI spec is explicit about which variables are volatile and > > > > > > which are not. > > > > > > Simply relaxing non-volatile to volatile in the general case doesn't > > > > > > seem like a useful approach to me. > > > > > > > > > I believe at boot-time, UEFI specs will be followed for volatile and > > > > > non-volatile > > > > variables. > > > > > Having this in statement EBBR, will help those platform, which cannot > > > > > expose > > > > non-volatile variables at runtime. > > > > > > > > If nothing currently does it the chances that anything will actually > > > > cope well > > > > seem minimal. Like Daniel said it seems more likely to break things - > > > > if the > > > > variables are defined as being non-volatile then the OS is unlikely to > > > > be checking > > > > at runtime if that's the case or not unless it's explicitly written to > > > > work with > > > > EBBR. If an error is generated because a non-volatile variable can't > > > > be set then > > > > that should at least fall into whatever error handling code is there to > > > > cover > > > > normal rutime failures which has some chance of doing something > > > > sensible. > > > > > > Right, > > > There will be some breaks or say diversion from UEFI specs. > > > If we need to follow UEFI specs 'Table 10. Global Variables' on such > > > platform > > > where we cannot write to NV storage at runtime, then in either case > > > 1/ passing OS as no-efi-runtime or > > > 2/ Returning errors/not saving to NV storage > > > is violation of UEFI spec. > > > > > > Which divergence is acceptable ? > > > > > Neither, fix the specs with proper updates to support your use-case. > > > > Or fix your platform to obey the specs you have chosen. > > How do you add firmware storage to existing platforms? > Why can't UEFI spec be updated to handle such reduced functionality platforms if this is important? Its not like appropriate people are unknown to Linaro. Graeme ___ boot-architecture mailing list boot-architecture@lists.linaro.org https://lists.linaro.org/mailman/listinfo/boot-architecture
Re: [Arm.ebbr-discuss] [RFC] uefi: Account for SetVariable() not working at runtime
On 12/07/2018 16:56, Graeme Gregory wrote: On Thu, 12 Jul 2018 at 16:50, Rob Herring wrote: On Thu, Jul 12, 2018 at 9:37 AM Graeme Gregory wrote: On Thu, 12 Jul 2018 at 16:30, Udit Kumar wrote: Hi Mark -Original Message- From: Mark Brown [mailto:broo...@kernel.org] Sent: Thursday, July 12, 2018 8:20 PM To: Udit Kumar Cc: Ard Biesheuvel ; Architecture Mailman List ; nd ; arm.ebbr-discuss Subject: Re: [Arm.ebbr-discuss] [RFC] uefi: Account for SetVariable() not working at runtime On Thu, Jul 12, 2018 at 02:19:49PM +, Udit Kumar wrote: Do any existing implementations change variables from non-volatile to volatile? The UEFI spec is explicit about which variables are volatile and which are not. Simply relaxing non-volatile to volatile in the general case doesn't seem like a useful approach to me. I believe at boot-time, UEFI specs will be followed for volatile and non-volatile variables. Having this in statement EBBR, will help those platform, which cannot expose non-volatile variables at runtime. If nothing currently does it the chances that anything will actually cope well seem minimal. Like Daniel said it seems more likely to break things - if the variables are defined as being non-volatile then the OS is unlikely to be checking at runtime if that's the case or not unless it's explicitly written to work with EBBR. If an error is generated because a non-volatile variable can't be set then that should at least fall into whatever error handling code is there to cover normal rutime failures which has some chance of doing something sensible. Right, There will be some breaks or say diversion from UEFI specs. If we need to follow UEFI specs 'Table 10. Global Variables' on such platform where we cannot write to NV storage at runtime, then in either case 1/ passing OS as no-efi-runtime or 2/ Returning errors/not saving to NV storage is violation of UEFI spec. Which divergence is acceptable ? Neither, fix the specs with proper updates to support your use-case. Or fix your platform to obey the specs you have chosen. How do you add firmware storage to existing platforms? Why can't UEFI spec be updated to handle such reduced functionality platforms if this is important? Its not like appropriate people are unknown to Linaro. That is exactly what we discussed in the meeting today. Right now UEFI 2.7 doesn't cover the use case we care about. Resolution was to put a note into EBBR v0.6 stating that this is a problem and asking for feedback on preferred solution. The end result will either be a clarification in UEFI, or a note in EBBR. We will coordinate with the USWG on this issue. g. ___ boot-architecture mailing list boot-architecture@lists.linaro.org https://lists.linaro.org/mailman/listinfo/boot-architecture
RE: [Arm.ebbr-discuss] [RFC] uefi: Account for SetVariable() not working at runtime
Agree, that's what we will do. - DW - -Original Message- From: arm.ebbr-discuss-boun...@arm.com On Behalf Of Graeme Gregory Sent: Thursday, July 12, 2018 8:37 AM To: udit.ku...@nxp.com Cc: nd ; boot-architecture@lists.linaro.org; Mark Brown ; arm.ebbr-discuss Subject: Re: [Arm.ebbr-discuss] [RFC] uefi: Account for SetVariable() not working at runtime On Thu, 12 Jul 2018 at 16:30, Udit Kumar wrote: > > Hi Mark > > > -Original Message- > > From: Mark Brown [mailto:broo...@kernel.org] > > Sent: Thursday, July 12, 2018 8:20 PM > > To: Udit Kumar > > Cc: Ard Biesheuvel ; Architecture Mailman > > List ; nd ; > > arm.ebbr-discuss > > Subject: Re: [Arm.ebbr-discuss] [RFC] uefi: Account for > > SetVariable() not working at runtime > > > > On Thu, Jul 12, 2018 at 02:19:49PM +, Udit Kumar wrote: > > > > > > > Do any existing implementations change variables from > > > > > non-volatile to volatile? > > > > > > The UEFI spec is explicit about which variables are volatile and which > > > > are not. > > > > Simply relaxing non-volatile to volatile in the general case > > > > doesn't seem like a useful approach to me. > > > > > I believe at boot-time, UEFI specs will be followed for volatile > > > and non-volatile > > variables. > > > Having this in statement EBBR, will help those platform, which > > > cannot expose > > non-volatile variables at runtime. > > > > If nothing currently does it the chances that anything will actually > > cope well seem minimal. Like Daniel said it seems more likely to > > break things - if the variables are defined as being non-volatile > > then the OS is unlikely to be checking at runtime if that's the case > > or not unless it's explicitly written to work with EBBR. If an > > error is generated because a non-volatile variable can't be set then > > that should at least fall into whatever error handling code is there to > > cover normal rutime failures which has some chance of doing something > > sensible. > > Right, > There will be some breaks or say diversion from UEFI specs. > If we need to follow UEFI specs 'Table 10. Global Variables' on such > platform where we cannot write to NV storage at runtime, then in > either case 1/ passing OS as no-efi-runtime or 2/ Returning errors/not > saving to NV storage is violation of UEFI spec. > > Which divergence is acceptable ? > Neither, fix the specs with proper updates to support your use-case. Or fix your platform to obey the specs you have chosen. Don't write a spec to bend another spec that way leads to chaos. Graeme ___ Arm.ebbr-discuss mailing list arm.ebbr-disc...@arm.com 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. ___ boot-architecture mailing list boot-architecture@lists.linaro.org https://lists.linaro.org/mailman/listinfo/boot-architecture
