-Multiprocessor Startup Protocol

On 24/09/2018 16:22, Ard Biesheuvel wrote:

On Mon, 24 Sep 2018 at 15:54, Grant Likely grant.likely@arm.com wrote:

...

Fill out the requirements for AArch32 systems. Not much needs to be specified here other than the different privilege modes defined by ARMv7 and below.

Resolves: #15 Signed-off-by: Grant Likely grant.likely@arm.com

---

source/chapter1-about.rst | 19 +++++++++++-------- source/chapter2-uefi.rst | 32 ++++++++++++++++++++------------ source/chapter3-secureworld.rst | 18 ++++++++++++++---- source/index.rst | 1 + 4 files changed, 46 insertions(+), 24 deletions(-)

diff --git a/source/chapter1-about.rst b/source/chapter1-about.rst index d1c6d1d..4d70b2a 100644 --- a/source/chapter1-about.rst +++ b/source/chapter1-about.rst @@ -107,9 +107,8 @@ The following guiding principles are used while developing the EBBR specificatio

• Support multiple architectures

  Any architecture can implement the EBBR requirements.

• .. note::

• At the time of writing this document only addresses AArch64, but AArch32 and others architectures are expected.
  

• Architecture specific requirements will clearly marked as to which

• architecture(s) they apply.

  • Design for common embedded hardware

@@ -139,7 +138,7 @@ The following guiding principles are used while developing the EBBR specificatio Scope ===== This document defines the boot and runtime services that are expected by an -Operating System or hypervisor, for an Arm embedded device, which follows the +Operating System or hypervisor, for a device which follows the UEFI specification [UEFI]_.

This specification defines the boot and runtime services for a physical system, @@ -180,6 +179,10 @@ This document uses the following terms and abbreviations. The 64-bit Arm instruction set used in AArch64 state. All A64 instructions are 32 bits.

• AArch32

•  Arm 32-bit architectures. AArch32 is a roll up term referring to all
  

•  32-bit versions of the Arm architecture starting at ARMv4.
  

• AArch64 state The Arm 64-bit Execution state that uses 64-bit general purpose registers, and a 64-bit program counter (PC), Stack Pointer (SP), and

@@ -193,19 +196,19 @@ This document uses the following terms and abbreviations. and which uses boot time services.

 EL0

•  The lowest Exception level. The Exception level that is used to execute
  

•  The lowest Exception level on AArch64. The Exception level that is used to execute
    user applications, in Non-secure state.
  
  

  EL1

•  Privileged Exception level. The Exception level that is used to execute
  

•  Privileged Exception level on AArch64. The Exception level that is used to execute
    Operating Systems, in Non-secure state.
  
  

  EL2

•  Hypervisor Exception level. The Exception level that is used to execute
  

•  Hypervisor Exception level on AArch64. The Exception level that is used to execute
    hypervisor code. EL2 is always in Non-secure state.
  
  

  EL3

•  Secure Monitor Exception level. The Exception level that is used to
  

•  Secure Monitor Exception level on AArch64. The Exception level that is used to
    execute Secure Monitor code, which handles the transitions between
    Non-secure and Secure states.  EL3 is always in Secure state.
  
  

diff --git a/source/chapter2-uefi.rst b/source/chapter2-uefi.rst index f89ac04..7fd8aa6 100644 --- a/source/chapter2-uefi.rst +++ b/source/chapter2-uefi.rst @@ -29,19 +29,27 @@ The system firmware must implement support for MBR, GPT and El Torito partitioni UEFI System Environment and Configuration =========================================

-AArch64 Exception Levels

-The resident AArch64 UEFI boot-time environment is specified to "Use the -highest 64-bit Non-secure privilege level available". -This level is either EL1 or EL2, depending on whether or not virtualization is -used or supported. +The resident UEFI boot-time environment shall use the highest non-secure +privilege level available. +The exact meaning of this is architecture dependant, as detailed below.

-Resident UEFI firmware might target a specific Exception level. +Resident UEFI firmware might target a specific priviledge level.

privilege

Fixed

...

In contrast, UEFI Loaded Images, such as thirdparty drivers and boot applications, must not contain any built-in assumptions that they are to be -loaded at a given Exception level during boot time, since they can legitimately -be loaded into EL1 or EL2. +loaded at a given priviledge level during boot time since they can, for example, +legitimately be loaded into either EL1 or EL2 on AArch64.

+AArch32 Priviledge Levels +-------------------------

+UEFI shall execute at either PL1 (svc) or PL2 (hyp), +depending on whether or not virtualization is used and supported.

Unfortunately, the UEFI spec currently does not permit booting in HYP mode, and since it also mandates short descriptors, this needs a bit of discussion (and a fair amount of EDK2 code) to support.

I was definitely writing out of ignorance here, and just matching what was done in the AArch32 blurb. Can you recommend some different text? I can also simply drop the blurb.

g.

Am 25.09.2018 um 16:50 schrieb Ard Biesheuvel ard.biesheuvel@linaro.org:

...

On Tue, 25 Sep 2018 at 16:45, Grant Likely grant.likely@arm.com wrote:

...

On 24/09/2018 16:22, Ard Biesheuvel wrote:

...

On Mon, 24 Sep 2018 at 15:54, Grant Likely grant.likely@arm.com wrote:

Fill out the requirements for AArch32 systems. Not much needs to be specified here other than the different privilege modes defined by ARMv7 and below.

Resolves: #15 Signed-off-by: Grant Likely grant.likely@arm.com

---

source/chapter1-about.rst | 19 +++++++++++-------- source/chapter2-uefi.rst | 32 ++++++++++++++++++++------------ source/chapter3-secureworld.rst | 18 ++++++++++++++---- source/index.rst | 1 + 4 files changed, 46 insertions(+), 24 deletions(-)

diff --git a/source/chapter1-about.rst b/source/chapter1-about.rst index d1c6d1d..4d70b2a 100644 --- a/source/chapter1-about.rst +++ b/source/chapter1-about.rst @@ -107,9 +107,8 @@ The following guiding principles are used while developing the EBBR specificatio

• Support multiple architectures

  Any architecture can implement the EBBR requirements.

• .. note::

• At the time of writing this document only addresses AArch64, but AArch32 and others architectures are expected.
  

• Architecture specific requirements will clearly marked as to which
• architecture(s) they apply.

• Design for common embedded hardware

@@ -139,7 +138,7 @@ The following guiding principles are used while developing the EBBR specificatio Scope ===== This document defines the boot and runtime services that are expected by an -Operating System or hypervisor, for an Arm embedded device, which follows the +Operating System or hypervisor, for a device which follows the UEFI specification [UEFI]_.

This specification defines the boot and runtime services for a physical system, @@ -180,6 +179,10 @@ This document uses the following terms and abbreviations. The 64-bit Arm instruction set used in AArch64 state. All A64 instructions are 32 bits.

• AArch32

•  Arm 32-bit architectures. AArch32 is a roll up term referring to all
  

•  32-bit versions of the Arm architecture starting at ARMv4.
  

• AArch64 state The Arm 64-bit Execution state that uses 64-bit general purpose registers, and a 64-bit program counter (PC), Stack Pointer (SP), and

@@ -193,19 +196,19 @@ This document uses the following terms and abbreviations. and which uses boot time services.

EL0

•  The lowest Exception level. The Exception level that is used to execute
  

•  The lowest Exception level on AArch64. The Exception level that is used to execute
   user applications, in Non-secure state.
  
  

  EL1

•  Privileged Exception level. The Exception level that is used to execute
  

•  Privileged Exception level on AArch64. The Exception level that is used to execute
   Operating Systems, in Non-secure state.
  
  

  EL2

•  Hypervisor Exception level. The Exception level that is used to execute
  

•  Hypervisor Exception level on AArch64. The Exception level that is used to execute
   hypervisor code. EL2 is always in Non-secure state.
  
  

  EL3

•  Secure Monitor Exception level. The Exception level that is used to
  

•  Secure Monitor Exception level on AArch64. The Exception level that is used to
   execute Secure Monitor code, which handles the transitions between
   Non-secure and Secure states.  EL3 is always in Secure state.
  
  

diff --git a/source/chapter2-uefi.rst b/source/chapter2-uefi.rst index f89ac04..7fd8aa6 100644 --- a/source/chapter2-uefi.rst +++ b/source/chapter2-uefi.rst @@ -29,19 +29,27 @@ The system firmware must implement support for MBR, GPT and El Torito partitioni UEFI System Environment and Configuration =========================================

-AArch64 Exception Levels

-The resident AArch64 UEFI boot-time environment is specified to "Use the -highest 64-bit Non-secure privilege level available". -This level is either EL1 or EL2, depending on whether or not virtualization is -used or supported. +The resident UEFI boot-time environment shall use the highest non-secure +privilege level available. +The exact meaning of this is architecture dependant, as detailed below.

-Resident UEFI firmware might target a specific Exception level. +Resident UEFI firmware might target a specific priviledge level.

privilege

Fixed

...

...

In contrast, UEFI Loaded Images, such as thirdparty drivers and boot applications, must not contain any built-in assumptions that they are to be -loaded at a given Exception level during boot time, since they can legitimately -be loaded into EL1 or EL2. +loaded at a given priviledge level during boot time since they can, for example, +legitimately be loaded into either EL1 or EL2 on AArch64.

+AArch32 Priviledge Levels

Here's another one btw ^^^

...

...

...

+-------------------------

+UEFI shall execute at either PL1 (svc) or PL2 (hyp), +depending on whether or not virtualization is used and supported.

Unfortunately, the UEFI spec currently does not permit booting in HYP mode, and since it also mandates short descriptors, this needs a bit of discussion (and a fair amount of EDK2 code) to support.

I was definitely writing out of ignorance here, and just matching what was done in the AArch32 blurb. Can you recommend some different text? I can also simply drop the blurb.

The UEFI spec is already very normative about the boot mode, so we can just refer to that.

But that leaves the question whether we should push for a UEFI spec update to permit HYP mode and thus long descriptors. Is anyone interested in using that, e.g., for partitioning on industrial/automotive?

We definitely want to run in HYP simply to be able to run KVM on ARMv7, no? Are you sure that's not allowed?

Alex

On 25/09/2018 16:50, Ard Biesheuvel wrote:

On Tue, 25 Sep 2018 at 16:45, Grant Likely grant.likely@arm.com wrote:

...

On 24/09/2018 16:22, Ard Biesheuvel wrote:

...

On Mon, 24 Sep 2018 at 15:54, Grant Likely grant.likely@arm.com wrote:

...

Fill out the requirements for AArch32 systems. Not much needs to be specified here other than the different privilege modes defined by ARMv7 and below.

Resolves: #15 Signed-off-by: Grant Likely grant.likely@arm.com

---

source/chapter1-about.rst | 19 +++++++++++-------- source/chapter2-uefi.rst | 32 ++++++++++++++++++++------------ source/chapter3-secureworld.rst | 18 ++++++++++++++---- source/index.rst | 1 + 4 files changed, 46 insertions(+), 24 deletions(-)

diff --git a/source/chapter1-about.rst b/source/chapter1-about.rst index d1c6d1d..4d70b2a 100644 --- a/source/chapter1-about.rst +++ b/source/chapter1-about.rst @@ -107,9 +107,8 @@ The following guiding principles are used while developing the EBBR specificatio

• Support multiple architectures

  Any architecture can implement the EBBR requirements.

• .. note::

• At the time of writing this document only addresses AArch64, but AArch32 and others architectures are expected.
  

• Architecture specific requirements will clearly marked as to which

• architecture(s) they apply.

  • Design for common embedded hardware

@@ -139,7 +138,7 @@ The following guiding principles are used while developing the EBBR specificatio Scope ===== This document defines the boot and runtime services that are expected by an -Operating System or hypervisor, for an Arm embedded device, which follows the +Operating System or hypervisor, for a device which follows the UEFI specification [UEFI]_.

This specification defines the boot and runtime services for a physical system, @@ -180,6 +179,10 @@ This document uses the following terms and abbreviations. The 64-bit Arm instruction set used in AArch64 state. All A64 instructions are 32 bits.

• AArch32

•  Arm 32-bit architectures. AArch32 is a roll up term referring to all
  

•  32-bit versions of the Arm architecture starting at ARMv4.
  

• AArch64 state
     The Arm 64-bit Execution state that uses 64-bit general purpose
     registers, and a 64-bit program counter (PC), Stack Pointer (SP), and
  

@@ -193,19 +196,19 @@ This document uses the following terms and abbreviations. and which uses boot time services.

  EL0

•  The lowest Exception level. The Exception level that is used to execute
  

•  The lowest Exception level on AArch64. The Exception level that is used to execute
     user applications, in Non-secure state.
  
  EL1
  

•  Privileged Exception level. The Exception level that is used to execute
  

•  Privileged Exception level on AArch64. The Exception level that is used to execute
     Operating Systems, in Non-secure state.
  
  EL2
  

•  Hypervisor Exception level. The Exception level that is used to execute
  

•  Hypervisor Exception level on AArch64. The Exception level that is used to execute
     hypervisor code. EL2 is always in Non-secure state.
  
  EL3
  

•  Secure Monitor Exception level. The Exception level that is used to
  

•  Secure Monitor Exception level on AArch64. The Exception level that is used to
     execute Secure Monitor code, which handles the transitions between
     Non-secure and Secure states.  EL3 is always in Secure state.
  
  

diff --git a/source/chapter2-uefi.rst b/source/chapter2-uefi.rst index f89ac04..7fd8aa6 100644 --- a/source/chapter2-uefi.rst +++ b/source/chapter2-uefi.rst @@ -29,19 +29,27 @@ The system firmware must implement support for MBR, GPT and El Torito partitioni UEFI System Environment and Configuration =========================================

-AArch64 Exception Levels

-The resident AArch64 UEFI boot-time environment is specified to "Use the -highest 64-bit Non-secure privilege level available". -This level is either EL1 or EL2, depending on whether or not virtualization is -used or supported. +The resident UEFI boot-time environment shall use the highest non-secure +privilege level available. +The exact meaning of this is architecture dependant, as detailed below.

-Resident UEFI firmware might target a specific Exception level. +Resident UEFI firmware might target a specific priviledge level.

privilege

Fixed

...

...

In contrast, UEFI Loaded Images, such as thirdparty drivers and boot applications, must not contain any built-in assumptions that they are to be -loaded at a given Exception level during boot time, since they can legitimately -be loaded into EL1 or EL2. +loaded at a given priviledge level during boot time since they can, for example, +legitimately be loaded into either EL1 or EL2 on AArch64.

+AArch32 Priviledge Levels

Here's another one btw ^^^

Thanks. I'll proofread more carefully before sending out v2

...

...

...

+-------------------------

+UEFI shall execute at either PL1 (svc) or PL2 (hyp), +depending on whether or not virtualization is used and supported.

Unfortunately, the UEFI spec currently does not permit booting in HYP mode, and since it also mandates short descriptors, this needs a bit of discussion (and a fair amount of EDK2 code) to support.

I was definitely writing out of ignorance here, and just matching what was done in the AArch32 blurb. Can you recommend some different text? I can also simply drop the blurb.

The UEFI spec is already very normative about the boot mode, so we can just refer to that.

Okay, I'll simply drop the blurb

g.

On 25/09/2018 14:02, Peter Robinson wrote:

On Mon, Sep 24, 2018 at 2:54 PM Grant Likely grant.likely@arm.com wrote:

...

The UEFI spec already covers the requirements on the runtime memory map. No need to have a whole section on it here.

Is it worth just referring to the relevant section in the UEFI spec?

I'm kind of going on the assumption that if it is in the UEFI spec, and is uncontroversial then just leave it unmentioned. However, if anyone feels strongly about it, then I'll add the UEFI Spec reference.

...

Signed-off-by: Grant Likely grant.likely@arm.com

Reviewed-by: Peter Robinson pbrobinson@gmail.com

Thanks, g.

...

---

source/chapter2-uefi.rst | 23 ----------------------- 1 file changed, 23 deletions(-)

diff --git a/source/chapter2-uefi.rst b/source/chapter2-uefi.rst index 7fd8aa6..6f7d260 100644 --- a/source/chapter2-uefi.rst +++ b/source/chapter2-uefi.rst @@ -125,29 +125,6 @@ EL1 or EL2, with appropriate virtual address mappings. When called, subsequent runtime service calls must be from the same Exception level.

-Runtime Memory Map

-Before calling ExitBootServices(), the final call to GetMemoryMap() returns a -description of the entire UEFI memory map, that includes the persistent Runtime -Services mappings.

-After the call to ExitBootServices(), the Runtime Services page mappings can be -relocated in virtual address space by calling SetVirtualAddressMap(). -This call allows the Runtime Services to assign virtual addresses that are -compatible with the incoming Operating System memory map.

-A UEFI runtime environment compliant with this specification must not be -written with any assumption of an identity mapping between virtual and physical -memory maps.

-UEFI operates with a 4K page size. With Runtime Services, these pages are -mapped into the Operating System address space.

-To allow Operating Systems to use 64K page mappings, UEFI 2.7, constrains all -mapped 4K memory pages to have identical page attributes, within the same -physical 64K page.

• Runtime Device Mappings

-- 2.13.0

---

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

Hi Grant

-----Original Message----- From: arm.ebbr-discuss-bounces@arm.com <arm.ebbr-discuss- bounces@arm.com> On Behalf Of Grant Likely Sent: Monday, September 24, 2018 7:24 PM To: boot-architecture@lists.linaro.org; arm.ebbr-discuss@arm.com Cc: nd@arm.com Subject: [Arm.ebbr-discuss] [PATCH 4/7] GetTime()/SetTime() should return EFI_UNSUPPORTED when unsupported

UEFI spec is adding ability for all runtime services to return EFI_UNSUPPORTED if not implemented. Use this return code instead of EFI_DEVICE_ERROR.

Could we wait to push this patch, until UEFI spec is not updated with this error code. AFAIK, Spec 2.7, Section 8.3 does not have EFI_UNSUPPORTED error.

Thanks Udit

Resolves: #14 Signed-off-by: Grant Likely grant.likely@arm.com

---

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

diff --git a/source/chapter2-uefi.rst b/source/chapter2-uefi.rst index 6f7d260..239fd8c 100644 --- a/source/chapter2-uefi.rst +++ b/source/chapter2-uefi.rst @@ -151,9 +151,9 @@ it may not be possible to access the RTC from runtime services. e.g., The RTC may be on a shared I2C bus which runtime services cannot access because it will conflict with the OS.

-Firmware still must provide the UEFI GetTime() and SetTime() runtime service -calls, but if an RTC isn't present, or cannot be accessed at runtime, then both - calls shall return EFI_DEVICE_ERROR. +If firmware does not support access to the RTC, then GetTime() and +SetTime() shall return EFI_UNSUPPORTED, and the OS must use a device +driver to control the RTC.

UEFI Reset and Shutdown

-- 2.13.0

---

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

On Mon, Sep 24, 2018 at 2:54 PM Grant Likely grant.likely@arm.com wrote:

UEFI spec is adding ability for all runtime services to return EFI_UNSUPPORTED if not implemented. Use this return code instead of EFI_DEVICE_ERROR.

Do we have a ticket number, errata or similar that we can reference here?

Resolves: #14 Signed-off-by: Grant Likely grant.likely@arm.com

Reviewed-by: Peter Robinson pbrobinson@gmail.com

---

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

diff --git a/source/chapter2-uefi.rst b/source/chapter2-uefi.rst index 6f7d260..239fd8c 100644 --- a/source/chapter2-uefi.rst +++ b/source/chapter2-uefi.rst @@ -151,9 +151,9 @@ it may not be possible to access the RTC from runtime services. e.g., The RTC may be on a shared I2C bus which runtime services cannot access because it will conflict with the OS.

-Firmware still must provide the UEFI GetTime() and SetTime() runtime service -calls, but if an RTC isn't present, or cannot be accessed at runtime, then both -calls shall return EFI_DEVICE_ERROR. +If firmware does not support access to the RTC, then GetTime() and +SetTime() shall return EFI_UNSUPPORTED, +and the OS must use a device driver to control the RTC.

UEFI Reset and Shutdown

-- 2.13.0

---

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

On 25/09/2018 11:08, Udit Kumar wrote:

Hi Grant

...

-----Original Message----- From: arm.ebbr-discuss-bounces@arm.com <arm.ebbr-discuss- bounces@arm.com> On Behalf Of Grant Likely Sent: Monday, September 24, 2018 7:24 PM To: boot-architecture@lists.linaro.org; arm.ebbr-discuss@arm.com Cc: nd@arm.com Subject: [Arm.ebbr-discuss] [PATCH 5/7] Refactor ResetSystem() requirements

ResetSystem() was over-specified in the document. UEFI already documents the behaviour of ResetSystem() sufficiently. Add notes on expected behaviour when platform specific or standard interface methods are available.

Resolves: #29 Signed-off-by: Grant Likely grant.likely@arm.com

---

source/chapter2-uefi.rst | 29 ++++++++++++----------------- 1 file changed, 12 insertions(+), 17 deletions(-)

diff --git a/source/chapter2-uefi.rst b/source/chapter2-uefi.rst index 239fd8c..a6b3ff7 100644 --- a/source/chapter2-uefi.rst +++ b/source/chapter2-uefi.rst @@ -158,23 +158,18 @@ and the OS must use a device driver to control the RTC. UEFI Reset and Shutdown

---

-The UEFI Runtime service ResetSystem() must implement the following commands, -for purposes of power management and system control.

-- EfiResetCold() -- EfiResetShutdown()

• • EfiResetShutdown must not reboot the system.

-If firmware updates are supported through the Runtime Service of - UpdateCapsule(), then ResetSystem() might need to support the following -command:

-- EfiWarmReset()

-.. note:: On platforms implementing the Power State Coordination Interface

• specification [PSCI]_, it is still required that EBBR compliant
• Operating Systems calls to reset the system will go via Runtime Services
• and not directly to PSCI.

+ResetSystem() is required to be implemented in boot services, but it is +optional for runtime services.

You meant, noefi to passed here to OS. or do you mean, ResetSystem passed in runtime service to be NULL. or you mean, ResetSystem() to be implemented and it can return error. Thanks to clarify.

I'm building on the language added in the next patch (I wrote everything at once, and then split into separate patches). In the next patch I make it clear that all runtime services functions need to be implmented.

From patch 6:

+Functions contained in EFI_RUNTIME_SERVICES are expected to be available +during both boot services and runtime services. +However, it isn't always practical for all EFI_RUNTIME_SERVICES functions +to be callable during runtime services due to hardware limitations. +If any EFI_RUNTIME_SERVICES functions are only available during boot services +then firmware shall provide the global `RuntimeServicesAvailable` variable to +indicate which functions are available during runtime services. +Functions that are not available during runtime services shall return +EFI_UNSUPPORTED.

Is that clear enough?

g.

On Mon, Sep 24, 2018 at 03:54:03PM +0200, Grant Likely wrote:

After face to face meeting at Linaro Connect YVR18, the decision was made to keep variable services very simple. Either fully provide SetVariable/GetVariable during runtime services, or don't provide them at all.

This is an RFC patch. In the process of writing it, and after looking at the ECR submitted by Peter Jones[1], I started having doubts. I no longer think this is the right decision. Since the ECR now provides a mechanism for reporting which runtime services can be called, it should be just fine to provide GetVariable() even if SetVariable() returns EFI_UNSUPPORTED. There is a note added to the document to this effect. I will remove the note after committing the final version of the patch, and depending on mailing list discussion.

[1] https://pjones.fedorapeople.org/rt-unsupported-ecr-0.txt

Resolves: #22 Signed-off-by: Grant Likely grant.likely@secretlab.ca Cc: Peter Jones pjones@redhat.com

---

source/chapter2-uefi.rst | 113 ++++++++++++++++++++++++----------------------- 1 file changed, 58 insertions(+), 55 deletions(-)

diff --git a/source/chapter2-uefi.rst b/source/chapter2-uefi.rst index cbf1529..72b3d59 100644 --- a/source/chapter2-uefi.rst +++ b/source/chapter2-uefi.rst @@ -197,66 +197,69 @@ unless a specific reset is required after a call to UpdateCapsule(). Runtime Variable Access

---

[old bits skipped]

+There are many platforms where it is difficult to implement SetVariable() for +non-volatile variables during runtime services 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 generic solution for accessing or updating +variables stored on shared media. [#OPTEESupplicant]_

Well, that's not *quite* true. OvmfPkg in edk2 has EmuVariableFvbRuntimeDxe, which might be fairly close to what we want.

+If a platform does not implement modifying non-volatile variables with +SetVariable() after ExitBootServices(), +then it must not provide any variable operations after ExitBootServices(). +Firmware shall return EFI_UNSUPPORTED for any call to GetVariable(), +GetNextVariableName() and SetVariable(). +Firmware shall not emulated non-volatile variables using volatile RAM cache.

+.. note:: I'm still not sold on this. Can we simply advertise that SetVariable()

• doesn't work via the `RuntimeServicesSupported` variable?
• RuntimeServicesSupported is a proposed ECR to the UEFI spec.

I think we can do that, but only if we *don't* support using some on-disk storage during Boot Services and then handing that storage off to a linux driver, which I see you've mentioned below. I'll comment about that down there.

• If we say here that GetVariable() must be disabled if SetVariable() doesn't
• work, then that precludes all the RT but !NV global varibles, including all
• the secure boot variables.
• It also potentially means distros will depend on the
• "no SetVariable == no GetVariable" behaviour, meaning it will be difficult
• re-enable GetVariable() without SetVariable().
• Looking at section 3.3, the folloing EFI_GLOBAL_VARIABLEs are RT but not NV:
• • AuditMode BS, RT
• • BootCurrent BS, RT
• • BootOptionSupport BS,RT,
• • ConInDev BS, RT
• • ConOutDev BS, RT
• • dbDefault BS, RT
• • dbrDefault BS, RT
• • dbtDefault BS, RT
• • dbxDefault BS, RT
• • DeployedMode BS, RT
• • ErrOutDev BS, RT
• • KEKDefault BS, RT
• • LangCodes BS, RT
• • OsIndicationsSupported BS, RT
• • PKDefault BS, RT
• • PlatformLangCodes BS, RT
• • PlatformRecovery#### BS, RT
• • SignatureSupport BS, RT
• • SecureBoot BS, RT
• • SetupMode BS, RT
• • VendorKeys BS, RT

Worth noting that all of these are expected to be generated during boot by the system firmware. It would be fairly reasonable to dump them into a UEFI config table and let us populate efivarfs from that.

Which actually means I'm violating the convention to use NV for RuntimeServicesSupported, and I should probably mark it as optionally "BS" due to its definition, as well. I'll fix that, with something along the lines of:

--- rt-unsupported-ecr-0.txt 2018-09-19 19:15:26.467010512 -0400 +++ rt-unsupported-ecr-1.txt 2018-09-25 10:23:26.470218080 -0400 @@ -78,9 +78,11 @@ Add the following entry to table 10 ("Global Variables")

+--------------------------+-------+----------------------------------------+ - | RuntimeServicesSupported | NV,BS | Bitmask of which calls are implemented | + | RuntimeServicesSupported | BS,RT | Bitmask of which calls are implemented | | | | by the firmware during runtime | - | | | services. See Section 8.5 . | + | | | services. RT access is required only | + | | | if GetVariable() is implemented by | + | | | runtime services. See Section 8.5 . | +--------------------------+-------+----------------------------------------+

In section 8.5, add the following text before the "Related Definitions" ---

I'll update the UEFI mantis ticket as well.

• In related news, I'm considering proposing a "SetVariable on Disk" analogous
• to the current Capsule on Disk [UEFI]_ 8.5.5.
• That would allow the OS to write a standard format variable update file to
• the ESP that firmware can read, update, and clear at boot time.
• However, this could also be implemented using an OS provided variable-update
• UEFI application.

It doesn't need to be *analogous* to Capsule on Disk - that's already exactly the mechanism we're looking for. We just have to define a data structure to go in the capsule and a GUID to identify it. If we're careful we could probably use the same GUID and the same format for the config table to hand off boot-time generated variables to the OS.

Just brainstorming here, but I think when we have shared storage like eMMC, there's a fairly compelling story along these lines:

- UEFI writes a capsule to an EFI Config Table during boot with any generated variables as well as any persistent variables stored on e.g. an eMMC partition it sets as write protected during ExitBootServices() - efivarfs picks up that capsule during boot and uses that as its seed data (maybe it uses it as is, maybe it translates it to some internal format and frees the ram back to the allocator. Doesn't make much difference.) - for runtime updates, we do "best effort" at having the same security model as UEFI, and represent the changes in ram both in /sys/firmware/efi/efivars , as well as a capsule file in e.g. /sys/firmware/efi/efivars-updates.cap - during shutdown, we copy that .cap to the ESP as a Capsule on Disk - during boot up, UEFI reads that .cap and applies the update to the storage. Any cases the OS was wrong about its "best effort" security model simply fail

That gets us more or less the same behavior normal UEFI machines have, with the exception of the "do both pieces of code know about all variable update rules" issue - but since UEFI gets to be the final arbiter there, that failure can generally be safe.

On Thu, Sep 27, 2018 at 04:07:34PM +0100, Grant Likely wrote:

...

...

• In related news, I'm considering proposing a "SetVariable on Disk" analogous
• to the current Capsule on Disk [UEFI]_ 8.5.5.
• That would allow the OS to write a standard format variable update file to
• the ESP that firmware can read, update, and clear at boot time.
• However, this could also be implemented using an OS provided variable-update
• UEFI application.

It doesn't need to be *analogous* to Capsule on Disk - that's already exactly the mechanism we're looking for. We just have to define a data structure to go in the capsule and a GUID to identify it. If we're careful we could probably use the same GUID and the same format for the config table to hand off boot-time generated variables to the OS.

That is a really good idea. Keeps it nice and simple.

...

Just brainstorming here, but I think when we have shared storage like eMMC, there's a fairly compelling story along these lines:

• UEFI writes a capsule to an EFI Config Table during boot with any generated variables as well as any persistent variables stored on e.g. an eMMC partition it sets as write protected during ExitBootServices()
• efivarfs picks up that capsule during boot and uses that as its seed data (maybe it uses it as is, maybe it translates it to some internal format and frees the ram back to the allocator. Doesn't make much difference.)

Wait, you've lost me. Are you suggesting that the OS read the capsule to get variables instead of using GetVariable()/GetNextVariableName()? I do not like the idea of having two different mechanisms for retrieving variables.

...

• for runtime updates, we do "best effort" at having the same security model as UEFI, and represent the changes in ram both in /sys/firmware/efi/efivars , as well as a capsule file in e.g. /sys/firmware/efi/efivars-updates.cap

Ah, clever. So that way the normal efibootmgr tool works, but userspace will still need to copy the new .cap from sysfs to the EFI, correct?

...

• during shutdown, we copy that .cap to the ESP as a Capsule on Disk
• during boot up, UEFI reads that .cap and applies the update to the storage. Any cases the OS was wrong about its "best effort" security model simply fail

Yes, completly agree here.

Alright, so I've taken a shot at this - here's my first attempt, let me know what's unclear/wrong/insane/etc :)

From: Peter Jones pjones@redhat.com Date: Thu, 11 Oct 2018 14:44:30 -0400 Subject: [PATCH] Update variable storage language

This patch updates the UEFI chapter of the spec, specifically the parts about UEFI variable storage. This language utilizes UEFI's existing Capsule Update on Disk and EFI Configuration table mechanisms, providing independent mechanisms for exporting variables to the OS and importing updates from the OS.

The mechanism for exporting variables from the firmware uses a UEFI Configuration Table rather than requiring the firmware to maintain the Capsule on Disk, so that a platform with no permanent storage can implement exporting variables to the OS without having to write to storage, and a system without permanent storage can implement exporting to the OS without having to implement importing from Capsule on Disk. To keep things simple, we do not specify Capsule on Disk as an export mechanism to the OS.

This text also specifies a de facto coherency protocol. As a result, in most cases requirements on the firmware producing the configuration table are "must" requirements, but they only apply if the export procedure is implemented. Likewise, the requirements on the OS to create a Variable Updates Capsule are mostly "should" requirements, but the requirements on the contents are "must" requirements. --- source/chapter2-uefi.rst | 237 ++++++++++++++++++++++++++++----------- 1 file changed, 174 insertions(+), 63 deletions(-)

diff --git a/source/chapter2-uefi.rst b/source/chapter2-uefi.rst index 0cbddff6b46..320d71d7456 100644 --- a/source/chapter2-uefi.rst +++ b/source/chapter2-uefi.rst @@ -196,66 +196,177 @@ command: 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@lists.linaro.org mailing list. - -.. [#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. - - https://github.com/OP-TEE/optee_os/blob/master/documentation/secure_storage.... +There are many platforms where it is difficult to implement SetVariable() for +non-volatile variables during runtime services 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 generic solution for accessing or updating +variables stored on shared media. [#OPTEESupplicant]_ + +If a platform does not implement modifying non-volatile variables with +SetVariable() after ExitBootServices(), then it must implement support for +discovering this during Boot Services via the "RuntimeServicesSupported" +variable (see UEFI Mantis 1961). + +Such a system may also support exporting the variable storage to the +kernel via a UEFI configuration table and re-loading it from a Capsule on +Disk as described in [UEFI]_ 8.5.5. If this is supported, the platform +must implement the following: + +- The firmware must provide BS variable named "CapsuleVariableSupport" + under the VARIABLE_STORAGE_GUID, with the following bits defined: + + #define EBBR_CAPSULE_VARIABLE_EXPORT 0x01 + #define EBBR_CAPSULE_VARIABLE_IMPORT 0x02 + #define EBBR_CAPSULE_VARIABLE_IMPORT_AUTH 0x04 + #define EBBR_CAPSULE_VARIABLE_IMPORT_AUTH_2 0x08 + #define EBBR_CAPSULE_VARIABLE_IMPORT_AUTH_3 0x10 + +- If the firmware supports exporting variables via a configuration table, + the EBBR_CAPSULE_VARIABLE_EXPORT bit must be set, and the firmware must + create a configuration table identified by the VARIABLE_STORAGE_GUID + (defined below) before any EFI applications are started, and must update it + any time a variable is altered via SetVariable(), until ExitBootServices() + has successfully returned. +- If the firmware supports importing non-volatile variables via a Capsule + on Disk, the EBBR_CAPSULE_VARIABLE_IMPORT bit must be set, and the + firmware must load its initial variable storage during boot services + from a capsule with the EFI_CAPSULE_HEADER.CapsuleGuid set to + VARIABLE_STORAGE_GUID. +- If the firmware supports authenticated variables, the bits + EBBR_CAPSULE_VARIABLE_IMPORT_AUTH, EBBR_CAPSULE_VARIABLE_IMPORT_AUTH_2, + and EBBR_CAPSULE_VARIABLE_IMPORT_AUTH_3 must be set to indicate support for + EFI_VARIABLE_AUTHENTICATION, EFI_VARIABLE_AUTHENTICATION_2, and + EFI_VARIABLE_AUTHENTICATION_3 descriptors defined in [UEFI]_ 8.2. +- If the CapsuleVariableSupport variable is not set, the OS must behave as if + all bits are 0. +- Any bits which are not present in the CapsuleVariableSupport variable must + be treated as 0. + +Variable storage data format +---------------------------- + +The Variable Configuration Table and the Variable Update Capsule structure +share the same data format, and are structured as a capsule update containing +a packed array of update records: + +#define VARIABLE_STORAGE_GUID \ + {0x1a3fb419, 0x2171, 0x458d,\ + {0xb8, 0xb4, 0xbe, 0xa3, 0x0c, 0x9f, 0x6b, 0xab }} + +typedef struct { + CHAR16[64] VariableName; + EFI_GUID VendorGuid; + UINT32 Attributes; + UINT32 DataSize; + UINT8[] Data; +} EBBR_VARIABLE; + +typedef struct { + EFI_CAPSULE_HEADER Header; + UINT8[Header.HeaderSize - sizeof(EFI_CAPSULE_HEADER)] Reserved; + EBBR_VARIABLE[] Variables; +} EBBR_VARIABLE_BUNDLE __attribute__((__packed__)); + +- EBBR_VARIABLE_BUNDLE.Header.CapsuleGuid must be VARIABLE_STORAGE_GUID +- EBBR_VARIABLE_BUNDLE.Reserved may be 0 or more bytes. +- EBBR_VARIABLE_BUNDLE.Header.HeaderSize is equal to the starting offset of + the EBBR_VARIABLE_BUNDLE.Variables array. +- EBBR_VARIABLE_BUNDLE.Variables may be 0 or more bytes. +- EBBR_VARIABLE_BUNDLE.Header.CapsuleImageSize is the full size of the capsule + including the Header, Reserved, and all Variable array members. +- EBBR_VARIABLE_BUNDLE.Header.Flags must not have any of the following set: + CAPSULE_FLAGS_INITIATE_RESET +- EBBR_VARIABLE_BUNDLE.Header.Flags should have all of the following set: + CAPSULE_FLAGS_PERSIST_ACROSS_RESET + CAPSULE_FLAGS_POPULATE_SYSTEM_TABLE + +Variable Configuration Table creation +------------------------------------- + +Any platform firmware which supports EBBR_CAPSULE_VARIABLE_EXPORT must +install a UEFI Configuration Table with all appropriate variables specified +in [UEFI]_ 3.3, as well as any variables which have been imported from a +Variable Update Capsule or set through SetVariable(). + +- The platform firmware must not include multiple entries for the same + variable. +- The platform should avoid storing any secrets in variables, including + variables without EFI_VARIABLE_RUNTIME_SERVICES set. + +Variable Configuration Table processing +--------------------------------------- + +When processing the Variable Configuration Table, the OS must treat each +EBBR_VARIABLE_BUNDLE.Variable entry as if it were a call to SetVariable() +before ExitBootServices() has been called: + +- The variables are processed according to the requirements in [UEFI]_ 8.2 +- Any update which would result in SetVariable() returning an error must + be ignored. +- The OS should preserve entries with EFI_VARIABLE_NON_VOLATILE set but + EFI_VARIABLE_RUNTIME_SERVICES unset, and save them to a Variable Updates + Capsule before system reset. +- Any entry without EFI_VARIABLE_RUNTIME_SERVICES set must not be exposed to + consumers of GetVariable(). +- Any entry authenticated with an Authentication Descriptor the OS does not + support should be preserved, but must not be exposed to consumers of + GetVariable(). Any following entry for any such variable must be treated + the same. +- All authenticated variables should have their Authentication Descriptors + preserved, but only the encapsulated data should be presented through + GetVariable()-like interfaces. +- The OS must take measures to prevent data in variables without + EFI_VARIABLE_RUNTIME_SERVICES set from being exposed to unprivileged tasks. + +Runtime Processing +------------------ + +The OS must take certain measures during runtime operation to insure +consistency: + +- The OS must keep a log of any updates to variables, including delete, + append, and create operations. +- The OS should attempt to simulate each operation as it would be applied + during the Variable Updates Capsule processing, in order to maintain a + view which is coherent across a reset. + +Variable Updates Capsule creation +--------------------------------- + +Before system reset, the OS should create a Variable Updates Capsule as a +Capsule on Disk defined in [UEFI]_ 8.5.5 . If a platform supports both +EBBR_CAPSULE_VARIABLE_EXPORT and EBBR_CAPSULE_VARIABLE_IMPORT, the capsule +should preserve the following from the Variable Configuration Table, if it +was present: + +- EBBR_VARIABLE_BUNDLE.Header.HeaderSize, EBBR_VARIABLE_BUNDLE.Header.Flags, + and EBBR_VARIABLE_BUNDLE.Reserved fields +- Any variables with EFI_VARIABLE_NON_VOLATILE set, including those without + EFI_VARIABLE_RUNTIME_SERVICES set +- Any variables authenticated with Authentication Descriptors not supported + by the OS. +- Runtime updates to authenticated variables must be included individually, + including any authenticated deletion. +- Runtime operations on newly created variables which are not authenticated + may be coalesced to a single entry. + +Variable Updates Capsule processing +----------------------------------- + +During boot, the system firmware must create the variables specified in [UEFI]_ +3.3 before processing the capsule update, and it must ensure that the variables +implemented in the UEFI spec are treated as specified at all times. When +processing a Variable Updates Capsule, the firmware must process each record in +the order they appear in the Variables array as if each were a call to +SetVariable() after ExitBootServices(): + +- The variables are processed according to the requirements in [UEFI]_ 8.2 +- Any update without the EFI_VARIABLE_NON_VOLATILE attribute set must be + ignored. +- Any update which would result in SetVariable() returning an error must + be ignored. +- Any variable authenticated with an unsupported Authentication Descriptor + not supported by the platform must be ignored.

I'll attempt not to add noise into an otherwise detailed and technical discussion, but I like to go back to first principles:

[1] Does Peter's suggested mechanism extend the use model that exists between a kernel and UEFI? If so, I would suggest that that is dangerous ground. As a side note, is there a how to covering UEFI from a functional use point of view?

[2] Is it reasonable to think about who 'owns' these variables? Usual database rules apply, one owner, no duplicates

[3] I think that I understand the need to work around a lack of file system storage in firmware by using the OS (however indirectly), but see question [1]

[4] Bending over backwards to help deal with legacy implementations is a good goal, but how far is too far?

Apologies if this adds nothing to the discussion, if so, please ignore...

David

On Thu, 1 Nov 2018 at 14:35 Grant Likely Grant.Likely@arm.com wrote:

On 12/10/2018 19:15, Peter Jones wrote:

...

Alright, so I've taken a shot at this - here's my first attempt, let me know what's unclear/wrong/insane/etc :)

From: Peter Jones pjones@redhat.com Date: Thu, 11 Oct 2018 14:44:30 -0400 Subject: [PATCH] Update variable storage language

This patch updates the UEFI chapter of the spec, specifically the parts about UEFI variable storage. This language utilizes UEFI's existing Capsule Update on Disk and EFI Configuration table mechanisms, providing independent mechanisms for exporting variables to the OS and importing updates from the OS.

The mechanism for exporting variables from the firmware uses a UEFI Configuration Table rather than requiring the firmware to maintain the Capsule on Disk, so that a platform with no permanent storage can implement exporting variables to the OS without having to write to storage, and a system without permanent storage can implement exporting to the OS without having to implement importing from Capsule on Disk. To keep things simple, we do not specify Capsule on Disk as an export mechanism to the OS > This text also specifies a de facto coherency protocol. As a result, in most cases requirements on the firmware producing the configuration table are "must" requirements, but they only apply if the export procedure is implemented. Likewise, the requirements on the OS to create a Variable Updates Capsule are mostly "should" requirements, but the requirements on the contents are "must" requirements.

---

source/chapter2-uefi.rst | 237 ++++++++++++++++++++++++++++----------- 1 file changed, 174 insertions(+), 63 deletions(-)

diff --git a/source/chapter2-uefi.rst b/source/chapter2-uefi.rst index 0cbddff6b46..320d71d7456 100644 --- a/source/chapter2-uefi.rst +++ b/source/chapter2-uefi.rst @@ -196,66 +196,177 @@ command: 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@lists.linaro.org

mailing list.

...

-.. [#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.

https://github.com/OP-TEE/optee_os/blob/master/documentation/secure_storage....

...

+There are many platforms where it is difficult to implement

SetVariable() for

...

+non-volatile variables during runtime services 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 generic solution for accessing or

updating

...

+variables stored on shared media. [#OPTEESupplicant]_

+If a platform does not implement modifying non-volatile variables with +SetVariable() after ExitBootServices(), then it must implement support

for

...

+discovering this during Boot Services via the "RuntimeServicesSupported" +variable (see UEFI Mantis 1961).

+Such a system may also support exporting the variable storage to the +kernel via a UEFI configuration table and re-loading it from a Capsule

on

...

+Disk as described in [UEFI]_ 8.5.5. If this is supported, the platform +must implement the following: > + +- The firmware must provide BS variable named "CapsuleVariableSupport"

• under the VARIABLE_STORAGE_GUID, with the following bits defined:
• #define EBBR_CAPSULE_VARIABLE_EXPORT 0x01
• #define EBBR_CAPSULE_VARIABLE_IMPORT 0x02
• #define EBBR_CAPSULE_VARIABLE_IMPORT_AUTH 0x04
• #define EBBR_CAPSULE_VARIABLE_IMPORT_AUTH_2 0x08
• #define EBBR_CAPSULE_VARIABLE_IMPORT_AUTH_3 0x10 > +

+- If the firmware supports exporting variables via a configuration

table,

...

• the EBBR_CAPSULE_VARIABLE_EXPORT bit must be set, and the firmware

must

...

• create a configuration table identified by the VARIABLE_STORAGE_GUID
• (defined below) before any EFI applications are started, and must

update it

...

• any time a variable is altered via SetVariable(), until

ExitBootServices()

...

• has successfully returned.

Hmmm. What I thought you were describing when we talked doesn't match up with what you're recommending here. I guess I misunderstood at first. Originally I though you were suggesting for the OS loader to extract the full set of UEFI variables, cache them in a configuration table, and then pick them up again after the kernel has booted. This is a solution that would work now without any changes to firmware (though it could still be argued unnecessary because we don't have any technical barriers to implementing GetVariable() during Runtime Services. Only GetVariable() is the problem).

However, it looks like you're suggesting the firmware be responsible for exporting variables into a configuration table. I'm not fond of this approach because it create a new firmware interface that does exactly the same thing as GetVariable() does right now.

...

+- If the firmware supports importing non-volatile variables via a

Capsule

...

• on Disk, the EBBR_CAPSULE_VARIABLE_IMPORT bit must be set, and the
• firmware must load its initial variable storage during boot services
• from a capsule with the EFI_CAPSULE_HEADER.CapsuleGuid set to
• VARIABLE_STORAGE_GUID.

It sounds like the model here is the firmware stores the entire set of variables in a capsule, which is rewritten by the kernel if the variable change. Do I have this correct? If so, I think this is a fragile model. There are all kinds of things that can go wrong if the new capsule gets corrupted, or potentially security attack vectors by editing/deleting the entire variable storage.

Could we instead make the import capsule contain a log of variable changes that modify the 'committed' variable set. Firmware can perform appropriate checks on each variable change before committing the change. This too doesn't require firmware behaviour changes other than parsing the variable storage capsule presuming the boot services SetVariable() call can be used to perform the updates.

...

+- If the firmware supports authenticated variables, the bits

• EBBR_CAPSULE_VARIABLE_IMPORT_AUTH,

EBBR_CAPSULE_VARIABLE_IMPORT_AUTH_2,

...

• and EBBR_CAPSULE_VARIABLE_IMPORT_AUTH_3 must be set to indicate

support for

...

• EFI_VARIABLE_AUTHENTICATION, EFI_VARIABLE_AUTHENTICATION_2, and
• EFI_VARIABLE_AUTHENTICATION_3 descriptors defined in [UEFI]_ 8.2.

+- If the CapsuleVariableSupport variable is not set, the OS must behave

as if

...

• all bits are 0.

+- Any bits which are not present in the CapsuleVariableSupport variable

must

...

• be treated as 0.

+Variable storage data format +----------------------------

+The Variable Configuration Table and the Variable Update Capsule

structure

...

+share the same data format, and are structured as a capsule update

containing

...

+a packed array of update records:

+#define VARIABLE_STORAGE_GUID \

•    {0x1a3fb419, 0x2171, 0x458d,\
  

•     {0xb8, 0xb4, 0xbe, 0xa3, 0x0c, 0x9f, 0x6b, 0xab }}
  

+typedef struct {

• CHAR16[64] VariableName;
• EFI_GUID VendorGuid;
• UINT32 Attributes;
• UINT32 DataSize;
• UINT8[] Data;

+} EBBR_VARIABLE;

+typedef struct {

• EFI_CAPSULE_HEADER Header;
• UINT8[Header.HeaderSize - sizeof(EFI_CAPSULE_HEADER)] Reserved;
• EBBR_VARIABLE[] Variables;

+} EBBR_VARIABLE_BUNDLE __attribute__((__packed__));

+- EBBR_VARIABLE_BUNDLE.Header.CapsuleGuid must be VARIABLE_STORAGE_GUID +- EBBR_VARIABLE_BUNDLE.Reserved may be 0 or more bytes. +- EBBR_VARIABLE_BUNDLE.Header.HeaderSize is equal to the starting

offset of

...

• the EBBR_VARIABLE_BUNDLE.Variables array.

+- EBBR_VARIABLE_BUNDLE.Variables may be 0 or more bytes. +- EBBR_VARIABLE_BUNDLE.Header.CapsuleImageSize is the full size of the

capsule

...

• including the Header, Reserved, and all Variable array members.

+- EBBR_VARIABLE_BUNDLE.Header.Flags must not have any of the following

set:

...

• CAPSULE_FLAGS_INITIATE_RESET

+- EBBR_VARIABLE_BUNDLE.Header.Flags should have all of the following

set:

...

• CAPSULE_FLAGS_PERSIST_ACROSS_RESET
• CAPSULE_FLAGS_POPULATE_SYSTEM_TABLE

+Variable Configuration Table creation +-------------------------------------

+Any platform firmware which supports EBBR_CAPSULE_VARIABLE_EXPORT must +install a UEFI Configuration Table with all appropriate variables

specified

...

+in [UEFI]_ 3.3, as well as any variables which have been imported from a +Variable Update Capsule or set through SetVariable().

+- The platform firmware must not include multiple entries for the same

• variable.

+- The platform should avoid storing any secrets in variables, including

• variables without EFI_VARIABLE_RUNTIME_SERVICES set.

+Variable Configuration Table processing +---------------------------------------

+When processing the Variable Configuration Table, the OS must treat each +EBBR_VARIABLE_BUNDLE.Variable entry as if it were a call to

SetVariable()

...

+before ExitBootServices() has been called: > + +- The variables are processed according to the requirements in [UEFI]_

8.2

...

+- Any update which would result in SetVariable() returning an error must

• be ignored.

+- The OS should preserve entries with EFI_VARIABLE_NON_VOLATILE set but

• EFI_VARIABLE_RUNTIME_SERVICES unset, and save them to a Variable

Updates

...

• Capsule before system reset.

+- Any entry without EFI_VARIABLE_RUNTIME_SERVICES set must not be

exposed to

...

• consumers of GetVariable().

+- Any entry authenticated with an Authentication Descriptor the OS does

not

...

• support should be preserved, but must not be exposed to consumers of
• GetVariable(). Any following entry for any such variable must be

treated

...

• the same.

+- All authenticated variables should have their Authentication

Descriptors

...

• preserved, but only the encapsulated data should be presented through
• GetVariable()-like interfaces.

+- The OS must take measures to prevent data in variables without

• EFI_VARIABLE_RUNTIME_SERVICES set from being exposed to unprivileged

tasks.

...

+Runtime Processing +------------------

+The OS must take certain measures during runtime operation to insure +consistency:

+- The OS must keep a log of any updates to variables, including delete,

• append, and create operations.

+- The OS should attempt to simulate each operation as it would be

applied

...

• during the Variable Updates Capsule processing, in order to maintain a
• view which is coherent across a reset.

+Variable Updates Capsule creation +---------------------------------

+Before system reset, the OS should create a Variable Updates Capsule as

a

...

+Capsule on Disk defined in [UEFI]_ 8.5.5 . If a platform supports both +EBBR_CAPSULE_VARIABLE_EXPORT and EBBR_CAPSULE_VARIABLE_IMPORT, the

capsule

...

+should preserve the following from the Variable Configuration Table, if

it

...

+was present:

+- EBBR_VARIABLE_BUNDLE.Header.HeaderSize,

EBBR_VARIABLE_BUNDLE.Header.Flags,

...

• and EBBR_VARIABLE_BUNDLE.Reserved fields

+- Any variables with EFI_VARIABLE_NON_VOLATILE set, including those

without

...

• EFI_VARIABLE_RUNTIME_SERVICES set

+- Any variables authenticated with Authentication Descriptors not

supported

...

• by the OS.

+- Runtime updates to authenticated variables must be included

individually,

...

• including any authenticated deletion.

+- Runtime operations on newly created variables which are not

authenticated

...

• may be coalesced to a single entry.

+Variable Updates Capsule processing +-----------------------------------

+During boot, the system firmware must create the variables specified in

[UEFI]_

...

+3.3 before processing the capsule update, and it must ensure that the

variables

...

+implemented in the UEFI spec are treated as specified at all times.

When

...

+processing a Variable Updates Capsule, the firmware must process each

record in

...

+the order they appear in the Variables array as if each were a call to +SetVariable() after ExitBootServices():

+- The variables are processed according to the requirements in [UEFI]_

8.2

...

+- Any update without the EFI_VARIABLE_NON_VOLATILE attribute set must be

• ignored.

+- Any update which would result in SetVariable() returning an error must

• be ignored.

+- Any variable authenticated with an unsupported Authentication

Descriptor

...

• not supported by the platform must be ignored.

Okay, now I'm confused because this matches what I thought you were talking about with the OS providing an update capsule, not a capsule containing the entire storage. This I agree with. What is the point of providing variable export in a configuration table then? And the language above seems to suggest firmware must store its entire variable pool in a capsule, which doesn't make sense to me.

Let's chat at the meeting today. g.

---

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