On Wed, Feb 03, 2021 at 04:01:27PM +0000, Grant Likely wrote: > On 03/02/2021 15:17, Ilias Apalodimas wrote: > > On Wed, Feb 03, 2021 at 03:53:09PM +0100, Fran�ois Ozog wrote: > > > > > > > > > > Sure, but we're not talking about U-Boot, we're talking about EBBR the > > > > > standard and U-Boot has a number of means of implementing HTTPS Boot, > > > > > but by hobbling the standard with deployment technologies of the last > > > > > century I think is a mistake. > > > > > > > > > > I have my opinions on whether implementing HTTP boot in U-Boot > > > > > directly or leaning on iPXE as the implementation but that is > > > > > irrelevant to what I think is right for EBBR as the standard. I think > > > > > we should be specifying HTTPS boot as a part of the spec, and having a > > > > > separate discussion of how that is supported in U-Boot. > > > > > > > > I agree here. EBBR should specify interfaces/specs without requiring > > > > iPXE, or any specific standard. HTTPS boot is clearly the right > > > > direction, but I'm wrestling with when/how it should be added. > > > > > > > > After our chat today, I'll propose that HTTPS boot be required by EBBR > > > > if network boot is supported. U-Boot on it's own won't meet that > > > > requirement, so for the time being U-Boot platforms won't be able to > > > > claim EBBR compliant network boot. > > > > > > > > Ilias and I discussed an approach where the HTTPs stack is in an EFI app > > > such as a standalone one or systemd-boot (this is a candidate because it > > > already has nice boot blessing capabilities that work in conjunction with > > > Linux systemd). iPXE has an implementation of the stack based on EFI > > > network protocol (raw packets), so the work shouldn't be that big. > > > > > > > I think what Grant proposes still stands (and for the record I agree with > > Peter). > > > > Having iPXE (while veryfying it before launching) is an alternative we can > > implement relatively fast. > > This raises a question here though. U-Boot won't be EBBR compliant, since it > > would need an external application for the HTTP boot. What about boards > > that > > offer the firmware as a 'bundle' though? If they got a firmware + EFI app > > that > > will be able to do HTTP boot they would be able to get a SystemReady-IR > > certification? > > Shouldn't be a problem. The platform is still EBBR compliant as long as it > doesn't claim to support network boot because network booting is optional. > > Also, if HTTPS boot is implemented using an external EFI binary that is > packaged with U-Boot, then it still meets the network boot requirement. EBBR > doesn't care how the feature is implemented.
... although we do care that a well behaved OS does not accidentally delete features. In practice I think there is already enough language in the spec to cover this since the app is in the ESP /FIRMWARE directory (or in a private filesystem on a Required Partition) then a well behaved EBBR OS will leave it alone. However a pre-certification checkbox does need to be slightly more sophisticated than "feature works when board is shipped"! Daniel. _______________________________________________ boot-architecture mailing list [email protected] https://lists.linaro.org/mailman/listinfo/boot-architecture
