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.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?
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.
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
