On Wed, 3 Feb 2021 at 15:04, Grant Likely <[email protected]> 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. >
+1 _______________________________________________ boot-architecture mailing list [email protected] https://lists.linaro.org/mailman/listinfo/boot-architecture
