Hi Mark
-----Original Message----- From: Mark Brown [mailto:broonie@kernel.org] Sent: Thursday, July 12, 2018 8:20 PM To: Udit Kumar udit.kumar@nxp.com Cc: Ard Biesheuvel ard.biesheuvel@linaro.org; Architecture Mailman List boot-architecture@lists.linaro.org; nd nd@arm.com; arm.ebbr-discuss arm.ebbr-discuss@arm.com Subject: Re: [Arm.ebbr-discuss] [RFC] uefi: Account for SetVariable() not working at runtime
On Thu, Jul 12, 2018 at 02:19:49PM +0000, 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
On Thu, 12 Jul 2018 at 16:30, Udit Kumar udit.kumar@nxp.com wrote:
Hi Mark
-----Original Message----- From: Mark Brown [mailto:broonie@kernel.org] Sent: Thursday, July 12, 2018 8:20 PM To: Udit Kumar udit.kumar@nxp.com Cc: Ard Biesheuvel ard.biesheuvel@linaro.org; Architecture Mailman List boot-architecture@lists.linaro.org; nd nd@arm.com; arm.ebbr-discuss arm.ebbr-discuss@arm.com Subject: Re: [Arm.ebbr-discuss] [RFC] uefi: Account for SetVariable() not working at runtime
On Thu, Jul 12, 2018 at 02:19:49PM +0000, 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
On Thu, Jul 12, 2018 at 9:37 AM Graeme Gregory graeme.gregory@linaro.org wrote:
On Thu, 12 Jul 2018 at 16:30, Udit Kumar udit.kumar@nxp.com wrote:
Hi Mark
-----Original Message----- From: Mark Brown [mailto:broonie@kernel.org] Sent: Thursday, July 12, 2018 8:20 PM To: Udit Kumar udit.kumar@nxp.com Cc: Ard Biesheuvel ard.biesheuvel@linaro.org; Architecture Mailman List boot-architecture@lists.linaro.org; nd nd@arm.com; arm.ebbr-discuss arm.ebbr-discuss@arm.com Subject: Re: [Arm.ebbr-discuss] [RFC] uefi: Account for SetVariable() not working at runtime
On Thu, Jul 12, 2018 at 02:19:49PM +0000, 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
On Thu, 12 Jul 2018 at 16:50, Rob Herring robherring2@gmail.com wrote:
On Thu, Jul 12, 2018 at 9:37 AM Graeme Gregory graeme.gregory@linaro.org wrote:
On Thu, 12 Jul 2018 at 16:30, Udit Kumar udit.kumar@nxp.com wrote:
Hi Mark
-----Original Message----- From: Mark Brown [mailto:broonie@kernel.org] Sent: Thursday, July 12, 2018 8:20 PM To: Udit Kumar udit.kumar@nxp.com Cc: Ard Biesheuvel ard.biesheuvel@linaro.org; Architecture Mailman List boot-architecture@lists.linaro.org; nd nd@arm.com; arm.ebbr-discuss arm.ebbr-discuss@arm.com Subject: Re: [Arm.ebbr-discuss] [RFC] uefi: Account for SetVariable() not working at runtime
On Thu, Jul 12, 2018 at 02:19:49PM +0000, 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
On 12/07/2018 16:56, Graeme Gregory wrote:
On Thu, 12 Jul 2018 at 16:50, Rob Herring robherring2@gmail.com wrote:
On Thu, Jul 12, 2018 at 9:37 AM Graeme Gregory graeme.gregory@linaro.org wrote:
On Thu, 12 Jul 2018 at 16:30, Udit Kumar udit.kumar@nxp.com wrote:
Hi Mark
-----Original Message----- From: Mark Brown [mailto:broonie@kernel.org] Sent: Thursday, July 12, 2018 8:20 PM To: Udit Kumar udit.kumar@nxp.com Cc: Ard Biesheuvel ard.biesheuvel@linaro.org; Architecture Mailman List boot-architecture@lists.linaro.org; nd nd@arm.com; arm.ebbr-discuss arm.ebbr-discuss@arm.com Subject: Re: [Arm.ebbr-discuss] [RFC] uefi: Account for SetVariable() not working at runtime
On Thu, Jul 12, 2018 at 02:19:49PM +0000, 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.
Agree, that's what we will do.
- DW - -----Original Message----- From: arm.ebbr-discuss-bounces@arm.com arm.ebbr-discuss-bounces@arm.com On Behalf Of Graeme Gregory Sent: Thursday, July 12, 2018 8:37 AM To: udit.kumar@nxp.com Cc: nd nd@arm.com; boot-architecture@lists.linaro.org; Mark Brown broonie@kernel.org; arm.ebbr-discuss arm.ebbr-discuss@arm.com Subject: Re: [Arm.ebbr-discuss] [RFC] uefi: Account for SetVariable() not working at runtime
On Thu, 12 Jul 2018 at 16:30, Udit Kumar udit.kumar@nxp.com wrote:
Hi Mark
-----Original Message----- From: Mark Brown [mailto:broonie@kernel.org] Sent: Thursday, July 12, 2018 8:20 PM To: Udit Kumar udit.kumar@nxp.com Cc: Ard Biesheuvel ard.biesheuvel@linaro.org; Architecture Mailman List boot-architecture@lists.linaro.org; nd nd@arm.com; arm.ebbr-discuss arm.ebbr-discuss@arm.com Subject: Re: [Arm.ebbr-discuss] [RFC] uefi: Account for SetVariable() not working at runtime
On Thu, Jul 12, 2018 at 02:19:49PM +0000, 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-discuss@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@lists.linaro.org
-
Dong Wei -
Graeme Gregory -
Grant Likely -
Rob Herring -
Udit Kumar