On 3/11/20 3:20 PM, Francois Ozog wrote:

On Wed, 11 Mar 2020 at 13:42, Francois Ozog <francois.ozog@linaro.org mailto:francois.ozog@linaro.org> wrote:

On Wed, 11 Mar 2020 at 12:45, Daniel Thompson
<daniel.thompson@linaro.org <mailto:daniel.thompson@linaro.org>> wrote:

    On Wed, Mar 11, 2020 at 11:20:17AM +0100, Francois Ozog wrote:
     > On Wed, 11 Mar 2020 at 07:48, Heinrich Schuchardt
    <xypron.glpk@gmx.de <mailto:xypron.glpk@gmx.de>> 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
     > > >> <daniel.thompson@linaro.org
    <mailto:daniel.thompson@linaro.org>> 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
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