On Wed, 3 Feb 2021 at 15:04, Grant Likely <grant.lik...@arm.com> wrote:
> > > On 02/02/2021 16:46, Peter Robinson wrote: > >>>>> * - EFI_PXE_BASE_CODE_PROTOCOL > >>>>> - Booting via the Preboot Execution Environment (PXE) is > insecure. > >>>>> Loading via PXE is typically executed before launching the > first > >>>>> UEFI application. > >>>> > >>>> I don't think PXE should be a requirement, as Heinrich mentions it's > >>>> insecure. We should be requiring a secure protocol for a new spec, not > >>>> an old one that's being EOLed. I believe vendors are moving to remove > >>>> it in favour of HTTPS boot which also has the advantage it's more > >>>> flexible, and it much better places for IoT/Edge deployments which use > >>>> CDNs and the life extensively and it will generally work with > >>>> firewalls etc. If we're going to require something for network > >>>> installs, if the device has a capable network interface, it should be > >>>> HTTPS Boot. > >>>> > >>>> Peter > >>> > >>> Unfortunately we've got a functionality gap. U-Boot doesn't yet support > >>> TCP, HTTP, or TLS. All that functionality needs to be written or ported > >>> from somewhere. > >>> > >>> I would really like to require a secure network boot mechanism, but I > >>> think it needs to be left out until U-Boot can do TCP and TLS. > >> > >> You can use iPXE as U-Boot payload which offers HTTPS and iSCSI. Isn't > >> that enough? > > > > iPXE is an implementation not the standard. I think EBBR the standard > > should require HTTPS boot, now if U-Boot chooses to implement that > > part of the standard using an iPXE UEFI binary to implement HTTPS boot > > that's an optoin. > > > >> TLS is quite complicated. GNU TLS has > 430,000 lines of code (without > >> comments). Looking at the number of CVEs in OpenSSL and GnuTLS I do not > >> believe that the U-Boot community will be able to produce and maintain a > >> secure implementation. > > > > 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. > g. > _______________________________________________ > boot-architecture mailing list > boot-architecture@lists.linaro.org > https://lists.linaro.org/mailman/listinfo/boot-architecture > -- François-Frédéric Ozog | *Director Linaro Edge & Fog Computing Group* T: +33.67221.6485 francois.o...@linaro.org | Skype: ffozog _______________________________________________ boot-architecture mailing list boot-architecture@lists.linaro.org https://lists.linaro.org/mailman/listinfo/boot-architecture
