On 5/20/20 7:49 PM, François Ozog wrote:

On Wed, 20 May 2020 at 19:30, Daniel Thompson <daniel.thompson@linaro.org mailto:daniel.thompson@linaro.org> wrote:

On Wed, May 20, 2020 at 07:00:53PM +0200, François Ozog wrote:
> On Wed, 20 May 2020 at 18:39, Daniel Thompson
<daniel.thompson@linaro.org <mailto:daniel.thompson@linaro.org>>
> 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?
> >
> > I would say it is not EBBR compliant because it does not follow
EFI spec
> and we mandate it in EBBR.

Sure, if there is language in the EFI spec that prohibits this then the
answer is a no brainer.

Assuming you've found such language could you quote your references? ;-)

Oups! I thought of GPT Header being at 18002..... as you push the firstUsableLBA... it seems to be valid in that EFI compliant and hence EBBR compliant ;-)

That said to get the GPT Partition move, the spec patch to table 20 is not impressive: image.png

• set to 0x000001 (ie...

• the LBA to the GPT partition header

The position of the GPT *HEADER* in Daniel's example is LBA 1 and should not be changed to stay UEFI compliant.

Daniel moved the first GPT *TABLE* whose position is defined in the GPT header and this is UEFI compliant.

Best regards

Heinrich

Daniel.


> Is the use case "valid"? I think it is valid because when you deal
with
> immutable BootROM you don't want complex code, GPT may evolve so
that you
> would have to evolve the BootROM...
> If we conclude this is a valid use case (and not creating ugly
legacy to
> deal with in the future), we need a clean reservation in EFI so
that GPT
> can start at an arbitrary LBA as 18002.
> enhancing the protective MBR semantics does not seem too complex to
> achieve.
> Can we list SoCs that have similar characteristic?
>
> >
> > Daniel.
> >
> >
> > PS 18002 is arbitrary but I think the example is sufficient in this
> >    form and it was easier to diagram with a concrete number.
> >
>
>
> --
> François-Frédéric Ozog | *Director Linaro Edge & Fog Computing Group*
> T: +33.67221.6485
> francois.ozog@linaro.org <mailto:francois.ozog@linaro.org> |
Skype: ffozog

--

François-Frédéric Ozog | /Director Linaro Edge & Fog Computing Group/ T: +33.67221.6485 francois.ozog@linaro.org mailto:francois.ozog@linaro.org | Skype: ffozog