Date: Wed, 18 Oct 2017 10:15:12 -0400 From: Eric McCorkle <eric@metricspace.net> To: freebsd-arch@freebsd.org Subject: Re: boot1.efi future Message-ID: <d039f33c-eaac-eba6-e793-8a0127e4166e@metricspace.net> In-Reply-To: <CANCZdfqWSqjdRGetoiscEKJ_dNf3JgOQ2S9mzA0v1mP9PGAy=g@mail.gmail.com> References: <CANCZdfqWSqjdRGetoiscEKJ_dNf3JgOQ2S9mzA0v1mP9PGAy=g@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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" >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?d039f33c-eaac-eba6-e793-8a0127e4166e>