Seeking input on two options for EFI GELI boot

[Eric McCorkle]

Hi all,

After spending literally days arguing with myself in circles about this, I'me decided to put it out for public discussion...

The root of the issue is that I'm working on GELI support for the EFI boot.  This involves implementing some kind of device tree framework to do it the Right Way, since encrypted partitions may have subpartitions within them.

There are basically two ways to do this, and it comes down to the decision of whether to embrace the EFI API or spurn it.  Here is a breakdown of how both options work out:

Minimal EFI (aka what my boot1 prototype does):
* Modify boot1 to use a more abstract device interface, allowing for a device tree
* Add a providers API, allowing for detection of subdevices
* Detect subdevices recursively, then try filesystems drivers
* Do basically the same thing in loader
* Somehow pass the key information from boot1 to loader to avoid asking for keys multiple times

Embrace EFI:
* Have the providers interface, but use the EFI boot services, device path, and driver APIs to create new device nodes, connect them to device paths, and install protocol interfaces (like BLOCK_IO_PROTOCOL) on the nodes.
* These new device handles will be available to loader, as boot is effectively installing boot-time device drivers.
* You could go a step further here and create SIMPLE_FILESYSTEM_PROTOCOL drivers for ZFS and UFS and install them on device handles that hold those filesystems.
* loader would run a round of detection, then try to boot.  If boot1 has already detected everything, then loader won't harm anything by trying.  OTOH, if we're coming in from something like grub, then we'll end up detecting everything.


It's not clear that one or the other is preferable.  They both have upsides and downsides:
* The EFI option could eliminate a lot of code duplication between boot1 and loader.  It also plays much nicer with other tools like Grub, which may want to work by creating EFI drivers to read FreeBSD partitions and filesystems.
* loader as written REALLY wants to just boot from the device handle its given.  Running detecting a whole entire device tree, then picking a node from it would be a nontrivial rearchitecting.
* On the other hand, using the EFI API more extensively introduces a dependence on the  specific platform's implementation.  These may be buggy, to otherwise untrustworthy.
* Leaning this heavily on EFI would depart somewhat from the existing boot architecture.
* Going the full EFI route would involve rewriting a whole lot of the EFI boot1 and loader (I'm willing to undertake this, but it's enough of a change that it should be understood and discussed before doing it; also, it might be worth doing in stages)


Please provide input/feedback/discussion...