On 20/05/2020 18:40, Heinrich Schuchardt wrote:
On 20.05.20 18:39, Daniel Thompson wrote:
On Tue, May 19, 2020 at 03:29:01PM +0100, Grant Likely wrote:
On 11/03/2020 16:42, Daniel Thompson wrote:
On Wed, Mar 11, 2020 at 01:42:36PM +0100, Francois Ozog wrote:
We have the following cases:
- FW compatible with GPT (I mean firmware can be searched based on
GUID partition)
Ok
- FW that uses offsets and can be positioned at LBA >= 33
Ok
Need to define a protective partition >>
- FW that uses offsets and can be positioned such that space between LBA-2
and LBA-33 is used.
Ok in theory as the header states where the partition entries location is
specified in a GPT_HEADER "Starting LBA of array of partition entries".
Linux kernel properly loads the partition entries if we push them after
16MB.
read_lba <https://elixir.bootlin.com/linux/latest/ident/read_lba>(state,
le64_to_cpu
<https://elixir.bootlin.com/linux/latest/ident/le64_to_cpu>(gpt->partition_entry_lba)
But I bet 2 is hardcoded in many tools...
Agree... but that's "just bugs" and I suspect we could get >90% test
coverage for Linux systems just by checking util-linux (and the kernel
itself). Maybe for extra style points also check on of the BSDs.
It is worth stepping back from the details to take a look at the intent. The
purpose of this entire section of EBBR is to describe how firmware and the
OS can co-exist on the same media device. In broad strokes it means if
firmware is stored on the block device, then the OS must constrain how it
uses the device.
On platforms with separate firmware storage (e.g., SPI flash or UFS boot
partitions) this isn't an issue. The OS can blow away everything on the disk
and recreate it.
But when it is an issue, the rules need to lay down what regions (offsets,
partitions, or file paths) firmware is allowed to own and what the OS is and
is not allowed to do. e.g., the OS is allowed to erase and recreate the OS
partitions, but it is not allowed to write a blank GPT or erase the system
partition.
I think the EBBR spec should focus on defining exactly what restrictions on
the OS are, and how the restrictions are communicated. Then OS vendors have
a fighting chance of supporting the restricted platforms well.
Ultimately though this is a guide and the OS could choose to ignore the
restrictions... in which case it gets to keep the unbootable brick when it
does. :-)
Agree with all above.
Also I think we can turn at least part of the original issue into a
concrete question.
We have a SOC with some magic values hard coded into its boot ROM. The
System Firmware author wants to ship it with the following GPT on the
shared eMMC.
LBA0 Protective MBR
LBA1 Primary GPT header
LBA2..18001 Reserved, mixture of dead space and a system firmware
loaded by Boot rom
LBA18002 Start of partition arrray (Entry 1, 2, 3, 4)
...
LBA18033 End of partition arrray
LBA18034 Start of allocatable partition space
LBA-33..-1 End of disk is labelled as normal
(or in a shorter GPT jargon form, a system where PartitionEntryLBA is
18002).
Is such a system EBBR compliant? If yes, should it be?
Where UEFI wants to restrict possible GPT header values it is mentioned
explicitly in the spec, e.g. SizeOfPartitionEntry has to be a power of
two and be at least 128. The UEFI 2.8 spec does not prescribe values for
PartitionEntryLBA and NumberOfPartitionEntries.
Many tools default to PartitionEntryLBA = 2, SizeOfPartitionEntry = 128
and NumberOfPartitionEntries = 128 which is a sensible choice in many cases.
If a tool or operating system cannot work with PartitionEntryLBA > 2,
SizeOfPartitionEntry > 128 or NumberOfPartitionEntries != 128, it is
simply not UEFI compliant and should be fixed.
So you should be fine as long as the first GPT table resides in the
first 2 TiB assuming an LBA size of 512 bytes.
The requirement to be written into the EBBR is that a firmware MUST be
able to deal with GPTs with PartitionEntryLBA > 2, SizeOfPartitionEntry
128, and NumberOfPartitionEntries != 128 to be EBBR compliant.
U-Boot can use such GPTs. It does not yet support creating them via the
'gpt write' command. - But the creation of partition tables should not
be in the scope of the EBBR.
That all sounds reasonable. Let me try drafting an update to the spec...
How does this look?
g.
---
From 4593cf03fd652448de0e3fe912c7ae9467850e78 Mon Sep 17 00:00:00 2001
From: Grant Likely <[email protected]>
Date: Mon, 25 May 2020 20:52:31 +0100
Subject: [PATCH] Attempt to refine firmware shared storage requirements.
Signed-off-by: Grant Likely <[email protected]>
---
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
--
2.20.1
_______________________________________________
boot-architecture mailing list
[email protected]
https://lists.linaro.org/mailman/listinfo/boot-architecture
