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.lik...@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/
_______________________________________________
boot-architecture mailing list
boot-architecture@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/boot-architecture
