On Tue, 10 Mar 2020 at 17:18, Grant Likely <[email protected]> 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. -- François-Frédéric Ozog | Director Linaro Edge & Fog Computing Group T: +33.67221.6485 [email protected] | Skype: ffozog _______________________________________________ boot-architecture mailing list [email protected] https://lists.linaro.org/mailman/listinfo/boot-architecture
