On 11/03/2021 20:06, Heinrich Schuchardt wrote:
On 3/11/21 5:53 PM, Grant Likely wrote:
[...]
+.. list-table:: Notable Deviations from UEFI § 2.6.2 + :widths: 50 50 + :header-rows: 1
+ * - Element + - Description of deviation + * - `LoadImage()` + - The LoadImage() boot service is not required to install an + EFI_HII_PACKAGE_LIST_PROTOCOL for an image containing a custom PE/COFF + resource with the type 'HII'. - HII resource images are not needed to run + the UEFI shell or the SCT. + * - `ConnectController()` + - The ConnectController()` boot service is not required to support the + EFI_PLATFORM_DRIVER_OVERRIDE_PROTOCOL, + EFI_DRIVER_FAMILY_OVERRIDE_PROTOCOL, and + EFI_BUS_SPECIFIC_DRIVER_OVERRIDE_PROTOCOL. - These override protocols are + only useful if drivers are loaded as EFI binaries by the firmware. + * - `EFI_HII_CONFIG_ACCESS_PROTOCOL` + - UEFI requires this for console devices, but it is rarely necessary in practice. + Therefore this protocol is not required. + * - `EFI_HII_CONFIG_ROUTING_PROTOCOL` + - UEFI requires this for console devices, but it is rarely necessary in practice. + Therefore this protocol is not required. + * - Graphical console
Hello Grant,
thanks for sharing this pre-release.
Should we mention the protocols that might not be provided:
EFI_GRAPHICS_OUTPUT_PROTOCOL EFI_EDID_DISCOVERED_PROTOCOL EFI_EDID_ACTIVE_PROTOCOL
I don't think it is strictly necessary, but if you want to propose a patch to add those protocols to the text then I'd be happy to add it.
+.. 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
Firmware will try BootNext and each Boot#### in the order given by BootOrder to find the first bootable image.
Fixed, will push out later.
+ * - `OsIndications` + - Method for OS to request features from firmware + * - `OsIndicationsSupported` + - Variable for firmware to indicate which features can be enabled
Block device partitioning ------------------------- @@ -53,7 +224,7 @@ a hypervisor or a virtualization aware Operating System. UEFI Boot at EL1 ^^^^^^^^^^^^^^^^
-Booting of UEFI at EL1 is most likely within a hypervisor hosted Guest +Booting of UEFI at EL1 is most likely employed within a hypervisor hosted Guest Operating System environment, to allow the subsequent booting of a UEFI-compliant Operating System. In this instance, the UEFI boot-time environment can be provided, as a @@ -77,7 +248,7 @@ The default RAM allocated attribute must be EFI_MEMORY_WB. Configuration Tables --------------------
-A UEFI system that complies with this specification may provide the additional +A UEFI system that complies with this specification may provide additional tables via the EFI Configuration Table.
Compliant systems are required to provide one, but not both, of the following @@ -151,26 +322,55 @@ EFI_UNSUPPORTED. are required to be implemented during boot services and runtime services.
.. _uefi_runtime_service_requirements: -.. table:: EFI_RUNTIME_SERVICES Implementation Requirements
- ============================== ============= ================ - EFI_RUNTIME_SERVICES function Boot Services Runtime Services - ============================== ============= ================ - EFI_GET_TIME Optional Optional - EFI_SET_TIME Optional Optional - EFI_GET_WAKEUP_TIME Optional Optional - EFI_SET_WAKEUP_TIME Optional Optional - EFI_SET_VIRTUAL_ADDRESS_MAP N/A Required - EFI_CONVERT_POINTER N/A Required - EFI_GET_VARIABLE Required Optional - EFI_GET_NEXT_VARIABLE_NAME Required Optional - EFI_SET_VARIABLE Required Optional - EFI_GET_NEXT_HIGH_MONO_COUNT N/A Optional - EFI_RESET_SYSTEM Required Optional - EFI_UPDATE_CAPSULE Optional Optional - EFI_QUERY_CAPSULE_CAPABILITIES Optional Optional - EFI_QUERY_VARIABLE_INFO Optional Optional > - ============================== ============= ================ +.. list-table:: `EFI_RUNTIME_SERVICES` Implementation Requirements + :widths: 40 30 30 + :header-rows: 1
+ * - `EFI_RUNTIME_SERVICES` function > + - Before ExitBootServices() + - After ExitBootServices() + * - `EFI_GET_TIME`
We should use the service names (not the type names) throughout this document:
GetTime(), SetTime(), ..., QueryVariableInfo().
Good comment. That will require some scrubbing of the document. I'll try to get to it, but any patches helping it along would be appreciated.
+ - Required if RTC present + - Optional + * - `EFI_SET_TIME` + - Required if RTC present + - Optional + * - `EFI_GET_WAKEUP_TIME` + - Required if wakeup supported + - Optional + * - `EFI_SET_WAKEUP_TIME` + - Required if wakeup supported + - Optional + * - `EFI_SET_VIRTUAL_ADDRESS_MAP` + - N/A + - Required + * - `EFI_CONVERT_POINTER` + - N/A + - Required + * - `EFI_GET_VARIABLE` + - Required + - Optional + * - `EFI_GET_NEXT_VARIABLE_NAME` + - Required + - Optional + * - `EFI_SET_VARIABLE` + - Required + - Optional + * - `EFI_GET_NEXT_HIGH_MONO_COUNT` + - N/A + - Optional + * - `EFI_RESET_SYSTEM` + - Required + - Optional + * - `EFI_UPDATE_CAPSULE` + - Required for in-band update + - Optional + * - `EFI_QUERY_CAPSULE_CAPABILITIES` + - Optional + - Optional + * - `EFI_QUERY_VARIABLE_INFO` + - Optional + - Optional
Runtime Device Mappings ----------------------- @@ -198,8 +398,11 @@ it may not be possible to access the RTC from runtime services. e.g., The RTC may be on a shared I2C bus which runtime services cannot access because it will conflict with the OS.
-If firmware does not support access to the RTC, then GetTime() and -SetTime() shall return EFI_UNSUPPORTED, +If an RTC is present, then GetTime() and SetTime() must be supported +before ExitBootServices() is called.
+However, if firmware does not support access to the RTC after +ExitBootServices(), then GetTime() and SetTime() shall return EFI_UNSUPPORTED and the OS must use a device driver to control the RTC.
UEFI Reset and Shutdown @@ -209,9 +412,10 @@ ResetSystem() is required to be implemented in boot services, but it is optional for runtime services. During runtime services, the operating system should first attempt to use ResetSystem() to reset the system. -If firmware doesn't support ResetSystem() during runtime services, -then the call will immediately return EFI_UNSUPPORTED, and the OS should -fall back to an architecture or platform specific reset mechanism.
+If firmware doesn't support ResetSystem() during runtime services, then the call +will immediately return, and the OS should fall back to an architecture or +platform specific reset mechanism.
On AArch64 platforms implementing [PSCI]_, if ResetSystem() is not implemented then the Operating System should fall @@ -242,6 +446,26 @@ Even when SetVariable() is not supported during runtime services, firmware should cache variable names and values in EfiRuntimeServicesData memory so that GetVariable() and GetNextVeriableName() can behave as specified.
+Firmware Update +---------------
+Being able to update firmware to address security issues is a key feature of secure platforms. +EBBR platforms are required to implement either an in-band or an out-of-band firmware update mechanism.
+If firmware update is performed in-band (firmware on the application processor updates itself), +then the firmware shall implement EFI_UPDATE_CAPSULE and accept updates
%s/EFI_UPDATE_CAPSULE/the UpdateCapsule() runtime service/
Is this the right way around to change this? Why doesn't it make sense to reference EFI_UPDATE_CAPSULE? The question is I suppose part of a larger question on how to refer to EFI elements throughout the document.
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
%s/is updated/can be updated/
Fixed
ESRT.
+If firmware update is performed out-of-band (e.g., by an independent Baseboard +Management Controller (BMC), or firmware is provided by a hypervisor), +then the platform is not required to implement EFI_UPDATE_CAPSULE.
the UpdateCapsule() runtime service
+EFI_UPDATE_CAPSULE is only required before ExitBootServices() is called.
UpdateCapsule() is only required to be supported ...
.. [#OPTEESupplicant] It is worth noting that OP-TEE has a similar problem regarding secure storage. OP-TEE's chosen solution is to rely on an OS supplicant agent to perform @@ -251,4 +475,12 @@ that GetVariable() and GetNextVeriableName() can behave as specified. Regardless, EBBR compliance does not require SetVariable() support during runtime services.
https://github.com/OP-TEE/optee_os/blob/master/documentation/secure_storage....
https://optee.readthedocs.io/en/latest/architecture/secure_storage.html
+.. [#FMPNote] The `EFI_UPDATE_CAPSULE` implementation is expected to be
UpdateCapsuel()
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`
UpdateCapsule()
+ before ExitBootServices() is called.
+ https://fwupd.org/ diff --git a/source/chapter4-firmware-media.rst b/source/chapter4-firmware-media.rst index fc71274..cfcc8bd 100644 --- a/source/chapter4-firmware-media.rst +++ b/source/chapter4-firmware-media.rst @@ -47,13 +47,19 @@ conflict with normal usage of the media by an OS. Partitioning of Shared Storage ==============================
-A shared storage device shall use GPT partitioning unless it is incompatible -with the platform boot sequence. -In which case, MBR partitioning shall be used. [#MBRReqExample]_
-.. [#MBRReqExample] For example, if the boot ROM doesn't understand GPT - partitioning, and will only work with an MBR, then the storage must be - partitioned using an MBR. +The shared storage device must use the GUID Partition Table (GPT) disk +layout as defined in [UEFI]_ § 5.3, unless the platform boot sequence is +fundamentally incompatible with the GPT disk layout. +In which case, a legacy Master Boot Recored (MBR) must be used. +[#MBRReqExample]_
+.. [#MBRReqExample] For example, if the SoC boot ROM requires an MBR to + find the next stage firmware image, then it is incompatible with + the GPT boot layout. + Similarly, if the boot ROM expects the next stage firmware to be located + at LBA1 (the location of the GPT Header), then it is incompatible with + the GPT disk layout. + In both cases the shared storage device must use legacy MBR partitioning.
.. warning::
@@ -62,7 +68,8 @@ In which case, MBR partitioning shall be used. [#MBRReqExample]_ GPT partitioning supports a much larger number of partitions, and has built in resiliency.
- A future issue of this specification will remove the MBR allowance. + A future issue of this specification will disallow the use of MBR
%s/issue/version/
Iterations of this spec are referred to as versions not issues.
fixed.
Best regards
Heinrich
Thanks for the comments Heinrich.
g.