Re: [PATCH] Base boot and runtime requirements - initial commit


Rahul Pathak
 

On Fri, Apr 9, 2021 at 11:11 AM Heinrich Schuchardt <xypron.glpk@...> wrote:

On 4/9/21 6:25 AM, Rahul Pathak wrote:
Initial changes for the Base Boot & Runtime requirements.
The sections which are currently in-progress are marked as TBD.
These changes can serve as the starting point and more details/changes can be done tailored for RISC-V
This is the main patch, there are minor changes in the contributors file and the changelog which are not relevant for now so I am not sending those.


Signed-off-by: Rahul Pathak <rpathak@...>
---
riscv-platform-spec.adoc | 86 ++++++++++++++++++++++++++++++++++++----
1 file changed, 79 insertions(+), 7 deletions(-)

diff --git a/riscv-platform-spec.adoc b/riscv-platform-spec.adoc
index 003181c..fd5e918 100644
--- a/riscv-platform-spec.adoc
+++ b/riscv-platform-spec.adoc
@@ -32,6 +32,35 @@ include::profiles.adoc[]
// Linux-2022 Platform
== Linux-2022 Platform

+=== Terminology
+[cols="1,2", width=80%, align="left", options="header"]
+|===
+|TERM | DESCRIPTION
+|SBI | Supervisor Binary Interface
+|UEFI | Unified Extensible Firmware Interface
+|ACPI | Advanced Configuration and Power Interface
+|SMBIOS | System Management Basic I/O System
+|DTS | Devicetree source file
+|DTB | Devicetree binary
+|RVA22 | RISC-V Application 2022
+|RV32GC | RISC-V 32-bit general purpose ISA described as RV32IMAFDC.
+|RV64GC | RISC-V 64-bit general purpose ISA described as RV64IMAFDC.
+|===
+
+
+=== Specifications
+[cols="1,2", width=80%, align="left", options="header"]
+|===
+|SPECIFICATION | VERSION
+|link:https://uefi.org/sites/default/files/resources/UEFI_Spec_2_9_2021_03_18.pdf[UEFI Specification] | v2.9
+|link:https://github.com/devicetree-org/devicetree-specification/releases/tag/v0.3[Devicetree Specification] | v0.3
+|link:https://github.com/riscv/riscv-sbi-doc/blob/master/riscv-sbi.adoc[SBI Specification] | v0.3-rc0
+|link:[RVA22 Specification] | TBD
+|link:https://arm-software.github.io/ebbr/[EBBR Specification] | v2.0.0-pre1
+|link:https://uefi.org/sites/default/files/resources/ACPI_Spec_6_4_Jan22.pdf[ACPI Specification] | v6.4
+|link:https://www.dmtf.org/sites/default/files/standards/documents/DSP0134_3.4.0.pdf[SMBIOS Specification] | v3.4.0
+|===
+
// Base feature set for Linux-2022 Platform
=== Base
==== Architecture
@@ -57,14 +86,57 @@ include::profiles.adoc[]
* Timers
* Watchdog Timers

-==== Boot Process
-* Firmware
-* Boot-Loader
-* Discovery Mechanisms
+==== Boot and Runtime Requirements
+- The base specification defines the interface between the firmware and the operating system suitable for the RISC-V platforms with rich operating systems.
Please, format the text with 80 characters per line.
I didn't do that because unlike code here the adoc will get converted
into the html while rendering on github or any other editor which can
handle the text wrapping dynamically
as per the screen size. That's what I thought but if it's still
required then I will do that.


+- These requirements specifies the required boot and runtime services, device discovery mechanism, etc.
+- The requirements are operating system agnostic, specific firmware/bootloader implementation agnostic.
+- The base boot specification depends on the RVA22 profile and all requirements from the RVA22 profile must be implemented.
What is RVA22? At least once the whole name should be mentioned. Where
can I find the RVA22 spec?
I think Greg answered this.


+- The base runtime specification depends on the RISC-V SBI specification and all requirements from the SBI spec must be implemented.
+- Any RV32GC or RV66GC system with Machine, Supervisor, User Mode can comply with the specification. Hypervisor Extension is optional. _**Will be defined in this spec if the RVA22 spec does not mention it.**_
%s/RV66GC/RV64GC/
Will correct this.


+- For the generic mandatory requirements this base specification will refer to the EBBR Specification. Any deviation from the EBBR will be explicitly mentioned in the requirements.
+- Specifications followed are mentioned in the <<Specifications,Specification Section>>
+- For more on scope of MANDATORY, DEPRECATED, COMPATIBILITY refer Platform Policy Specification.
+
+
+===== Firmware
+- UEFI Platform must meet RISC-V Platform requirements on calling conventions, ABI support and the control handoff specific to RISC-V. Refer Chapter - 2.3.7 RISC-V Platforms of UEFI specification.
+- For compliance with base specification platform must implement link:https://arm-software.github.io/ebbr/#required-elements[EBBR - UEFI Required Elements], link:https://arm-software.github.io/ebbr/#required-platform-specific-elements[EBBR - UEFI Platform Specific Elements] and support the following link:https://arm-software.github.io/ebbr/#required-global-variables[EBBR - Global Variables].
+
+====== Block Device Partition Format
+- Firmware must implement the support for GPT Partitioning and meet the requirements as per the link:https://arm-software.github.io/ebbr/#firmware-storage[EBBR Firmware Storage].
+
+===== Boot Services
+- Base specification compliant firmware must implement all UEFI functions marked as EFI_BOOT_SERVICES.
+
+====== Multiprocessor Startup Protocol
+- Firmware shall use the Machine privilege level(M-Mode) to load UEFI drivers and boot applications which provides the boot and runtime services. Though these UEFI images must not be tightly coupled with any specific privilege level.
The UEFI spec says: "RISC-V UEFI firmware could be executed in either
Machine mode or Supervisor mode during the entire POST, according to the
hart capability and the platform design."

In future we want to run trusted applications like OP-TEE. The UEFI
firmware will not be a trusted application. Therefore the UEFI firmware
should run in S-mode (or once we have the hypervisor extension in HS- or
VS-mode) and not in M-mode.
We need to see how this can be represented here also since there is a
separate chapter on secure boot which should be dealing with
these scenarios, That's why I went with the simplest scenario for now.


Compare this to the ARM world. TF-A BL2, BL30, BL31, BL32 run in EL3.
BL33 (U-Boot, EDK II) runs in EL2.
Yeah, more scenarios need to be added like when H extension is implemented.



Here is on example why UEFI cannot be a trusted application: UEFI may
execute firmware from PCIe-ROMs. As arbitrary PCIe devices may be
plugged in by the user the ROMs cannot be trusted.
Again, should be covered in the secure boot chapter.
I will pass on these comments to the author of that chapter. There is
no one yet.



Currently OpenSBI runs in M-mode while main U-Boot is running in S-mode.
Where U-Boot's SPL is used to load OpenSBI U-Boot's SPL runs in M-mode.

+- After the completion of boot process from UEFI context, firmware shall launch the next stage bootloader or rich operating system in Supervisor privilege level(S-Mode).
This switch should occur at the handoff from SBI to the UEFI firmware.
I don't think this is right. Since the UEFI implementation will be
implementing the SBI as runtime services. Currently EDK II integrates
OpenSBI as a library.
The simplest boot flow I think should be "ZSBL/FSBL(M-Mode) -->
EDKII (M-Mode, OpenSBI Library for Runtime) --> Bootloader (S-Mode)
---> Linux (S-Mode).
Though EDKII can launch the linux directly but the requirements will
not be dealing with this level of details.


+- Before yielding control to S-Mode stage, firmware must configure the M-Mode state. Refer the RISC-V SBI specification for details.
+- If the Hypervisor Extension is implemented. **TBD**.
+
+
+====== Memory Map
+- UEFI environment must provide a system memory map and meet the requirements for link:https://arm-software.github.io/ebbr/#memory-map[EBBR - Memory Map].
+
+===== Boot-Loader
+**TBD**
+
+===== Discovery Mechanisms
+- The base specification mandates the use of Devicetree for system description.
Please, add a reference to the devicetree specification:

DeviceTree Specification Release v0.3 - Released 13 February 2020
https://github.com/devicetree-org/devicetree-specification/releases/tag/v0.3
This reference is already added in the "Specification" table at the
top. But I will also mention explicitly here to refer that table.

+- System must meet link:https://arm-software.github.io/ebbr/#devicetree[EBBR - Devicetree requirements] to comply with this base specification. Also refer Devicetree tables section in chapter - 4.6 EFI Configuration Table & Properties Table of UEFI specification.
+
+===== Runtime Services
+====== SBI
+- Firmware must implement the runtime services/extensions specified by the RISC-V SBI Specification.
+- Operating System must prioritize the UEFI Interface before falling back to SBI Interface or architecture/platform specific methods for runtime services. For example, ResetSystem() if not implemented by the UEFI runtime services the OS shall use the SBI Reset Extension and platform specific mechanism for system reset.
We should require that the UEFI runtime implements ResetSystem() via the
SBI reset extension. This way we ensure that there is only one place
where this is coded.
Agree, EBBR has this optional for Runtime Services. We shall mandate
this to implement in this spec. I will update this.


+- Legacy Extensions from the SBI Specification are deprecated and must not be implemented.
+
+====== UEFI
+- Firmware must conform to the link:https://arm-software.github.io/ebbr/#uefi-runtime-services[EBBR - UEFI EFI_RUNTIME_SERVICES requirements].
+- Firmware must meet the requirements for link:https://arm-software.github.io/ebbr/#runtime-device-mappings[EBBR - Runtime Device Mappings] to avoid conflict between the firmware and OS which accessing the mapped devices.
%s/which/when/
Will correct this.


Best regards

Heinrich

+- Compliant UEFI runtime environment must meet the requirements for the link:https://arm-software.github.io/ebbr/#runtime-variable-access[EBBR - Runtime Variable Access].
+- Compliant implementation must meet the Realtime Clock requirements link:https://arm-software.github.io/ebbr/#real-time-clock-rtc[EBBR - UEFI RTC interface] if RTC is present in the system.

-==== Runtime services
-* SBI
-* UEFI

// Server extension for Linux-2022 Platform
=== Server Extension
Thanks
Rahul Pathak


On Fri, Apr 9, 2021 at 11:11 AM Heinrich Schuchardt <xypron.glpk@...> wrote:

On 4/9/21 6:25 AM, Rahul Pathak wrote:
Initial changes for the Base Boot & Runtime requirements.
The sections which are currently in-progress are marked as TBD.
These changes can serve as the starting point and more details/changes can be done tailored for RISC-V
This is the main patch, there are minor changes in the contributors file and the changelog which are not relevant for now so I am not sending those.


Signed-off-by: Rahul Pathak <rpathak@...>
---
riscv-platform-spec.adoc | 86 ++++++++++++++++++++++++++++++++++++----
1 file changed, 79 insertions(+), 7 deletions(-)

diff --git a/riscv-platform-spec.adoc b/riscv-platform-spec.adoc
index 003181c..fd5e918 100644
--- a/riscv-platform-spec.adoc
+++ b/riscv-platform-spec.adoc
@@ -32,6 +32,35 @@ include::profiles.adoc[]
// Linux-2022 Platform
== Linux-2022 Platform

+=== Terminology
+[cols="1,2", width=80%, align="left", options="header"]
+|===
+|TERM | DESCRIPTION
+|SBI | Supervisor Binary Interface
+|UEFI | Unified Extensible Firmware Interface
+|ACPI | Advanced Configuration and Power Interface
+|SMBIOS | System Management Basic I/O System
+|DTS | Devicetree source file
+|DTB | Devicetree binary
+|RVA22 | RISC-V Application 2022
+|RV32GC | RISC-V 32-bit general purpose ISA described as RV32IMAFDC.
+|RV64GC | RISC-V 64-bit general purpose ISA described as RV64IMAFDC.
+|===
+
+
+=== Specifications
+[cols="1,2", width=80%, align="left", options="header"]
+|===
+|SPECIFICATION | VERSION
+|link:https://uefi.org/sites/default/files/resources/UEFI_Spec_2_9_2021_03_18.pdf[UEFI Specification] | v2.9
+|link:https://github.com/devicetree-org/devicetree-specification/releases/tag/v0.3[Devicetree Specification] | v0.3
+|link:https://github.com/riscv/riscv-sbi-doc/blob/master/riscv-sbi.adoc[SBI Specification] | v0.3-rc0
+|link:[RVA22 Specification] | TBD
+|link:https://arm-software.github.io/ebbr/[EBBR Specification] | v2.0.0-pre1
+|link:https://uefi.org/sites/default/files/resources/ACPI_Spec_6_4_Jan22.pdf[ACPI Specification] | v6.4
+|link:https://www.dmtf.org/sites/default/files/standards/documents/DSP0134_3.4.0.pdf[SMBIOS Specification] | v3.4.0
+|===
+
// Base feature set for Linux-2022 Platform
=== Base
==== Architecture
@@ -57,14 +86,57 @@ include::profiles.adoc[]
* Timers
* Watchdog Timers

-==== Boot Process
-* Firmware
-* Boot-Loader
-* Discovery Mechanisms
+==== Boot and Runtime Requirements
+- The base specification defines the interface between the firmware and the operating system suitable for the RISC-V platforms with rich operating systems.
Please, format the text with 80 characters per line.

+- These requirements specifies the required boot and runtime services, device discovery mechanism, etc.
+- The requirements are operating system agnostic, specific firmware/bootloader implementation agnostic.
+- The base boot specification depends on the RVA22 profile and all requirements from the RVA22 profile must be implemented.
What is RVA22? At least once the whole name should be mentioned. Where
can I find the RVA22 spec?

+- The base runtime specification depends on the RISC-V SBI specification and all requirements from the SBI spec must be implemented.
+- Any RV32GC or RV66GC system with Machine, Supervisor, User Mode can comply with the specification. Hypervisor Extension is optional. _**Will be defined in this spec if the RVA22 spec does not mention it.**_
%s/RV66GC/RV64GC/

+- For the generic mandatory requirements this base specification will refer to the EBBR Specification. Any deviation from the EBBR will be explicitly mentioned in the requirements.
+- Specifications followed are mentioned in the <<Specifications,Specification Section>>
+- For more on scope of MANDATORY, DEPRECATED, COMPATIBILITY refer Platform Policy Specification.
+
+
+===== Firmware
+- UEFI Platform must meet RISC-V Platform requirements on calling conventions, ABI support and the control handoff specific to RISC-V. Refer Chapter - 2.3.7 RISC-V Platforms of UEFI specification.
+- For compliance with base specification platform must implement link:https://arm-software.github.io/ebbr/#required-elements[EBBR - UEFI Required Elements], link:https://arm-software.github.io/ebbr/#required-platform-specific-elements[EBBR - UEFI Platform Specific Elements] and support the following link:https://arm-software.github.io/ebbr/#required-global-variables[EBBR - Global Variables].
+
+====== Block Device Partition Format
+- Firmware must implement the support for GPT Partitioning and meet the requirements as per the link:https://arm-software.github.io/ebbr/#firmware-storage[EBBR Firmware Storage].
+
+===== Boot Services
+- Base specification compliant firmware must implement all UEFI functions marked as EFI_BOOT_SERVICES.
+
+====== Multiprocessor Startup Protocol
+- Firmware shall use the Machine privilege level(M-Mode) to load UEFI drivers and boot applications which provides the boot and runtime services. Though these UEFI images must not be tightly coupled with any specific privilege level.
The UEFI spec says: "RISC-V UEFI firmware could be executed in either
Machine mode or Supervisor mode during the entire POST, according to the
hart capability and the platform design."

In future we want to run trusted applications like OP-TEE. The UEFI
firmware will not be a trusted application. Therefore the UEFI firmware
should run in S-mode (or once we have the hypervisor extension in HS- or
VS-mode) and not in M-mode.

Compare this to the ARM world. TF-A BL2, BL30, BL31, BL32 run in EL3.
BL33 (U-Boot, EDK II) runs in EL2.

Here is on example why UEFI cannot be a trusted application: UEFI may
execute firmware from PCIe-ROMs. As arbitrary PCIe devices may be
plugged in by the user the ROMs cannot be trusted.

Currently OpenSBI runs in M-mode while main U-Boot is running in S-mode.
Where U-Boot's SPL is used to load OpenSBI U-Boot's SPL runs in M-mode.

+- After the completion of boot process from UEFI context, firmware shall launch the next stage bootloader or rich operating system in Supervisor privilege level(S-Mode).
This switch should occur at the handoff from SBI to the UEFI firmware.

+- Before yielding control to S-Mode stage, firmware must configure the M-Mode state. Refer the RISC-V SBI specification for details.
+- If the Hypervisor Extension is implemented. **TBD**.
+
+
+====== Memory Map
+- UEFI environment must provide a system memory map and meet the requirements for link:https://arm-software.github.io/ebbr/#memory-map[EBBR - Memory Map].
+
+===== Boot-Loader
+**TBD**
+
+===== Discovery Mechanisms
+- The base specification mandates the use of Devicetree for system description.
Please, add a reference to the devicetree specification:

DeviceTree Specification Release v0.3 - Released 13 February 2020
https://github.com/devicetree-org/devicetree-specification/releases/tag/v0.3

+- System must meet link:https://arm-software.github.io/ebbr/#devicetree[EBBR - Devicetree requirements] to comply with this base specification. Also refer Devicetree tables section in chapter - 4.6 EFI Configuration Table & Properties Table of UEFI specification.
+
+===== Runtime Services
+====== SBI
+- Firmware must implement the runtime services/extensions specified by the RISC-V SBI Specification.
+- Operating System must prioritize the UEFI Interface before falling back to SBI Interface or architecture/platform specific methods for runtime services. For example, ResetSystem() if not implemented by the UEFI runtime services the OS shall use the SBI Reset Extension and platform specific mechanism for system reset.
We should require that the UEFI runtime implements ResetSystem() via the
SBI reset extension. This way we ensure that there is only one place
where this is coded.

+- Legacy Extensions from the SBI Specification are deprecated and must not be implemented.
+
+====== UEFI
+- Firmware must conform to the link:https://arm-software.github.io/ebbr/#uefi-runtime-services[EBBR - UEFI EFI_RUNTIME_SERVICES requirements].
+- Firmware must meet the requirements for link:https://arm-software.github.io/ebbr/#runtime-device-mappings[EBBR - Runtime Device Mappings] to avoid conflict between the firmware and OS which accessing the mapped devices.
%s/which/when/

Best regards

Heinrich

+- Compliant UEFI runtime environment must meet the requirements for the link:https://arm-software.github.io/ebbr/#runtime-variable-access[EBBR - Runtime Variable Access].
+- Compliant implementation must meet the Realtime Clock requirements link:https://arm-software.github.io/ebbr/#real-time-clock-rtc[EBBR - UEFI RTC interface] if RTC is present in the system.

-==== Runtime services
-* SBI
-* UEFI

// Server extension for Linux-2022 Platform
=== Server Extension

Join tech-unixplatformspec@lists.riscv.org to automatically receive all group messages.