From 159a51e41c6d4b2ca919fa989cfa1c624657c49c Mon Sep 17 00:00:00 2001 From: Ilias Apalodimas <ilias.apalodimas@linaro.org> Date: Mon, 27 Sep 2021 14:09:33 +0300 Subject: [PATCH] Some rewording and cleanups - 'Note:' is now bold - Reword watchdog requirements Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> --- source/chapter1-about.rst | 37 ++++++++++++++++++------------------- source/chapter2-uefi.rst | 13 ++++++++----- 2 files changed, 26 insertions(+), 24 deletions(-) diff --git a/source/chapter1-about.rst b/source/chapter1-about.rst index 879ce67..4818bec 100644 --- a/source/chapter1-about.rst +++ b/source/chapter1-about.rst @@ -38,29 +38,29 @@ The intent of this document is to provide guidelines for firmware updates that w device against bricking and rollback attacks. The update itself may occur from the non-secure world (Non-secure firmware) or the secure world (Secure firmware) depending on the implementation and the hardware requirements. - *Comments or change requests can be sent to `boot-architecture@lists.linaro.org`.* Scope -======== - +===== Dependable Boot was written as a response to the lack of firmware upgrade standardization in the embedded system ecosystem. As embedded systems are becoming more sophisticated and connected, it is becoming increasingly important for embedded systems to standardize the way they upgrade their firmware. -Assumptions ------------ - -- Since this document targets [EBBR]_ and [PSBG]_ compliant systems, the update process of platforms - without UEFI is outside the scope of this document -- Every firmware binary must support dual A/B partitions -- TF-A must be able to access our firmware NVCounter -- Update capsules are designed and deployed to target systems using a mechanism outside the - scope of this document. [#UEFICapsuleUpdateNote]_ -- We assume that the masked ROM can load TF-A from a dual image. In case the masked ROM can not - boot with an alternative location, similar functionality can be added to Secondary bootloader stage. - In that case updating of Secondary bootloader stage should be disallowed from OTA +Prerequisites +------------- +Since this document targets [EBBR]_ and [PSBG]_ compliant systems, the update process of platforms +without UEFI is outside the scope of this document. + +- Every firmware binary **must** support dual A/B partitions for all of it's + componenents. +- The first stage bootloader **must** be able to access our firmware NVCounter. +- UEFI capsule updates are the mechanism used for delivering firmware updates. + Refer to [#UEFICapsuleUpdateNote]_ for details. +- We assume that the masked ROM can load the first staged boot loader (e.g TF-A) from a dual image. + In case the masked ROM can not boot with an alternative location, similar functionality + can be added to the secondary bootloader stage. + In that case updating the Secondary bootloader stage should be disallowed from OTA update. In person update of Secondary bootloader stage may be possible and may require extra tools or procedures but that is out of the scope of this document. - Update process can target a single firmware component or multiple components. Updating multiple @@ -68,13 +68,12 @@ Assumptions the firmware as a single entity regardless of the components it comprises. Failing to update one of the components will lead to rollbacks of every affected component - Updating the firmware and the OS at the same time is prohibited. -- A hardware watchdog must always be active when Non-secure firmware is - executing. It's advisable the watchdog is activated on earlier boot stages as well. - The watchdog must reset the board if a timeout occurs. +- A hardware watchdog **must** always be active when critical components are executed. + It's advisable the watchdog is activated on the earliest possible boot stages. + The watchdog **must** reset the board if a timeout occurs. .. [#UEFICapsuleUpdateNote] [UEFI]_ 2.8B ยง 23 - Firmware Update and Reporting - Transactional updates --------------------- Since firmware updates are independent from the OS upgrades, an important aspect of the update diff --git a/source/chapter2-uefi.rst b/source/chapter2-uefi.rst index 6ccd634..d885240 100644 --- a/source/chapter2-uefi.rst +++ b/source/chapter2-uefi.rst @@ -68,7 +68,7 @@ If the OS wants to revert the FW images to a previously working bank, it can do - Flags = 0 - CapsuleImageSize = sizeof(EFI_CAPSULE_HEADER) -Note: the image acceptance capsule must be authenticated. Details TBD. +**Note**: the image acceptance capsule must be authenticated. Details TBD. When UEFI receives the capsule above, UEFI will change the FWU metadata active_index to a previously working bank index by either: @@ -100,7 +100,7 @@ The OS must accept each image, that has an acceptance pending, by using a capsul - CapsuleImageSize = sizeof(EFI_CAPSULE_HEADER) + sizeof(UUID) -Note: the image acceptance capsule must be authenticated. Details TBD. +**Note**: the image acceptance capsule must be authenticated. Details TBD. Update permission verification ------------------------------ @@ -121,7 +121,6 @@ The FW update authorization [NIST_800_193]_ can be checked by the OS, using OS s UpdateCapsule. Alternatively, the FW update authorization can rely on the FW image authenticity check. If all FW images in the capsule are authentic then the user is deemed authorized to progress with the FW update procedure. - FW image authentication ^^^^^^^^^^^^^^^^^^^^^^^ @@ -134,8 +133,6 @@ The FW vendor signature should be placed before the FW image as is described in The FW images should be authenticated before being written to the FW store or before being allowed to execute on the platform. - - Maximum Trial platform boots ---------------------------- @@ -143,3 +140,9 @@ The UEFI implementation must keep a count of the consecutive platform boots in the Trial state [FWU]_. If the number of consecutive platform boot in the Trial state exceeds a platform defined value of *max_trial_boots* then the UEFI implementation must revert the FW to the previous working bank [FWU]_. + +**Note**: Similar functionality must be implemented in the first stage boot loader. +This is platform specific, but the first stage bootloader must be able to count +the number of reboots. If the number exceeds *max_trial_boots* then we must +revert to a previous working version of the firmware. + -- GitLab