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 | 32 +++++++++++++++++++++++++++++++-
 1 file changed, 31 insertions(+), 1 deletion(-)

diff --git a/source/chapter2-uefi.rst b/source/chapter2-uefi.rst
index 7b5eb24..b1182a8 100644
--- a/source/chapter2-uefi.rst
+++ b/source/chapter2-uefi.rst
@@ -167,7 +167,10 @@ are required to be implemented during boot services and 
runtime services.
    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_UPDATE_CAPSULE             Required      Optional
+                                  for in-band
+                                  firmware
+                                  update
    EFI_QUERY_CAPSULE_CAPABILITIES Optional      Optional
    EFI_QUERY_VARIABLE_INFO        Optional      Optional
    ============================== ============= ================
@@ -243,6 +246,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
@@ -253,3 +275,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/
--
2.20.1

IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
_______________________________________________
boot-architecture mailing list
boot-architecture@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/boot-architecture

Reply via email to