On Wed, Mar 11, 2020 at 01:42:36PM +0100, Francois Ozog wrote:
> On Wed, 11 Mar 2020 at 12:45, Daniel Thompson <daniel.thompson(a)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(a)gmx.de>
> > wrote:
> > > > On 3/11/20 12:04 AM, Heinrich Schuchardt wrote:
> > > > 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...
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.
> - 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
In the current spec this case isn't materially different to firmware
whose boot ROM parses the MBR to load extra code (which wasn't listed
above). In both cases the system would be expected to adopt MBR and
create protective partitions for the firmware (and accept that the
protective partition is vulnerable to damage by auto-partitioning
installers).
Having said is this really relevant for MacchiatoBin? Why put EBBR
firmware onto shared media? I thought MacchiatoBin could boot from the
4MB SPI NOR.
Daniel.
Hi,
Following implementation (or work towards) of EBBR 1.0 + UEFI Secure
boot + UEFI update capsule we learnt a lot.
Here are some topics that may need some clarification on the EBBR
specs and It looks timely to start working on EBBR evolution.
0.1 - EBBR goal
May be a reassessment on the "for what" the specification is built.
Following all the discussions with prominent industry players, I start
to think that limiting the constraints to be EBBR compliant may become
counter productive. There will be both EBBR non compliant and EBBR
compliant systems. This is inevitable. But EBBR exist for a number of
use cases in a number of markets. The value of EBBR is consistent
behavior across those.
Maximising number of EBBR compliant systems without stating use case
parameters ( "why" and "for what") may not be the best goal.
Out of things to be more explicit are supported secure boot flows
(with/without shim+grub or direct). Some vendors require shim+grub
while industry players want the exact opposite: nothing but UEFI. This
drivers a number of requirements in terms of UEFI protocols needed
0.2 - normative text
The normative section shall be stated clearly: is " 1.2. Guiding
Principles" normative?
IETF and ETSI have different language conventions to express
absolutely mandated and various levels of optionality. This spec may
be red by Telecom people or Linux people. Their interpretation may be
erroneous on words such as "shall" (ETSI "SHALL" = "IETF "MUST"). The
language need to be explicit.
I - protective offsets
EBBR 1.0 states in "4.1. Partitioning of Shared Storage" that
"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."
StandaloneMM is 2.5MB by itself with U-Boot being over 1MB without the
variable rework done and update capsules. 4MB seems the minimum. 8MB
to get margin and 16MB for A/B scheme.
EBBR same paragraph also states:
"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. Manual partitioning tools should
provide warnings when modifying protective partitions or creating
partitions within the first 1MiB."
is it expected that Linaro upstreams changes in installation tools,
partition tools to conform to this (with updated to be agreed
minimum)?
II - identifying partitions
Having two EFI partitions defined with EFI_GUID need a precise
behaviour defined: boot with first or boot with second.
Shall we have a EFI_GUID_ALT defined for A/B partition schemes?
If not, the BootXXX variables should be used as selector?
We lean towards BootXXX variables and not defining a new GUID. But
this would mean explicit behavior to be stated in case of lack of
BootXXX.
I think GPT volume mirroring should be used in conjunction with A/B:
A/B to recover version failures with current hardware, surrounding
software; mirroring to protect against storage failures.
Is there any recommendation on mirrored EFI volumes handling ?
III - 32 bits
are there any 32 bits specific considerations to be added?
IV - UEFI_RNG_PROTOCOL
Following my view in 0) I think this shall be made mandatory
Linaro has upstreamed this in U-Boot and started to implement
additional hardware drivers.
KASLR is thus functional in 64 bits and will be in 32bits.
V - UEFI SecureBoot
Following my view in 0) I think this shall be made mandatory
UEFI SecureBoot is not mentioned in section 2.6 so we need to clarify
what needs to be implemented.
In particular, we need to implement EFI_LOAD_FILE2_PROTOCOL for initrd
signature checking.
VI - UEFI update capsules
Following my view in 0) I think this shall be made mandatory
Section 2.6 of UEFI spec 2.7 mentions
At some point in time we will need to propose UEFI specification update for:
- anti-bricking anti rollback expected behavior
- abstract capsules for "start transaction", "commit", "rollback" when
we will be dealing with system wide transactional updates.
There is probably a lot to state here but I am just starting the discussion.
VII - UEFI watchdog
Following my view in 0) I think this shall be made mandatory
In addition to its definition, it should also integrate consistent
parameters to define total duration covered as well as number of
failed consecutive updates to be triggered as well as how it is
delivered (powercycle, NMI, secureIRQ...)
Cheers
--
François-Frédéric
On 3/11/20 3:20 PM, Francois Ozog wrote:
>
>
> On Wed, 11 Mar 2020 at 13:42, Francois Ozog <francois.ozog(a)linaro.org
> <mailto:francois.ozog@linaro.org>> wrote:
>
>
>
> On Wed, 11 Mar 2020 at 12:45, Daniel Thompson
> <daniel.thompson(a)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(a)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(a)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_L…>,
> &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(a)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(a)linaro.org <mailto:francois.ozog@linaro.org> | Skype: ffozog
>
>
Le mar. 10 mars 2020 à 18:46, Mark Brown <broonie(a)kernel.org> a écrit :
> On Tue, Mar 10, 2020 at 05:37:29PM +0000, Daniel Thompson wrote:
> > On Tue, Mar 10, 2020 at 05:35:40PM +0100, Francois Ozog wrote:
>
> > > Thanks Leif for the links. I tend to like the ETSI one because it is
> > > somewhat complete on necessary english grammar stuff.
> > > But I am flexible, important we state explicitly the reference
> > > document and we use the language constructs.
>
> > Does ETSI offer us "features" that are missing from RFC 2119.
>
> > Personally I would favour RFC 2119 simply because it is so much better
> > known than the ETSI drafting rules.
>
> > If you cite RFC 2119 and I don't have to go and read anything... and
> > even if I did it is super concise and quick to read.
>
> > Cite ETSI drafting rules, clause 3 and I have to put in a lot more
> > effort.
>
> The RFC 2119 usage of "MUST" is also a more standard English usage (in
> that people are more likely to be familiar with it) than the ETSI SHALL
> so there's a bit of a comprehensibility win.
RFC2119 sold on my side ;-)
>
> --
François-Frédéric Ozog | *Director Linaro Edge & Fog Computing Group*
T: +33.67221.6485
francois.ozog(a)linaro.org | Skype: ffozog
Well, if you think IIot and Edge, you have physical access and the system
is thus vulnerable....
https://www.sdxcentral.com/articles/news/intel-vulnerability-serious-but-un…
Cheers
FF
PS: Intel CSME is an auxiliary micro-controller much like the SCP but with
the capability to access the whole DRAM and having some TrustZone style
role.
--
François-Frédéric Ozog | *Director Linaro Edge & Fog Computing Group*
T: +33.67221.6485
francois.ozog(a)linaro.org | Skype: ffozog
