On 20/05/2020 18:00, François Ozog wrote:
On Wed, 20 May 2020 at 18:39, Daniel Thompson
<[email protected] <mailto:[email protected]>> 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.
Not quite that cut and dry. We have the ability to specify exceptions to
what UEFI specifies where it is warranted to do so.
In this particular example the GPT looks like it is entirely
spec-compliant, but if the OS recreates the GPT without accounting for
the firmware space then it results in a dead platform. Within spec, but
with behaviour an OS might not be prepared for. In this case EBBR should
specify how the OS knows not to mess with the GPT layout.
g.
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
[email protected] <mailto:[email protected]> | Skype: ffozog
_______________________________________________
boot-architecture mailing list
[email protected]
https://lists.linaro.org/mailman/listinfo/boot-architecture
