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
On 1/29/21 8:21 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
This is my first complete draft itemizing the specific UEFI requirements for EBBR. Please review and comment.
Cheers, g.
Dear Grant,
thanks for putting this into the spec.
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 platforminformation.
- `EFI_BOOT_SERVICES`
- All functions defined as boot services must exist.Methods for unsupported or unimplemented behavour must return an appropriate error code.
%s/behavour/behavior/g
- `EFI_RUNTIME_SERVICES`
- All functions defined as runtime services must exist.Methods for unsupported or unimplemented behavour must return an appropriate error code.
ditto
- `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
What is the requirement? The protocol must be installed on all handles related to devices?
- `EFI_DEVICE_PATH_UTILITIES_PROTOCOL`
- Interface for creating and manipulating UEFI device paths+.. list-table:: Notible Omissions from UEFI section 2.6.1
%s/Omissions/omissions/ ?
- :header-rows: 1
- Element
- Note
- EFI_DECOMPRESS_PROTOCOL
- Native EFI Decompression is rarely used and therefore not required.
%s/Decompression/decompression/ ?
+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.
TFTP booting means loading the first EFI binary via TFTP. The EFI_PXE_BASE_CODE_PROTOCOL does not help to do this. This requirement needs some clarification.
+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.
%s/requried/required/
- `EFI_HII_CONFIG_ROUTING_PROTOCOL`
- UEFI requires this for console devices, but it is rarely necessary in practice.Therefore this protocol is not requried.
ditto
- 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
ditto
- 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
I am missing a justification for ignoring option ROMs in the suggested text.
Can't we write that option ROMs are currently not available for non-x86 architectures.
+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
These variables except BootCurrent are not "implemented" by the platform but set by the user. The firmware provides a "boot manager".
- `OsIndications`
- Method for OS to request features from firmware
This variable is set by the OS and interpreted by the firmware.
Otherwise the patch looks good to me.
In a future patch we should add advice for configuration tables like the EFI System Resource Table and the Image Execution Information Table.
Best regards
Heinrich
- `OsIndicationsSupported`
- Variable for firmware to indicate which features can be enabledBlock 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
On 29/01/2021 20:17, Heinrich Schuchardt wrote:
On 1/29/21 8:21 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
This is my first complete draft itemizing the specific UEFI requirements for EBBR. Please review and comment.
Cheers, g.
Dear Grant,
thanks for putting this into the spec.
Thanks for the feedback Heinrich. Comments below...
--- 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.
%s/behavour/behavior/g
+ * - `EFI_RUNTIME_SERVICES` + - All functions defined as runtime services must exist. + Methods for unsupported or unimplemented behavour must return an appropriate error code.
ditto
done
+ * - `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
What is the requirement? The protocol must be installed on all handles related to devices?
I don't know. What do you recommend be specified here?
+ * - `EFI_DEVICE_PATH_UTILITIES_PROTOCOL` + - Interface for creating and manipulating UEFI device paths
+.. list-table:: Notible Omissions from UEFI section 2.6.1
%s/Omissions/omissions/ ?
fixed
+ :header-rows: 1
+ * - Element + - Note + * - EFI_DECOMPRESS_PROTOCOL + - Native EFI Decompression is rarely used and therefore not required.
%s/Decompression/decompression/ ?
fixed
+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.
TFTP booting means loading the first EFI binary via TFTP. The EFI_PXE_BASE_CODE_PROTOCOL does not help to do this. This requirement needs some clarification.
Okay, so should I then drop EFI_PXE_BASE_CODE_PROTOCOL and required something else? Can you suggest some language?
+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.
%s/requried/required/
+ * - `EFI_HII_CONFIG_ROUTING_PROTOCOL` + - UEFI requires this for console devices, but it is rarely necessary in practice. + Therefore this protocol is not requried.
ditto
+ * - 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
ditto
fixed
+ * - 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
I am missing a justification for ignoring option ROMs in the suggested text.
Can't we write that option ROMs are currently not available for non-x86 architectures.
All this is saying is that option ROM loading isn't required by the platform. A platform is still able to implement it if needed, but my read on the ecosystem is that supporting generic add-in boards is not a high priority. Rather native OS drivers and integration are relied on to support specific PCIe devices.
"But wait," I hear you say, "What about GPUs?". I simply don't think GPU add in board support is a significant enough use case for option ROMs to be required by EBBR. Change my mind. :-)
I've added the reasoning to the text as discussed in our meeting today. New version out shortly.
+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
These variables except BootCurrent are not "implemented" by the platform but set by the user. The firmware provides a "boot manager".
How about: s/required to implement/required to support/
+ * - `OsIndications` + - Method for OS to request features from firmware
This variable is set by the OS and interpreted by the firmware.
Otherwise the patch looks good to me.
In a future patch we should add advice for configuration tables like the EFI System Resource Table and the Image Execution Information Table.
Yes. ESRT should be added at the same time as UpdateCapsule. I haven't looked into IEIT yet.
Best regards
Heinrich
+ * - `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
On 2/1/21 8:56 PM, Grant Likely wrote:
On 29/01/2021 20:17, Heinrich Schuchardt wrote:
On 1/29/21 8:21 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
This is my first complete draft itemizing the specific UEFI requirements for EBBR. Please review and comment.
Cheers, g.
Dear Grant,
thanks for putting this into the spec.
Thanks for the feedback Heinrich. Comments below...
--- 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.
%s/behavour/behavior/g
+ * - `EFI_RUNTIME_SERVICES` + - All functions defined as runtime services must exist. + Methods for unsupported or unimplemented behavour must return an appropriate error code.
ditto
done
+ * - `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
What is the requirement? The protocol must be installed on all handles related to devices?
I don't know. What do you recommend be specified here?
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:: Notible Omissions from UEFI section 2.6.1
%s/Omissions/omissions/ ?
fixed
+ :header-rows: 1
+ * - Element + - Note + * - EFI_DECOMPRESS_PROTOCOL + - Native EFI Decompression is rarely used and therefore not required.
%s/Decompression/decompression/ ?
fixed
+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.
TFTP booting means loading the first EFI binary via TFTP. The EFI_PXE_BASE_CODE_PROTOCOL does not help to do this. This requirement needs some clarification.
Okay, so should I then drop EFI_PXE_BASE_CODE_PROTOCOL and required something else? Can you suggest some language?
* -`EFI_SIMPLE_NETWORK_PROTOCOL` - Required for network booting if a network device is available.
+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.
%s/requried/required/
+ * - `EFI_HII_CONFIG_ROUTING_PROTOCOL` + - UEFI requires this for console devices, but it is rarely necessary in practice. + Therefore this protocol is not requried.
ditto
+ * - 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
* - 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.
Best regards
Heinrich
ditto
fixed
+ * - 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
I am missing a justification for ignoring option ROMs in the suggested text.
Can't we write that option ROMs are currently not available for non-x86 architectures.
All this is saying is that option ROM loading isn't required by the platform. A platform is still able to implement it if needed, but my read on the ecosystem is that supporting generic add-in boards is not a high priority. Rather native OS drivers and integration are relied on to support specific PCIe devices.
"But wait," I hear you say, "What about GPUs?". I simply don't think GPU add in board support is a significant enough use case for option ROMs to be required by EBBR. Change my mind. :-)
I've added the reasoning to the text as discussed in our meeting today. New version out shortly.
+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
These variables except BootCurrent are not "implemented" by the platform but set by the user. The firmware provides a "boot manager".
How about: s/required to implement/required to support/
+ * - `OsIndications` + - Method for OS to request features from firmware
This variable is set by the OS and interpreted by the firmware.
Otherwise the patch looks good to me.
In a future patch we should add advice for configuration tables like the EFI System Resource Table and the Image Execution Information Table.
Yes. ESRT should be added at the same time as UpdateCapsule. I haven't looked into IEIT yet.
Best regards
Heinrich
+ * - `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
Thanks Heinrich,
Changes made and new patch to be posted soon.
g.
On 01/02/2021 20:27, Heinrich Schuchardt wrote:
On 2/1/21 8:56 PM, Grant Likely wrote:
On 29/01/2021 20:17, Heinrich Schuchardt wrote:
On 1/29/21 8:21 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
This is my first complete draft itemizing the specific UEFI requirements for EBBR. Please review and comment.
Cheers, g.
Dear Grant,
thanks for putting this into the spec.
Thanks for the feedback Heinrich. Comments below...
--- 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.
%s/behavour/behavior/g
+ * - `EFI_RUNTIME_SERVICES` + - All functions defined as runtime services must exist. + Methods for unsupported or unimplemented behavour must return an appropriate error code.
ditto
done
+ * - `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
What is the requirement? The protocol must be installed on all handles related to devices?
I don't know. What do you recommend be specified here?
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:: Notible Omissions from UEFI section 2.6.1
%s/Omissions/omissions/ ?
fixed
+ :header-rows: 1
+ * - Element + - Note + * - EFI_DECOMPRESS_PROTOCOL + - Native EFI Decompression is rarely used and therefore not required.
%s/Decompression/decompression/ ?
fixed
+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.
TFTP booting means loading the first EFI binary via TFTP. The EFI_PXE_BASE_CODE_PROTOCOL does not help to do this. This requirement needs some clarification.
Okay, so should I then drop EFI_PXE_BASE_CODE_PROTOCOL and required something else? Can you suggest some language?
- -`EFI_SIMPLE_NETWORK_PROTOCOL`
- Required for network booting if a network device is available.
+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.
%s/requried/required/
+ * - `EFI_HII_CONFIG_ROUTING_PROTOCOL` + - UEFI requires this for console devices, but it is rarely necessary in practice. + Therefore this protocol is not requried.
ditto
+ * - 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
- 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.
Best regards
Heinrich
ditto
fixed
+ * - 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
I am missing a justification for ignoring option ROMs in the suggested text.
Can't we write that option ROMs are currently not available for non-x86 architectures.
All this is saying is that option ROM loading isn't required by the platform. A platform is still able to implement it if needed, but my read on the ecosystem is that supporting generic add-in boards is not a high priority. Rather native OS drivers and integration are relied on to support specific PCIe devices.
"But wait," I hear you say, "What about GPUs?". I simply don't think GPU add in board support is a significant enough use case for option ROMs to be required by EBBR. Change my mind. :-)
I've added the reasoning to the text as discussed in our meeting today. New version out shortly.
+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
These variables except BootCurrent are not "implemented" by the platform but set by the user. The firmware provides a "boot manager".
How about: s/required to implement/required to support/
+ * - `OsIndications` + - Method for OS to request features from firmware
This variable is set by the OS and interpreted by the firmware.
Otherwise the patch looks good to me.
In a future patch we should add advice for configuration tables like the EFI System Resource Table and the Image Execution Information Table.
Yes. ESRT should be added at the same time as UpdateCapsule. I haven't looked into IEIT yet.
Best regards
Heinrich
+ * - `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
On 02.02.21 11:45, Grant Likely wrote:
Thanks Heinrich,
Changes made and new patch to be posted soon.
g.
In the protocols section we should add that the UEFI System Partition GUID has to be installed on the handle for the ESP. There is no protocol for it. EDK II simply sets the protocol interface to NULL.
Best regards
Heirnich
On 02/02/2021 15:37, Heinrich Schuchardt wrote:
On 02.02.21 11:45, Grant Likely wrote:
Thanks Heinrich,
Changes made and new patch to be posted soon.
g.
In the protocols section we should add that the UEFI System Partition GUID has to be installed on the handle for the ESP. There is no protocol for it. EDK II simply sets the protocol interface to NULL.
Is this already covered in the UEFI spec?
g.
On 2/12/21 7:14 PM, Grant Likely wrote:
On 02/02/2021 15:37, Heinrich Schuchardt wrote:
On 02.02.21 11:45, Grant Likely wrote:
Thanks Heinrich,
Changes made and new patch to be posted soon.
g.
In the protocols section we should add that the UEFI System Partition GUID has to be installed on the handle for the ESP. There is no protocol for it. EDK II simply sets the protocol interface to NULL.
Is this already covered in the UEFI spec?
It is a requirement from the UEFI spec:
"If an MBR partition has an OSType field of 0xEF (i.e., UEFI System Partition), then the firmware must add the UEFI System Partition GUID to the handle for the MBR partition using InstallProtocolInterface()."
"The firmware must add the PartitionTypeGuid to the handle of every active GPT partition using EFI_BOOT_SERVICES.InstallProtocolInterface()."
As we enumerate all required protocols we should also add this one to the list.
Best regards
Heinrich
On Mon, Feb 1, 2021 at 8:28 PM Heinrich Schuchardt xypron.glpk@gmx.de wrote:
On 2/1/21 8:56 PM, Grant Likely wrote:
On 29/01/2021 20:17, Heinrich Schuchardt wrote:
On 1/29/21 8:21 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
This is my first complete draft itemizing the specific UEFI requirements for EBBR. Please review and comment.
Cheers, g.
Dear Grant,
thanks for putting this into the spec.
Thanks for the feedback Heinrich. Comments below...
--- 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 accessUEFI Boot Services,
UEFI Runtime Services, consoles, and other firmware, vendorand platform
information.
- `EFI_BOOT_SERVICES`
- All functions defined as boot services must exist.Methods for unsupported or unimplemented behavour must returnan appropriate error code.
%s/behavour/behavior/g
- `EFI_RUNTIME_SERVICES`
- All functions defined as runtime services must exist.Methods for unsupported or unimplemented behavour must returnan appropriate error code.
ditto
done
- `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 deviceWhat is the requirement? The protocol must be installed on all handles related to devices?
I don't know. What do you recommend be specified here?
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:: Notible Omissions from UEFI section 2.6.1
%s/Omissions/omissions/ ?
fixed
- :header-rows: 1
- Element
- Note
- EFI_DECOMPRESS_PROTOCOL
- Native EFI Decompression is rarely used and therefore notrequired.
%s/Decompression/decompression/ ?
fixed
+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.TFTP booting means loading the first EFI binary via TFTP. The EFI_PXE_BASE_CODE_PROTOCOL does not help to do this. This requirement needs some clarification.
Okay, so should I then drop EFI_PXE_BASE_CODE_PROTOCOL and required something else? Can you suggest some language?
- -`EFI_SIMPLE_NETWORK_PROTOCOL`
- Required for network booting if a network device is available.
+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 rarelynecessary in practice.
Therefore this protocol is not requried.%s/requried/required/
- `EFI_HII_CONFIG_ROUTING_PROTOCOL`
- UEFI requires this for console devices, but it is rarelynecessary in practice.
Therefore this protocol is not requried.ditto
- Graphical console
- Platforms with a graphical device are not required to exposeit as a graphical console.
- EFI_DISK_IO_PROTOCOL
- Rarely used interface that isn't requried 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.
I don't think PXE should be a requirement, as Heinrich mentions it's insecure. We should be requiring a secure protocol for a new spec, not an old one that's being EOLed. I believe vendors are moving to remove it in favour of HTTPS boot which also has the advantage it's more flexible, and it much better places for IoT/Edge deployments which use CDNs and the life extensively and it will generally work with firewalls etc. If we're going to require something for network installs, if the device has a capable network interface, it should be HTTPS Boot.
Peter
Best regards
Heinrich
ditto
fixed
- Network protocols
- A full implementation of the UEFI general purpose networkingABIs is not required,
including `EFI_NETWORK_INTERFACE_IDENTIFIER_PROTOCOL`,`EFI_MANAGED_NETWORK_PROTOCOL`,
`EFI_*_SERVICE_BINDING_PROTOCOL`, or any of the IPv4 or IPv6protocols.
- 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 ROMloading
I am missing a justification for ignoring option ROMs in the suggested text.
Can't we write that option ROMs are currently not available for non-x86 architectures.
All this is saying is that option ROM loading isn't required by the platform. A platform is still able to implement it if needed, but my read on the ecosystem is that supporting generic add-in boards is not a high priority. Rather native OS drivers and integration are relied on to support specific PCIe devices.
"But wait," I hear you say, "What about GPUs?". I simply don't think GPU add in board support is a significant enough use case for option ROMs to be required by EBBR. Change my mind. :-)
I've added the reasoning to the text as discussed in our meeting today. New version out shortly.
+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 orderThese variables except BootCurrent are not "implemented" by the platform but set by the user. The firmware provides a "boot manager".
How about: s/required to implement/required to support/
- `OsIndications`
- Method for OS to request features from firmwareThis variable is set by the OS and interpreted by the firmware.
Otherwise the patch looks good to me.
In a future patch we should add advice for configuration tables like the EFI System Resource Table and the Image Execution Information Table.
Yes. ESRT should be added at the same time as UpdateCapsule. I haven't looked into IEIT yet.
Best regards
Heinrich
- `OsIndicationsSupported`
- Variable for firmware to indicate which features can be enabledBlock 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
boot-architecture mailing list boot-architecture@lists.linaro.org https://lists.linaro.org/mailman/listinfo/boot-architecture
On 02/02/2021 12:48, Peter Robinson wrote:
On Mon, Feb 1, 2021 at 8:28 PM Heinrich Schuchardt xypron.glpk@gmx.de wrote:
On 2/1/21 8:56 PM, Grant Likely wrote:
[...]
On 29/01/2021 20:17, Heinrich Schuchardt wrote:
On 1/29/21 8:21 PM, Grant Likely wrote:
- 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.
I don't think PXE should be a requirement, as Heinrich mentions it's insecure. We should be requiring a secure protocol for a new spec, not an old one that's being EOLed. I believe vendors are moving to remove it in favour of HTTPS boot which also has the advantage it's more flexible, and it much better places for IoT/Edge deployments which use CDNs and the life extensively and it will generally work with firewalls etc. If we're going to require something for network installs, if the device has a capable network interface, it should be HTTPS Boot.
Peter
Unfortunately we've got a functionality gap. U-Boot doesn't yet support TCP, HTTP, or TLS. All that functionality needs to be written or ported from somewhere.
I would really like to require a secure network boot mechanism, but I think it needs to be left out until U-Boot can do TCP and TLS.
g.
On 02.02.21 14:56, Grant Likely wrote:
On 02/02/2021 12:48, Peter Robinson wrote:
On Mon, Feb 1, 2021 at 8:28 PM Heinrich Schuchardt xypron.glpk@gmx.de wrote:
On 2/1/21 8:56 PM, Grant Likely wrote:
[...]
On 29/01/2021 20:17, Heinrich Schuchardt wrote:
On 1/29/21 8:21 PM, Grant Likely wrote:
- 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.
I don't think PXE should be a requirement, as Heinrich mentions it's insecure. We should be requiring a secure protocol for a new spec, not an old one that's being EOLed. I believe vendors are moving to remove it in favour of HTTPS boot which also has the advantage it's more flexible, and it much better places for IoT/Edge deployments which use CDNs and the life extensively and it will generally work with firewalls etc. If we're going to require something for network installs, if the device has a capable network interface, it should be HTTPS Boot.
Peter
Unfortunately we've got a functionality gap. U-Boot doesn't yet support TCP, HTTP, or TLS. All that functionality needs to be written or ported from somewhere.
I would really like to require a secure network boot mechanism, but I think it needs to be left out until U-Boot can do TCP and TLS.
You can use iPXE as U-Boot payload which offers HTTPS and iSCSI. Isn't that enough?
TLS is quite complicated. GNU TLS has > 430,000 lines of code (without comments). Looking at the number of CVEs in OpenSSL and GnuTLS I do not believe that the U-Boot community will be able to produce and maintain a secure implementation.
There have been multiple attempts to get TCP into U-Boot but all got stuck but I think that TCP should be feasible.
The major obstacle with network in U-Boot is that we are running single threaded without interrupts.
Best regards
Heinrich
- 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.
I don't think PXE should be a requirement, as Heinrich mentions it's insecure. We should be requiring a secure protocol for a new spec, not an old one that's being EOLed. I believe vendors are moving to remove it in favour of HTTPS boot which also has the advantage it's more flexible, and it much better places for IoT/Edge deployments which use CDNs and the life extensively and it will generally work with firewalls etc. If we're going to require something for network installs, if the device has a capable network interface, it should be HTTPS Boot.
Peter
Unfortunately we've got a functionality gap. U-Boot doesn't yet support TCP, HTTP, or TLS. All that functionality needs to be written or ported from somewhere.
I would really like to require a secure network boot mechanism, but I think it needs to be left out until U-Boot can do TCP and TLS.
You can use iPXE as U-Boot payload which offers HTTPS and iSCSI. Isn't that enough?
iPXE is an implementation not the standard. I think EBBR the standard should require HTTPS boot, now if U-Boot chooses to implement that part of the standard using an iPXE UEFI binary to implement HTTPS boot that's an optoin.
TLS is quite complicated. GNU TLS has > 430,000 lines of code (without comments). Looking at the number of CVEs in OpenSSL and GnuTLS I do not believe that the U-Boot community will be able to produce and maintain a secure implementation.
Sure, but we're not talking about U-Boot, we're talking about EBBR the standard and U-Boot has a number of means of implementing HTTPS Boot, but by hobbling the standard with deployment technologies of the last century I think is a mistake.
I have my opinions on whether implementing HTTP boot in U-Boot directly or leaning on iPXE as the implementation but that is irrelevant to what I think is right for EBBR as the standard. I think we should be specifying HTTPS boot as a part of the spec, and having a separate discussion of how that is supported in U-Boot.
Peter
On 02/02/2021 16:46, Peter Robinson wrote:
- 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.
I don't think PXE should be a requirement, as Heinrich mentions it's insecure. We should be requiring a secure protocol for a new spec, not an old one that's being EOLed. I believe vendors are moving to remove it in favour of HTTPS boot which also has the advantage it's more flexible, and it much better places for IoT/Edge deployments which use CDNs and the life extensively and it will generally work with firewalls etc. If we're going to require something for network installs, if the device has a capable network interface, it should be HTTPS Boot.
Peter
Unfortunately we've got a functionality gap. U-Boot doesn't yet support TCP, HTTP, or TLS. All that functionality needs to be written or ported from somewhere.
I would really like to require a secure network boot mechanism, but I think it needs to be left out until U-Boot can do TCP and TLS.
You can use iPXE as U-Boot payload which offers HTTPS and iSCSI. Isn't that enough?
iPXE is an implementation not the standard. I think EBBR the standard should require HTTPS boot, now if U-Boot chooses to implement that part of the standard using an iPXE UEFI binary to implement HTTPS boot that's an optoin.
TLS is quite complicated. GNU TLS has > 430,000 lines of code (without comments). Looking at the number of CVEs in OpenSSL and GnuTLS I do not believe that the U-Boot community will be able to produce and maintain a secure implementation.
Sure, but we're not talking about U-Boot, we're talking about EBBR the standard and U-Boot has a number of means of implementing HTTPS Boot, but by hobbling the standard with deployment technologies of the last century I think is a mistake.
I have my opinions on whether implementing HTTP boot in U-Boot directly or leaning on iPXE as the implementation but that is irrelevant to what I think is right for EBBR as the standard. I think we should be specifying HTTPS boot as a part of the spec, and having a separate discussion of how that is supported in U-Boot.
I agree here. EBBR should specify interfaces/specs without requiring iPXE, or any specific standard. HTTPS boot is clearly the right direction, but I'm wrestling with when/how it should be added.
After our chat today, I'll propose that HTTPS boot be required by EBBR if network boot is supported. U-Boot on it's own won't meet that requirement, so for the time being U-Boot platforms won't be able to claim EBBR compliant network boot.
g.
On Wed, 3 Feb 2021 at 15:04, Grant Likely grant.likely@arm.com wrote:
On 02/02/2021 16:46, Peter Robinson wrote:
- 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.
I don't think PXE should be a requirement, as Heinrich mentions it's insecure. We should be requiring a secure protocol for a new spec, not an old one that's being EOLed. I believe vendors are moving to remove it in favour of HTTPS boot which also has the advantage it's more flexible, and it much better places for IoT/Edge deployments which use CDNs and the life extensively and it will generally work with firewalls etc. If we're going to require something for network installs, if the device has a capable network interface, it should be HTTPS Boot.
Peter
Unfortunately we've got a functionality gap. U-Boot doesn't yet support TCP, HTTP, or TLS. All that functionality needs to be written or ported from somewhere.
I would really like to require a secure network boot mechanism, but I think it needs to be left out until U-Boot can do TCP and TLS.
You can use iPXE as U-Boot payload which offers HTTPS and iSCSI. Isn't that enough?
iPXE is an implementation not the standard. I think EBBR the standard should require HTTPS boot, now if U-Boot chooses to implement that part of the standard using an iPXE UEFI binary to implement HTTPS boot that's an optoin.
TLS is quite complicated. GNU TLS has > 430,000 lines of code (without comments). Looking at the number of CVEs in OpenSSL and GnuTLS I do not believe that the U-Boot community will be able to produce and maintain a secure implementation.
Sure, but we're not talking about U-Boot, we're talking about EBBR the standard and U-Boot has a number of means of implementing HTTPS Boot, but by hobbling the standard with deployment technologies of the last century I think is a mistake.
I have my opinions on whether implementing HTTP boot in U-Boot directly or leaning on iPXE as the implementation but that is irrelevant to what I think is right for EBBR as the standard. I think we should be specifying HTTPS boot as a part of the spec, and having a separate discussion of how that is supported in U-Boot.
I agree here. EBBR should specify interfaces/specs without requiring iPXE, or any specific standard. HTTPS boot is clearly the right direction, but I'm wrestling with when/how it should be added.
After our chat today, I'll propose that HTTPS boot be required by EBBR if network boot is supported. U-Boot on it's own won't meet that requirement, so for the time being U-Boot platforms won't be able to claim EBBR compliant network boot.
+1
On Wed, 3 Feb 2021 at 15:04, Grant Likely grant.likely@arm.com wrote:
On 02/02/2021 16:46, Peter Robinson wrote:
- EFI_PXE_BASE_CODE_PROTOCOL
- Booting via the Preboot Execution Environment (PXE) is
insecure.
Loading via PXE is typically executed before launching thefirst
UEFI application.I don't think PXE should be a requirement, as Heinrich mentions it's insecure. We should be requiring a secure protocol for a new spec, not an old one that's being EOLed. I believe vendors are moving to remove it in favour of HTTPS boot which also has the advantage it's more flexible, and it much better places for IoT/Edge deployments which use CDNs and the life extensively and it will generally work with firewalls etc. If we're going to require something for network installs, if the device has a capable network interface, it should be HTTPS Boot.
Peter
Unfortunately we've got a functionality gap. U-Boot doesn't yet support TCP, HTTP, or TLS. All that functionality needs to be written or ported from somewhere.
I would really like to require a secure network boot mechanism, but I think it needs to be left out until U-Boot can do TCP and TLS.
You can use iPXE as U-Boot payload which offers HTTPS and iSCSI. Isn't that enough?
iPXE is an implementation not the standard. I think EBBR the standard should require HTTPS boot, now if U-Boot chooses to implement that part of the standard using an iPXE UEFI binary to implement HTTPS boot that's an optoin.
TLS is quite complicated. GNU TLS has > 430,000 lines of code (without comments). Looking at the number of CVEs in OpenSSL and GnuTLS I do not believe that the U-Boot community will be able to produce and maintain a secure implementation.
Sure, but we're not talking about U-Boot, we're talking about EBBR the standard and U-Boot has a number of means of implementing HTTPS Boot, but by hobbling the standard with deployment technologies of the last century I think is a mistake.
I have my opinions on whether implementing HTTP boot in U-Boot directly or leaning on iPXE as the implementation but that is irrelevant to what I think is right for EBBR as the standard. I think we should be specifying HTTPS boot as a part of the spec, and having a separate discussion of how that is supported in U-Boot.
I agree here. EBBR should specify interfaces/specs without requiring iPXE, or any specific standard. HTTPS boot is clearly the right direction, but I'm wrestling with when/how it should be added.
After our chat today, I'll propose that HTTPS boot be required by EBBR if network boot is supported. U-Boot on it's own won't meet that requirement, so for the time being U-Boot platforms won't be able to claim EBBR compliant network boot.
Ilias and I discussed an approach where the HTTPs stack is in an EFI app
such as a standalone one or systemd-boot (this is a candidate because it already has nice boot blessing capabilities that work in conjunction with Linux systemd). iPXE has an implementation of the stack based on EFI network protocol (raw packets), so the work shouldn't be that big.
g. _______________________________________________ boot-architecture mailing list boot-architecture@lists.linaro.org https://lists.linaro.org/mailman/listinfo/boot-architecture
On Wed, Feb 03, 2021 at 03:53:09PM +0100, François Ozog wrote:
Sure, but we're not talking about U-Boot, we're talking about EBBR the standard and U-Boot has a number of means of implementing HTTPS Boot, but by hobbling the standard with deployment technologies of the last century I think is a mistake.
I have my opinions on whether implementing HTTP boot in U-Boot directly or leaning on iPXE as the implementation but that is irrelevant to what I think is right for EBBR as the standard. I think we should be specifying HTTPS boot as a part of the spec, and having a separate discussion of how that is supported in U-Boot.
I agree here. EBBR should specify interfaces/specs without requiring iPXE, or any specific standard. HTTPS boot is clearly the right direction, but I'm wrestling with when/how it should be added.
After our chat today, I'll propose that HTTPS boot be required by EBBR if network boot is supported. U-Boot on it's own won't meet that requirement, so for the time being U-Boot platforms won't be able to claim EBBR compliant network boot.
Ilias and I discussed an approach where the HTTPs stack is in an EFI app
such as a standalone one or systemd-boot (this is a candidate because it already has nice boot blessing capabilities that work in conjunction with Linux systemd). iPXE has an implementation of the stack based on EFI network protocol (raw packets), so the work shouldn't be that big.
I think what Grant proposes still stands (and for the record I agree with Peter).
Having iPXE (while veryfying it before launching) is an alternative we can implement relatively fast. This raises a question here though. U-Boot won't be EBBR compliant, since it would need an external application for the HTTP boot. What about boards that offer the firmware as a 'bundle' though? If they got a firmware + EFI app that will be able to do HTTP boot they would be able to get a SystemReady-IR certification?
Thanks /Ilias
g. _______________________________________________ boot-architecture mailing list boot-architecture@lists.linaro.org https://lists.linaro.org/mailman/listinfo/boot-architecture
-- François-Frédéric Ozog | *Director Linaro Edge & Fog Computing Group* T: +33.67221.6485 francois.ozog@linaro.org | Skype: ffozog _______________________________________________ boot-architecture mailing list boot-architecture@lists.linaro.org https://lists.linaro.org/mailman/listinfo/boot-architecture
On 03/02/2021 15:17, Ilias Apalodimas wrote:
On Wed, Feb 03, 2021 at 03:53:09PM +0100, Fran�ois Ozog wrote:
Sure, but we're not talking about U-Boot, we're talking about EBBR the standard and U-Boot has a number of means of implementing HTTPS Boot, but by hobbling the standard with deployment technologies of the last century I think is a mistake.
I have my opinions on whether implementing HTTP boot in U-Boot directly or leaning on iPXE as the implementation but that is irrelevant to what I think is right for EBBR as the standard. I think we should be specifying HTTPS boot as a part of the spec, and having a separate discussion of how that is supported in U-Boot.
I agree here. EBBR should specify interfaces/specs without requiring iPXE, or any specific standard. HTTPS boot is clearly the right direction, but I'm wrestling with when/how it should be added.
After our chat today, I'll propose that HTTPS boot be required by EBBR if network boot is supported. U-Boot on it's own won't meet that requirement, so for the time being U-Boot platforms won't be able to claim EBBR compliant network boot.
Ilias and I discussed an approach where the HTTPs stack is in an EFI app
such as a standalone one or systemd-boot (this is a candidate because it already has nice boot blessing capabilities that work in conjunction with Linux systemd). iPXE has an implementation of the stack based on EFI network protocol (raw packets), so the work shouldn't be that big.
I think what Grant proposes still stands (and for the record I agree with Peter).
Having iPXE (while veryfying it before launching) is an alternative we can implement relatively fast. This raises a question here though. U-Boot won't be EBBR compliant, since it would need an external application for the HTTP boot. What about boards that offer the firmware as a 'bundle' though? If they got a firmware + EFI app that will be able to do HTTP boot they would be able to get a SystemReady-IR certification?
Shouldn't be a problem. The platform is still EBBR compliant as long as it doesn't claim to support network boot because network booting is optional.
Also, if HTTPS boot is implemented using an external EFI binary that is packaged with U-Boot, then it still meets the network boot requirement. EBBR doesn't care how the feature is implemented.
g.
Thanks /Ilias
g. _______________________________________________ boot-architecture mailing list boot-architecture@lists.linaro.org https://lists.linaro.org/mailman/listinfo/boot-architecture
-- Fran�ois-Fr�d�ric Ozog | *Director Linaro Edge & Fog Computing Group* T: +33.67221.6485 francois.ozog@linaro.org | Skype: ffozog _______________________________________________ boot-architecture mailing list boot-architecture@lists.linaro.org https://lists.linaro.org/mailman/listinfo/boot-architecture
On Wed, Feb 03, 2021 at 04:01:27PM +0000, Grant Likely wrote:
On 03/02/2021 15:17, Ilias Apalodimas wrote:
On Wed, Feb 03, 2021 at 03:53:09PM +0100, Fran�ois Ozog wrote:
Sure, but we're not talking about U-Boot, we're talking about EBBR the standard and U-Boot has a number of means of implementing HTTPS Boot, but by hobbling the standard with deployment technologies of the last century I think is a mistake.
I have my opinions on whether implementing HTTP boot in U-Boot directly or leaning on iPXE as the implementation but that is irrelevant to what I think is right for EBBR as the standard. I think we should be specifying HTTPS boot as a part of the spec, and having a separate discussion of how that is supported in U-Boot.
I agree here. EBBR should specify interfaces/specs without requiring iPXE, or any specific standard. HTTPS boot is clearly the right direction, but I'm wrestling with when/how it should be added.
After our chat today, I'll propose that HTTPS boot be required by EBBR if network boot is supported. U-Boot on it's own won't meet that requirement, so for the time being U-Boot platforms won't be able to claim EBBR compliant network boot.
Ilias and I discussed an approach where the HTTPs stack is in an EFI app
such as a standalone one or systemd-boot (this is a candidate because it already has nice boot blessing capabilities that work in conjunction with Linux systemd). iPXE has an implementation of the stack based on EFI network protocol (raw packets), so the work shouldn't be that big.
I think what Grant proposes still stands (and for the record I agree with Peter).
Having iPXE (while veryfying it before launching) is an alternative we can implement relatively fast. This raises a question here though. U-Boot won't be EBBR compliant, since it would need an external application for the HTTP boot. What about boards that offer the firmware as a 'bundle' though? If they got a firmware + EFI app that will be able to do HTTP boot they would be able to get a SystemReady-IR certification?
Shouldn't be a problem. The platform is still EBBR compliant as long as it doesn't claim to support network boot because network booting is optional.
Also, if HTTPS boot is implemented using an external EFI binary that is packaged with U-Boot, then it still meets the network boot requirement. EBBR doesn't care how the feature is implemented.
... although we do care that a well behaved OS does not accidentally delete features.
In practice I think there is already enough language in the spec to cover this since the app is in the ESP /FIRMWARE directory (or in a private filesystem on a Required Partition) then a well behaved EBBR OS will leave it alone.
However a pre-certification checkbox does need to be slightly more sophisticated than "feature works when board is shipped"!
Daniel.
boot-architecture@lists.linaro.org
-
Ard Biesheuvel -
Daniel Thompson -
François Ozog -
Grant Likely -
Heinrich Schuchardt -
Ilias Apalodimas -
Peter Robinson