On Tue, 10 Mar 2020 at 17:18, Grant Likely grant.likely@arm.com wrote:
Hi Francois,
This is really good. EBBR regular meetings have been on hold while the U-Boot work progressed, but it is probably about time to start them up again. This is list is a great first agenda item.
Comments below...
On 10/03/2020 16:02, 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.
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.
I would like people to think about this one before getting into the meeting because without this we can't discuss most of the rest.
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
Have you got a comparison of the protocols needed in each scenario? It has been pretty clear that both models are important, is there a large delta from one to the other, and it is an extra burden to support all of them in U-Boot (e.g., once implemented in mainline, most of the protocols should work for all).
Supporting industrial players require EFI_LOAD_FILE2_PROTOCOL in addition to the distro subset. Pushed upstream. Ilias may comment about merging
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.
Fair point. Do you have a suggesting on how to proceed here?
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.
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.
The 1MB was to deal with limitations in the boot rom. If the boot rom needs extra space, would it not be better to have an initial loader that understands partitioning in the 1st 1MB and load the remaining images from a real partition?
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.
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)?
I would expect so, if they aren't already doing that.
Will need to create initiatives for that.
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 ?
This is definitely a big gap. UEFI in general doesn't say much on handling A/B updates.
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...)
All above look reasonable and need discussion on whether to adopt and how to put it into the document.
I'll schedule the next meeting and send it out to the list.
g.
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.