> Am 25.09.2018 um 16:50 schrieb Ard Biesheuvel <[email protected]>: > >> On Tue, 25 Sep 2018 at 16:45, Grant Likely <[email protected]> wrote: >> >>> On 24/09/2018 16:22, Ard Biesheuvel wrote: >>>> On Mon, 24 Sep 2018 at 15:54, Grant Likely <[email protected]> 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 <[email protected]> >>>> --- >>>> 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 _______________________________________________ boot-architecture mailing list [email protected] https://lists.linaro.org/mailman/listinfo/boot-architecture
