Purpose of this ticket, to document, some sort of compliance test to declare that platform supports EBBR.

Is UEFI SCT is enough for this ?

In Section 4.2, we currently have the following recommendation:

Vendors are recommended to use their Devicetree vendor prefix as their vendor subdirectory name.

Vendors that only produce platforms based on ACPI may not have such a prefix. Since ACPI is the preferred system description method (and the only one supported in SBBR), I suggest adding the words "ACPI vendor ID or" before "Devicetree vendor prefix", to read:

Vendors are recommended to use their ACPI vendor ID or Devicetree vendor prefix as their vendor subdirectory name.

Add an appendix that has example use cases to show the value and illustrate operation.
These are examples and are not requirements.
Will reference example platforms to show how use case can be achieved

Include such things as:

• Installer removable media (or net boot media) installing to platform
• Board specific media that prompts user for selection of possible OS'es to install (like RPi Noob)
• OS Live disk image
• Board specific recovery image (include to show that it is not bound to EBBR rules)

Current language in EBBR requires runtime SetVariable() to work without OS intervention. However, there is no mechanism for doing this on systems with shared storage. (e.g. the OS owns the eMMC device, and corruption can occur if firmware attempts to perform writes to eMMC at runtime).

The language in chapter 3, section "Set Variable" needs to be fixed.

For attested boot we should support the EFI TPM2 protocol. It shouldn't be a hard requirement but would be useful for IoT devices and other related devices.

UEFI spec doesn't know anything about the configuration table GUID for FDT.

See https://uefi.org/sites/default/files/resources/UEFI_Spec_2_8_A_Feb14.pdf#page=172

...because of that, this spec should cover the GUID used to pass FDT (e.g. gFdtTableGuid = { 0xb1b621d5, 0xf19c, 0x41a5, { 0x83, 0x0b, 0xd9, 0x15, 0x2c, 0x69, 0xaa, 0xe0 } }), as well as requirements on memory - should this BS Data or RT Data? Should the memory type be ACPI NVS or it doesn't matter?

A

We should specify and have in the reference implementation support for UEFI secure boot.
There would need to be means to enroll keys etc.

Not all embedded platforms have an RTC, UEFI requires it.
Should it be optional in EBBR? At least for early levels?
Should we recommend OS actions to deal with this?

For binaries the UEFI specifies a default path for the storage of boot images to run if these are not specified by BootXXXX variables.

For flattened device trees (*.dtb) such a directory is not defined. U-Boot searches the EFI partition paths , \dtb, \dtb\current for a filename specified in the U-Boot configuration (CONFIG_DEFAULT_DEVICE_TREE) by default.

When using boot options BootXXXX or BootNext it is not specified how to declare the related device tree file. A solution might be to use variables FdtXXXX and FdtNext to define the device paths of the FDT matching the boot option.

Current EBBR text only talks about AArch64 support. We want to support AArch32 also.

Add the requirements for AArch32

Section 24.7 HTTP boot of version 2.7 of the UEFI spec. Useful for provisioning of devices.

The current README helps people get started on building the document from source and helping to author it. This is good and helpful.

However, right up front we should provide guidance for people that find this site that only want to read the current version (or current released version). Is this just a link to the single *.md file or will it be more complex in the future? When we have a PDF CI loop we could publish the PDF results also and (under a constant URL) add a link in the README.

In chapter 4 this requirement is made:

"Firmware needs a method to modify variable storage at runtime while the OS controls access to the device."

In the footnote: "If firmware doesn't have a dedicated channel to the storage device, then the OS must proxy all runtime storage IO."

• The requirement is superfluous if we do not require SetVariable() to be implemented.
• It is completely unclear how an OS could proxy runtime storage IO.

The requirement should be removed.

From mailing list discussion (courtesy Sumit Garg):

What do you think of a security addendum or checklist that goes
alongside EBBR to detail what is required to make the platform actually
secure?

I would be in favour of such a security addendum.

IMO, "make the platform actually secure" has a bit wider scope than
just secure boot. And the scope may vary depending on the threat model
which may be specific to a particular use-case. So I will try to list
down security features along with their requirements as follows.
Please feel free to extend this list in case I missed any relevant
security feature:

Feature: Secure boot
Platform requirements:

• BootROM being the Root of Trust for Secure boot shall initiate the
  chain of trust via verifying the first stage boot-loader.
• Provide platform binding of the root public key used for verification.

Feature: Anti-rollback protection
Platform requirements:

• BootROM shall provide anti-rollback protection for first stage
  boot-loader updates.

Feature: Unbrickable firmware updates
Platform requirements:

• BootROM shall support A/B partition scheme to load first stage
  boot-loader from alternate locations.

Feature: Secure storage
Platform requirements:

• Either provide a dedicated non-volatile memory accessible to secure
  world only or provide a RPMB based secure storage.
• Provide a Hardware Unique Key (HUK) which is accessible to the
  secure world only.

Feature: Secure entropy source
Platform requirements:

• Provide a hardware entropy source which is accessible to secure world only.

Feature: Memory firewalls / TZASC
Platform requirements:

• Provide a way to carve out DRAM so that it's accessible to the
  secure world only.

Feature: Secure peripherals / TZPC
Platform requirements:

• Provide a way to partition peripherals so that secure peripherals
  are accessible to secure world only.

Currently, the specification lists certain UEFI protocols as required, and others optional. Some protocols, for example EFI_GRAPHICS_OUTPUT_PROTOCOL, are listed in neither category. This can be construed such that supporting EFI_GRAPHICS_OUTPUT_PROTOCOL is forbidden.

It needs to be clarified what it means for a protocol to be optional vs. not listed at all.

The reserved memory node of the device-tree may have the following properties according to https://www.kernel.org/doc/Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt:

• compatible
• no-map
• reusable

We need should define how these properties should be modeled in the memory map returned by GetMemoryMap().

In the EBBR we require to implement everything that is in chapter "2.6 Requirements" of the UEFI spec if it is not explicitly excluded in the EBBR.

• This requires scope that is far too big for the embedded use case.
• This is not easily testable because of the many cross references in the UEFI spec.
• It is a scope that U-Boot will never implement.

We should return to a positive list of requirements.

Here are examples of what should be discussed:

• support for EFI_LOAD_FILE_PROTOCOL and EFI_LOAD_FILE2_PROTOCOL in LoadImage()
• support for EFI_PLATFORM_DRIVER_OVERRIDE_PROTOCOL and EFI_DRIVER_FAMILY_OVERRIDE_PROTOCOL in ConnectController()
• supported nodes in EFI_DEVICE_PATH_TO_TEXT_PROTOCOL

Especially for protocols to be implemented we need a list identifying the once really needed to be implemented. Protocols required by chapter 2.6 and not implemented in U-Boot include for example:

• EFI_DISK_IO_PROTOCOL
• EFI_NETWORK_INTERFACE_IDENTIFIER_PROTOCOL
• EFI_EDID_DISCOVERED_PROTOCOL
• EFI_EDID_ACTIVE_PROTOCOL

The reserved memory node of the device-tree may have the following properties according to https://www.kernel.org/doc/Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt:

• compatible
• no-map
• reusable

We need should define how these properties should be modeled in the memory map returned by GetMemoryMap().

We shouldn't specify the /FIRMWARE hierarchy in the ESP unless we get agreement from the UEFI USWG chair. Need to send an email requesting that structure.

Many embedded platforms only have a single type of storage (ex. eMMC) that is used to store firmware images, firmware variables, and the operating system itself. Shared storage poses problems if both firmware and the OS need to access it at runtime (ex. to store variables in a SetVariable() runtime service call).

Document what is required of the firmware and of the OS to used shared storage for variable storage at runtime.

Draft EBBR does not mention any hardware requirement expect ARM CPU architecture.
Purpose of this ticket to mention hardware need (if any) like interrupt controllers, timers etc.
IMO, a small note in this document should be ok .

To facilitate storing system firmware for multiple SoCs on the same block device, we need a standard path layout for where to store the firmware files. Each Vendor/SoC should get its own subdirectory.

Having a path standard is needed for both the separate system firmware partition scenario, and the firmware-files-in-ESP scenario

We should require device trees to be backwards compatible. The easiest way to ensure this is to have a tag in the DT that tells reviewers and users of the DT that they can expect backwards compatibility of the device tree.

This tag and requirement of the tag needs to get documented in EBBR. Without the tag, EBBR compliance won't exist.

The tag also needs to get an official binding in the Linux DT binding documents.

I think we need an intro section that shows what our approach is and why this is different than the server requirements.

Examples: (not these words)

• Spec is implementation independent but is defined so it can be satisfied by Tianocore/EDK2 or u-boot
• DeviceTree or ACPI
• "Embedded" platforms may not have RTC or require OS and firmware to share a single storage medium

We should also discuss the "levels" of EBBR and how we approach that.

UEFI 2.8B spec chapter "2.3.7.3 Detailed Calling Convention" does not describe which registers are saved by the UEFI payload's entry point and restored by the payload before calling the UEFI API or returning to the UEFI payload. This concerns especially
registers gp (x3) and tp (x4).

Into the EBBR or UEFI spec we should put a link to the "RISC-V ELF psABI specification" https://github.com/riscv/riscv-elf-psabi-doc/blob/master/riscv-elf.md which is referenced by "The RISC-V Instruction Set Manual".

From the "RISC-V ELF psABI specification" one might conclude that the UEFI payload should not be allowed to change gp and tp before calling ExitBootServices() or SetVirtualAddressMap() whichever occurs last.

Due to this missing clarification U-Boot is currently saving gp before calling the entry point of the payload and restores it on reentry or on entry of an API call. Nothing is done for tp.

The ResetSystem() runtime service is marked as optional after ExitBootServices().

With UEFI 2.8 Erratum A the OS would be able to detect that it is not implemented by inspecting the configuration table EFI_RT_PROPERTIES_TABLE. Linux before patch 9b42f76ad58b3f6 does not check this table.

So it is unclear what an unimplemented ResetSystem() should do:

• simply return (as EDK II mentions in comments)
• hang in an endless loop (as U-Boot v2020.07 does)

ResetShutdown() has this comment in EDK II: "System shutdown should not return, if
it returns, it means the system does not support shut down reset."

ResetWarm() has this comment in EDK II: "System reset should not return, if it
returns, it means the system does not support warm reset."

If ResetSystem() returns, Linux will try to reset the board by its own means which makes more sense than hanging in an endless loop.

Best regards

Heinrich

cc. @agraf

The UEFI spec has this sentence:

"When UEFI firmware handoff control to OS, the RISC-V is operated in machine-mode privilege." (M-mode is the equivalent to EL3 in ARM). This does not make any sense to me when using a secure execution environement (SEE) like OpenSBI.

The hand-off should occur in S-Mode if the CPU supports it and only in M-Mode when the CPU only supports M-mode.

We should prescribe this in the EBBR and somehow get the UEFI spec fixed afterwards.

GPT partitioning is preferred, but many SoCs use boot schemes that are incompatible with the GPT partition table.

Change the spec to allow MBR or GPT partitioning

Some feedback on EBBR suggested that this doesn't match how an existing OS already behaves:

"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."

It can be argued that the PSCI interfaces are more trustworthy than UEFI interface which requires running firmware code in the kernel context. Need to reevaluate this guidance before a v1.0 release

Add 2 or 3 example platforms in an appendix to illustrate the range of platforms. Don't make the list exhaustive and don't try to cover the worst case.

The UEFI spec allows to provide a random seed to the kernel. Implement the ability to provide a random seed to enable KASLR in the kernel using the UEFI interface. There should be the ability to use a HW entropy source to provide the seed. It might be worthwhile to provide a default software means of generating a random seed but there might be other implications to that.

Section 2 references the PSCI spec, but doesn't say anything about Devicetree. Both should be mentioned to make it clear that this spec is applicable to both types of systems

EBBR needs to comment on whether it is okay for firmware to access devices at runtime (ie. via a Runtime Services call, or via SecureWorld).

Typically there should be no sharing of devices at all. A device's register interface should be either entirely owned by firmware or entirely owned by the OS.

The U-Boot project supports a subset of the UEFI specification, but EBBR compliance also depends on how U-Boot is configured. Add an appendix or supplemental document detailing how to configure U-Boot to be EBBR compliant.

If storage is shared between the OS and FW, any operating system installer program must take care not to overwrite critical firmware components.

Document the requirements on OS storage partitioning and filesystem formatting tools.

Embedded devices need a standard way to pass devicetree overlays during boot. Currently, both u-boot and edk2 (not sure how much) have support for handling devicetree overlays, so a standard way to pass and apply them before passing the final dtb to kernel needs to be provisioned.

Below are some of the options:

1. Separate dtbo partition which can hold an overlay at a time.
2. A vfat based dtbo partition for handling multiple overlays.
3. Multiple dtbo partitions like how Android is doing.

CC: @johnstultz-work

A roadmap document to describe which features we hope to target for what level would be very useful... especially to keep us focused on getting level 0 out of the door!

Now that the spec is in chapters, the link in the README does not give the whole document.
Can it point to the CI PDF?

PRIVILEDGED should be changed to PRIVILEGED.

If graphics is supported the BGRT should to be supported

EBBR v1.0 requires compliance with UEFI specification v2.7 (section 2.1), and then later refers to UEFI v2.8 in section 2.5.3. The whole specification should refer to a single UEFI version.

Arm has refactored the SBBR document to include a generic part (BBR, Base Boot Requirements) and segment specific recepies (e.g., SBBR, Server Base Boot Requirements). The BBR structure makes it easier for EBBR to draw from language already in the BBR spec without duplicating language from SBBR.

EBBR should be refactored to refer to the generic portions of BBR, particularly in regard to exception level handling and secure world interfaces (PSCI, etc).

BBR Spec: https://developer.arm.com/documentation/den0044/latest

The EBBR is applicable independent of architecture but architectural requirements have only been described for ARM. Here is a list of ideas:

• passing of booting hart and device-tree to next stage
• privilege levels
• SBI HSM extension
• reference to booting section of RISC-V Platform specification

Cc. @avpatel, @lbmeng

The UEFI specifiction does not describe the compression algorithm used for the EFI_DECOMPRESS_PROTOCOL. Only sample code is provided. So it is impossible to create an independent implementation.

BaseTools/Source/C/Common/EfiCompress.c has a BSD-2-Clause-Patent license. It is unknown if an independent implementation of the compression protocol would infringe Intel's patents.

We should exclude the requirement to implement the EFI_DECOMPRESS_PROTOCOL from the EBBR specification.

On systems where the boot ROM is hardcoded to fetch firmware from a block address >=2 and <34 (yes, they exist) it appears possible and standards compliant to place (for example):

• Protective MBR at LBA0
• GPT header in LBA1
• Firmware at LBA16
• GPT partition table in LBA(8192 - 32)
• First usable LBA: LBA8192

Current EBBR text is unclear about whether the above is permitted or not. Currently we require GPT except where it is impossible and we require firmware to reside within protective partitions except where impossible. It's not clear which of these rules should take precedent!

Support for being able to update the firmware using industry standard UEFI capsule from the OS using tools such as fwupdate (https://github.com/rhboot/fwupdate)

Define the meanings of "MUST" and similar language for clarity.