On Tue, Sep 25, 2018 at 9:51 AM Ard Biesheuvel ard.biesheuvel@linaro.org 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 all32-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?
I would say yes, we should push for that change or allow for deviation in that case otherwise virtualization and EBBR are mutually-exclusive. Or is virtualization on v7 too broken (lack of IOMMUs, GICv2, etc.) to really be used anyways?
Rob