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 +set. +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). +There are no requirements on the contents or layout of the firmware +protective partition. + +Placing GPT data structures away from firmware images can be accomplished by +adjusting the GUID Partition Entry array location +(adjusting the values of `PartitionEntryLBA` and `NumberOfPartitionEntries`, +and `SizeOfPartitionEntry`), +or by specifying the usable LBAs (Choosing `FirstUsableLBA`/`LastUsableLBA` +to not overlap the fixed firmware location). +See [UEFI]_ § 5.3.2. + +Given the choice, platforms should use protective partitions over +adjusting the placement of GPT data structures because protective partitions +provide explicit information about the protected region.
.. _section-mbr-parts:
MBR partitioning ^^^^^^^^^^^^^^^^
-Protective partitions should have a partition type of 0xF8 unless some +If firmware is at a fixed location entirely within the first 1MiB of +storage (<= LBA2047) then no protective partitions are required. +If firmware resides in a fixed location outside the first 1MiB, +then a protective partition must be used to cover the firmware LBAs. +Protective partitions should have a partition type of 0xF8 unless an immutable feature of the platform makes this impossible.
+OS partitioning tools must not create partitions in the first 1MiB +of the storage device, and must not remove protective partitions. + .. _section-fw-partition-fs:
Firmware Partition Filesystem
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'?
In gdisk you can set the bits via:
x - extra functionality (experts only) a - set attributes 0 - bit 0, system partition 1 - bit 1, hide from EFI
I could not find anything similar in gparted.
Adding a footnote explaining how to set the attribute with gdisk might be helpful.
+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."
In gdisk you can change the GUID in the main menu with
t - change a partition's type code
Best regards
Heinrich
+There are no requirements on the contents or layout of the firmware +protective partition.
+Placing GPT data structures away from firmware images can be accomplished by +adjusting the GUID Partition Entry array location +(adjusting the values of `PartitionEntryLBA` and `NumberOfPartitionEntries`, +and `SizeOfPartitionEntry`), +or by specifying the usable LBAs (Choosing `FirstUsableLBA`/`LastUsableLBA` +to not overlap the fixed firmware location). +See [UEFI]_ § 5.3.2.
+Given the choice, platforms should use protective partitions over +adjusting the placement of GPT data structures because protective partitions +provide explicit information about the protected region.
.. _section-mbr-parts:
MBR partitioning ^^^^^^^^^^^^^^^^
-Protective partitions should have a partition type of 0xF8 unless some +If firmware is at a fixed location entirely within the first 1MiB of +storage (<= LBA2047) then no protective partitions are required. +If firmware resides in a fixed location outside the first 1MiB, +then a protective partition must be used to cover the firmware LBAs. +Protective partitions should have a partition type of 0xF8 unless an immutable feature of the platform makes this impossible.
+OS partitioning tools must not create partitions in the first 1MiB +of the storage device, and must not remove protective partitions.
.. _section-fw-partition-fs:
Firmware Partition Filesystem
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?
+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.
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.
On Tue, Sep 01, 2020 at 04:53:49PM +0200, Heinrich Schuchardt wrote:
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.
Not quite sure I agree with that.
It certainly means it is not impossible for an EFI app to update firmware components. However not having partitioned block IO protocols sounds like the updater would need to include additional GPT parsing code (although on platforms where the offsets are fixed perhaps the offsets could be burned in instead).
Daniel.
+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.
On 02.09.20 12:11, Daniel Thompson wrote:
On Tue, Sep 01, 2020 at 04:53:49PM +0200, Heinrich Schuchardt wrote:
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.
Not quite sure I agree with that.
It certainly means it is not impossible for an EFI app to update firmware components. However not having partitioned block IO protocols sounds like the updater would need to include additional GPT parsing code (although on platforms where the offsets are fixed perhaps the offsets could be burned in instead).
I don't have any strong feelings about that bit being set or not. I meant my comment as a question.
In U-Boot there is currently no support for bit 1 suppressing the IO_BLOCK_PROTOCOL.
So this leads to the next question. Shall EBBR require support for bit 1, 'No Block IO Protocol' of GPT partitions? If yes, we should write it into the EBBR.
Best regards
Heinrich
Daniel.
+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.
On 02/09/2020 13:26, Heinrich Schuchardt wrote:
On 02.09.20 12:11, Daniel Thompson wrote:
On Tue, Sep 01, 2020 at 04:53:49PM +0200, Heinrich Schuchardt wrote:
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.
Not quite sure I agree with that.
It certainly means it is not impossible for an EFI app to update firmware components. However not having partitioned block IO protocols sounds like the updater would need to include additional GPT parsing code (although on platforms where the offsets are fixed perhaps the offsets could be burned in instead).
I don't have any strong feelings about that bit being set or not. I meant my comment as a question.
In U-Boot there is currently no support for bit 1 suppressing the IO_BLOCK_PROTOCOL.
So this leads to the next question. Shall EBBR require support for bit 1, 'No Block IO Protocol' of GPT partitions? If yes, we should write it into the EBBR.
I think that is unnecessary at this point, unless we start having problems. The primary purpose of this text is to signal to the OS "hands off" so that an installer doesn't blow away firmware. It doesn't say anything about how the firmware protects itself, and any platform that stores firmware within the normal eMMC storage region cannot be made safe against an erase attack.
g.
Best regards
Heinrich
Daniel.
+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.
On Wed, 2 Sep 2020 at 15:26, Heinrich Schuchardt xypron.glpk@gmx.de wrote:
On 02.09.20 12:11, Daniel Thompson wrote:
On Tue, Sep 01, 2020 at 04:53:49PM +0200, Heinrich Schuchardt wrote:
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.
Not quite sure I agree with that.
It certainly means it is not impossible for an EFI app to update firmware components. However not having partitioned block IO protocols sounds like the updater would need to include additional GPT parsing code (although on platforms where the offsets are fixed perhaps the offsets could be burned in instead).
I don't have any strong feelings about that bit being set or not. I meant my comment as a question.
In U-Boot there is currently no support for bit 1 suppressing the IO_BLOCK_PROTOCOL.
So this leads to the next question. Shall EBBR require support for bit 1, 'No Block IO Protocol' of GPT partitions? If yes, we should write it into the EBBR.
Given that the purpose appears to be to allow a single storage device to host both system firmware and OS components as well as user data, using the 'no block i/o' protocol seems appropriate. Even though we're treading on PI spec territory here, it is common for EDK2 based UEFI implementations to implement the firmware volume block protocol (FVB) for UEFI firmware images (which themselves typically consist of 50+ individual PE/COFF executables which are hosted using the FVB filesystem abstraction)
In other words, it makes sense for GPT partitions to exist that are not intended to be exposed as ordinary file systems, which is what the block I/O protocol implies (as this is what filesystem drivers bind to)
On 02/09/2020 13:41, Ard Biesheuvel wrote:
On Wed, 2 Sep 2020 at 15:26, Heinrich Schuchardt xypron.glpk@gmx.de wrote:
On 02.09.20 12:11, Daniel Thompson wrote:
On Tue, Sep 01, 2020 at 04:53:49PM +0200, Heinrich Schuchardt wrote:
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.
Not quite sure I agree with that.
It certainly means it is not impossible for an EFI app to update firmware components. However not having partitioned block IO protocols sounds like the updater would need to include additional GPT parsing code (although on platforms where the offsets are fixed perhaps the offsets could be burned in instead).
I don't have any strong feelings about that bit being set or not. I meant my comment as a question.
In U-Boot there is currently no support for bit 1 suppressing the IO_BLOCK_PROTOCOL.
So this leads to the next question. Shall EBBR require support for bit 1, 'No Block IO Protocol' of GPT partitions? If yes, we should write it into the EBBR.
Given that the purpose appears to be to allow a single storage device to host both system firmware and OS components as well as user data, using the 'no block i/o' protocol seems appropriate. Even though we're treading on PI spec territory here, it is common for EDK2 based UEFI implementations to implement the firmware volume block protocol (FVB) for UEFI firmware images (which themselves typically consist of 50+ individual PE/COFF executables which are hosted using the FVB filesystem abstraction)
In other words, it makes sense for GPT partitions to exist that are not intended to be exposed as ordinary file systems, which is what the block I/O protocol implies (as this is what filesystem drivers bind to)
Chatter on this one has died down and I haven't heard any objections to the patch, only refinements. There are still some open questions, but I think they are better handled as follow-up patches rather than iterating on this one. I'm going to go ahead and merge the change.
g.
On Wed, Sep 02, 2020 at 02:26:26PM +0200, Heinrich Schuchardt wrote:
On 02.09.20 12:11, Daniel Thompson wrote:
On Tue, Sep 01, 2020 at 04:53:49PM +0200, Heinrich Schuchardt wrote:
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.
Not quite sure I agree with that.
It certainly means it is not impossible for an EFI app to update firmware components. However not having partitioned block IO protocols sounds like the updater would need to include additional GPT parsing code (although on platforms where the offsets are fixed perhaps the offsets could be burned in instead).
I don't have any strong feelings about that bit being set or not. I meant my comment as a question.
Fair enough. As you can infer I'm reluctant to mandate the bit, if only because the description associated with a RequiredPartition seems to fully describe the nature of the partition already. It's a weakly held view... but it is nevertheless held.
In U-Boot there is currently no support for bit 1 suppressing the IO_BLOCK_PROTOCOL.
So this leads to the next question. Shall EBBR require support for bit 1, 'No Block IO Protocol' of GPT partitions? If yes, we should write it into the EBBR.
I believe that technically this is already a requirement of EBBR. The language in the UEFI spec is unambiguous ("No Block IO Protocol: If this bit is set, then firmware must not produce an EFI_BLOCK_IO_PROTOCOL device for this partition.") and GPT support is an explicit (albeit conditional) requirement in UEFI section 2.6.2 (which is required for EBBR compliance).
Daniel.
On Tue, Sep 01, 2020 at 11:59:09AM +0100, 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 +set. +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). +There are no requirements on the contents or layout of the firmware +protective partition.
+Placing GPT data structures away from firmware images can be accomplished by +adjusting the GUID Partition Entry array location +(adjusting the values of `PartitionEntryLBA` and `NumberOfPartitionEntries`, +and `SizeOfPartitionEntry`), +or by specifying the usable LBAs (Choosing `FirstUsableLBA`/`LastUsableLBA` +to not overlap the fixed firmware location). +See [UEFI]_ § 5.3.2.
+Given the choice, platforms should use protective partitions over +adjusting the placement of GPT data structures because protective partitions +provide explicit information about the protected region. .. _section-mbr-parts: MBR partitioning ^^^^^^^^^^^^^^^^ -Protective partitions should have a partition type of 0xF8 unless some +If firmware is at a fixed location entirely within the first 1MiB of +storage (<= LBA2047) then no protective partitions are required. +If firmware resides in a fixed location outside the first 1MiB, +then a protective partition must be used to cover the firmware LBAs. +Protective partitions should have a partition type of 0xF8 unless an immutable feature of the platform makes this impossible. +OS partitioning tools must not create partitions in the first 1MiB +of the storage device, and must not remove protective partitions.
What is this last paragraph for? It duplicates (and could even be read as contradicting) the earlier paragraph commencing "Automatic partitioning tools (e.g. an OS installer) must not delete..." which applies to both GPT and MBR systems.
Daniel.
On 01/09/2020 15:54, Daniel Thompson wrote:
On Tue, Sep 01, 2020 at 11:59:09AM +0100, 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.
[...]
@@ -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.
[...]
MBR partitioning ^^^^^^^^^^^^^^^^ -Protective partitions should have a partition type of 0xF8 unless some +If firmware is at a fixed location entirely within the first 1MiB of +storage (<= LBA2047) then no protective partitions are required. +If firmware resides in a fixed location outside the first 1MiB, +then a protective partition must be used to cover the firmware LBAs. +Protective partitions should have a partition type of 0xF8 unless an immutable feature of the platform makes this impossible. +OS partitioning tools must not create partitions in the first 1MiB +of the storage device, and must not remove protective partitions.
What is this last paragraph for? It duplicates (and could even be read as contradicting) the earlier paragraph commencing "Automatic partitioning tools (e.g. an OS installer) must not delete..." which applies to both GPT and MBR systems.
The other paragraph states that protective partitions (maybe they should be called 'firmware partitions'?) must not be moved or removed. This paragraph also adds the requirements to stay out of the first 1MB of storage because we're not requiring firmware partition entries for the first 1MB. Partition entries are precious in an MBR, so don't want to consume one entry to protect a region that the OS isn't supposed to use anyway.
What's the contradictory bit? Would there be a better way for me to phrase the requirement?
g.
On Wed, Sep 02, 2020 at 01:49:40PM +0100, Grant Likely wrote:
On 01/09/2020 15:54, Daniel Thompson wrote:
On Tue, Sep 01, 2020 at 11:59:09AM +0100, 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.
[...]
@@ -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.
[...]
MBR partitioning ^^^^^^^^^^^^^^^^ -Protective partitions should have a partition type of 0xF8 unless some +If firmware is at a fixed location entirely within the first 1MiB of +storage (<= LBA2047) then no protective partitions are required. +If firmware resides in a fixed location outside the first 1MiB, +then a protective partition must be used to cover the firmware LBAs. +Protective partitions should have a partition type of 0xF8 unless an immutable feature of the platform makes this impossible. +OS partitioning tools must not create partitions in the first 1MiB +of the storage device, and must not remove protective partitions.
What is this last paragraph for? It duplicates (and could even be read as contradicting) the earlier paragraph commencing "Automatic partitioning tools (e.g. an OS installer) must not delete..." which applies to both GPT and MBR systems.
The other paragraph states that protective partitions (maybe they should be called 'firmware partitions'?) must not be moved or removed.
Perhaps we should have independent text in GPT and MBR sub-sections. Then we can use obvious language ("Required Partitions" for GPT, and "Partition type 0xF8" for MBR).
This paragraph also adds the requirements to stay out of the first 1MB of storage because we're not requiring firmware partition entries for the first 1MB. Partition entries are precious in an MBR, so don't want to consume one entry to protect a region that the OS isn't supposed to use anyway.
Thanks. I hadn't spotted that bit of text moving out of its original position.
What's the contradictory bit? Would there be a better way for me to phrase the requirement?
Only that the language used above discusses strong restrictions on automatic partitioning tools (never modify a recognisable protective partition) and much weaker ones on manual partitioning tools (an informed user remains sovereign).
Here we talk about "OS partitioning tools" which can be read as covering both cases.
Daniel.
boot-architecture@lists.linaro.org
-
Ard Biesheuvel -
Daniel Thompson -
Grant Likely -
Heinrich Schuchardt