Just a general note on this entire thread; if there are specific things you want to clarify or add to EBBR, it would be helpful to add them as issues in GitHub here:
https://github.com/ARM-software/ebbr/issues
g.
On 10/03/2020 20:14, Heinrich Schuchardt wrote:
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.
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?
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?
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.
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?
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.
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.
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)
Watchdogs are available both in EDK II and U-Boot.
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
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.