On 3/11/20 3:20 PM, Francois Ozog wrote:
On Wed, 11 Mar 2020 at 13:42, Francois Ozog <[email protected]
<mailto:[email protected]>> wrote:
On Wed, 11 Mar 2020 at 12:45, Daniel Thompson
<[email protected] <mailto:[email protected]>> wrote:
On Wed, Mar 11, 2020 at 11:20:17AM +0100, Francois Ozog wrote:
> On Wed, 11 Mar 2020 at 07:48, Heinrich Schuchardt
<[email protected] <mailto:[email protected]>> wrote:
> > On 3/11/20 12:04 AM, Heinrich Schuchardt wrote:
> > > On 3/10/20 7:37 PM, Francois Ozog wrote:
> > >> Le mar. 10 mars 2020 à 18:37, Daniel Thompson
> > >> <[email protected]
<mailto:[email protected]>> a écrit :
> > >>> On Tue, Mar 10, 2020 at 05:35:40PM +0100, Francois Ozog
wrote:
> > >>>> This is driven by the BL2 which is platform specific
and I am not sure
> > >>>> we can have any influence.
> > >>>> The flashimage.bin in a number of system consists of a
(blob) FIP that
> > >>>> has BL2, SCP stuff, BL31, BL32, BL33.
> > >>>> Ilias upstream U-Boot patches to change from "ADR" to
"ADRL" because
> > >>>> the code grew too much.
> > >>>
> > >>> I'm not quite sure I understand the concern here.
> > >>>
> > >>> Are you still working on systems where the boot ROM
mandates using MBR
> > >>> partitioning and attempting to put secure boot on it?
If so perhaps we
> > >>> could simply discontinue MBR support for systems with
secure boot!
> > >>>
> > >>
> > >> Well..... we want Products on the market to benefit from
EBBR compliance
> > >> rather than two years from now. So MBR is inevitable.
And is not that a
> > >> pain ;-) Of course its not as clean as we would like but
“sales first”!
> > >
> > > A typical problem is that a SoC has an entry address
within the first 17
> > > KiB, e.g. the Allwinner CPUs want a firmware entry point
at 0x2000. If I
> > > correctly understand the UEFI standard, one might use
PartitionEntryLBA
> > > to place the GPT Partition Entry Array behind the
firmware in this case.
> > >
> >
> > In the expert mode of gdisk there is command 'j' for moving
the GPT
> > Partition Entry Array to an arbitrary sector. This will
protect the area
> > between the GPT header and the GPT Partition Entry Array
from being used
> > for a partition. The same can be done with parameter -j of
sgdisk.
> >
> > Furthermore gdisk supports creating a hybrid MBR. This
allow to have
> > GUID partition table and a MBR partion table at the same
time where the
> > MBR partition table mirrors up to three GPT partitions and
the fourth
> > MBR partition is used to protect the GUID partition table.
> >
> > So requiring GPT and having boards only supporting booting
from an MBR
> > partition (like the Raspberry) seems not to be exclusive.
> >
>
> That sounds like a great solution!
The last time we discussed this there was *very* strong opposition
during meetings to hybrid partitioning and IIRC language was
added to
the spec to prohibit it.
Hybrid partitioning is a problem because it imposes to difficult
to meet
constraints on partitioning tools provided by the operating system.
In other words if we permit hybrid partitioning in order that
boot code
can find the firmware then the operating system would inherit a
duty to
not to screw up the firmware loading when it modifies the partition
tables. It is hard to express how the OS should go about that.
Hence the current approach where we accept that MBR partitioning
offers an inferior feature set to GPT.
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...
If I had done my homework properly, I would have seen that
U-Boot CONFIG_EFI_PARTITION_ENTRIES_OFF is just configuring that...
CONFIG_EFI_PARTITION_ENTRIES_OFF is only relevant if you use U-Boot to
create a GUID partition table. When reading a GPT U-Boot correctly
considers the current value of PartitionEntryLBA.
Best regards
Heinrich
So there is some experience in playing with that.... I'd be happy to
read ;-)
- FW that supposes LBA-1 (macchiatobin the firmware blob that
contain TF-A must be here)
In theory OK as Linux will detect bad signature and use the
alternate GPT
good_pgpt = is_gpt_valid
<https://elixir.bootlin.com/linux/latest/ident/is_gpt_valid>(state,
GPT_PRIMARY_PARTITION_TABLE_LBA
<https://elixir.bootlin.com/linux/latest/ident/GPT_PRIMARY_PARTITION_TABLE_LBA>,
&pgpt, &pptes);
if (good_pgpt)
good_agpt = is_gpt_valid
<https://elixir.bootlin.com/linux/latest/ident/is_gpt_valid>(state,
le64_to_cpu
<https://elixir.bootlin.com/linux/latest/ident/le64_to_cpu>(pgpt->alternate_lba),
&agpt, &aptes);
if (!good_agpt && force_gpt
<https://elixir.bootlin.com/linux/latest/ident/force_gpt>)
good_agpt = is_gpt_valid
<https://elixir.bootlin.com/linux/latest/ident/is_gpt_valid>(state, lastlba,
&agpt, &aptes);
We loose the protective nature of GPT but it sounds like it will be
working.
That said, we could enhance the EFI specification so that:
- we have a firmware protective partition
- the start LBA of the "GPT protective partition (0xEE)" is used to
define the GPT header placement instead of 1.
image.png
Daniel.
--
François-Frédéric Ozog | /Director Linaro Edge & Fog Computing Group/
T: +33.67221.6485
[email protected] <mailto:[email protected]>
| Skype: ffozog
--
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
