- boot-architecture - lists.linaro.org

Re: [TF-A] Proposal: TF-A to adopt hand-off blocks (HOBs) for information passing between boot stages

by François Ozog

+Boot Architecture Mailman List <boot-architecture(a)lists.linaro.org> standardization is very much welcomed here and need to accommodate a very diverse set of situations. For example, TEE OS may need to pass memory reservations to BL33 or "capture" a device for the secure world. I have observed a number of architectures: 1) pass information from BLx to BLy in the form of a specific object 2) BLx called by BLy by a platform specific SMC to get information 3) BLx called by BLy by a platform specific SMC to perform Device Tree fixups I also imagined a standardized "broadcast" FF-A call so that any firmware element can either provide information or "do something". My understanding of your proposal is about standardizing on architecture 1) with the HOB format. The advantage of the HOB is simplicity but it may be difficult to implement schemes such as pruning a DT because device assignment in the secure world. In any case, it looks feasible to have TF-A and OP-TEE complement the list of HOBs to pass information downstream (the bootflow). It would be good to start with building the comprehensive list of information that need to be conveyed between firmware elements: information. | authoritative entity | reporting entity | information exchanged: dram | TFA | TFA | <format to be detailed, NUMA topology to build the SRAT table or DT equivalent?> PSCI | SCP | TFA? | SCMI | SCP or TEE-OS | TFA? TEE-OS?| secure SRAM | TFA. | TFA. | secure DRAM | TFA? TEE-OS? | TFA? TEE-OS? | other? | | | Cheers FF On Mon, 22 Mar 2021 at 09:34, Harb Abdulhamid OS via TF-A < tf-a(a)lists.trustedfirmware.org> wrote: > Hello Folks, > > > > I'm emailing to start an open discussion about the adoption of a concept > known as "hand-off blocks" or HOB to become a part of the TF-A Firmware > Framework Architecture (FFA). This is something that is a pretty major > pain point when it comes to the adoption of TF-A in ARM Server SoC’s > designed to enable a broad range of highly configurable datacenter > platforms. > > > > > > What is a HOB (Background)? > > --------------------------- > > UEFI PI spec describes a particular definition for how HOB may be used for > transitioning between the PEI and DXE boot phases, which is a good > reference point for this discussion, but not necessarily the exact solution > appropriate for TF-A. > > > > A HOB is simply a dynamically generated data structure passed in between > two boot phases. This is information that was obtained through discovery > and needs to be passed forward to the next boot phase *once*, with no API > needed to call back (e.g. no call back into previous firmware phase is > needed to fetch this information at run-time - it is simply passed one time > during boot). > > > > There may be one or more HOBs passed in between boot phases. If there are > more than one HOB that needs to be passed, this can be in a form of a "HOB > table", which (for example) could be a UUID indexed array of pointers to > HOB structures, used to locate a HOB of interest (based on UUID). In such > cases, instead of passing a single HOB, the boot phases may rely on passing > the pointer to the HOB table. > > > > This has been extremely useful concept to employ on highly configurable > systems that must rely on flexible discovery mechanisms to initialize and > boot the system. This is especially helpful when you have multiple > > > > > > Why do we need HOBs in TF-A?: > > ----------------------------- > > It is desirable that EL3 firmware (e.g. TF-A) built for ARM Server SoC in > a way that is SoC specific *but* platform agnostic. This means that a > single ARM SoC that a SiP may deliver to customers may provide a single > TF-A binary (e.g. BL1, BL2, BL31) that could be used to support a broad > range of platform designs and configurations in order to boot a platform > specific firmware (e.g. BL33 and possibly even BL32 code). In order to > achieve this, the platform configuration must be *discovered* instead of > statically compiled as it is today in TF-A via device tree based > enumeration. The mechanisms of discovery may differ broadly depending on > the relevant industry standard, or in some cases may have rely on SiP > specific discovery flows. > > > > For example: On server systems that support a broad range DIMM memory > population/topologies, all the necessary information required to boot is > fully discovered via standard JEDEC Serial Presence Detect (SPD) over an > I2C bus. Leveraging the SPD bus, may platform variants could be supported > with a single TF-A binary. Not only is this information required to > initialize memory in early boot phases (e.g. BL2), the subsequent boot > phases will also need this SPD info to construct a system physical address > map and properly initialize the MMU based on the memory present, and where > the memory may be present. Subsequent boot phases (e.g. BL33 / UEFI) may > need to generate standard firmware tables to the operating systems, such as > SMBIOS tables describing DIMM topology and various ACPI tables (e.g. SLIT, > SRAT, even NFIT if NVDIMM's are present). > > > > In short, it all starts with a standardized or vendor specific discovery > flow in an early boot stage (e.g. BL1/BL2), followed by the passing of > information to the next boot stages (e.g. BL31/BL32/BL33). > > > > Today, every HOB may be a vendor specific structure, but in the future > there may be benefit of defining standard HOBs. This may be useful for > memory discovery, passing the system physical address map, enabling TPM > measured boot, and potentially many other common HOB use-cases. > > > > It would be extremely beneficial to the datacenter market segment if the > TF-A community would adopt this concept of information passing between all > boot phases as opposed to rely solely on device tree enumeration. This is > not intended to replace device tree, rather intended as an alternative way > to describe the info that must be discovered and dynamically generated. > > > > > > Conclusion: > > ----------- > > We are proposing that the TF-A community begin pursuing the adoption of > HOBs as a mechanism used for information exchange between each boot stage > (e.g. BL1->BL2, BL2->BL31, BL31->BL32, and BL31->BL33)? Longer term we > want to explore standardizing some HOB structures for the BL33 phase (e.g. > UEFI HOB structures), but initially would like to agree on this being a > useful mechanism used to pass information between each boot stage. > > > > Thanks, > > --Harb > > > > > > > -- > TF-A mailing list > TF-A(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-a > -- François-Frédéric Ozog | *Director Linaro Edge & Fog Computing Group* T: +33.67221.6485 francois.ozog(a)linaro.org | Skype: ffozog

4 years, 7 months

2
2
0 0

DTE call today 4pm UK, noon US eastern

by Bill Mills

All, We have our normal DTE call today. Due to different day light saving time dates in US vs UK the meeting will be one hour later than usual for most US people. When I checked yesterday Frank was not yet ready to talk about the DTB format changes so I have no ready made agenda today. We have a DT & SysDT talk and BOF tomorrow at Linaro Connect. Hope to see you all there. Attendance is free: https://connect.linaro.org/ Thanks, Bill -- Bill Mills Principal Technical Consultant, Linaro +1-240-643-0836 TZ: US Eastern Work Schedule: Tues/Wed/Thur

4 years, 7 months

1
0
0 0

Change review for EBBR v2.0-pre1

by Grant Likely

Hi all, I'm about ready to tag the first pre-release of EBBR v2.0. Here is the full changelog as compared to v1.0.1. Once I tag this release I'll be casting the net wider for comments before the document gets released. There are lots of little changes to the document, and a few notable big ones. Big things to look for are: - Reduced required elements in UEFI requirements - Firmware shared storage refinements - Capsule Update is now required Please let me know if you have any comments. Better yet, open an issue in github so that it doesn't get forgotten. We'll also be discussing the release at the EBBR biweekly on Monday 15th March. https://github.com/ARM-software/ebbr/issues Here's the full list of changes: 96dbb03 Reference BBR instead of SBBR (not yet merged) 2a6ca89 Fedora needs two more packages 2e3e873 CONTRIBUTING: let wording follow branching cf29c4c README.rst: Python 2 is long time gone 396abac Fix build warnings: e5d32ca trivial: remove duplicate SCSI pass through support 98e24fe Merge pull request #73 from glikely/for-next eb34dbf Require EFI_UPDATE_CAPSULE 139e6c2 Refine RTC requirements 48e1e56 UEFI section 2.6 exceptions for boot services 72f3e2d Override UEFI section 2.6 requirements 58a2a27 Change required services table titles to be more accurate d4ff44e Minor suggestions to hopefully improve the text 0555e38 Reformat revision history table to render better 5d836bc Refine firmware shared storage requirements. a89cf43 Add reference to RFC 2119 in conventions 8db9eed Fix ResetSystem() text to describe failure condition eda36e4 Merge pull request #48 from jbech-linaro/optee-url c4ef5c7 Update link to OP-TEE secure storage And here is the full diff: CONTRIBUTING.rst | 2 +- README.rst | 15 ++-- source/chapter1-about.rst | 30 ++++--- source/chapter2-uefi.rst | 292 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++------- source/chapter4-firmware-media.rst | 72 ++++++++++++---- source/conf.py | 2 +- source/index.rst | 57 ++++++------- source/references.rst | 12 ++- 8 files changed, 378 insertions(+), 104 deletions(-) diff --git a/CONTRIBUTING.rst b/CONTRIBUTING.rst index 7021f0f..be979e0 100644 --- a/CONTRIBUTING.rst +++ b/CONTRIBUTING.rst @@ -1,7 +1,7 @@ Contributing ============ -Master copy of this project is hosted on GitHub: +Main copy of this project is hosted on GitHub: https://github.com/ARM-software/ebbr Anyone may contribute to the EBBR project. diff --git a/README.rst b/README.rst index 7480dcb..acf6742 100644 --- a/README.rst +++ b/README.rst @@ -41,31 +41,28 @@ On Debian and Ubuntu ^^^^^^^^^^^^^^^^^^^^ :: - # apt-get install python-sphinx texlive texlive-latex-extra libalgorithm-diff-perl \ + # apt-get install python3-sphinx texlive texlive-latex-extra libalgorithm-diff-perl \ texlive-humanities texlive-generic-recommended texlive-generic-extra \ latexmk If the version of python-sphinx installed is too old, then an additional new version can be installed with the Python package installer:: - $ apt-get install python-pip - $ pip install --user --upgrade Sphinx + $ apt-get install python3-pip + $ pip3 install --user --upgrade Sphinx $ export SPHINXBUILD=~/.local/bin/sphinx-build -Export SPHINXBUILD (see above) if Sphinx was installed with pip --user, then follow Make commands below +Export SPHINXBUILD (see above) if Sphinx was installed with pip3 --user, then follow Make commands below. On Fedora ^^^^^^^^^ :: - # dnf install python2-sphinx texlive texlive-capt-of texlive-draftwatermark \ + # dnf install python3-sphinx texlive texlive-capt-of texlive-draftwatermark \ texlive-fncychap texlive-framed texlive-needspace \ texlive-tabulary texlive-titlesec texlive-upquote \ - texlive-wrapfig - -It is also possible to use python3-sphinx; this requires -SPHINXBUILD=sphinx-build-3 to be passed on the Make command line. + texlive-wrapfig texinfo latexmk On Mac OS X ^^^^^^^^^^^ diff --git a/source/chapter1-about.rst b/source/chapter1-about.rst index 3744d8a..6f69f53 100644 --- a/source/chapter1-about.rst +++ b/source/chapter1-about.rst @@ -50,8 +50,8 @@ Vendors have heavy investments in both projects and are not interested in large scale changes to their firmware architecture. The challenge for EBBR is to define a set of boot standards that reduce the amount of custom engineering required, make it possible for OS distributions to -support embedded platforms, while still preserving the firmware stack product -vendors are comfortable with. +support embedded platforms, while still preserving the firmware stack that +product vendors are comfortable with. Or in simpler terms, EBBR is designed to solve the embedded boot mess by adding a defined standard (UEFI) to the existing firmware projects (U-Boot). @@ -146,19 +146,23 @@ including services that are required for virtualization. It does not define a standardized abstract virtual machine view for a Guest Operating System. -This specification is similar to the Arm Server Base Boot Requirements -specification [SBBR]_ in that it defines the firmware interface presented to an -operating system. -SBBR is targeted at the server ecosystem and places strict requirements on the -platform to ensure cross vendor interoperability. -EBBR on the other hand allows more flexibility to support embedded designs -which do not fit within the SBBR model. -For example, a platform that isn't SBBR compliant because the SoC is only -supported using Devicetree could be EBBR compliant, but not SBBR compliant. - -By definition, all SBBR compliant systems are also EBBR compliant, but the +This specification is referenced by the Arm Base Boot Requirements +Specification [ArmBBR]_ § 4.3. +The UEFI requirements found in this document are similar but not identical to +the requirements found in BBR. +EBBR provides greater flexibility for support embedded designs which cannot +easily meet the stricter BBR requirements. + +By definition, all BBR compliant systems are also EBBR compliant, but the converse is not true. +Conventions Used in this Document +================================= + +The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", +"SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be +interpreted as described in :rfc:`2119`. + Cross References ================ This document cross-references sources that are listed in the References diff --git a/source/chapter2-uefi.rst b/source/chapter2-uefi.rst index 066fefb..a0b3e8d 100644 --- a/source/chapter2-uefi.rst +++ b/source/chapter2-uefi.rst @@ -14,8 +14,179 @@ This document uses version 2.8 Errata A of the UEFI specification [UEFI]_. UEFI Compliance =============== -EBBR compliant platforms shall conform to the requirements in [UEFI]_ § 2.6, -except where explicit exemptions are provided by this document. +EBBR compliant platform shall conform to a subset of the [UEFI]_ spec as listed +in this section. +Normally, UEFI compliance would require full compliance with all items listed +in UEFI § 2.6. +However, the EBBR target market has a reduced set of requirements, +and so some UEFI features are omitted as unnecessary. + +Required Elements +----------------- + +This section replaces the list of required elements in [UEFI]_ § 2.6.1. +All of the following UEFI elements are required for EBBR compliance. + +.. list-table:: UEFI Required Elements + :widths: 50 50 + :header-rows: 1 + + * - Element + - Requirement + * - `EFI_SYSTEM_TABLE` + - The system table is required to provide required to access UEFI Boot Services, + UEFI Runtime Services, consoles, and other firmware, vendor and platform + information. + * - `EFI_BOOT_SERVICES` + - All functions defined as boot services must exist. + Methods for unsupported or unimplemented behaviour must return + an appropriate error code. + * - `EFI_RUNTIME_SERVICES` + - All functions defined as runtime services must exist. + Methods for unsupported or unimplemented behaviour must return + an appropriate error code. + If any runtime service is unimplemented, it must be indicated + via the EFI_RT_PROPERTIES_TABLE. + * - `EFI_LOADED_IMAGE_PROTOCOL` + - Must be installed for each loaded image + * - `EFI_LOADED_IMAGE_DEVICE_PATH_PROTOCOL` + - Must be installed for each loaded image + * - `EFI_DEVICE_PATH_PROTOCOL` + - An `EFI_DEVICE_PATH_PROTOCOL` must be installed onto all device + handles provided by the firmware. + * - `EFI_DEVICE_PATH_UTILITIES_PROTOCOL` + - Interface for creating and manipulating UEFI device paths + +.. list-table:: Notable omissions from UEFI § 2.6.1 + :header-rows: 1 + + * - Element + - Note + * - `EFI_DECOMPRESS_PROTOCOL` + - Native EFI decompression is rarely used and therefore not required. + +Required Platform Specific Elements +----------------------------------- + +This section replaces the list of required elements in [UEFI]_ § 2.6.2. +All of the following UEFI elements are required for EBBR compliance. + +.. list-table:: UEFI Platform-Specific Required Elements + :widths: 50 50 + :header-rows: 1 + + * - Element + - Description + * - Console devices + - The platform must have at least one console device + * - `EFI_SIMPLE_TEXT_INPUT_PROTOCOL` + - Needed for console input + * - `EFI_SIMPLE_TEXT_INPUT_EX_PROTOCOL` + - Needed for console input + * - `EFI_SIMPLE_TEXT_OUTPUT_PROTOCOL` + - Needed for console output + * - `EFI_DEVICE_PATH_TO_TEXT_PROTOCOL` + - Needed for console output + * - `EFI_HII_STRING_PROTOCOL` + - Required by EFI shell and for compliance testing + * - `EFI_HII_DATABASE_PROTOCOL` + - Required by EFI shell and for compliance testing + * - `EFI_UNICODE_COLLATION2_PROTOCOL` + - Required by EFI shell and for compliance testing + * - `EFI_BLOCK_IO_PROTOCOL` + - Required for block device access + * - `EFI_SIMPLE_FILE_SYSTEM_PROTOCOL` + - Required if booting from block device is supported + * - `EFI_RNG_PROTOCOL` + - Required if the platform has a hardware entropy source + * - `EFI_SIMPLE_NETWORK_PROTOCOL` + - Required if the platform has a network device. + * - HTTP Boot (UEFI § 24.7) + - Required if the platform supports network booting + +The following table is a list of notable deviations from UEFI § 2.6.2. +Many of these deviations are because the EBBR use cases do not require +interface specific UEFI protocols, and so they have been made optional. + +.. list-table:: Notable Deviations from UEFI § 2.6.2 + :widths: 50 50 + :header-rows: 1 + + * - Element + - Description of deviation + * - `LoadImage()` + - The LoadImage() boot service is not required to install an + EFI_HII_PACKAGE_LIST_PROTOCOL for an image containing a custom PE/COFF + resource with the type 'HII'. - HII resource images are not needed to run + the UEFI shell or the SCT. + * - `ConnectController()` + - The ConnectController()` boot service is not required to support the + EFI_PLATFORM_DRIVER_OVERRIDE_PROTOCOL, + EFI_DRIVER_FAMILY_OVERRIDE_PROTOCOL, and + EFI_BUS_SPECIFIC_DRIVER_OVERRIDE_PROTOCOL. - These override protocols are + only useful if drivers are loaded as EFI binaries by the firmware. + * - `EFI_HII_CONFIG_ACCESS_PROTOCOL` + - UEFI requires this for console devices, but it is rarely necessary in practice. + Therefore this protocol is not required. + * - `EFI_HII_CONFIG_ROUTING_PROTOCOL` + - UEFI requires this for console devices, but it is rarely necessary in practice. + Therefore this protocol is not required. + * - Graphical console + - Platforms with a graphical device are not required to expose it as a graphical console. + * - `EFI_DISK_IO_PROTOCOL` + - Rarely used interface that isn't required for EBBR use cases + * - `EFI_PXE_BASE_CODE_PROTOCOL` + - Booting via the Preboot Execution Environment (PXE) is insecure. + Loading via PXE is typically executed before launching the first UEFI application. + * - Network protocols + - A full implementation of the UEFI general purpose networking ABIs is not required, + including `EFI_NETWORK_INTERFACE_IDENTIFIER_PROTOCOL`, `EFI_MANAGED_NETWORK_PROTOCOL`, + `EFI_*_SERVICE_BINDING_PROTOCOL`, or any of the IPv4 or IPv6 protocols. + * - Byte stream device support (UART) + - UEFI protocols not required + * - PCI bus support + - UEFI protocols not required + * - USB bus support + - UEFI protocols not required + * - NVMe pass through support + - UEFI protocols not required + * - SCSI pass through support + - UEFI protocols not required + * - `EFI_DRIVER_FAMILY_OVERRIDE_PROTOCOL` + - Not required + * - Option ROM support + - In many EBBR use cases there is no requirement to generically support + any PCIe add in card at the firmware level. + When PCIe devices are used, drivers for the device are often built into + the firmware itself rather than loaded as option ROMs. + For this reason EBBR implementations are not required to support option + ROM loading. + +Required Global Variables +------------------------- + +EBBR compliant platforms are required to support the following Global +Variables as found in [UEFI]_ § 3.3. + +.. list-table:: Required UEFI Variables + :widths: 25 75 + :header-rows: 1 + + * - Variable Name + - Description + * - `Boot####` + - A boot load option. #### is a numerical hex value + * - `BootCurrent` + - The boot option that was selected for the current boot + * - `BootNext` + - The boot option that will be used for the next boot only + * - `BootOrder` + - An ordered list of boot options. + Firmware will attempt each Boot#### entry in this order + * - `OsIndications` + - Method for OS to request features from firmware + * - `OsIndicationsSupported` + - Variable for firmware to indicate which features can be enabled Block device partitioning ------------------------- @@ -53,7 +224,7 @@ a hypervisor or a virtualization aware Operating System. UEFI Boot at EL1 ^^^^^^^^^^^^^^^^ -Booting of UEFI at EL1 is most likely within a hypervisor hosted Guest +Booting of UEFI at EL1 is most likely employed within a hypervisor hosted Guest Operating System environment, to allow the subsequent booting of a UEFI-compliant Operating System. In this instance, the UEFI boot-time environment can be provided, as a @@ -77,7 +248,7 @@ The default RAM allocated attribute must be EFI_MEMORY_WB. Configuration Tables -------------------- -A UEFI system that complies with this specification may provide the additional +A UEFI system that complies with this specification may provide additional tables via the EFI Configuration Table. Compliant systems are required to provide one, but not both, of the following @@ -151,26 +322,55 @@ EFI_UNSUPPORTED. are required to be implemented during boot services and runtime services. .. _uefi_runtime_service_requirements: -.. table:: EFI_RUNTIME_SERVICES Implementation Requirements - - ============================== ============= ================ - EFI_RUNTIME_SERVICES function Boot Services Runtime Services - ============================== ============= ================ - EFI_GET_TIME Optional Optional - EFI_SET_TIME Optional Optional - EFI_GET_WAKEUP_TIME Optional Optional - EFI_SET_WAKEUP_TIME Optional Optional - EFI_SET_VIRTUAL_ADDRESS_MAP N/A Required - EFI_CONVERT_POINTER N/A Required - EFI_GET_VARIABLE Required Optional - EFI_GET_NEXT_VARIABLE_NAME Required Optional - EFI_SET_VARIABLE Required Optional - EFI_GET_NEXT_HIGH_MONO_COUNT N/A Optional - EFI_RESET_SYSTEM Required Optional - EFI_UPDATE_CAPSULE Optional Optional - EFI_QUERY_CAPSULE_CAPABILITIES Optional Optional - EFI_QUERY_VARIABLE_INFO Optional Optional - ============================== ============= ================ +.. list-table:: `EFI_RUNTIME_SERVICES` Implementation Requirements + :widths: 40 30 30 + :header-rows: 1 + + * - `EFI_RUNTIME_SERVICES` function + - Before ExitBootServices() + - After ExitBootServices() + * - `EFI_GET_TIME` + - Required if RTC present + - Optional + * - `EFI_SET_TIME` + - Required if RTC present + - Optional + * - `EFI_GET_WAKEUP_TIME` + - Required if wakeup supported + - Optional + * - `EFI_SET_WAKEUP_TIME` + - Required if wakeup supported + - Optional + * - `EFI_SET_VIRTUAL_ADDRESS_MAP` + - N/A + - Required + * - `EFI_CONVERT_POINTER` + - N/A + - Required + * - `EFI_GET_VARIABLE` + - Required + - Optional + * - `EFI_GET_NEXT_VARIABLE_NAME` + - Required + - Optional + * - `EFI_SET_VARIABLE` + - Required + - Optional + * - `EFI_GET_NEXT_HIGH_MONO_COUNT` + - N/A + - Optional + * - `EFI_RESET_SYSTEM` + - Required + - Optional + * - `EFI_UPDATE_CAPSULE` + - Required for in-band update + - Optional + * - `EFI_QUERY_CAPSULE_CAPABILITIES` + - Optional + - Optional + * - `EFI_QUERY_VARIABLE_INFO` + - Optional + - Optional Runtime Device Mappings ----------------------- @@ -198,8 +398,11 @@ 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. -If firmware does not support access to the RTC, then GetTime() and -SetTime() shall return EFI_UNSUPPORTED, +If an RTC is present, then GetTime() and SetTime() must be supported +before ExitBootServices() is called. + +However, if firmware does not support access to the RTC after +ExitBootServices(), then GetTime() and SetTime() shall return EFI_UNSUPPORTED and the OS must use a device driver to control the RTC. UEFI Reset and Shutdown @@ -209,9 +412,10 @@ ResetSystem() is required to be implemented in boot services, but it is optional for runtime services. During runtime services, the operating system should first attempt to use ResetSystem() to reset the system. -If firmware doesn't support ResetSystem() during runtime services, -then the call will immediately return EFI_UNSUPPORTED, and the OS should -fall back to an architecture or platform specific reset mechanism. + +If firmware doesn't support ResetSystem() during runtime services, then the call +will immediately return, and the OS should fall back to an architecture or +platform specific reset mechanism. On AArch64 platforms implementing [PSCI]_, if ResetSystem() is not implemented then the Operating System should fall @@ -242,6 +446,26 @@ Even when SetVariable() is not supported during runtime services, firmware should cache variable names and values in EfiRuntimeServicesData memory so that GetVariable() and GetNextVeriableName() can behave as specified. +Firmware Update +--------------- + +Being able to update firmware to address security issues is a key feature of secure platforms. +EBBR platforms are required to implement either an in-band or an out-of-band firmware update mechanism. + +If firmware update is performed in-band (firmware on the application processor updates itself), +then the firmware shall implement EFI_UPDATE_CAPSULE and accept updates in the +"Firmware Management Protocol Data Capsule Structure" format as described in [UEFI]_ § 23.3, +"Delivering Capsules Containing Updates to Firmware Management Protocol. [#FMPNote]_ +Firmware is also required to provide an EFI System Resource Table (ESRT). [UEFI]_ § 23.4 +Every firmware image that is updated in-band must be described in the ESRT. + +If firmware update is performed out-of-band (e.g., by an independent Baseboard +Management Controller (BMC), or firmware is provided by a hypervisor), +then the platform is not required to implement EFI_UPDATE_CAPSULE. + +EFI_UPDATE_CAPSULE is only required before ExitBootServices() is called. + + .. [#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 @@ -251,4 +475,12 @@ that GetVariable() and GetNextVeriableName() can behave as specified. Regardless, EBBR compliance does not require SetVariable() support during runtime services. - https://github.com/OP-TEE/optee_os/blob/master/documentation/secure_storage… + https://optee.readthedocs.io/en/latest/architecture/secure_storage.html + +.. [#FMPNote] The `EFI_UPDATE_CAPSULE` implementation is expected to be suitable + for use by generic firmware update services like fwupd and Windows Update. + Both fwupd and Windows Update read the ESRT table to determine what firmware + can be updated, and use an EFI helper application to call `EFI_UPDATE_CAPSULE` + before ExitBootServices() is called. + + https://fwupd.org/ diff --git a/source/chapter4-firmware-media.rst b/source/chapter4-firmware-media.rst index fc71274..cfcc8bd 100644 --- a/source/chapter4-firmware-media.rst +++ b/source/chapter4-firmware-media.rst @@ -47,13 +47,19 @@ conflict with normal usage of the media by an OS. Partitioning of Shared Storage ============================== -A shared storage device shall use GPT partitioning unless it is incompatible -with the platform boot sequence. -In which case, MBR partitioning shall be used. [#MBRReqExample]_ - -.. [#MBRReqExample] For example, if the boot ROM doesn't understand GPT - partitioning, and will only work with an MBR, then the storage must be - partitioned using an MBR. +The shared storage device must use the GUID Partition Table (GPT) disk +layout as defined in [UEFI]_ § 5.3, unless the platform boot sequence is +fundamentally incompatible with the GPT disk layout. +In which case, a legacy Master Boot Recored (MBR) must be used. +[#MBRReqExample]_ + +.. [#MBRReqExample] For example, if the SoC boot ROM requires an MBR to + find the next stage firmware image, then it is incompatible with + the GPT boot layout. + Similarly, if the boot ROM expects the next stage firmware to be located + at LBA1 (the location of the GPT Header), then it is incompatible with + the GPT disk layout. + In both cases the shared storage device must use legacy MBR partitioning. .. warning:: @@ -62,7 +68,8 @@ In which case, MBR partitioning shall be used. [#MBRReqExample]_ GPT partitioning supports a much larger number of partitions, and has built in resiliency. - A future issue of this specification will remove the MBR allowance. + A future issue of this specification will disallow the use of MBR + partitioning. Firmware images and data in shared storage should be contained in partitions described by the GPT or MBR. @@ -71,15 +78,14 @@ the partition(s) containing firmware. However, some SoCs load firmware from a fixed offset into the storage media. In this case, to protect against partitioning tools overwriting firmware, the -firmware image shall either reside entirely within the first 1MiB of storage, -or should be covered by a protective partition entry in the partition table as +partition table must be formed in a way to protect the firmware image(s) as described in sections :ref:`section-gpt-parts` and :ref:`section-mbr-parts`. -Automatic partitioning tools (e.g. an OS installer) must not create -partitions within the first 1MiB of storage, or delete, move, or modify -protective partition entries. +Automatic partitioning tools (e.g. an OS installer) must not +delete the protective information in the partition table, or +delete, move, or modify protective partition entries. Manual partitioning tools should provide warnings when modifying -protective partitions or creating partitions within the first 1MiB. +protective partitions. .. warning:: @@ -95,19 +101,49 @@ GPT partitioning ---------------- The partition table must strictly conform to the UEFI specification and include -a protective MBR authored exactly as described in [UEFI]_ § 5 (hybrid +a protective MBR authored exactly as described in [UEFI]_ § 5.3 (hybrid partitioning schemes are not permitted). -Protective partitions must have the Platform Required Attribute Flag set. +Fixed-location firmware images must be protected by creating protective +partition entries, or by placing GPT data structures away from the LBAs +occupied by firmware, + +Protective partitions are entries in the partition table that cover the +LBA region occupied by firmware and have the 'Required Partition' attribute +set. +A protective partition must use a `PartitionTypeGUID` that identifies it +as a firmware protective partition. (e.g., don't reuse a GUID used by +non-protective partitions). +There are no requirements on the contents or layout of the firmware +protective partition. + +Placing GPT data structures away from firmware images can be accomplished by +adjusting the GUID Partition Entry array location +(adjusting the values of `PartitionEntryLBA` and `NumberOfPartitionEntries`, +and `SizeOfPartitionEntry`), +or by specifying the usable LBAs (Choosing `FirstUsableLBA`/`LastUsableLBA` +to not overlap the fixed firmware location). +See [UEFI]_ § 5.3.2. + +Given the choice, platforms should use protective partitions over +adjusting the placement of GPT data structures because protective partitions +provide explicit information about the protected region. .. _section-mbr-parts: MBR partitioning ^^^^^^^^^^^^^^^^ -Protective partitions should have a partition type of 0xF8 unless some +If firmware is at a fixed location entirely within the first 1MiB of +storage (<= LBA2047) then no protective partitions are required. +If firmware resides in a fixed location outside the first 1MiB, +then a protective partition must be used to cover the firmware LBAs. +Protective partitions should have a partition type of 0xF8 unless an immutable feature of the platform makes this impossible. +OS partitioning tools must not create partitions in the first 1MiB +of the storage device, and must not remove protective partitions. + .. _section-fw-partition-fs: Firmware Partition Filesystem @@ -202,7 +238,7 @@ and cannot be moved between systems. eMMC and Universal Flash Storage (UFS) device are often used as shared fixed storage for both firmware and the OS. -Where possible, it is prefered for the system to boot from a dedicated boot +Where possible, it is preferred for the system to boot from a dedicated boot region on media that provides one (e.g., eMMC) that is sufficiently large. Otherwise, the platform storage should be pre-formatted in the factory with a partition table, a dedicated firmware partition, and firmware binaries diff --git a/source/conf.py b/source/conf.py index 86f7b88..4a2566a 100644 --- a/source/conf.py +++ b/source/conf.py @@ -100,7 +100,7 @@ html_theme = 'alabaster' # Add any paths that contain custom static files (such as style sheets) here, # relative to this directory. They are copied after the builtin static files, # so a file named "default.css" will overwrite the builtin "default.css". -html_static_path = ['_static'] +# html_static_path = ['_static'] # -- Options for HTMLHelp output ------------------------------------------ diff --git a/source/index.rst b/source/index.rst index 8eab909..bf2dadf 100644 --- a/source/index.rst +++ b/source/index.rst @@ -21,35 +21,34 @@ Creative Commons, PO Box 1866, Mountain View, CA 94042, USA. .. tabularcolumns:: l c p{11.5cm} .. table:: Revision History - ================= ========= ============================================= - Date Issue Changes - ================= ========= ============================================= - 20 September 2017 0.51 Confidentiality Change, EBBR version 0.51 - 6 July 2018 0.6-pre1 - Relicense to CC-BY-SA 4.0 - - Added Devicetree requirements - - Added Multiprocessor boot requirements - - Transitioned to reStructuredText and GitHub - - Added firmware on shared media requirements - - RTC is optional - - Add constraints on sharing devices between - firmware and OS - 12 July 2018 0.6 - Response to comments on v0.6-pre1 - - Add large note on implementation of runtime - modification of non-volatile variables - 18 October 2018 0.7 - Add AArch32 details - - Refactor Runtime Services text after face - to fact meeting at Linaro Connect YVR18 - 12 March 2019 0.8 - Update language around SetVariable() and - what is available during runtime services - - Editorial changes preparing for v1.0 - 31 March 2019 1.0 - Remove unnecessary UEFI requirements - appendix - - Allow for ACPI vendor id in firmware path - 5 August 2020 1.0.1 - Update to UEFI 2.8 Errata A - - Specify UUID for passing DTB - - Typo and editorial fixes - - Document the release process - ================= ========= ============================================= + ============= ======= ============================================= + Date Issue Changes + ============= ======= ============================================= + 20 Sep 2017 0.51 - Confidentiality Change, EBBR version 0.51 + 12 Jul 2018 0.6 - Relicense to CC-BY-SA 4.0 + - Added Devicetree requirements + - Added Multiprocessor boot requirements + - Transitioned to reStructuredText and GitHub + - Added firmware on shared media requirements + - RTC is optional + - Add constraints on sharing devices between + firmware and OS + - Add large note on implementation of runtime + modification of non-volatile variables + 18 Oct 2018 0.7 - Add AArch32 details + - Refactor Runtime Services text after face + to fact meeting at Linaro Connect YVR18 + 12 Mar 2019 0.8 - Update language around SetVariable() and + what is available during runtime services + - Editorial changes preparing for v1.0 + 31 Mar 2019 1.0 - Remove unnecessary UEFI requirements + appendix + - Allow for ACPI vendor id in firmware path + 5 Aug 2020 1.0.1 - Update to UEFI 2.8 Errata A + - Specify UUID for passing DTB + - Typo and editorial fixes + - Document the release process + ============= ======= ============================================= .. toctree:: :numbered: diff --git a/source/references.rst b/source/references.rst index 1eb0509..fb7dc81 100644 --- a/source/references.rst +++ b/source/references.rst @@ -1,5 +1,11 @@ .. SPDX-License-Identifier: CC-BY-SA-4.0 +.. only:: html + + ************ + Bibliography + ************ + .. [ACPI] `Advanced Configuration and Power Interface specification v6.2A <http://www.uefi.org/sites/default/files/resources/ACPI%206_2_A_Sept29.pdf>`_, September 2017, `UEFI Forum <http://www.uefi.org>`_ @@ -16,9 +22,9 @@ <https://static.docs.arm.com/den0022/c/DEN0022C_Power_State_Coordination_Int…>`_ 30 January 2015, `Arm Limited <http://arm.com>`_ -.. [SBBR] `Arm Server Base Boot Requirements specification Issue B (v1.0) - <https://static.docs.arm.com/den0044/b/DEN0044B_Server_Base_Boot_Requirement…>`_ - 8 March 2016, `Arm Limited <http://arm.com>`_ +.. [ArmBBR] `Arm Base Boot Requirements specification Issue F (v1.0) + <https://developer.arm.com/documentation/den0044/f>`_ + 6 Oct 2020, `Arm Limited <http://arm.com>`_ .. [UEFI] `Unified Extensable Firmware Interface Specification v2.8 Errata A <https://uefi.org/sites/default/files/resources/UEFI_Spec_2_8_A_Feb14.pdf>`_,

4 years, 7 months

2
4
0 0

[EBBR PATCH] Reference BBR instead of SBBR

by Grant Likely

SBBR has been superseded by Arm BBR. Update the about section to reference BBR instead. However, none of the specification language changes because EBBR has a relaxed set of UEFI requirements compared to BBR. Fixes: #62 Signed-off-by: Grant Likely <grant.likely(a)secretlab.ca> --- source/chapter1-about.rst | 19 ++++++++----------- source/references.rst | 6 +++--- 2 files changed, 11 insertions(+), 14 deletions(-) diff --git a/source/chapter1-about.rst b/source/chapter1-about.rst index 68a1abc..6f69f53 100644 --- a/source/chapter1-about.rst +++ b/source/chapter1-about.rst @@ -146,17 +146,14 @@ including services that are required for virtualization. It does not define a standardized abstract virtual machine view for a Guest Operating System. -This specification is similar to the Arm Server Base Boot Requirements -specification [SBBR]_ in that it defines the firmware interface presented to an -operating system. -SBBR is targeted at the server ecosystem and places strict requirements on the -platform to ensure cross vendor interoperability. -EBBR on the other hand allows more flexibility to support embedded designs -which do not fit within the SBBR model. -For example, a platform that isn't SBBR compliant because the SoC is only -supported using Devicetree could be EBBR compliant, but not SBBR compliant. - -By definition, all SBBR compliant systems are also EBBR compliant, but the +This specification is referenced by the Arm Base Boot Requirements +Specification [ArmBBR]_ § 4.3. +The UEFI requirements found in this document are similar but not identical to +the requirements found in BBR. +EBBR provides greater flexibility for support embedded designs which cannot +easily meet the stricter BBR requirements. + +By definition, all BBR compliant systems are also EBBR compliant, but the converse is not true. Conventions Used in this Document diff --git a/source/references.rst b/source/references.rst index d91dc08..fb7dc81 100644 --- a/source/references.rst +++ b/source/references.rst @@ -22,9 +22,9 @@ <https://static.docs.arm.com/den0022/c/DEN0022C_Power_State_Coordination_Int…>`_ 30 January 2015, `Arm Limited <http://arm.com>`_ -.. [SBBR] `Arm Server Base Boot Requirements specification Issue B (v1.0) - <https://static.docs.arm.com/den0044/b/DEN0044B_Server_Base_Boot_Requirement…>`_ - 8 March 2016, `Arm Limited <http://arm.com>`_ +.. [ArmBBR] `Arm Base Boot Requirements specification Issue F (v1.0) + <https://developer.arm.com/documentation/den0044/f>`_ + 6 Oct 2020, `Arm Limited <http://arm.com>`_ .. [UEFI] `Unified Extensable Firmware Interface Specification v2.8 Errata A <https://uefi.org/sites/default/files/resources/UEFI_Spec_2_8_A_Feb14.pdf>`_, -- 2.20.1

4 years, 7 months

1
0
0 0

DTE meeting notes 2021-03-08

by Bill Mills

All, Here are my notes from today. Please correct anything I got wrong. Attendees: Bruce Ashfield Frank Rowand Simon Glass Etienne Carriere Heinrich Schuchardt Ilias Apalodimas Joakim Bech Loic Pallardy Mark Brown Mathieu Poirier Rob Herring Ruchika Gupta Vincent Guittot Vincent Stehle CC: Stefano Stabellini Kumar Gala Discussion: Today we did a brainstorming session on goals/requirements for a new DTB format. Remember this is a laundry list of requirements / concerns. Not all will necessarily be included in the new format but all will be considered. It is not a discussion of the format changes to achieve these goals. Frank Rowand will be collecting past discussions related to this and expects this to be ready for the meeting on March 22. * FR: Reduce Size * FR: Overlay support in "symbol table" not looking like HW description * FR: Ability to express "delete node" and "delete property" ** many: do we really need delete node, every node should have status ** RH: not everyone today looks for status != ok ** general agreement that they should ** RH: perhaps we should make it more automatic somehow * SG: New format should be little endian ** most current active / popular CPU arch are LE these days * SG: Ability to refer to data blob by reference instead of inline ** blob would still be in DTB file/image but not inline as a property blob * RH: Include type info ** Know what is a u64 vs u32 vs phandle ** replicate what we have in schema with bit fields etc ** enums?? structs?? * SG: Provision for comments * RH: In general want more less conversion DTS -> DTB -> DTS ** WAM: Is it OK to rely on schema? ** SG: Ideally not, would prefer self describing format * HS: Want to be able to validate DTB (against schema) ** WAM: Isnt this the same as type info? ** RH: That is a lot of it but there is more * WAM: We want a new section for meta data ** WAM: signatures as discussed on this call ** FR: Source file info / version markers ** HS/WAM: taint flag if the DTC compile or validate is not clean * SG: IN yaml we can import a node, ** would be good to have this in DTS as well ** FR: It is valid to bring in DTS requirements as some of this will effect anyway * WAM: Segmeneted DTB or DTB set ** instead of applying overlays leave base and overlay intact ** deliver to OS as a set with assembly order. ** [We can call it IKEA mode :) ] ** allows signatures to reamin valid, can be passed on ** makes it clear what fixups were performed by the firmware * SG: a previous node "pointer" ** going backwards is very slow in FDT * WAM: Huawei is asking for B-Tree to speed up search in FDT ** FR/RH: probably too far but we will consider * RH: DTB format could be unflattened ** SG: could be too big ** SG: we may really need more than one format to balance speed vs size ** [WAM: learns that libfdt does not unflatten. U-boot copies Linux code for this.] ** RH: we could have a libdt that would be lib for live trees * SG: for speed it would be nice to have a directory for quick access ** WAM: improved alias? SG: Yes if they were phandles perhaps * WAM: Can we revist size, that is pretty broad ** Eliminate as many strings as possible ** FR: Compiler does "tail recursion" on strings already ** WAM: strings in properties are not in symbold table today ** SG: Yes I studied that and elimination of that did not help a lot. ** SG: Today everything is 32 bit *** I looked at reducing and could save 20% *** But it is not as regular *** WAM: is it aligned today? *** RH: Yes, 64 bit aligned but not very clear in spec ** HS: Just gzip the DTB if you just want to reduce storage size ** WAM: Published ATOM based DTB doc a few years ago. *** Try to move most strings to 32 bit ATOM constants (not offsets) *** Optionally include ATOM table to include the strings Devicetree Atom Table Format: https://docs.google.com/document/d/19XbxN-zX-GYwOXdF78lGnp0j7UNx1MT3wzyCjai… Frank reminds us that we want to collect all the stake holders: * Linux * DTC * U-Boot * BSDs ** One has its own DTC * RTOS ** Zephyr (mostly DTS) *** Have their own DTS parser, DOM lib, and code gen *** Want to make it more generic ** Vxworks (does use runtime DT of some sort) All agree: Old DTB format will need to be supported for a good while after new DTB format is defined. Thanks, Bill -- Bill Mills Principal Technical Consultant, Linaro +1-240-643-0836 TZ: US Eastern Work Schedule: Tues/Wed/Thur

4 years, 8 months

1
0
0 0

DT Evo call today March 8 at 4pm UK/UTC 11AM US East

by Bill Mills

Hello, We have our DTE call today. I don't have anything on the agenda unless we want to brainstorm on the DTB format changes. I know Frank is trying to collect/organize past work on this. Is it worth while talking today or should we wait for Frank? Open to any other agenda items. Join Zoom Meeting https://linaro-org.zoom.us/j/96170428801?pwd=elBJNFdVMFJub0UzanFUcVQxTHBqdz… Meeting ID: 961 7042 8801 Passcode: 8250 ------ A note on timezones. This meeting is now anchored to the UK timezone to match the EBBR call. UK goes to Daylight savings on March 28 Most of the USA goes to Daylight savings on March 14. This means: UK: no visible change in time slot. USA (most): Meeting on 22nd will be one hour later. (and EBBR meeting on 15th) Non-daylight savings time zones: DTE and EBBR meetings are 1 hour earlier from March 28 to Oct 31. Thanks, Bill -- Bill Mills Principal Technical Consultant, Linaro +1-240-643-0836 TZ: US Eastern Work Schedule: Tues/Wed/Thur

4 years, 8 months

1
0
0 0

EFI_LOAD_FILE2 for initrd standardization

by Ilias Apalodimas

Hi, An arch agnostic way was recently added on the kernel, as an alternative method to load an initrd [1]. The kernel call to the firmware ends up calling the protocol with a Device Path End Structure, so the firmware must know which initrd to load on the buffer the kernel provides. The protocol is currently implemented by U-boot and EDK2, which both define a way of specifying the initrd to load. We could use this protocol, in order to provide vertical distros a way of loading (kernel, initrd) pairs without GRUB. In that case we need a common way for firmware implementations to define and manage the initrd. User space applications that control the boot flow (e.g efibootmgr), should also be able to change the variable accordingly. Looking at the EFI spec and specifically § 3.1.3 Load Options, we can use the FilePathList[] of the EFI_LOAD_OPTION, which is described as: "A packed array of UEFI device paths. The first element of the array is a device path that describes the device and location of the Image for this load option. The FilePathList[0] is specific to the device type. Other device paths may optionally exist in the FilePathList, but their usage is OSV specific. Each element in the array is variable length, and ends at the device path end structure. Because the size of Description is arbitrary, this data structure is not guaranteed to be aligned on a natural boundary. This data structure may have to be copied to an aligned natural boundary before it is used." So FilePatrhList[1-n] are available for OS usage. There are 3 ways we could implement that. All 3 ways would allow us to specify multiple initrds (and we could extend the same logic to DTBs, but that's a different discussion). They all re-use the same idea, prepend a VenMedia DP, which has a GUID. We can then use that GUID to identify the filetype and behavior of the device paths. 1. Prepend a VenMedia Device Path in every initrd Device Path. In that case FilePathList[] would look like this: Loaded Image device path - end node - VenMedia - Initrd DP - end node - VenMedia - Initrd DP - end node - repeat 2. Prepend a VenMedia Device Path once. In that case FilePathList[] would look like this: Loaded Image device path - end node - VenMedia - Initrd DP - end instance - (repeat) - Initrd DP - end node - other DPs In this case we could use the VenMedia Vendor Defined Data to indicate the number of device paths that follow, although it's redundant, since each instance would terminate on the Device Path End Structure. 3. Use Vendor Defined Data of the VenMedia device path and copy the initrd device path(s) in there. In that case the Vendor Defined Data will it self be in a device path format with all the initrds we want. Loaded Image device path - end node - VenMedia - end node - other DPs Any preference on these? Is one of them closer to the EFI spec, so we could go ahead and try to standardize some of the GUIDs of the VenMedia? [1] https://lkml.org/lkml/2020/2/16/105 Regards /Ilias

4 years, 8 months

7
17
0 0

*cancelled* EBBR Biweekly for 1 March 2021

by Grant Likely

Hi all, I'll be doing a presentation and round table about SystemReady IR at Embedded World on 1 March, but unfortunately it overlaps entirely our EBBR biweekly so I'm going to cancel that day. If you're interested in attending the round table, please email me privately. The session apparently limited to a small number of people (which seems odd for a virtual conference), so I'm sending out invites. The session is scheduled for 15:50-16:50 GMT on 1 March 2021. Cheers, g. IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

4 years, 8 months

1
1
0 0

DTE Call today (Feb 22) at 11am US ET, 4PM UTC

by Bill Mills

All, We have the DTE call in ~ 1 hour (if my message is not delayed). Frank Rowand has agreed to talk about his TODO/backlog plans. We can probably entertain other agenda items after that. Thanks, Bill -- Bill Mills Principal Technical Consultant, Linaro +1-240-643-0836 TZ: US Eastern Work Schedule: Tues/Wed/Thur

4 years, 8 months

2
1
0 0

[EBBR PATCH 0/3] Updates for v2.0

by Grant Likely

Hi all, Here are the updates I've prepared for v2.0 of EBBR which I'd like to tag for review sometime in the next few weeks. Please take a look and yell if you have any concerns. g. [EBBR PATCH 1/3] Override UEFI section 2.6 requirements [EBBR PATCH 2/3] Refine RTC requirements [EBBR PATCH 3/3] Require EFI_UPDATE_CAPSULE

4 years, 8 months

5
13
0 0

[PATCH 1/1] Fix build warnings:

by Heinrich Schuchardt

Building target html results in warnings: WARNING: html_static_path entry '_static' does not exist ebbr/source/index.rst:53: WARNING: toctree contains reference to document 'references' that doesn't have a title: no link will be generated * remove reference to path _static * add title to references Signed-off-by: Heinrich Schuchardt <xypron.glpk(a)gmx.de> --- source/conf.py | 2 +- source/references.rst | 3 +++ 2 files changed, 4 insertions(+), 1 deletion(-) diff --git a/source/conf.py b/source/conf.py index 86f7b88..4a2566a 100644 --- a/source/conf.py +++ b/source/conf.py @@ -100,7 +100,7 @@ html_theme = 'alabaster' # Add any paths that contain custom static files (such as style sheets) here, # relative to this directory. They are copied after the builtin static files, # so a file named "default.css" will overwrite the builtin "default.css". -html_static_path = ['_static'] +# html_static_path = ['_static'] # -- Options for HTMLHelp output ------------------------------------------ diff --git a/source/references.rst b/source/references.rst index 1eb0509..c94d1d1 100644 --- a/source/references.rst +++ b/source/references.rst @@ -1,5 +1,8 @@ .. SPDX-License-Identifier: CC-BY-SA-4.0 +References +========== + .. [ACPI] `Advanced Configuration and Power Interface specification v6.2A <http://www.uefi.org/sites/default/files/resources/ACPI%206_2_A_Sept29.pdf>`_, September 2017, `UEFI Forum <http://www.uefi.org>`_ -- 2.30.0

4 years, 8 months

1
0
0 0

[PATCH 1/1] UEFI section 2.6 exceptions for boot services

by Heinrich Schuchardt

Describes deviations for ConnectController() and LoadImage(). Signed-off-by: Heinrich Schuchardt <xypron.glpk(a)gmx.de> --- source/chapter2-uefi.rst | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/source/chapter2-uefi.rst b/source/chapter2-uefi.rst index 49aec46..660eb27 100644 --- a/source/chapter2-uefi.rst +++ b/source/chapter2-uefi.rst @@ -112,6 +112,17 @@ interface specific UEFI protocols, and so they have been made optional. * - Element - Description of deviation + * - `LoadImage()` + - The LoadImage() boot service is not required to install an + EFI_HII_PACKAGE_LIST_PROTOCOL for an image containing a custom PE/COFF + resource with the type 'HII'. - HII resource images are not needed to run + the UEFI shell or the SCT. + * - `ConnectController()` + - The ConnectController()` boot service is not required to support the + EFI_PLATFORM_DRIVER_OVERRIDE_PROTOCOL, + EFI_DRIVER_FAMILY_OVERRIDE_PROTOCOL, and + EFI_BUS_SPECIFIC_DRIVER_OVERRIDE_PROTOCOL. - These override protocols are + only useful if drivers are loaded as EFI binaries by the firmware. * - `EFI_HII_CONFIG_ACCESS_PROTOCOL` - UEFI requires this for console devices, but it is rarely necessary in practice. Therefore this protocol is not required. -- 2.30.0

4 years, 8 months

2
1
0 0

[PATCH] Override UEFI section 2.6 requirements

by Grant Likely

EBBR only requires a subset of UEFI. Provide a replacement for the UEFI section that lists base requirements. Fixes: #60 Fixes: #61 Fixes: #64 --- This is my first complete draft itemizing the specific UEFI requirements for EBBR. Please review and comment. Cheers, g. source/chapter2-uefi.rst | 155 ++++++++++++++++++++++++++++++++++++++- 1 file changed, 152 insertions(+), 3 deletions(-) diff --git a/source/chapter2-uefi.rst b/source/chapter2-uefi.rst index aab1c2c..5864a17 100644 --- a/source/chapter2-uefi.rst +++ b/source/chapter2-uefi.rst @@ -14,8 +14,157 @@ This document uses version 2.8 Errata A of the UEFI specification [UEFI]_. UEFI Compliance =============== -EBBR compliant platforms shall conform to the requirements in [UEFI]_ § 2.6, -except where explicit exemptions are provided by this document. +EBBR compliant platform shall conform to a subset of the [UEFI]_ spec as listed +in this section. +Normally, UEFI compliance would require full compliance with all items listed +in section 2.6 of the UEFI spec. +However, the EBBR target market has a reduced set of requirements, +and so some UEFI features are omitted as unnecessary. + +Required Elements +----------------- + +This section replaces the list of required elements in [UEFI]_ § 2.6.1. +All of the following UEFI elements are required for EBBR compliance. + +.. list-table:: UEFI Required Elements + :widths: 50 50 + :header-rows: 1 + + * - Element + - Requirement + * - `EFI_SYSTEM_TABLE` + - The system table is required to provide required to access UEFI Boot Services, + UEFI Runtime Services, consoles, and other firmware, vendor and platform + information. + * - `EFI_BOOT_SERVICES` + - All functions defined as boot services must exist. + Methods for unsupported or unimplemented behavour must return an appropriate error code. + * - `EFI_RUNTIME_SERVICES` + - All functions defined as runtime services must exist. + Methods for unsupported or unimplemented behavour must return an appropriate error code. + * - `EFI_LOADED_IMAGE_PROTOCOL` + - Must be installed for each loaded image + * - `EFI_LOADED_IMAGE_DEVICE_PATH_PROTOCOL` + - Must be installed for each loaded image + * - `EFI_DEVICE_PATH_PROTOCOL` + - Interface to provide location of a device + * - `EFI_DEVICE_PATH_UTILITIES_PROTOCOL` + - Interface for creating and manipulating UEFI device paths + +.. list-table:: Notible Omissions from UEFI section 2.6.1 + :header-rows: 1 + + * - Element + - Note + * - EFI_DECOMPRESS_PROTOCOL + - Native EFI Decompression is rarely used and therefore not required. + +Required Platform Specific Elements +----------------------------------- + +This section replaces the list of required elements in [UEFI]_ § 2.6.2. +All of the following UEFI elements are required for EBBR compliance. + +.. list-table:: UEFI Platform-Specific Required Elements + :widths: 50 50 + :header-rows: 1 + + * - Element + - Description + * - Console devices + - The platform must have at least one console device + * - `EFI_SIMPLE_TEXT_INPUT_PROTOCOL` + - Needed for console input + * - `EFI_SIMPLE_TEXT_INPUT_EX_PROTOCOL` + - Needed for console input + * - `EFI_SIMPLE_TEXT_OUTPUT_PROTOCOL` + - Needed for console output + * - `EFI_DEVICE_PATH_TO_TEXT_PROTOCOL` + - Needed for console output + * - `EFI_HII_STRING_PROTOCOL` + - Required by EFI shell and for compliance testing + * - `EFI_HII_DATABASE_PROTOCOL` + - Required by EFI shell and for compliance testing + * - `EFI_UNICODE_COLLATION2_PROTOCOL` + - Required by EFI shell and for compliance testing + * - `EFI_BLOCK_IO_PROTOCOL` + - Required for block device access + * - `EFI_SIMPLE_FILE_SYSTEM_PROTOCOL` + - Required if booting from block device is supported + * - `EFI_RNG_PROTOCOL` + - Required if platform has a hardware entropy source + * - Network booting + - If the platform supports network booting via TFTP, + then `EFI_SIMPLE_NETWORK_PROTOCOL` and + `EFI_PXE_BASE_CODE_PROTOCOL` must be implemented. + +The following table is a list of notable deviations from UEFI section 2.6.2. +Many of these deviations are because the EBBR use cases do not require +interface specific UEFI protocols, and so they have been made optional. + +.. list-table:: Notible Deviations from UEFI section 2.6.2 + :widths: 50 50 + :header-rows: 1 + + * - Element + - Description of deviation + * - `EFI_HII_CONFIG_ACCESS_PROTOCOL` + - UEFI requires this for console devices, but it is rarely necessary in practice. + Therefore this protocol is not requried. + * - `EFI_HII_CONFIG_ROUTING_PROTOCOL` + - UEFI requires this for console devices, but it is rarely necessary in practice. + Therefore this protocol is not requried. + * - Graphical console + - Platforms with a graphical device are not required to expose it as a graphical console. + * - EFI_DISK_IO_PROTOCOL + - Rarely used interface that isn't requried for EBBR use cases + * - Network protocols + - A full implementation of the UEFI general purpose networking ABIs is not required, + including `EFI_NETWORK_INTERFACE_IDENTIFIER_PROTOCOL`, `EFI_MANAGED_NETWORK_PROTOCOL`, + `EFI_*_SERVICE_BINDING_PROTOCOL`, or any of the IPv4 or IPv6 protocols. + * - Byte stream device support (UART) + - UEFI protocols not required + * - PCI bus support + - UEFI protocols not required + * - USB bus support + - UEFI protocols not required + * - NVMe pass through support + - UEFI protocols not required + * - SCSI pass through support + - UEFI protocols not required + * - SCSI pass through support + - UEFI protocols not required + * - `EFI_DRIVER_FAMILY_OVERRIDE_PROTOCOL` + - Not required + * - Option ROM support + - EBBR implementations are not required to support option ROM loading + +Required Global Variables +------------------------- + +EBBR compliant platforms are required to implement the following Global +Variables as found in [UEFI]_ § 3.3. + +.. list-table:: Required UEFI Variables + :widths: 25 75 + :header-rows: 1 + + * - Variable Name + - Description + * - `Boot####` + - A boot load option. #### is a numerical hex value + * - `BootCurrent` + - The boot option that was selected for the current boot + * - `BootNext` + - The boot option that will be used for the next boot only + * - `BootOrder` + - An ordered list of boot options. + Firmware will attempt each Boot#### entry in this order + * - `OsIndications` + - Method for OS to request features from firmware + * - `OsIndicationsSupported` + - Variable for firmware to indicate which features can be enabled Block device partitioning ------------------------- @@ -148,7 +297,7 @@ are required to be implemented during boot services and runtime services. .. table:: EFI_RUNTIME_SERVICES Implementation Requirements ============================== ============= ================ - EFI_RUNTIME_SERVICES function Boot Services Runtime Services + EFI_RUNTIME_SERVICES function Before EBS() After EBS() ============================== ============= ================ EFI_GET_TIME Optional Optional EFI_SET_TIME Optional Optional -- 2.20.1

4 years, 8 months

7
17
0 0

EBBR Biweekly for Monday 01 Feb 2021

by Grant Likely

Hi all, Next EBBR biweekly is on Monday at 16:00 GMT. Dial-in details are below. Below is the agenda I have so far. I've carried over the items that we did not have time to discuss last week. Agenda: - Initrd passing - Revised UEFI requirements (patch on mailing list) - UpdateCapsule() - other business Please email if you want to add anything to the agenda Cheers, g. ---- Topic: EBBR Biweekly Time: 1 Feb 2021, 16:00-17:00 GMT Join Zoom Meeting https://armltd.zoom.us/j/92081365511?pwd=SFZpRitXUEp3Zy9GM0h3UUZ1b1pnUT09 Meeting ID: 920 8136 5511 Passcode: 490324 One tap mobile +14086380968,,92081365511#,,,,*490324# US (San Jose) +16465189805,,92081365511#,,,,*490324# US (New York) Dial by your location +1 408 638 0968 US (San Jose) +1 646 518 9805 US (New York) +1 346 248 7799 US (Houston) Meeting ID: 920 8136 5511 Passcode: 490324 Find your local number: https://armltd.zoom.us/u/aelJgr9ZAW IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

4 years, 8 months

1
2
0 0

Re: Ideas for DT improvements

by Zhangpeng (Parker, Kirin)

Hi Bill, Improve search algorithm performance: We will need data to show the problem. I suppose this would best be done when unflatening the data at runtime? What is the expected gain in boot time? Are there any measurements of how much time is spent in the search routines today? Actually, It is nessary to search and modify device tree in boot loader, and the device tree has not be unflatened. We need to search device tree node int dtb by libfdt, however libfdt algorithm is pretty horrible, eg:fdt_node_offset_by_compatible. It takes about 10ms on average to search for a node. I suppose the dtb structure and libfdt algorithm can be optimized to reduce boot time? The time for searching for a node should be less than 1 ms. Reduce DTB space: What is the goal of the use case? 1) Fit in limited storage ( ex: 256MB ) 2) Conserve more space of modest storage for container data ( 1GB eMMC) 3) Improve boot time For 3, the load time will be reduced but the decompression time will be added. These need to be balanced based on the CPU. One pet peeve I have in most of our boot loaders today is that they do loading and decompression serially. During loading the IO is 100% loaded and the CPU is very lightly loaded. During decomoression the CPU is 100% loaded and the IO is 0%. It makes sense to pipleline / overlap these things which means that it needs to go into the loader. To optimize boot time the decompression algorithm needs to be chosen correctly. On smaller CPUs the time taken to decompress newer algorithms can greatly outweigh the time taken to load the decompressed data. Ideally the time to decompress 1 block == time to load one block. The dynamics shift with CPU and IO performance. Today, a lot of people focused on boot speed just use decompressed data but I think we could do better if we pipeline Since one dtbo image contains of hundreds of dtbs, the iamge is too large. The goal of reducing dtb space is to fit in limited storage without increasing boot time. Pipleline / overlap loading and decompression is a good idea. We can try to overlap them in boot loader, and discuss it further if there's a problem. Define specific rule for properties: This is harder.In 2019 I had proposed an ATOM based DTB enhancement [2]. I was told Frank Rowand had other proposals for format changes. OK.I am very interested in the ATOM based DTB enhancement. I will learn about it and other format changes, then make some detailed discussions with you. Thanks very much, Bill. Happy Chinese New Year Regards, Zhangpeng 发件人: Jammy Zhou [mailto:jammy.zhou@linaro.org] 发送时间: 2021年2月9日 16:45 收件人: Xiamingliang (XML, Hisilicon) <xiamingliang(a)huawei.com> 抄送: Bill Mills <bill.mills(a)linaro.org>; boot-architecture(a)lists.linaro.org; Frank Rowand <frowand.list(a)gmail.com>; Zhangpeng (Parker, Kirin) <zhangpeng55(a)huawei.com>; Wangjun (U) <wangjundrv.wang(a)huawei.com> 主题: Re: Ideas for DT improvements Hi Bill, Thanks very much for your comments. Since we're close to the Chinese New Year holiday, I would assume there will be some delay for the response by Zhangpeng. Regards, Jammy On Sun, 7 Feb 2021 at 09:35, Xiamingliang (XML, Hisilicon) <xiamingliang(a)huawei.com<mailto:xiamingliang@huawei.com>> wrote: + zhangpeng, owner of DT in Hisilicon -----Original Message----- From: Bill Mills [mailto:bill.mills@linaro.org<mailto:bill.mills@linaro.org>] Sent: 2021年2月7日 1:39 To: Jammy Zhou <jammy.zhou(a)linaro.org<mailto:jammy.zhou@linaro.org>>; boot-architecture(a)lists.linaro.org<mailto:boot-architecture@lists.linaro.org>; Frank Rowand <frowand.list(a)gmail.com<mailto:frowand.list@gmail.com>> Cc: Xiamingliang (XML, Hisilicon) <xiamingliang(a)huawei.com<mailto:xiamingliang@huawei.com>> Subject: Re: Ideas for DT improvements Hi Jammy & Mingliang, On 2/5/21 2:59 AM, Jammy Zhou wrote: > Hi, > > There are several ideas for DT improvements. Please check if they are > reasonable, and any comments are welcome. I would let Mingliang (CCed) > share more details if needed. > > 1) Improve search algorithm performance: Is the binary search tree or > other algorithm better than current algorithm? > We will need data to show the problem. I suppose this would best be done when unflatening the data at runtime? What is the expected gain in boot time? Are there any measurements of how much time is spent in the search routines today? > 2) Reduce DTB space: when use one DTB to support multiple boards, the > image is quite big (e.g, ~39MB space for 100 configurations), and some > compression algorithm can reduce the space a lot (e.g, from 39MB to 7MB). > Shall we have such compression support for DTB? And it can be helpful > if we can have more efficient compression algorithm. > This could be done as an enhancement to the DTB loader instead of the DTB format itself. Compressing each DTB (boardx.dtb.xz) will get you gains but compressing a set of boards (vmlinux-5.4.0-65-generic-dbt-set-20.tar.xz) might give you more. To be significant, the number of boards would need to be large and the size of the rootfs would need to be modest. A 200 to 300 MB minimal image would make an interesting comparison point. (A rootfs of 10s of MB would probably only target a few boards.) What is the goal of the use case? 1) Fit in limited storage ( ex: 256MB ) 2) Conserve more space of modest storage for container data ( 1GB eMMC) 3) Improve boot time For 3, the load time will be reduced but the decompression time will be added. These need to be balanced based on the CPU. One pet peeve I have in most of our boot loaders today is that they do loading and decompression serially. During loading the IO is 100% loaded and the CPU is very lightly loaded. During decomoression the CPU is 100% loaded and the IO is 0%. It makes sense to pipleline / overlap these things which means that it needs to go into the loader. To optimize boot time the decompression algorithm needs to be chosen correctly. On smaller CPUs the time taken to decompress newer algorithms can greatly outweigh the time taken to load the decompressed data. Ideally the time to decompress 1 block == time to load one block. The dynamics shift with CPU and IO performance. Today, a lot of people focused on boot speed just use decompressed data but I think we could do better if we pipeline > 3) Define specific rule for properties: The property value > (FDT_PROP_DATA) itself occupies only ~50% of the total DTB space. And > the property of each node is different and the private property name > length is too long, for > example: “freq-autodown-baseaddress-num” in dt_strings. It seems more > reasonable that the property value should occupies more than 70% of > the total DTB space. It can probably be achieved to define some rules > to restrict the length of property name, etc. > This is harder. In 2019 I had proposed an ATOM based DTB enhancement [2]. I was told Frank Rowand had other proposals for format changes. Thanks, Bill [2] https://docs.google.com/document/d/19XbxN-zX-GYwOXdF78lGnp0j7UNx1MT3wzyCjai… > Thanks, > Jammy > _______________________________________________ > boot-architecture mailing list > boot-architecture(a)lists.linaro.org<mailto:boot-architecture@lists.linaro.org> > https://lists.linaro.org/mailman/listinfo/boot-architecture > -- Bill Mills Principal Technical Consultant, Linaro +1-240-643-0836 TZ: US Eastern Work Schedule: Tues/Wed/Thur

4 years, 8 months

1
0
0 0

Ideas for DT improvements

by Jammy Zhou

Hi, There are several ideas for DT improvements. Please check if they are reasonable, and any comments are welcome. I would let Mingliang (CCed) share more details if needed. 1) Improve search algorithm performance: Is the binary search tree or other algorithm better than current algorithm? 2) Reduce DTB space: when use one DTB to support multiple boards, the image is quite big (e.g, ~39MB space for 100 configurations), and some compression algorithm can reduce the space a lot (e.g, from 39MB to 7MB). Shall we have such compression support for DTB? And it can be helpful if we can have more efficient compression algorithm. 3) Define specific rule for properties: The property value (FDT_PROP_DATA) itself occupies only ~50% of the total DTB space. And the property of each node is different and the private property name length is too long, for example: “freq-autodown-baseaddress-num” in dt_strings. It seems more reasonable that the property value should occupies more than 70% of the total DTB space. It can probably be achieved to define some rules to restrict the length of property name, etc. Thanks, Jammy

4 years, 8 months

3
3
0 0

Devicetree Evo Call Monday Jan 25 and every two weeks thereafter

by Bill Mills

All, I hope we have finally settled on a standing meeting time for the DT Evo call. We will have the call every other Monday alternating with EBBR in the same time slot. If I have done the TZ math correctly this is 16:00 UTC, and 11 AM US Eastern, 8AM US Pacific. I have sent a google calendar invite to all those listed on the previous call. If you would like to be added to that please email me directly at bill.mills(a)linaro.org Topic: Devicetree Evolution Time: Jan 25, 2021 11:00 AM Eastern Time (US and Canada) Every 2 weeks on Mon (Alternates with EBBR meeting in same time slot) Join Zoom Meeting https://linaro-org.zoom.us/j/96170428801?pwd=elBJNFdVMFJub0UzanFUcVQxTHBqdz… Meeting ID: 961 7042 8801 Passcode: 8250 One tap mobile +13017158592,,96170428801# US (Washington D.C) +16465588656,,96170428801# US (New York) Dial by your location +1 301 715 8592 US (Washington D.C) 888 788 0099 US Toll-free 877 853 5247 US Toll-free +44 203 481 5237 United Kingdom 0 800 031 5717 United Kingdom Toll-free Meeting ID: 961 7042 8801 Find your local number: https://linaro-org.zoom.us/u/acQEZ30MEP -- Bill Mills Principal Technical Consultant, Linaro +1-240-643-0836 TZ: US Eastern Work Schedule: Tues/Wed/Thur

4 years, 9 months

2
2
0 0

[EBBR RFC] Refine RTC requirements

by Grant Likely

If the platform has an RTC, then EFI_GET_TIME and EFI_SET_TIME are required before ExitBootServices(). Clarify this in the spec. Also specify that EFI_{GET,SET}_WAKEUP_TIME are required before ExitBootService() if the RTC can wakeup the platform. Signed-off-by: Grant Likely <grant.likely(a)arm.com> --- Reading through the RTC text it didn't seem clear to me. How's this for a clarification? g. source/chapter2-uefi.rst | 15 +++++++++------ 1 file changed, 9 insertions(+), 6 deletions(-) diff --git a/source/chapter2-uefi.rst b/source/chapter2-uefi.rst index 9906fd9..ab22932 100644 --- a/source/chapter2-uefi.rst +++ b/source/chapter2-uefi.rst @@ -159,16 +159,16 @@ are required to be implemented during boot services and runtime services. - Before ExitBootServices() - After ExitBootServices() * - `EFI_GET_TIME` - - Optional + - Required if RTC present - Optional * - `EFI_SET_TIME` - - Optional + - Required if RTC present - Optional * - `EFI_GET_WAKEUP_TIME` - - Optional + - Required if wakeup supported - Optional * - `EFI_SET_WAKEUP_TIME` - - Optional + - Required if wakeup supported - Optional * - `EFI_SET_VIRTUAL_ADDRESS_MAP` - N/A @@ -227,8 +227,11 @@ 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. -If firmware does not support access to the RTC, then GetTime() and -SetTime() shall return EFI_UNSUPPORTED, +If an RTC is present, then GetTime() and SetTime() must be supported +before ExitBootServices() is called. + +However, if firmware does not support access to the RTC after +ExitBootServices(), 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.20.1

4 years, 9 months

1
0
0 0

DT based PSA description of hardware partition

by François Ozog

Hi I assume this needs to be analyzed from System Device Tree perspective: https://trustedfirmware-a.readthedocs.io/en/latest/components/psa-ffa-manif… And this is to be included in the DT Technical Report. Cheers FF -- François-Frédéric Ozog | *Director Linaro Edge & Fog Computing Group* T: +33.67221.6485 francois.ozog(a)linaro.org | Skype: ffozog

4 years, 9 months

4
6
0 0

EBBR Biweekly (Postponed to 14th Dec)

by Grant Likely

Hi everyone. I have to do this, but I have another unexpected conflict for the EBBR biweekly on the 14th. Rather than cancelling outright, does anyone else want to chair the meeting? The major planned orientatio item on the agenda was to talk about EBBR testing, with Heinrich sharing what he is currently doing. If I don't hear anything by about 1pm GMT tomorrow then I'll just cancel. Our next meeting will be in January as I believe most of us will already be on Christmas holiday on the 21st g. Get Outlook for Android<https://aka.ms/ghei36> IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

4 years, 9 months

6
13
0 0

[EBBR PATCH] Require EFI_UPDATE_CAPSULE

by Grant Likely

EFI_UPDATE_CAPSULE is the industry standard method for applying firmware updates. Make it a requirement in EBBR so that fwupd, Windows Update, and any other generic firmware update service can support EBBR platforms. This is made required because the ability to update firmware is a critical part of building secure platforms. Fixes: #69 Signed-off-by: Grant Likely <grant.likely(a)arm.com> --- source/chapter2-uefi.rst | 32 +++++++++++++++++++++++++++++++- 1 file changed, 31 insertions(+), 1 deletion(-) diff --git a/source/chapter2-uefi.rst b/source/chapter2-uefi.rst index 7b5eb24..b1182a8 100644 --- a/source/chapter2-uefi.rst +++ b/source/chapter2-uefi.rst @@ -167,7 +167,10 @@ are required to be implemented during boot services and runtime services. EFI_SET_VARIABLE Required Optional EFI_GET_NEXT_HIGH_MONO_COUNT N/A Optional EFI_RESET_SYSTEM Required Optional - EFI_UPDATE_CAPSULE Optional Optional + EFI_UPDATE_CAPSULE Required Optional + for in-band + firmware + update EFI_QUERY_CAPSULE_CAPABILITIES Optional Optional EFI_QUERY_VARIABLE_INFO Optional Optional ============================== ============= ================ @@ -243,6 +246,25 @@ Even when SetVariable() is not supported during runtime services, firmware should cache variable names and values in EfiRuntimeServicesData memory so that GetVariable() and GetNextVeriableName() can behave as specified. +Firmware Update +--------------- + +Being able to update firmware to address security issues is a key feature of secure platforms. +EBBR platforms are required to implement either an in-band or an out-of-band firmware update mechanism. + +If firmware update is performed in-band (firmware on the application processor updates itself), +then the firmware shall implement EFI_UPDATE_CAPSULE and accept updates in the +"Firmware Management Protocol Data Capsule Structure" format as described in [UEFI]_ § 23.3, +"Delivering Capsules Containing Updates to Firmware Management Protocol. [#FMPNote]_ +Firmware is also required to provide an EFI System Resource Table (ESRT). [UEFI]_ § 23.4 +Every firmware image that is updated in-band must be described in the ESRT. + +If firmware update is performed out-of-band (e.g., by an independent Board Management Controller, +or firmware is provided by a hypervisor), then the platform is not required to implement EFI_UPDATE_CAPSULE. + +EFI_UPDATE_CAPSULE is only required before ExitBootServices() is called. + + .. [#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 @@ -253,3 +275,11 @@ that GetVariable() and GetNextVeriableName() can behave as specified. during runtime services. https://optee.readthedocs.io/en/latest/architecture/secure_storage.html + +.. [#FMPNote] The `EFI_UPDATE_CAPSULE` implementation is expected to be suitable + for use by generic firmware update services like fwupd and Windows Update. + Both fwupd and Windows Update read the ESRT table to determine what firmware + can be updated, and use an EFI helper application to call `EFI_UPDATE_CAPSULE` + before ExitBootServices() is called. + + https://fwupd.org/ -- 2.20.1 IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

4 years, 9 months

1
0
0 0

Specifying the boot flow

by Simon Glass

Hi, I thought perhaps it might be worth starting a thread on this, as despite Grant and Heinrich kinding spending a bit of time talking about this, I am still very much in the dark about how 'embedded' and distro/other boot flows are going to come together with EBBR. Of course this would be easier f2f. Case 1: Firmware loads the kernel to a particular address, selects DT and boots it. The kernel may require EFI boot services, or may not, but in the general case the firmware provides them. Case 2: Firmware loads EFI app and provides EFI boot services to it. How the system actually boots is under control of the app. I feel that a lot of the confusion about verified boot, DT selections, boot menus, etc. is coming from the introduction of an EFI app which has no specification (it can be grub, shim or something else, as I understand it). Certainly this is very flexible and future-proof, but it is also arbitrarily complex, unpredictable and hard to secure. I am wondering if we can come up with a way to deterministically specify how a system will boot and how to make it boot a different way (i.e. with a different kernel, initrd, DT). Heinrich mentioned EFI variables as a way of selecting kernel/initrd/DT. Then the problem becomes just a case of being able to change those variables from Linux userspace. Is that right? We are talking about having a 'secure' part of EBBR, which allows for secure boot. Should we have a 'defined boot' part of EBBR, that defines how the kernel/DT/initrd are selected, based on EFI variables? Unfortunately I just don't know enough about all the different boot flows used by the different distros. It seems like crazy town. Does anyone have some pointers so I can do some study? Regards, SImon

4 years, 9 months

7
20
0 0

Devicetree state of U-Boot vs kernel

by Bill Mills

All, On the Devicetree evolution call Wednesday I promised to finish my comparison of u-boot DT vs kernel DT. The script is not perfect but the results are still interesting. For each dts and dtsi file in the tip of the u-boot tree, it tries to correlate it to the kernel tip. It compares git SHA1 signatures or falls back to filenames. The results were surprising to me but perhaps they should not have been. I have checked in the script[1] and the full results here [2] The full file lists (with some diff stats) are in the root dir. Example [3] I also looked at the line count of the u-boot override files. Even though we don't expect these to correlate, we do expect reasonable usage to result in small files. Big files are an indication of possible abuse of the system. (I don't think the idea was to have wholesale new versions of the DTS as an override.) I plan to redo the script in python. It will be much easier to be more precise and to look deeper. (For example figure out how old the u-boot version is in number of change sets and number of days. Or if no content sync now were they ever synced?) Here is the scripts output: (from summary.txt) Devicetree sync status for u-boot v2021.01-rc5-7-gb8c725e736 Compared to kernel v5.11-rc2-156-g71c061d24438 14% (255) are completely synced 253 arm 2 riscv 0 mips 0 powerpc 0 x86 0 68k 0 microblaze 0 sh 0 arc 23% (416) content has appeared in the kernel but is not up to date 411 arm 0 riscv 1 mips 0 powerpc 1 x86 0 68k 0 microblaze 0 sh 1 arc 33% (584) filename appears in kernel but content never has 467 arm 1 riscv 12 mips 91 powerpc 0 x86 0 68k 0 microblaze 0 sh 8 arc 28% (510) neither filename nor content appears in kernel 305 arm 4 riscv 48 mips 35 powerpc 44 x86 0 68k 1 microblaze 1 sh 6 arc n/a (510) U-Boot specific, no correlation expected 7 sandbox 358 override 211 test histogram of override size (in raw lines) 10 61 20 53 30 38 40 33 50 23 60 14 70 12 80 7 90 5 100 4 110 4 120 5 130 6 140 4 150 0 160 2 170 0 180 0 190 4 200 0 210 2 220 2 230 1 240 2 250 1 260 1 270 1 280 0 290 0 300 0 310 0 320 1 [1] https://github.com/wmamills/devicetree-source/blob/master/scripts/correlate… [2] https://github.com/wmamills/devicetree-source [3] https://github.com/wmamills/devicetree-source/blob/master/dts-somewhere.txt -- Bill Mills Principal Technical Consultant, Linaro +1-240-643-0836 TZ: US Eastern Work Schedule: Tues/Wed/Thur

4 years, 9 months

2
1
0 0

DeviceTree Evolution call tomorrow Jan 6

by Bill Mills

Hello, Thanks to all that have participated in the doodle poll. We don't yet have all key stakeholders so please add your info if you have not. As expected there is no perfect time but the current leader is Wednesdays at 4PM UK, 11 AM US Eastern. I have scheduled a meeting for tomorrow as this first one. Possible topics for tomorrow include: * More Conformance testing of DT source * Keeping multiple DT projects in sync (w/o moving the DT source) * DT overlay source in the kernel source tree (for bootloader applied overlays) If we stay with Wednesdays the meeting after this one would be Jan 27. (Wednesdays require working around Linaro TSC calls) Thanks, Bill *** Bill Mills is inviting you to a scheduled Zoom meeting. Topic: DT Evolution Time: Jan 6, 2021 04:00 PM London Join Zoom Meeting https://linaro-org.zoom.us/j/94413146152?pwd=NEs1Ym1xbnRBS0U4ZWNsaXFzbm1Ndz… Meeting ID: 944 1314 6152 Passcode: 8250 One tap mobile +13017158592,,94413146152# US (Washington D.C) +13126266799,,94413146152# US (Chicago) Dial by your location +1 301 715 8592 US (Washington D.C) +1 312 626 6799 US (Chicago) +1 646 558 8656 US (New York) +1 669 900 9128 US (San Jose) +1 253 215 8782 US (Tacoma) +1 346 248 7799 US (Houston) 877 853 5247 US Toll-free 888 788 0099 US Toll-free Meeting ID: 944 1314 6152 Find your local number: https://linaro-org.zoom.us/u/aesZr3aPDG -- Bill Mills Principal Technical Consultant, Linaro +1-240-643-0836 TZ: US Eastern Work Schedule: Tues/Wed/Thur

4 years, 10 months

1
0
0 0

DT conformance and "reg" tuples

by François Ozog

Hi, As I am thinking about conformance testing for SystemReady and Trusted Substrate, I'd like to get your feedback on the following. There are 7 values in the reg entry of interrupt-controller@210000 from the below DT. This corresponds to 3 valid {address,size} plus a single {address}. The spec does not state anything on incomplete {address,size} pairs... I understand that #size-cell can be zero, indicating that the reg will contain only {address} "tuples" and not {address,size} tuples. But that should be for all reg tuples, not just one. In this case, I assume the driver will get what it wants, but from a certification perspective: - I would reject this DT. - I would document proper tuple forming in the spec (no incomplete pairs) Last, I would also add some "notes" in the spec about where to get the "#*-cells" for the reg property of a device. If you think "hardware" it is obvious that the information must be retrieved from the immediate parent and "inheritance" does not make sense. But as I Googled the topic, I have seen a number of discussions and wrong patches around that. So I would add a non normative text (properly identified as such) to describe that in the spec. Thank you for your help Cheers FF config-space@f0000000 { #address-cells = <0x01>; #size-cells = <0x01>; compatible = "simple-bus"; ranges = <0x00 0x00 0xf0000000 0x1000000>; interrupt-controller@210000 { compatible = "arm,gic-400"; #interrupt-cells = <0x03>; #address-cells = <0x01>; #size-cells = <0x01>; ranges; interrupt-controller; interrupts = <0x01 0x09 0xf04>; reg = <0x210000 0x10000 0x220000 0x20000 0x240000 0 0x20000>; phandle = <0x01>; v2m@280000 { compatible = "arm,gic-v2m-frame"; msi-controller; reg = <0x280000 0x1000>; arm,msi-base-spi = <0xa0>; arm,msi-num-spis = <0x20>; phandle = <0x03>; }; -- François-Frédéric Ozog | *Director Linaro Edge & Fog Computing Group* T: +33.67221.6485 francois.ozog(a)linaro.org | Skype: ffozog

4 years, 10 months

2
1
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

boot-architecture