From owner-freebsd-hackers@freebsd.org Sat Apr 16 02:16:29 2016 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7FE57AED45D for ; Sat, 16 Apr 2016 02:16:29 +0000 (UTC) (envelope-from eric@metricspace.net) Received: from mail.metricspace.net (mail.metricspace.net [IPv6:2001:470:1f11:617::107]) by mx1.freebsd.org (Postfix) with ESMTP id 5AA5B1A4F for ; Sat, 16 Apr 2016 02:16:29 +0000 (UTC) (envelope-from eric@metricspace.net) Received: from [IPv6:2001:470:1f11:617:8fe:6a13:797b:e9c9] (unknown [IPv6:2001:470:1f11:617:8fe:6a13:797b:e9c9]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) (Authenticated sender: eric) by mail.metricspace.net (Postfix) with ESMTPSA id 9AA3213E7 for ; Sat, 16 Apr 2016 02:16:28 +0000 (UTC) Subject: Seeking input on two options for EFI GELI boot From: Eric McCorkle Content-Type: text/plain; charset=us-ascii X-Mailer: iPad Mail (13D15) Message-Id: Date: Fri, 15 Apr 2016 22:16:27 -0400 To: "freebsd-hackers@freebsd.org" Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (1.0) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Apr 2016 02:16:29 -0000 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...=