Date: Thu, 19 May 2016 02:33:16 -0400 From: Eric McCorkle <eric@metricspace.net> To: "freebsd-hackers@freebsd.org" <freebsd-hackers@freebsd.org> Subject: Re: Update on EFI work: refactoring ready for testing, GELI coming very soon Message-ID: <CE3B606C-56A2-4BD7-AB17-FCEB0C179431@metricspace.net> In-Reply-To: <C54B6238-4186-4DC0-8FDB-067E1724D808@metricspace.net> References: <C54B6238-4186-4DC0-8FDB-067E1724D808@metricspace.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Update: GELI functionality is operational, with a GELI volume being detected= , a ZFS volume contained inside of it being detected and mounted, and a kern= el being loaded and booted from that filesystem. Kernel key injection is not yet implemented, as I promised to give until the= weekend for comments on my proposal. As such, it is not yet possible to co= mplete the boot process from a kernel loaded from a GELI volume. > On May 15, 2016, at 10:32, Eric McCorkle <eric@metricspace.net> wrote: >=20 > Hello everyone, >=20 > I've been working on a rather significant refactoring of the EFI boot/load= er code. While this was originally in support of adding GELI support, it ha= s grown to such a scope that it could be considered a patch in its own right= . >=20 > The branch containing my work can be found here: https://github.com/emc2/f= reebsd/tree/efize >=20 > The following is a summary of the changes: > * Both boot1 and loader have been redesigned to look for instances of EFI_= SIMPLE_FILESYSTEM_PROTOCOL and load using that interface. In loader, this i= s accomplished through a new synthetic filesystem driver (called efifs) that= is just a wrapper around EFI_SIMPLE_FILESYSTEM_PROTOCOL. In boot, this is a= chieved by calling the interface directly. > * The efipart and filesystem back ends (including ZFS) have been moved int= o a drivers directory, where they have been wrapped up into a filesystem bac= kend driver that does the same probing that loader does today, and then inst= alls an EFI_SIMPLE_FILESYSTEM_INTERFACE on all device handles that host supp= orted filesystems. This interface is a wrapper around the filesystem interf= ace currently used by loader. > * boot now uses the same filesystem backend code as loader. This increase= d its size, necessitating recreation of the FAT templates. The old boot fil= esystem code and boot modules have been discarded. > * loader can use any protocol interface installed by boot just fine. Thes= e remain valid until ExitBootServices is called. Moreover, the probing proc= ess is idempotent, and is run by both boot and loader, with the first one to= run actually installing the interfaces. > * I had originally hoped to move the entire code base to use the EFI drive= r model, which would support hotplugging devices. However, the new bcache s= tuff currently requires that all devices be statically detected before the c= aches are used, which is fundamentally incompatible with this way of doing t= hings. This was the sole blocker of such a transition (the handles.c code r= equires some minor modification as well, but nothing problematic) > * I had also considered altering the device name code to use textual repre= sentations of EFI device paths, but I don't see any real reason for doing so= . > * I have not touched efinet or nfs in this changeset. >=20 > The rationale for these changes is as follows: > * The model of looking for EFI_SIMPLE_FILESYSTEM_PROTOCOL instances and us= ing them to load things increases interoperability with other systems. For e= xample, the new boot and loader would work just fine with interfaces install= ed by GRUB or another boot loader, or perhaps custom filesystem modules adde= d into an open-source firmware implementation like coreboot. > * This model works really well for functionality like GELI or custom parti= tion schemes that potentially create new devices. All you do is create one o= r more new device nodes, attach device paths and block io interfaces, and ca= ll ConnectController on them (for now, it's necessary to make sure the fs_dr= iver runs AFTER) all new nodes have been created. This also vastly simplifie= s passing information between stages about filesystems and devices (this is i= mportant for GELI). > * This approach can leverage drivers that are mandated by the EFI spec, li= ke the GPT partition driver. This avoids reimplementing such a driver to su= pport partition schemes nested inside GELI volumes, for example. > * This model provides most of the groundwork for supporting hot plugging o= f devices at boot time. All that is required at this point is a refactoring= of bcache to support adding new devices dynamically (I had to draw the line= somewhere, and this had already gotten big enough, and I want to focus on G= ELI support) > * Getting rid of the duplicated and minimized filesystem code in boot1 imp= roves maintainability. Indeed, the actual boot1 code is quite small now. >=20 > Some notes and future work: > * In general, the FreeBSD loader framework and the EFI framework do many s= imilar things. For the most part, there is a fairly direct mapping, though E= FI interfaces tend to be more tedious. The one thing EFI does decidedly bet= ter is support dynamic detection of devices (hotplugging). > * There are some interesting possibilities for hotplugging beyond just the= obvious. For example, loading GELI or other keys off of hotplugged USB sti= cks. > * I didn't touch efinet or nfs on this patch. It is certainly possible to= efize them as well, but I don't have a test setup for doing so (or frankly,= the motivation to do so). > * It might make more sense to use the EFI_LOAD_FILE_PROTOCOL to do the act= ual loading, as some applications support this without supporting a full fil= esystem interface (some embedded devices do this, as do some network boot pr= otocols). However, this would involve changing the non-EFI boot code and in= terfaces, which is something I specifically wanted to avoid in this work. >=20 > This changeset can be tested as is, and should just work. Disclaimer: I r= ebased it to head yesterday, and haven't had time to build and test it yet, b= ut I will. I know it works with ZFS, but I have no UFS systems on which to t= est that functionality. >=20 > If you intend to test this, I STRONGLY recommend installing an EFI shell o= n your ESP, and then installing the modified boot block under something like= boot.tst. This will allow you to run the modified boot block, but fall bac= k to a working boot if it fails. Also, I had modified the loader path to /b= oot/loader.tst for similar reasons, and it may still be set to that in the c= ode. >=20 > I am currently adding GELI support as a proper EFI driver, and should be c= oming in the very near future (the code is already written, in fact). If an= yone wants to test the refactoring by itself, any results or comments are ce= rtainly appreciated. > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CE3B606C-56A2-4BD7-AB17-FCEB0C179431>