Date: Wed, 18 Oct 2017 10:26:05 -0400 From: Kris Moore <kris@ixsystems.com> To: freebsd-arch@freebsd.org Subject: Re: boot1.efi future Message-ID: <b4fc97ff-3245-828b-30aa-62ace2ff0317@ixsystems.com> In-Reply-To: <d039f33c-eaac-eba6-e793-8a0127e4166e@metricspace.net> References: <CANCZdfqWSqjdRGetoiscEKJ_dNf3JgOQ2S9mzA0v1mP9PGAy=g@mail.gmail.com> <d039f33c-eaac-eba6-e793-8a0127e4166e@metricspace.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On 10/18/2017 10:15, Eric McCorkle wrote: > My $0.02... > > I'm in agreement. I've been down in this stuff with the ZFS EFI > support, and lately the GELI stuff. In both cases, it complicates > things quite a bit. With ZFS, it meant I basically had to do everything > twice. With GELI, it introduced a number of complications, and GELI > probably would have landed over a year ago if it was just loader. Going > forward, I want to do some signed kernel/modules stuff, and the > existence of boot1 is just going to complicate that as well. > > An interesting point: back when I briefly took up EFI support as a GSoC > project (which I was forced to abandon, unfortunately), the prototype > *did* only have loader.efi, which was installed to the ESP. So the plan > should work. You'd have to modify loader.efi a bit to alter its device > detection logic, but you could probably salvage some code from my boot1 > refactor (which is actually modified code I stole from loader.efi anyway). > > As far as my work goes, this won't cause me any problems, and in fact > will simplify things. The GELI stuff mostly modifies loader anyway, and > the actual GELI EFI driver works the same in boot1 and loader (by > design). For secure boot, getting rid of boot1 avoids having to haul in > a bunch more EFI APIs and debug signed image stuff. For other work, I > can't say for certain, of course, but I've been working on this stuff > for a while now and I can't really think of a use case that makes me say > "man, boot1 really solves that problem in a way nothing else can". > > So in summary, I don't doubt it was a sensible decision at some point, > but I'm in agreement that its time has come. > > On 10/17/2017 19:18, Warner Losh wrote: >> I'd like to remove boot1.efi. It's no longer relevant. It was a useful hack >> to get us going, but now it's becoming more of a liability than a win. >> >> There's a lot of work that has been put into it so it can understand every >> filesystem. However, in doing so boot1.efi has morphed into a loader.efi >> without the scripting interpreter. Let's just kill boot1.efi and load the >> full-featured loader directly. >> >> boot1.efi used to have a role to play. It was a tiny, rarely changing bit >> of glue in the UEFI world. It is now none of those things. It has become >> rather large and bloated, and there's work to make it even more so. >> >> My proposal is to fix the one bug in loader.efi that would preclude its use >> as a primary boot loader (it sometimes guesses wrong for currdev and >> loaddev). Once we've done that, we'll use it where we use boot1.efi today. >> It would also simplify the load process and make it easier to implement the >> full EFI Boot Manager protocol from the UEFI specifications. It should also >> make secure boot easier to bring to market. >> >> This dovetails nicely into some of the other changes on-tap for FreeBSD 12. >> efibootmgr is coming soon (I'm reviewing the code from a coworker now). >> There's plans to move the FreeBSD boot loader to >> \efi\FreeBSD\loader-$ARCH.efi when that goes in, since we'll be able to >> point the LoadOptions to that. There's plans to make the installer create >> the EFI partition rather than just dd the efifat file we're doing today. >> Plus, there's work underway to move all the boot block installation stuff >> to a new script (install-boot) as well as efforts to make images for any >> bootable system (spin). >> >> There's lots of details to get right before we can make the final switch, >> but I think it's in the interest of the project to do so. >> >> Comments? >> >> Warner >> _______________________________________________ >> freebsd-arch@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-arch >> To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" >> > _______________________________________________ > freebsd-arch@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" +1 here. We still use boot1.efi in TrueOS but if retiring that brings with it the aforementioned improvements, then bring it on! -- Kris Moore Director of Engineering iXsystems Enterprise Storage & Servers Driven By Open Source
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?b4fc97ff-3245-828b-30aa-62ace2ff0317>