On 3/10/20 9:45 PM, Francois Ozog wrote:
Le mar. 10 mars 2020 à 21:15, Heinrich Schuchardt <[email protected]> a
écrit :
On 3/10/20 5:02 PM, Francois Ozog wrote:
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.
EBBR 1.0 is quite vague about this point.
Implementing the requirements of version 1.0 was enough to allow systems
to be booted in a common way. Secure boot is not supported by what is
required.
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
Shim and GRUB are optional tools which operating systems like BSD, Linux
or Windows do not need for booting. I think the EBBR should be operating
system agnostic.
Absolutely.
This does not deny the usefulness of some of these tools. My personal
favorite is booting via U-Boot -> iPXE -> GRUB -> Linux from an iSCSI
drive ;)
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.
A reference to RFC 2119 should be added to the EBBR.
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)?
Obviously the minimum required space depends on the firmware and the
maximum depends on the hardware (some devices like routers simply only
have 16MiB flash for firmware and operating system in total).
Shouldn't the firmware have a way to tell the OS how much space it wants
instead of prescribing a fixed quantity?
probably a good idea. It’s never good to take margin of margin (16MB) to
end up being cornered a few years later.
II - identifying partitions
Having two EFI partitions defined with EFI_GUID need a precise
behaviour defined: boot with first or boot with second.
This is only relevant when relying on the \EFI\BOOT directory. If
Bootxxxx variables are defined, these specify the relevant partition.
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 ?
Isn't the availability of Bootxxxx variables enough?
I think so. There is a forming thinking that when we commit a partition for
successful update the other is “synchronized”.
That said mirroring in UEFI is a block mirroring between two physical disk
(is it software RAID1?) so both A/B and RAID1 can be combined . But I don’t
know what shall be uboot behavior here.
III - 32 bits
are there any 32 bits specific considerations to be added?
The only thing 32bit specific that comes to my mind is clearing
architecture specific caches as defined in the UEFI spec.
For RISC-V there is a development ongoing for communicating the boot
hart ID form the firmware to the operating system.
Just thought of: we also bumped into lpae support problem. We ended up
experimenting a “standard” variable set by the platform so that
distro_bootcmd just use the right image. May be something to clarify at
least at Uboot but I wonder how to properly phrase a requirement around the
topic.
U-Boot's current distro boot command is not meant to make an image choice.
In U-Boot we have CONFIG_ARMV7_LPAE. That value could be copied to an
environment variable for usage in a script.
An installer could use the device tree to determine the CPU's compatible
string to decide which image is supported, e.g.
compatible = "arm,arm1176jzf-s" - no LPAE support
compatible = "arm,cortex-a7" - LPAE support
As we are talking about device-tree. The configuration table GUID for
the device-tree should be put into either the EBBR or the UEFI spec.
IV - UEFI_RNG_PROTOCOL
Following my view in 0) I think this shall be made mandatory
EBBR v1.0 has as design goal: 'Design for common embedded target'.
"Generally anything that has a near near-upstream U-Boot implementation
should be able to implement the EBBR requirements."
Not all common SoCs have a hardware RNG, e.g. Allwinner (cf.
https://linux-sunxi.org/Cryptographic_Hardware_Accelerators).
I would not assume that enough entropy can be gathered by the firmware
on a standalone device without a hardware RNG to drive the
EFI_RNG_PROTOCOL.
A high entropy RNG is needed for secure network communication. It can be
used for randomizing kernel memory layout. But why should it be made
mandatory for devices that do not need network communication before the
operating system is started?
Good point. I am too focused on connected edge devices. The good thing is
the lack of support does not influence the distro content. So probably not
a candidate for being in EBBR.
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.
The protocol (without checking) is implemented in U-Boot 2020.04. But we
should also consider the device-tree and the command line.
VI - UEFI update capsules
Following my view in 0) I think this shall be made mandatory
The UEFI specification provides multiple possibilities to update:
UpdateCapsule() runtime service - This runtime service is quite hard to
implement if there is no storage that is off limits for the operating
system.
We do not favor that. There is no way to trust code that could have been
compromised in memory. It would mean doing an update of uboot from OPTEE so
it does not look good as only uboot of a platform knows how to update
itself.
Directory \EFI\UpdateCapsule - A file placed on this directory on the
boot device is considered a capsule. This is much easier to implement.
Essentially you could also use BootNext to run any binary for updating.
I suggest to go for the directory method of capsule updating.
That’s the goal for the moment. Yet a whole bunch new to be clarified. We
are working on a document to be commented.
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
I could imagine the following scenarios where a watchdog is helpful:
* A/B scenario: this would require a variable to be updated that
switches between A and B
* booting via network (retry)
Yes: would you consider HTTP booting as an option (not in EBBR though but
in Uboot)?
U-Boot does not have a TCP stack. But you can load iPXE to boot via HTTP(S).
Watchdogs are available both in EDK II and U-Boot.
Problem is that a leading industrial OEM reported inconsistency in
implementation and too small (5 minutes) delay . The exact problem yet need
to be fully described by the vendor so that it be solved.
Five minutes is a default. SetWatchdogTimer() can be used to modify the
interval. A timer event can be used to reset the watchdog timer
periodically by calling SetWatchdogTimer().
I could imagine that flashing a new image might take more than five
minutes. So maybe you want to reset the watchdog timer whenever a block
has been written to flash.
In U-Boot we have two watchdogs. The hardware one is reset at boot time
whenever an event is handled (see efi_timer_check()). The UEFI one
starts with a five minute default but considers changes by
SetWatchdogTimer().
Best regards
Heinrich
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
_______________________________________________
boot-architecture mailing list
[email protected]
https://lists.linaro.org/mailman/listinfo/boot-architecture
