Date: Thu, 26 Oct 2017 09:19:15 -0600 From: Warner Losh <imp@bsdimp.com> To: Eric McCorkle <eric@metricspace.net> Cc: "freebsd-arch@freebsd.org" <freebsd-arch@freebsd.org>, "freebsd-hackers@freebsd.org" <freebsd-hackers@freebsd.org>, Warner Losh <imp@freebsd.org> Subject: Re: New behaviors for loader.efi Message-ID: <CANCZdfrHSM2oU47V-HcLjRPyZEvaFirT2y5CP17fp1k2mGfVrg@mail.gmail.com> In-Reply-To: <87ceccf2-09fb-1adb-6304-649961cae2d4@metricspace.net> References: <ecfa88fb-be25-0c47-ee24-ef6511dccd9e@metricspace.net> <CANCZdfpfxxkAjmFoCdeXi-Q0kduJiXCS_%2BiwfuW_32FY_m0EbA@mail.gmail.com> <87ceccf2-09fb-1adb-6304-649961cae2d4@metricspace.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Oct 26, 2017 at 6:32 AM, Eric McCorkle <eric@metricspace.net> wrote: > On 10/25/2017 22:58, Warner Losh wrote: > > > I would vote neither. If it belongs on the ESP at all, it belongs in > > \efi\freebsd\boot.conf. We now own \efi\freebsd, so that's where all our > > boot files need to wind up in our install. But I'm not sure that we need > > it at all, since boot.conf is only for boot1/boot2 in the current system > > (though it does set serial by default, which might be helpful to > > preserve). It would be even better, though, to use the command line > > that's passed in as part of the UEFI:BootXXXX environment variable. > > Since we have to move it anyway, we should do things in the EFI way, > > which is to store all the nonvolatile info in UEFI environment variables > > (and in this case, the command line / aux info in the BootXXXX > > variable). We really need to stop polluting \efi\boot with anything, > > except on removable media. > > That seems reasonable, however it might be worth having a backup > mechanism (boot.conf) in case the EFI vars get clobbered. Also, a file > with the args can be more easily signed and verified than EFI vars. So long as it's a backup method, that's fine. It occurs to me that it might be useful for removable media where you can't count on EFI env vars and you are bootstrapping such that you need the args (serial console is the canonical case). > I think it should be in /boot/loader.conf on /, not the ESP. We should > > only have \efi\freebsd\loader.efi in the ESP. > > Also my inclination. Excellent. If we do have a boot.conf to supply a backup way of specifying command line args, then we should look for it in ESP:\efi\freebsd\boot.conf. > I'm not sure that it should look very hard, and it should only look as a > > last result. > > > > UEFI:BootCurrent lists the current boot variable. It points to the > > UEFI:BootXXXX that contains a LoadOption variable. This variable > > contains a series of DevicePaths. The first one is what the UEFI BIOS > > uses to load loader.efi (installed as ESP:\EFI\FREEBSD\LOADER.EFI). The > > second one in the list will point to the kernel to load. That way we > > shouldn't have to go looking at all. We assume that the root is the same > > partition we load the kernel comes from. We should only go looking if we > > fail to find the second path in the LoadOption. > > Right. The search would be a fallback mechanism, if all else fails. It > doesn't even need to succeed; it just needs to make a reasonable guess. The fallback mechanism should try too hard though. Trying hard gets in the way of many things. The biggest one being when I have multiple disks in a system that have multiple copies of the OS. You want the fallback mechanism to try as limited a number of things as possible then FAIL so we can go to the next BootXXXX in the boot order. So long as the guesses are super limited, and/or only done done when we don't specify something explicit, then that's OK. So the change from the present would be: (1) If a second path is specified in the BootXXXX option, then boot it (might want to look in the list to generalize this, but for the moment that's an enhancement). If we fail to boot an explicit path, fail back to the EFI boot manager. We were told to do something explicitly, and we couldn't do that, so we shouldn't go guessing (this includes ZFS BE, UFS, etc) (2) If no path is specified and if we come from a UFS or ZFS partition (the boot1.efi vector), then try to boot the kernel off of that partition. If that fails, then fail the boot back to EFI boot manager. (3) If no path is specified and there's ZFS BE we can boot from, boot that (fail if we can't) (4) if no path is specified and we can find a UFS partition on the current disk, boot that (fail if we can't) Otherwise fail back to EFI boot manager for the next one on the list. > No, we don't. boot1.efi already does this, and legacy systems will > > already have this installed. So we don't have to recreate this behavior > > if we don't want to since updated systems will need to follow the > > efibootmgr protocol. There's no way the loader.efi will fit on the old > > ESPs we created anyway... loader.efi needs to cope with being loaded > > this way, but it doesn't have to recreate boot1.efi's behavior. > > OK, I was assuming there'd be an interim period where loader.efi still > gets installed to /boot/, in which case the dual-purpose would be > necessary. It sounds like you want to quit installing it there altogether. > Yes. I want to get loader.efi in shape to be the primary loader, but won't get rid of boot1.efi right away until the installer catches up. A small case could be made for having boot1.efi for legacy users that keeps simple UFS / ZFS features we have in 11.x, but removes any features we've added since then. It's still unclear to me if that's useful or not. > With regard to GELI, it sounds like it can actually be committed in > parallel with any of the changes you're planning here. This would give > loader the ability to attach and explore EFI partitions, but you > wouldn't be able to boot a pure-GELI system until the loader-only setup > is viable. > Yes. I agree. I'd like to see it so you could install one by hand in the base prior to the installer supporting that. I'll have to look at the individual changes carefully, but at a high level when I saw them they looked like the right direction. I'll try to find some time today to update the boot document and to try to draw in points you have in your chain of trust documents because that's also important. It might also be worth bringing in the 'self contained load env' work that I know is going on elsewhere (basically, you load a loader with a MD burned into it and boot from that, with the entire loader.efi signed such that the shim-loader that floating around can load and verify it -- a lite version of the stuff you are working on). Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfrHSM2oU47V-HcLjRPyZEvaFirT2y5CP17fp1k2mGfVrg>