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
Hi,
I am taking over Steve to drive Device Tree Evolution project except the
System Device Tree which will continue to evolve under the leadership of
Nathalie and Stefano.
To discuss:
- lifecycle (how TFA, OP-TEE, U-Boot and Operating Systems deal with DT and
pass information between them)
- overlays
- unified repo
- summary of System DT activities
I'd like to set up a weekly call starting next week. Please state the best
timeslot in this poll: https://www.doodle.com/poll/k57zhwa4q9caivgy
(the poll proposes the timeslot to be repeated).
By next week, Joakim, Ilias and myself will have prepared some content to
launch/continue debate.
Cordially,
François-Frédéric
--
François-Frédéric Ozog | *Director Linaro Edge & Fog Computing Group*
T: +33.67221.6485
francois.ozog(a)linaro.org | Skype: ffozog
+boot architecture
Le sam. 25 avr. 2020 à 19:26, François Ozog <francois.ozog(a)linaro.org> a
écrit :
> Hi
>
> I would like to start the discussion on DTE-8 as LEDGE is going to need
> results soon. I'd like to keep it high level, general principles, not too
> precise on implementation details. Let's take overlays and other
> complications out of the discussion until we share a vision for the basics.
>
> When we have concluded this discussion cycle we will need to address:
> - DTE-8 DeviceTree lifecycle: BL32 (BL32 may mask some devices until
> given credentials...)
> - DTE-8 DeviceTree lifecycle: overlays
> - DTE-8 DeviceTree lifecycle: tooling
> - DTE-8 DeviceTree lifecycle: chain of trust
>
> Is the following correct?
> Is it complete on the target reduced scope?
> Is the discussion series/roadmap complete, is the order right ?
>
> Cordially,
>
> François-Frédéric
>
>
> I - Definitions
>
> Let's consider there are four trees used by the following entities:
> - TFA which spans BL1, BL2, BL31 has a tree <TFA> which originates from
> tfa.dtb
> - BL32 (let's assume OP-TEE) has a tree <BL32> which originates from
> bl32.dtb
> - BL33 (let's assume U-Boot) has a tree <BL33> which originates from
> bl33.dtb
> - THING, the "thing" that is booted by BL33, has a tree <THING> which
> originates from thing.dtb and manipulations from BL33.
>
> The THING can be a Linux kernel, a bsd kernel, grub, shim<arch>.efi,
> efibootguard.efi, Xen, Hafnium or many other possibilities.
> BL33 is assumed to be U-Boot but it can be EDK2, Linux Kernel, Hafnium,
> Xen or other thing.
>
> A tree is not dtb. A tree is the result of loading a DTB with or without
> manipulations.
>
> II - Build time assumptions
>
> It is assumed that TFA, BL32 and BL33 are board specific while THINGS is
> board agnostic.
>
> As a result of this architectural decision:
> - tfa.dtb, bl32.dtb and bl33.dtb can be built by the build process of the
> respective entity TFA, BL32, BL33.
> - thing.dtb is purely describing hardware and has no "chosen" nodes for
> instance, it may contain architectural/platform/board specific
> "reserved-memory". In other words, nothing that can tie it to a particular
> "thing".
>
> All DTBs shall be derived from a single source repository.
>
> The bindings of a single piece of hardware, may differ depending on the
> entity that needs it (there are many ways to implement that aspect, let's
> not talk about implementation yet).
> For instance, a display panel for BL33 can be represented as a single
> small node while the same display panel can be controlled out of several
> large nodes by a downstream Operating System.
>
> III - Lifecycle
>
> Out of all possible transitions, let's consider BL31->BL33 and
> BL33->THING. Transitions are opportunities to pass DT information from one
> entity to the other that complements the static *.dtb . For instance,
> passing PSCI interface information, memory reservations, PCI IO ranges...
>
> III.1 BL31->BL33
>
> III.1.1 nature of manipulations
> typically, PSCI interface may be injected as well some memory
> reservations.
>
> III.1.2 manipulation operational considerations
> There are three possibilities for passing this information:
> - BL31 manipulates the BL33 tree to add/change nodes
> - BL33 asks BL31 to add/change nodes
> - BL31 passes an interim tree that BL33 will merge into his.
>
> Current wisdom is BL31 manipulates the BL33 tree.
>
> III.2 BL33->THING
>
> III.2.1 nature of manipulations
> * operational
> - board information (part numbers, serial numbers...)
> - memory layout (beyond the typical 4G)
> - IO specifics (PCIe...)
> - reserved areas for runtime services (UEFI for instance)
> - os.dtb
> * THING dependent elements
> - chosen for "command line" or other aspects
>
> III.2.2 manipulation operational considerations
> In the case of UEFI interface, os.dtb passed as DT artifact or a UEFI
> table shall be referring to the same tree (a single tree in memory, two
> access methods).
>
> BL33 will operate all necessary manipulations on os.dtb before passing it
> to the THING. The THING (grub, efiapp, kernel) can further operate
> manipulations, it is outside scope of the discussion.
>
>
>
> --
> François-Frédéric Ozog | *Director Linaro Edge & Fog Computing Group*
> T: +33.67221.6485
> francois.ozog(a)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 | Skype: ffozog
Hi,
I instrumented boot on my Ubuntu 18.04 server right after systemd startup
and caught an access to:
/sys/firmware/efi/efivars/LoaderDevicePartUUID-4a67b082-0a4c-41cf-b6c7-440b29bb8c4f
This led to:
https://systemd.io/DISCOVERABLE_PARTITIONS/
And then:
https://systemd.io/BOOT_LOADER_INTERFACE/https://systemd.io/AUTOMATIC_BOOT_ASSESSMENT/
My server is configured with Grub to boot (grub and kernel on a HD, root FS
of NVME as grub do not have nvme driver for my card) but the udev is still
checking those systemd-boot variables.
>From a boot loader perspective, we have the following EFI applications:
- Grub2
- EFIBootGuard (used by CIP)
- Systemd-boot (used by ?)
Regardless of the loader, I assume we need to ensure whatever option is
selected by solution builders, they can implement it with our U-Boot
reference implementation of UEFI.
The Systemd boot-bless seems of high interest for rolling back UEFI update
capsules of firmware...
I'd be happy to get some feed back on :
- the systemd-boot technology
- whether we need to implement the above specs in our UEFI implementation
- whether this has an influence on EBBR
Cheers
FF
PS: other references
https://manpages.debian.org/testing/systemd/systemd-boot.7.en.htmlhttps://manpages.debian.org/testing/systemd/systemd-bless-boot.service.8.en…http://man7.org/linux/man-pages/man1/bootctl.1.html
--
François-Frédéric Ozog | *Director Linaro Edge & Fog Computing Group*
T: +33.67221.6485
francois.ozog(a)linaro.org | Skype: ffozog
