Date: Tue, 17 Oct 2017 21:16:12 -0600 From: Warner Losh <imp@bsdimp.com> To: Julian Elischer <julian@elischer.org> Cc: "freebsd-arch@freebsd.org" <arch@freebsd.org> Subject: Re: boot1.efi future Message-ID: <CANCZdfoKLnAz3KbV%2BDPaH-_CYmyqYReAYnU5L-7gdj72qLyDJw@mail.gmail.com> In-Reply-To: <de96f7b9-6cc6-3d10-d3d9-4ee0c8ec3c52@elischer.org> References: <CANCZdfqWSqjdRGetoiscEKJ_dNf3JgOQ2S9mzA0v1mP9PGAy=g@mail.gmail.com> <de96f7b9-6cc6-3d10-d3d9-4ee0c8ec3c52@elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Oct 17, 2017 at 8:54 PM, Julian Elischer <julian@elischer.org> wrote: > On 18/10/17 7:18 am, 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? >> > > I haven't been following the EFI story. > Is there a doc that describes the current FreeBSD EFI boot process? > I wrote one for the EFI Boot Manger stuff. https://docs.google.com/document/d/1aK9IqF-60JPEbUeSAUAkYjF2W_8EnmczFs6RqCT90Jg/edit#heading=h.jdwnfj2sxlfb and nobody objected to it in a timely fashion, so it's the implementation path I set out on... But long story short: We bogusly put boot1.efi into \efi\boot\bootx64.efi and hope for the best (since it's the default for removable media and most BIOSes use it as a default for non-removable media too). If it loads, we search in the vain hope that we might guess which of the /boot/loader.efi's might be out there is the right one and jump to it. From there, the process is much the same as anything else. The above doc changes this to 'we follow the normal EFI boot mgr protocol as amended by the above doc' though the elimination of boot1.efi hasn't made it's way through the above doc. Basically, we pass two device paths in the BootOptions BootXXXX variable. First one is loader.efi (which we'll preferentially put in \efi\freebsd\loader-x64.efi) and the second one is the kernel to load (with the implicit load module path, per today's stuff). boot1.efi complicates things for no benefit. It complicates loading, it complicates guessing where to put stuff to make it happy, it complicates key signing and handoff for secure boot. We should ditch this clever hack as something whose time has come and gone. We'd like to get secure boot in place, and boot1.efi just increases by 1 the number of boot loaders that have to cope with that stuff. boot1.efi has to have all the filesystem support for everything. It has to know about EFI Boot mgr protocol. In short, it's every single thing that /boot/loader.efi must be, but without the FORTH or the flexibility. Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfoKLnAz3KbV%2BDPaH-_CYmyqYReAYnU5L-7gdj72qLyDJw>