On Mon, 25 May 2020 at 21:55, Grant Likely <[email protected]> wrote:
> > > 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. > For the boards I work on, fixed locations FIP with (TFA+DDR+SCP+U-Boot) are 1.5MB. Adding OP-TEE and StandaloneMM to get UEFI SecureBoot we are getting close to 4MB. If we add firmwareTPM and measuredBoot, I assume we will reach 4MB. So I wonder if the right value shouldn't be 32MiB (rationale is 4MB/Page rounding; future growth to 8MB; A/B versions:16MB; 2x margin: 32MiB). > + > .. _section-fw-partition-fs: > > Firmware Partition Filesystem > -- > 2.20.1 > > -- François-Frédéric Ozog | *Director Linaro Edge & Fog Computing Group* T: +33.67221.6485 [email protected] | Skype: ffozog _______________________________________________ boot-architecture mailing list [email protected] https://lists.linaro.org/mailman/listinfo/boot-architecture
