Date: Mon, 16 May 2016 17:51:23 +0900 From: Naomichi Nonaka <nao@enuenu.org> To: Eric McCorkle <eric@metricspace.net>, Oliver Pinter <oliver.pinter@hardenedbsd.org> Cc: "freebsd-hackers@freebsd.org" <freebsd-hackers@freebsd.org> Subject: Re: Update on EFI work: refactoring ready for testing, GELI coming very soon Message-ID: <58159dcd-4187-473f-4a20-1d2f7a20c955@enuenu.org> In-Reply-To: <1C7554E1-DF5F-4D86-B4D3-757CF55FCB9E@metricspace.net> References: <C54B6238-4186-4DC0-8FDB-067E1724D808@metricspace.net> <CAPQ4ffuo2DpwWZjEw8pAEJaQMFc_k=KCadj0LjwGhZ%2BAEZGyNw@mail.gmail.com> <1C7554E1-DF5F-4D86-B4D3-757CF55FCB9E@metricspace.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi Eric. On 2016/05/16 5:37, Eric McCorkle wrote: > How close is that patch to going in? > > Something like this would be pretty straightforward following the > refactoring; however, its worth considering all the options here: > > * GRUB works fine pulling loader off the disk, with either ZFS or UFS, > with no boot1 at all. This was my setup for developing the ZFS support, > actually. Is Grub + loader really work in EFI mode ? My test results are 1) Grub's kfreebsd command does not support loader.efi 2) Chainload loader.efi in Grub couldn't show display. maybe it work in keadless but I didn't tested headless mode. 3) Chaiload boot1.efi in Grub works. That is why I wrote PR#207940. Maybe I miss something. So, If anyone successed to boot in Grub + loader.efi combination, please let me know. > * In theory it should be possible to install loader itself on the ESP > and install a /boot/config that points it to the real kernel and rootfs > > The takeaway is that boot1 is kind of an odd citizen in the EFI world. Year, I agree that. But I myself need boot menu, and expand boot1 seems better than to install Grub in Freebsd installer. > When you get into things like GELI support and secure boot (my next > planned thing after this), its role is much clearer, but at that point > it also becomes a key attack vector in a system that's presumably trying > to resist some level of tampering. > > What I'm getting at is that there is a future-oriented case for keeping > boot1 simple, and if it's a boot menu you want, grub is already an > option (also, the loader-only method). > > To be clear: I'm not opposed to adding this feature; I just want to make > sure these issues are given due consideration. I agree that too. Naomichi Nonaka > On May 15, 2016 12:00:58 PM EDT, Oliver Pinter > <oliver.pinter@hardenedbsd.org> wrote: > > Hi Eric! > > Could you please take a look at this PR: > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207940 > This feature would be nice too. > > On 5/15/16, Eric McCorkle <eric@metricspace.net> wrote: > > Hello everyone, > > I've been working on a rather significant refactoring of the EFI > boot/loader > code. While this was originally in support of adding GELI > support, it has > grown to such a scope that it could be considered a patch in its > own right. > > The branch containing my work can be found here: > https://github.com/emc2/freebsd/tree/efize > > 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 is accomplished through a new synthetic filesystem driver > (called > efifs) that is just a wrapper around > EFI_SIMPLE_FILESYSTEM_PROTOCOL. In > boot, this is achieved by calling the interface directly. > * The efipart and filesystem back ends (including ZFS) have been > moved into > a drivers directory, where they have been wrapped up into a > filesystem > backend driver that does the same probing that loader does > today, and then > installs an EFI_SIMPLE_FILESYSTEM_INTERFACE on all device > handles that host > supported filesystems. This interface is a wrapper around the > filesystem > interface currently used by loader. > * boot now uses the same filesystem backend code as loader. This > increased > its size, necessitating recreation of the FAT templates. The old > boot > filesystem code and boot modules have been discarded. > * loader can use any protocol interface installed by boot just > fine. These > remain valid until ExitBootServices is called. Moreover, the probing > process 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 driver > model, which would support hotplugging devices. However, the new > bcache > stuff currently requires that all devices be statically detected > before the > caches are used, which is fundamentally incompatible with this > way of doing > things. This was the sole blocker of such a transition (the > handles.c code > requires some minor modification as well, but nothing problematic) > * I had also considered altering the device name code to use textual > representations 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. > > The rationale for these changes is as follows: > * The model of looking for EFI_SIMPLE_FILESYSTEM_PROTOCOL > instances and > using them to load things increases interoperability with other > systems. > For example, the new boot and loader would work just fine with > interfaces > installed by GRUB or another boot loader, or perhaps custom > filesystem > modules added into an open-source firmware implementation like > coreboot. > * This model works really well for functionality like GELI or custom > partition schemes that potentially create new devices. All you > do is create > one or more new device nodes, attach device paths and block io > interfaces, > and call ConnectController on them (for now, it's necessary to > make sure the > fs_driver runs AFTER) all new nodes have been created. This also > vastly > simplifies passing information between stages about filesystems > and devices > (this is important for GELI). > * This approach can leverage drivers that are mandated by the > EFI spec, like > the GPT partition driver. This avoids reimplementing such a > driver to > support partition schemes nested inside GELI volumes, for example. > * This model provides most of the groundwork for supporting hot > plugging of > 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 > GELI support) > * Getting rid of the duplicated and minimized filesystem code in > boot1 > improves maintainability. Indeed, the actual boot1 code is quite > small > now. > > Some notes and future work: > * In general, the FreeBSD loader framework and the EFI framework > do many > similar things. For the most part, there is a fairly direct > mapping, though > EFI interfaces tend to be more tedious. The one thing EFI does > decidedly > better 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 > sticks. > * 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 > actual loading, as some applications support this without > supporting a full > filesystem interface (some embedded devices do this, as do some > network boot > protocols). However, this would involve changing the non-EFI > boot code and > interfaces, which is something I specifically wanted to avoid in > this work. > > This changeset can be tested as is, and should just work. > Disclaimer: I > rebased it to head yesterday, and haven't had time to build and > test it yet, > but I will. I know it works with ZFS, but I have no UFS systems > on which to > test that functionality. > > If you intend to test this, I STRONGLY recommend installing an > EFI shell on > 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 back > to a working boot if it fails. Also, I had modified the loader > path to > /boot/loader.tst for similar reasons, and it may still be set to > that in the > code. > > I am currently adding GELI support as a proper EFI driver, and > should be > coming in the very near future (the code is already written, in > fact). If > anyone wants to test the refactoring by itself, any results or > comments are > certainly 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" > > > > -- > Sent from my Android device with K-9 Mail. Please excuse my brevity.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?58159dcd-4187-473f-4a20-1d2f7a20c955>