From owner-freebsd-arch@freebsd.org Fri Aug 11 04:03:59 2017 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DEF50D92F79 for ; Fri, 11 Aug 2017 04:03:59 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id BAC0E835BC for ; Fri, 11 Aug 2017 04:03:59 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mailman.ysv.freebsd.org (Postfix) id B70F7D92F78; Fri, 11 Aug 2017 04:03:59 +0000 (UTC) Delivered-To: arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B69E0D92F76 for ; Fri, 11 Aug 2017 04:03:59 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x232.google.com (mail-io0-x232.google.com [IPv6:2607:f8b0:4001:c06::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8452E835BB for ; Fri, 11 Aug 2017 04:03:59 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x232.google.com with SMTP id c74so16247455iod.4 for ; Thu, 10 Aug 2017 21:03:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:from:date:message-id:subject:to; bh=zss1P+GlI+n73pzz+f86ARPyxlA+CvAchkQeyiqR27s=; b=HCIAtalov04HurTeOdlBOeDX3ELQNfMOtKtXRcleU6H8CIl9wKUHMdD+Y4sGzycASI fioSi/onSB0iEikgVUinl+K1lvWbL5FgkfevDO/kN4FIGahmd3Bl2ucSDe61WmLt3EOk Kar0ly15sdHQ5ZFhlNIA+HimMC1qDR6OyBXO3TQumv+ykOJVlV2DQBvjjVNjQHbEcLUN +PtA5DmO4XoxkRvgu+bKuXsEx2IqdbiAM2gGMNmhhxL0UiVHLk13uDGPReM8SuZKB0DZ /UDRveJ37BH/Vl1LPNZgEFTHMwSLZI1Xf9MKDmu/RFfFaW4idhgUp9X3pOqEfsjjiK6Q G2LQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to; bh=zss1P+GlI+n73pzz+f86ARPyxlA+CvAchkQeyiqR27s=; b=Kd9qwK9JqClsnog+EoBW7c24RtSruhPQz+GULCSjVyQkJNftWSKE8buXeOdApIIJj3 lbezXt1l/4meh9humb91IyIYNwPBQdwBfmPKqrf40pvYFnd3XkkkhOn6805a2KyhAkx6 Iv0EKWCz3kfFutxlpy8Zg6ssVWVCl6s84fPuDym4iw/T1DNpQuuUUeqfKka5HZVUG0rj uCSVZdGB9YlVC6NoeZYotnYTJhLSDFlzaMLeiR1GAYOm8EtAgkpzyaOGSP1oKGjKbsoB VDZNcurh3NmE+qky+Jp1KK48ScVcQ0qbc1+c2poYp0QMlCAn6JM/RjiBKo56KEI49F1Z I38Q== X-Gm-Message-State: AHYfb5gM8mPtwGSuJu4FqgWPuRbYI75LSI9ESzm/0WVjFSe9iYcLDyep o8t6kSU8HYpPUTWtXNFl2nyxq3Q4IoMSWbQ= X-Received: by 10.107.136.104 with SMTP id k101mr11649415iod.62.1502424238521; Thu, 10 Aug 2017 21:03:58 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.10.71 with HTTP; Thu, 10 Aug 2017 21:03:57 -0700 (PDT) X-Originating-IP: [2603:300b:6:5100:fc73:9056:67a0:a7d0] From: Warner Losh Date: Thu, 10 Aug 2017 22:03:57 -0600 X-Google-Sender-Auth: Ax1LfHdybnDowHSRCuXqvaFEAf4 Message-ID: Subject: Proposed Enhancements to the EFI booting To: "freebsd-arch@freebsd.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Aug 2017 04:04:00 -0000 Greetings, I've been circulating a document (the latest version you can find here https://docs.google.com/document/d/1aK9IqF-60JPEbUeSAUAkYjF2W_8EnmczFs6RqCT= 90Jg/edit?usp=3Dsharing ) I'm opening it up for general comments now. I intend to turn this into a full spec, including the bits in the UEFI standard that I reference by pointer, and move to implementation soon once any issues are resolved. Warner FreeBSD UEFI boot protocol This document outlines the enhancements to the UEFI Boot Manager Protocol, as outlined in Version 2.6 of the UEFI spec, chapter 3. It assumes that you are familiar with that chapter and though a comprehensive doc with our additions folded into it would be good, it hasn=E2=80=99t been produced. Current Algorithm Boot1.efi currently searches for /boot/loader.efi using a fairly complicated algorithm. First, we look for any ZFS pool that has a /boot/loader.efi on it, consistent with its boot environment settings. If we find that, we use it. Second, we search all of the partitions on the device that we booted boot1.efi off of for a UFS partition that has a /boot/loader.efi we can load. If we find that, we use it. Third, we search all other devices for a partition that is UFS formatted and has a /boot/loader.efi we can load. There=E2=80=99s some problems with this algorithm. It=E2=80=99s not possibl= e to specify a partition to boot from. We boot from the first /boot/loader.efi that=E2=80= =99s found, even if multiple partitions on a drive have one. Second, it=E2=80=99= s very non-deterministic. The second step was added to add some determinism to the process so if you plugged in a FreeBSD 11.0R release USB stick and rebooted, you would reboot to the installed system and not the USB installer. It doesn=E2=80=99t use the ad-hoc method for identifying which F= reeBSD partition to boot off of that we use for BIOS boots since in the UEFI runtime environment it=E2=80=99s tricky to get the attribute flags of a par= tition. Finally, it doesn=E2=80=99t use the standard UEFI boot manager protocol. Proposed Algorithm First, the FreeBSD UEFI Boot Loader UUID shall be cfee69ad-a0de-47a9-93a8-f63106f8ae99 (below as FreeBSD:). The UEFI defined global variable UUID (EFI_GLOBAL_VARIABLE) is 8BE4DF61-93CA-11d2-AA-0D-00-E0-98-03-2B-8C (below as UEFI:) Boot1.efi will find what to use with the following algorithm: 1. If the UEFI boot manager passes an optional parameter to boot1.efi, then parse it as if it were a EFI Device Path to find the next stage boot loa= der to use. If we can use that boot loader, we=E2=80=99re done. Otherwise, i= gnore it. 2. Get the value of UEFI:BootCurrent. This will be a 4 digit hex number XXXX. If FreeBSD:BootLoaderXXXX exists, and specifies a file we can load= , use it. This is in the form of a EFI device path (binary). If it is a Fi= le path that=E2=80=99s ZFS:yyyy, then boot from the Boot environment for ZF= S pool yyyy. If :yyyy is omitted, use the first ZFS pool you find. 3. If a ZFS pool exists with a bootable environment, boot it. 4. If a partition with a known filesystem exists on the same device as boot1.efi was loaded from, and it contains /boot/loader.efi, use it. 5. Set FreeBSD:BootFailedXXXX to the reason for the failure and return Failure to UEFI (so UEFI goes to the next item in the list) If FreeBSD:BootArgumentsXXXX exists, parse it like ASCII text and pass it to the boot loader found in steps 1-4 above. Otherwise pass nothing. If the FreeBSD:Update variable is set, the rc system will update the boot order so that UEFI:BootCurrent is at the start of UEFI:BootOrder. This is currently done in /etc/rc.d/gptupdate. I propose a /etc/rc.d/efiupdate to do this, and to report all the BootFailedXXXX variables ala gptupdate. Discussion of points raised on IRC: FreeBSD currently implements a =E2=80=98boot once=E2=80=99 option that=E2= =80=99s similar to =E2=80=98BootNext=E2=80=99 but happens only once. In UEFI, BootNext almost = implements this. The BIOS loads that option, then deletes the BootNext env variable. Unless the OS does something the make it permanent, this is the same as FreeBSD=E2= =80=99s boot once (because the order then reverts to BootOrder). I think that BootFailed needs to be implemented with the extra protocol outlined in step 5. Open Issues: Allan Jude has raised some issues about ZFS. ZFS has it=E2=80=99s own way t= o deal with all this and he=E2=80=99s curious how this fits into that. EFI doesn= =E2=80=99t know about ZFS, so at most we can only define what happens when boot1.efi takes over. In that case, I proposed to him that we do what we do now, and selection of what ZFS thing can be done either as I proposed, or via the zfsbootcfg process if nothing further than ZFS is specified (or automatically selected). How does loader.efi fit for people that load it directly? Do we want to enable / disable the automatic looking for boot locations separately from what to boot being explicitly specified or not? I=E2=80=99m= leaning against. Can nextboot -k foo be implemented with this? My first notion is that it would FreeBSD:KernelXXXX to specify the kernel and FreeBSD:NextKernelXXXX which would load that kernel and then unset FreeBSD:NextKernelXXXX. Ditto for FreeBSD:KernelFlagsXXXX and FreeBSD:NextKernelFlagsXXXX. nextboot(8) would set all these. Maybe FreeBSD:LoaderXXXX and FreeBSD:NextLoaderXXXX too...