loader.efi architecture for replacing boot1.efi

[Warner Losh]

On Dec 15, 2017 5:57 PM, "Eric McCorkle" <eric at metricspace.net> wrote:

I have posted a review which begins to move loader.efi in the direction
of replacing boot1.efi.  The review can be found here:
https://reviews.freebsd.org/D13497

This patch enables loader.efi to be installed to /efi/boot/BOOTX64.EFI
on the ESP.  It implements what I envision being the last-resort
fallback mechanism, but this is enough to allow it to boot a FreeBSD system.


This will move to /efi/freebsd/loader.efi

It also preserves the existing behavior, so as not to break anyone's
install.

The *eventual* procedure for initial partition selection looks like this:

1) See if the boot loader arguments directly specify a kernel and/or
partition, use that if they do.


This should be second. Uefi variables Trump all.

2) If not, then attempt to read EFI vars to determine the boot location

3) If no EFI vars are defined, and no partition was specified, fall back
to looking for an installed system on devices


This is fine, so long as it is only on the device that the loader loaded
from.

4) At the very last, do the legacy (what loader.efi currently does)
behavior.


This is bogus. It violates the uefi boot loader protocol. We must abandon
this legacy behavior. The behavior is actively harmful since something
random will boot. This has caused actual operational issues at Netflix.
Guessing is really bad.

Step (3) is done by attempting to stat /boot/loader.conf and
/boot/kernel.  First, all partitions on the same disk are searched, then
all remaining partitions are searched.

This should allow mechanisms like EFI vars and command-line args to work
without interference from the fallback mechanisms.  However, it also
provides robustness in the face of failure modes and uninitialized
systems (I personally ran into a problem a while back with a linux
system, where I couldn't boot with EFI, because the EFI vars weren't
set, because I couldn't set them if I couldn't boot with EFI; had to use
Shell.efi to sort out the mess...)

More importantly, it provides a seamless transition from the way things
are now to the way we want things to be.

Please provide comments and feedback.


Please listen when I say searching all devices is actively harmful. The
uefi boot manager, which I'm in the process of bringing in, offers a way to
specifically say what you want to boot. If someone needs something
complicated, they must use that moving forward. Part of what makes the
protocol work is loaders giving up early so the next one on the list can be
tried.

Warner