Re: [PATCH 0/7] efi: Various tidy-ups and drop the default

[Ilias Apalodimas <ilias.apalodimas@linaro.org>]

I generally agree with Mark here.

On Mon, Jun 28, 2021 at 10:38:50AM +0200, Mark Kettenis wrote:
> > From: Simon Glass <sjg@chromium.org>
> > Date: Sun, 27 Jun 2021 19:48:34 -0600
> > 
> > It has come to light that EFI_LOADER adds an extraordinary amount of
> > code to U-Boot. For example, with nokia_rx51 the size delta is about
> > 90KB. About 170 boards explicitly disable the option, but is is clear
> > that many more could, thus saving image size and boot time.
> 
> EFI_LOADER used to be a lot smaller.  It is great to see that over the
> years UEFI support has become more complete, but a lot of that new
> code implements features that are not at all essential for just
> booting an OS from storage.  If that growth leads to the suggestion to
> disable EFI_LOADER completely by default, we're putting the cart
> before the horse.
> 
> > The current situation is affecting U-Boot's image as a svelt bootloader.
> 
> Really?  I know UEFI has a bad reputation in the Open Source world,
> and some of its Microsoft-isms are really annoying (yay UCS-2).  But
> it works, it provides a standardized approach across several platforms
> (ARMv7, AMRv8, RISC-V) and the industry seems to like it.  Personally
> I'd wish the industry had standardized on Open Firmware instead, but
> that ship sailed a long time ago...

I think the basics of EFI (mostly those that EBBR requires) are sane and
nice to boot multiple architectures as well.

> 
> I find it hard to imagine that 90k is a serious amount of storage for
> something that is going to include a multi-MB Linux kernel.  This
> isn't code that lives in SPL or TPL where severe size restrictions
> apply.
> 
> > EFI_LOADER is required by EBBR, a new boot standard which aims to
> > bring in UEFI protocols to U-Boot. But EBRR is not required for
> > booting. U-Boot already provides support for FIT, the 'bootm' command
> > and a suitable hand-off to Linux. EBRR has made the decision to create
> > a parallel infrastructure, e.g. does not use FIT, nor U-Boot's signing
> > infrastructure.
> 
> EFI_LOADER is required to boot FreeBSD and OpenBSD on several
> platforms as well as generic Linux distros.  For example
> OpenBSD/armv7, OpenBSD/arm64 and OpenBSD/riscv64 all rely on
> EFI_LOADER to boot and have done so for the last 4 years.  The fact
> that ARM has embraced UEFI as an embedded boot standard and branded it
> EBBR really isn't all that relevant.
> 
> FIT simply isn't fit for purpose (pun intended).  It only really works
> for booting Linux, and forces people to combine u-boot, kernel,
> initial ramdisk and other firmware components into a single image.
> That is really undesirable as:
> 
> - This makes it sigificantly harder to update individual components of
>   such an image.  Making it hard to update a kernel is obviously a
>   serious security risk.
> 
> - This makes it impossible to build an OS install image that works om
>   multiple boards/SoCs.
> 
> > EBBR should be truly optional, enabled only by boards that use it. Most
> > don't use it but it is enabled anyway. The default boot path should be
> > one that makes use of the existing U-Boot support.
> 
> I don't particularly care about EBBR myself, but EFI_LOADER should be
> the default for as many armv7/arm64/riscv U-Boot targets as possible
> to give users an easy way to choose the OS they want to run on their
> machines.  That is the best way to guarantee that vendors ship their
> firmware with it enabled.
> 
> > To try to retify this situation, this series adds a new Kconfig option
> > for EBBR so that the naming is more explicit. Then EFI_LOADER is updated
> > to depend on it.
> 
> Isn't using the the term EBBR for non-ARM platforms misleading?

Not really, we are discussing with RISC-V atm and having platfomrs being
EBBR compliant.  In essence we don't desire EBBR to be an Arm only thing.

> EFI_LOADER is used much more widely.  Anyway, I disagree with this
> direction.
> 

Same here 

> If size really matters here, we should look at reducing the EFI_LOADER
> feature set to reduce the amount of code i adds, and maybe introduce
> an EBBR option that can be enabled by those boards that desire full
> EBBR compliance?

+1

[...]