On 12/02/2021 20:55, Heinrich Schuchardt wrote:

On 2/12/21 7:59 PM, Grant Likely wrote:

...

EBBR only requires a subset of UEFI. Provide a replacement for the UEFI section that lists base requirements.

Fixes: #60 Fixes: #61 Fixes: #64

---

source/chapter2-uefi.rst | 164 ++++++++++++++++++++++++++++++++++++++-   1 file changed, 162 insertions(+), 2 deletions(-)

diff --git a/source/chapter2-uefi.rst b/source/chapter2-uefi.rst index 9906fd9..f47a98d 100644 --- a/source/chapter2-uefi.rst +++ b/source/chapter2-uefi.rst @@ -14,8 +14,168 @@ 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.

We had consensus in the discussion that the ConnectController() service is not required to support:

• EFI_PLATFORM_DRIVER_OVERRIDE_PROTOCOL.
• EFI_DRIVER_FAMILY_OVERRIDE_PROTOCOL
• EFI_BUS_SPECIFIC_DRIVER_OVERRIDE_PROTOCOL

Do you want to add that in "Notable Deviations"?

...

+   * - `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 not implemented, the EFI_RT_PROPERTIES_TABLE must be provided and indicate this.

Changed. Thanks.

g.

The rest looks good to me.

Best regards

Heinrich

...

+   * - `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 +   * - `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 +   * - 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   -------------------------

On 2/12/21 7:59 PM, Grant Likely wrote:

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@arm.com

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 f47a98d..3d48c99 100644 --- a/source/chapter2-uefi.rst +++ b/source/chapter2-uefi.rst @@ -319,16 +319,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
  

Persisting daylight saving time and "timezone" are currently not supported in U-Boot.

EDK-II assumes RTC is UTC and adds the timezone offset and an extra hour if daylight saving is enabled.

This assumption is strange as Windows uses local time for the RTC (without hacking the registry). And EDK II was written to support Windows.

The UEFI spec requires that the time zone and the daylight saving flag should be adjusted when entering or leaving daylight saving time. But without knowing which country you are in there is no clue on which date and hour this change might occur. There is not even a UEFI service to switch the time zone between Europe/Brussels (which has daylight saving times in summer only) and Morocco (which has permanent daylight saving time).

To me it is not clear what the UEFI requirement on daylight saving time and time zones really are.

The SCT test case specification is equally vague: 5.2.2.2.36 "The return Time should be set before." No hint concerning the expected value.

Here some work is needed to get to a verifiable specification.

But that is beyond the scope of your patch series.

Reviewed-by: Heinrich Schuchardt xypron.glpk@gmx.de

   - 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

@@ -387,8 +387,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

On 15/02/2021 16:38, Heinrich Schuchardt wrote:

On 12.02.21 19:59, Grant Likely wrote:

...

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@arm.com

This patch cannot be applied to upstream:

Applying: Refine RTC requirements error: patch failed: source/chapter2-uefi.rst:319 error: source/chapter2-uefi.rst: patch does not apply

Sorry, there was a trivial formatting patch that I haven't pushed out yet. I'll push it out shortly.

g.

Please, rebase.

Best regards

Heinrich

...

---

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 f47a98d..3d48c99 100644 --- a/source/chapter2-uefi.rst +++ b/source/chapter2-uefi.rst @@ -319,16 +319,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

@@ -387,8 +387,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

On 2/12/21 7:59 PM, Grant Likely wrote:

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@arm.com

---

source/chapter2-uefi.rst | 29 ++++++++++++++++++++++++++++- 1 file changed, 28 insertions(+), 1 deletion(-)

diff --git a/source/chapter2-uefi.rst b/source/chapter2-uefi.rst index 3d48c99..4e8a24d 100644 --- a/source/chapter2-uefi.rst +++ b/source/chapter2-uefi.rst @@ -352,7 +352,7 @@ are required to be implemented during boot services and runtime services. - Required - Optional * - `EFI_UPDATE_CAPSULE`

As you have secure firmware in mind, shouldn't we explicitly require signature verification of capsules?

Best regards

Heinrich

• - Optional
  

• - Required for in-band update
   - Optional
  

  • • `EFI_QUERY_CAPSULE_CAPABILITIES`
    • Optional

@@ -435,6 +435,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

@@ -445,3 +464,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/

Hi Grant,

# apart from capsule update/EBBR,

On Mon, Feb 15, 2021 at 05:28:32PM +0000, Grant Likely wrote:

On 12/02/2021 21:50, Heinrich Schuchardt wrote:

...

On 2/12/21 7:59 PM, Grant Likely wrote:

...

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@arm.com

---

source/chapter2-uefi.rst | 29 ++++++++++++++++++++++++++++-   1 file changed, 28 insertions(+), 1 deletion(-)

diff --git a/source/chapter2-uefi.rst b/source/chapter2-uefi.rst index 3d48c99..4e8a24d 100644 --- a/source/chapter2-uefi.rst +++ b/source/chapter2-uefi.rst @@ -352,7 +352,7 @@ are required to be implemented during boot services and runtime services.        - Required        - Optional      * - `EFI_UPDATE_CAPSULE`

As you have secure firmware in mind, shouldn't we explicitly require signature verification of capsules?

Yes, but not yet. All the security requirements need to come in at the same time so that it makes sense, and it may be that we adopt BBSR as the security standard instead of adding it into EBBR.

looking at BBSR (v1.0a, downloaded from Arm site), it mentions EFI_VARIABLE_AUTHENTICATED_WRITE_ACCESS as one of required attributes for authenticated variables. But it is already marked as deprecated in UEFI spec, and I didn't implement it on U-Boot UEFI.

Has that statement in BBSR already been modified/fixed?

-Takahiro Akashi

g.

...

Best regards

Heinrich

...

-     - Optional +     - Required for in-band update        - Optional      * - `EFI_QUERY_CAPSULE_CAPABILITIES`        - Optional @@ -435,6 +435,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 @@ -445,3 +464,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/

---

boot-architecture mailing list boot-architecture@lists.linaro.org https://lists.linaro.org/mailman/listinfo/boot-architecture

On 2/15/21 6:17 PM, AKASHI Takahiro wrote:

Hi Grant,

# apart from capsule update/EBBR,

On Mon, Feb 15, 2021 at 05:28:32PM +0000, Grant Likely wrote:

...

On 12/02/2021 21:50, Heinrich Schuchardt wrote:

...

On 2/12/21 7:59 PM, Grant Likely wrote:

...

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@arm.com

---

source/chapter2-uefi.rst | 29 ++++++++++++++++++++++++++++-   1 file changed, 28 insertions(+), 1 deletion(-)

diff --git a/source/chapter2-uefi.rst b/source/chapter2-uefi.rst index 3d48c99..4e8a24d 100644 --- a/source/chapter2-uefi.rst +++ b/source/chapter2-uefi.rst @@ -352,7 +352,7 @@ are required to be implemented during boot services and runtime services.        - Required        - Optional      * - `EFI_UPDATE_CAPSULE`

As you have secure firmware in mind, shouldn't we explicitly require signature verification of capsules?

Yes, but not yet. All the security requirements need to come in at the same time so that it makes sense, and it may be that we adopt BBSR as the security standard instead of adding it into EBBR.

looking at BBSR (v1.0a, downloaded from Arm site), it mentions EFI_VARIABLE_AUTHENTICATED_WRITE_ACCESS as one of required attributes for authenticated variables. But it is already marked as deprecated in UEFI spec, and I didn't implement it on U-Boot UEFI.

Has that statement in BBSR already been modified/fixed?

That is removed in BBSR v1.1, which will be published later this Spring.

Stuart