On 01.09.20 16:49, Daniel Thompson wrote:
On Tue, Sep 01, 2020 at 03:55:15PM +0200, Heinrich Schuchardt wrote:
On 01.09.20 12:59, Grant Likely wrote:
The existing language around how firmware and an OS can share a storage device doesn't go into sufficient detail on how the firmware should protect firmware data on the device. Add language for both the GPT and MBR partitioning schemes on how firmware images should be described in the partition table.
Signed-off-by: Grant Likely grant.likely@arm.com
I posted this patch before the v1.0.1 release, but didn't merge it at that time because it needs a little more due diligence than can be give on a minor point release. Posting it now for proper review.
source/chapter4-firmware-media.rst | 67 +++++++++++++++++++++++------- 1 file changed, 51 insertions(+), 16 deletions(-)
diff --git a/source/chapter4-firmware-media.rst b/source/chapter4-firmware-media.rst index fc71274..65da603 100644 --- a/source/chapter4-firmware-media.rst +++ b/source/chapter4-firmware-media.rst @@ -47,13 +47,19 @@ conflict with normal usage of the media by an OS. Partitioning of Shared Storage ==============================
-A shared storage device shall use GPT partitioning unless it is incompatible -with the platform boot sequence. -In which case, MBR partitioning shall be used. [#MBRReqExample]_
-.. [#MBRReqExample] For example, if the boot ROM doesn't understand GPT
- partitioning, and will only work with an MBR, then the storage must be
- partitioned using an MBR.
+The shared storage device must use the GUID Partition Table (GPT) disk +layout as defined in [UEFI]_ § 5.3, unless the platform boot sequence is +fundamentally incompatible with the GPT disk layout. +In which case, a legacy Master Boot Recored (MBR) must be used. +[#MBRReqExample]_
+.. [#MBRReqExample] For example, if the SoC boot ROM requires an MBR to
- find the next stage firmware image, then it is incompatible with
- the GPT boot layout.
- Similarly, if the boot ROM expects the next stage firmware to be located
- at LBA1 (the location of the GPT Header), then it is incompatible with
- the GPT disk layout.
- In both cases the shared storage device must use legacy MBR partitioning.
.. warning::
@@ -71,15 +77,14 @@ the partition(s) containing firmware.
However, some SoCs load firmware from a fixed offset into the storage media. In this case, to protect against partitioning tools overwriting firmware, the -firmware image shall either reside entirely within the first 1MiB of storage, -or should be covered by a protective partition entry in the partition table as +partition table must be formed in a way to protect the firmware image(s) as described in sections :ref:`section-gpt-parts` and :ref:`section-mbr-parts`.
-Automatic partitioning tools (e.g. an OS installer) must not create -partitions within the first 1MiB of storage, or delete, move, or modify -protective partition entries. +Automatic partitioning tools (e.g. an OS installer) must not +delete the protective information in the partition table, or +delete, move, or modify protective partition entries. Manual partitioning tools should provide warnings when modifying -protective partitions or creating partitions within the first 1MiB. +protective partitions.
.. warning::
@@ -95,19 +100,49 @@ GPT partitioning
The partition table must strictly conform to the UEFI specification and include -a protective MBR authored exactly as described in [UEFI]_ § 5 (hybrid +a protective MBR authored exactly as described in [UEFI]_ § 5.3 (hybrid partitioning schemes are not permitted).
-Protective partitions must have the Platform Required Attribute Flag set. +Fixed-location firmware images must be protected by creating protective +partition entries, or by placing GPT data structures away from the LBAs +occupied by firmware,
+Protective partitions are entries in the partition table that cover the +LBA region occupied by firmware and have the 'Required Partition' attribute
%s/'Required Partition'/bit 0, 'Required Partition'/
+set.
Shouldn't we also set bit 1, 'No Block IO Protocol'?
Would that make it more difficult to write EFI based firmware update tools (that do know what the partition is used for) to write out updates?
You would still have the Block IO Protocol on disk level. So no, I do not think this would complicate things.
Best regards
Heinrich
+A protective partition must use a `PartitionTypeGUID` that identifies it +as a firmware protective partition. (e.g., don't reuse a GUID used by +non-protective partitions).
Can we positively define a PartitionTypeGUID here that identifies a firmware protective partition, e.g.
"GUID 72c91f31-9307-4668-b6e8-9a9ea07112e1 can be used to mark a partition as firmware protective."
No objections to providing a value but I think it should be strictly optional (e.g. MAY/OPTIONAL in the SHALL, SHOULD, MAY taxonomy of requirements).
Daniel.