Date: Fri, 15 Apr 2016 22:16:27 -0400 From: Eric McCorkle <eric@metricspace.net> To: "freebsd-hackers@freebsd.org" <freebsd-hackers@freebsd.org> Subject: Seeking input on two options for EFI GELI boot Message-ID: <F9EC0594-C9A7-4346-93AE-0D63396E6970@metricspace.net>
next in thread | raw e-mail | index | archive | help
Hi all, After spending literally days arguing with myself in circles about this, I'm= e 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 R= ight Way, since encrypted partitions may have subpartitions within them. There are basically two ways to do this, and it comes down to the decision o= f whether to embrace the EFI API or spurn it. Here is a breakdown of how bo= th options work out: Minimal EFI (aka what my boot1 prototype does): * Modify boot1 to use a more abstract device interface, allowing for a devic= e 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 k= eys multiple times Embrace EFI: * Have the providers interface, but use the EFI boot services, device path, a= nd 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 effective= ly installing boot-time device drivers. * You could go a step further here and create SIMPLE_FILESYSTEM_PROTOCOL dri= vers for ZFS and UFS and install them on device handles that hold those file= systems. * loader would run a round of detection, then try to boot. If boot1 has alr= eady detected everything, then loader won't harm anything by trying. OTOH, i= f we're coming in from something like grub, then we'll end up detecting ever= ything. It's not clear that one or the other is preferable. They both have upsides a= nd 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 wan= t 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 giv= en. Running detecting a whole entire device tree, then picking a node from i= t would be a nontrivial rearchitecting. * On the other hand, using the EFI API more extensively introduces a depende= nce on the specific platform's implementation. These may be buggy, to othe= rwise untrustworthy. * Leaning this heavily on EFI would depart somewhat from the existing boot a= rchitecture. * Going the full EFI route would involve rewriting a whole lot of the EFI bo= ot1 and loader (I'm willing to undertake this, but it's enough of a change t= hat it should be understood and discussed before doing it; also, it might be= worth doing in stages) Please provide input/feedback/discussion...=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?F9EC0594-C9A7-4346-93AE-0D63396E6970>