From 97b19910ead0e6b005945bc4370c381eb08b4f53 Mon Sep 17 00:00:00 2001
From: Jose Marinho <jose.marinho@arm.com>
Date: Tue, 21 Sep 2021 11:35:12 +0100
Subject: [PATCH] Remove TF-A related nomenclature from the spec.
The following substitutions were made:
- BL1 -> Immutable stage
- BL2 -> Secondary stage
- BL31 -> Monitor firmware
- BL32 -> Secure firmware
- BL33 -> Non-secure firmware
---
source/chapter1-about.rst | 10 +++++-----
source/chapter2-uefi.rst | 2 +-
source/chapter3-fwupdate.rst | 6 +++---
source/conventions.rst | 23 +++++++++++++----------
4 files changed, 22 insertions(+), 19 deletions(-)
diff --git a/source/chapter1-about.rst b/source/chapter1-about.rst
index e424214..390abdd 100644
--- a/source/chapter1-about.rst
+++ b/source/chapter1-about.rst
@@ -36,7 +36,7 @@ rest of the document.
The intent of this document is to provide guidelines for firmware updates that will protect the
device against bricking and rollback attacks. The update itself may occur from the non-secure world
-(BL33) or the secure world (BL32) depending on the implementation and the hardware requirements.
+(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`.*
@@ -59,9 +59,9 @@ Assumptions
- 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 BL2.
- In that case updating of BL2 should be disallowed from OTA
- update. In person update of BL2 may be possible and may require extra
+ 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
+ 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
components and multiplexing boot combinations can be very challenging. In this document we treat
@@ -85,7 +85,7 @@ Instead of having each firmware component non-volatile counter (used for rollbac
increased upon successful update, we can leave the counter untouched until the operating system
has reached a verdict. If the OS decides the current state is operational it will signal via UEFI
services and send capsule update indicating the transaction is successful.
-The firmware running in BL33 will, on next reboot, signal the individual firmware binaries to
+The Non-secure firmware will, on next reboot, signal the individual firmware binaries to
increase their rollback counter to the correct value. This assumes A/B partitions for all
firmware components and a TF-A upgrade mechanism that supports this functionality.
diff --git a/source/chapter2-uefi.rst b/source/chapter2-uefi.rst
index f0b342e..6ccd634 100644
--- a/source/chapter2-uefi.rst
+++ b/source/chapter2-uefi.rst
@@ -39,7 +39,7 @@ EFI_FIRMWARE_IMAGE_DESCRIPTOR provided by FMP.GetImageInfo().
The resource entry field FwClass must be set to “ESRT_FW_TYPE_SYSTEMFIRMWARE”
The fields LowestSupportedVersion, FwVersion are provided by
- the Secure World FWU when Secure world is responsible for the update
-- BL33 if Non-Secure world is responsible for the update
+- Non-secure firmware if Non-Secure world is responsible for the update
LastAttemptStatus is expected to be information kept by the UEFI implementation. This can partially
rely on information provided by early platform bootstages [FWU]_.
diff --git a/source/chapter3-fwupdate.rst b/source/chapter3-fwupdate.rst
index da8e98a..0d9db24 100644
--- a/source/chapter3-fwupdate.rst
+++ b/source/chapter3-fwupdate.rst
@@ -21,7 +21,7 @@ The FWU metadata [FWU]_ is managed by the FWU Implementation in the Secure world
When the flash is owned by the Secure World, the FMP communicates with the FWU Implementation
in the secure world using the FF-A Firmware Update ABI [FWU]_
-The FWU Implementation provides BL33 with a list of all FW images handled by it. The information
+The FWU Implementation provides Non-secure firmware with a list of all FW images handled by it. The information
is provided via the image directory [#FFANote]_.
.. [#FFANote] image directory is a stream of data structured as an array of image entries [FWU]_.
@@ -119,8 +119,8 @@ Post-capsule install reboot success
#. OS install the image acceptance capsule when all acceptance tests pass
#. Firmware processes the image acceptance capsule and updates the boot bank
#. Rollback counter updates
- * If BL33 can update the rollback counter(s) directly, it should do it on the fly
- * Otherwise, on the next reboot BL2 must detect the new version
+ * If the Non-secure firmware can update the rollback counter(s) directly, it should do it on the fly
+ * Otherwise, on the next reboot Secure firmware must detect the new version
(rollback counter < fw rollback counter)and update the rollback counter(s) accordingly.
Post-capsule install reboot fails before UEFI
diff --git a/source/conventions.rst b/source/conventions.rst
index 633d6da..46eb18c 100644
--- a/source/conventions.rst
+++ b/source/conventions.rst
@@ -31,20 +31,23 @@ This document uses the following terms and abbreviations.
EBBR
Embedded Base Boot Requirements
- Boot Loader stage 1 (BL1)
- AP Trusted ROM
+ ROM
+ Read only memory
- Boot Loader stage 2 (BL2)
- Trusted Boot Firmware
+ Immutable bootloader stage (Immutable stage)
+ First bootloader stage, generally stored in a ROM -- equatable to BL1 in TF-A or u-boot-spl.
- Boot Loader stage 3-1 (BL31)
- EL3 Runtime Firmware
+ Secondary bootloader stage (Secondary stage)
+ Optional bootloader stage that executes following the immutable stage -- equatable to BL2 in TF-A.
- Boot Loader stage 3-2 (BL32)
- Secure-EL1 Payload (optional)
+ Monitor Firmware
+ EL3 Runtime Firmware -- refered to as BL31 in TF-A.
- Boot Loader stage 3-3 (BL33)
- Non-trusted Firmware
+ Secure firmware
+ Firmware executing at S-EL2 and/or S-EL1 -- BL32 in the TF-A context. The Secure payload can be composed of different binaries.
+
+ Non-secure firmware
+ Firmware executing at EL2 or EL1 -- BL33 in the TF-A context.
SCP Firmware
System Control Processor firmware
--
GitLab