boot-architecture

boot-architecture@lists.linaro.org

4 participants
669 discussions

[PATCH] uefi: Add todo item on how to handle SetVariable()

by Grant Likely

We don't have agreement yet on what the behaviour should be if non-volatile variables cannot be updated or created at runtime. Add a paragraph discussing the factors involved and asking for feedback. Cc: Dong Wei <dong.wei(a)arm.com> Cc: Alexander Graf <agraf(a)suse.de> Cc: Peter Robinson <pbrobinson(a)redhat.com> Signed-off-by: Grant Likely <grant.likely(a)arm.com> --- source/chapter2-uefi.rst | 72 ++++++++++++++++++++++++++++++++++++++++++------ 1 file changed, 64 insertions(+), 8 deletions(-) diff --git a/source/chapter2-uefi.rst b/source/chapter2-uefi.rst index 7b6843e..10448fd 100644 --- a/source/chapter2-uefi.rst +++ b/source/chapter2-uefi.rst @@ -197,13 +197,69 @@ command: Operating Systems calls to reset the system will go via Runtime Services and not directly to PSCI. -Set Variable ------------- +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(a)lists.linaro.org mailing list. -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. +.. [#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. -.. note:: This normally requires dedicated storage for UEFI variables that is - not directly accessible from the Operating System. + https://github.com/OP-TEE/optee_os/blob/master/documentation/secure_storage… -- 2.13.0

7 years, 3 months

RE: [Arm.ebbr-discuss] [RFC] uefi: Account for SetVariable() not working at runtime

by Udit Kumar

Hi Mark > -----Original Message----- > From: Mark Brown [mailto:broonie@kernel.org] > Sent: Thursday, July 12, 2018 8:20 PM > To: Udit Kumar <udit.kumar(a)nxp.com> > Cc: Ard Biesheuvel <ard.biesheuvel(a)linaro.org>; Architecture Mailman List > <boot-architecture(a)lists.linaro.org>; nd <nd(a)arm.com>; arm.ebbr-discuss > <arm.ebbr-discuss(a)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

7 years, 3 months

Re: [Arm.ebbr-discuss] [RFC] uefi: Account for SetVariable() not working at runtime

by Grant Likely

On 12/07/2018 15:50, Mark Brown wrote: > 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. 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-discuss(a)arm.com >

7 years, 3 months

[RFC] uefi: Account for SetVariable() not working at runtime

by Grant Likely

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(a)arm.com> Cc: Alexander Graf <agraf(a)suse.de> Cc: Peter Robinson <pbrobinson(a)redhat.com> Signed-off-by: Grant Likely <grant.likely(a)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

7 years, 3 months

Re: [Arm.ebbr-discuss] [RFC] uefi: Account for SetVariable() not working at runtime

by Grant Likely

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.

7 years, 3 months

RE: [Arm.ebbr-discuss] [PATCH] Update manifesto from comments on mailing list

by Dong Wei

I like this better😊 - DW - -----Original Message----- From: arm.ebbr-discuss-bounces(a)arm.com <arm.ebbr-discuss-bounces(a)arm.com> On Behalf Of Mark Brown Sent: Thursday, July 12, 2018 3:18 AM To: Grant Likely <Grant.Likely(a)arm.com> Cc: boot-architecture(a)lists.linaro.org; arm.ebbr-discuss <arm.ebbr-discuss(a)arm.com>; nd <nd(a)arm.com> Subject: Re: [Arm.ebbr-discuss] [PATCH] Update manifesto from comments on mailing list On Wed, Jul 11, 2018 at 09:11:53PM +0100, Grant Likely wrote: > On 09/07/2018 13:39, Mark Brown wrote: > > On Mon, Jul 09, 2018 at 01:17:56PM +0100, Grant Likely wrote: > > > - While ACPI provides more standardization, Devicetree is > > > preferred in may embedded > > > - platforms for its flexibility. > > > + While ACPI provides more standardization, Devicetree is > > > + preferred in many embedded platforms for its flexibility. > > Bit of a pet peeve of mine since ASoC means I'm frequently having to > > think about systems that fall off the edge of what ACPI can express > > and it's just a miserable experience. > Understood, but I'm going to leave it as is for now. I don't want to > get into a discussion of the reasons Devicetree is preferred. I just > want to acknowledge that both DT and ACPI are supported options. OK... part of what I was reacting to there was that the text read to me like it was making value judgements about the merits of the two (or at least it's a lot like what people say). How about either striking this entirely or something like: Either ACPI or Devicetree may be used depending on which meets the needs of the system better, they have different platform models. 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.

7 years, 3 months

Re: [Arm.ebbr-discuss] [RFC] uefi: Account for SetVariable() not working at runtime

by Ard Biesheuvel

On 12 July 2018 at 15:12, Mark Brown <broonie(a)kernel.org> 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.

7 years, 3 months

Re: [PATCH] Update manifesto from comments on mailing list

by Grant Likely

On 12/07/2018 11:18, Mark Brown wrote: > On Wed, Jul 11, 2018 at 09:11:53PM +0100, Grant Likely wrote: >> On 09/07/2018 13:39, Mark Brown wrote: >>> On Mon, Jul 09, 2018 at 01:17:56PM +0100, Grant Likely wrote: > >>>> - While ACPI provides more standardization, Devicetree is preferred in may embedded >>>> - platforms for its flexibility. >>>> + While ACPI provides more standardization, Devicetree is preferred in many >>>> + embedded platforms for its flexibility. > >>> Bit of a pet peeve of mine since ASoC means I'm frequently having to >>> think about systems that fall off the edge of what ACPI can express and >>> it's just a miserable experience. > >> Understood, but I'm going to leave it as is for now. I don't want to get >> into a discussion of the reasons Devicetree is preferred. I just want to >> acknowledge that both DT and ACPI are supported options. > > OK... part of what I was reacting to there was that the text read to me > like it was making value judgements about the merits of the two (or at > least it's a lot like what people say). How about either striking this > entirely or something like: I've dropped it entirely. g.

7 years, 3 months

[PATCH] v0.6-pre1 draft comments responses

by Grant Likely

Edits responding to comments from Udit Kumar Suggested-by: Udit Kumar <udit.kumar(a)nxp.com> Signed-off-by: Grant Likely <grant.likely(a)arm.com> --- source/chapter1-about.rst | 16 +++++++++------- source/chapter4-firmware-media.rst | 3 ++- 2 files changed, 11 insertions(+), 8 deletions(-) diff --git a/source/chapter1-about.rst b/source/chapter1-about.rst index a2561d6..1dafd39 100644 --- a/source/chapter1-about.rst +++ b/source/chapter1-about.rst @@ -10,7 +10,7 @@ between platform firmware and an operating system that is suitable for embedded platforms. EBBR compliant platforms present a consistent interface that will boot an EBBR compliant operating system without any custom tailoring required. -For example, an Arm A-class embedded networking platform will benefit +For example, an Arm A-class embedded platform will benefit from a standard interface that supports features such as secure boot and firmware update. @@ -149,12 +149,14 @@ Operating System. This specification is similar to the Arm Server Base Boot Requirements specification [SBBR]_ in that it defines the firmware interface presented to an -operating system, with SBBR having stricter requirements on hardware and -firmware than EBBR. -EBBR allows for design decisions that are common in the embedded space, but not -supported by the server ecosystem. -For example, an embedded system may use a single eMMC storage device to hold -both firmware and operating system images. +operating system. +SBBR is targeted at the server ecosystem and places strict requirements on the +platform to ensure cross vendor interoperability. +EBBR on the other hand allows more flexibility to support embedded designs +which do not fit within the SBBR model. +For example, a platform that isn't SBBR compliant because the SoC is only +supported using Devicetree could be EBBR compliant, but not SBBR compliant. + By definition, all SBBR compliant systems are also EBBR compliant, but the converse is not true. diff --git a/source/chapter4-firmware-media.rst b/source/chapter4-firmware-media.rst index 604df18..39a1c03 100644 --- a/source/chapter4-firmware-media.rst +++ b/source/chapter4-firmware-media.rst @@ -4,7 +4,8 @@ Firmware Storage In general, EBBR compliant platforms should use dedicated storage for boot firmware images and data, -independent of the storage used for OS partitions and the ESP. +independent of the storage used for OS partitions and the EFI System Partition +(ESP). This could be a physically separate device (e.g. SPI flash), or a dedicated logical unit (LU) within a device (e.g. eMMC boot partition, [#eMMCBootPartition]_ -- 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.

7 years, 3 months

EBBR v0.6-pre1 Released

by Grant Likely

I've tagged the prerelease in preparation for a wider v0.6 RFC release next week. Please review and comment: https://github.com/glikely/ebbr/releases/tag/v0.6-pre1 (I've linked to the copy on my personal ebbr fork because I'm having trouble getting Travis-ci to deploy to the official repo. It will take a bit of effort to work out what is wrong) g. 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.

7 years, 3 months

← Newer
1
...
39
40
41
42
43
44
45
...
67
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

boot-architecture