From owner-freebsd-arch@freebsd.org Wed Aug 16 04:15:21 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 04364DE58AE for ; Wed, 16 Aug 2017 04:15:21 +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 C99116EAC3 for ; Wed, 16 Aug 2017 04:15:20 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mailman.ysv.freebsd.org (Postfix) id C5D0EDE58AC; Wed, 16 Aug 2017 04:15:20 +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 C5434DE58AB for ; Wed, 16 Aug 2017 04:15:20 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x22f.google.com (mail-it0-x22f.google.com [IPv6:2607:f8b0:4001:c0b::22f]) (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 8C32D6EAC2 for ; Wed, 16 Aug 2017 04:15:20 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x22f.google.com with SMTP id 76so12624843ith.0 for ; Tue, 15 Aug 2017 21:15:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to; bh=wza6PTkkcSK7OTlZcmjXyb4c19TCzOSnFPm8rdCwN4g=; b=Y7yBrZK11F0P+dtghSAb4ENinN82cypd8CvyuUJAGUaiZDkwynU/BuGo4Sin7+/M+K rOMklX7kvYn+0IHe4iuSlFoyPo3+VI0dIQrgZ0L4trSw7RLCjvn4DUDoDOLYStb3nxT9 HTDAot+8YnhGCvxzmFURd4lApHCuZKTl8H05jtXtPlNFhTj0cCWNF8T66NIXWFfQCsbZ pcF+EZViGqVaxjbdy8wB7+cJ9oJ8djCrOpRZ+8zTA/AA1sCJgXh1F+eESPXfRt4ThvtW M6jD3bAi8m62k7cTRl0ijoW/EPbUnyp1Z4Vb7qkXvNUoyrnTVItU4Mg0yFdVIqDG98Ji VAnA== 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:in-reply-to:references:from :date:message-id:subject:to; bh=wza6PTkkcSK7OTlZcmjXyb4c19TCzOSnFPm8rdCwN4g=; b=kuL0nufvWPncCmIyBr9zJaz6vPVjwqoi8da0os2toasn2Uthc/0mrZR5i5CzTcIYs3 wiaJwVeed/tbeh4xVIMsZZNwM1+/Zbpa51dYHZZ34vX7GslAYu5bxx5dWuroXJllYDM7 o9y907144q7BkpaH7Q79eQb2BMowzWVhX4pQ3nCfzWHOUsNlTN/gc/ExGiM0VD3FdssS Ly0djAk4buR4AJCpCexOB5+fThIBXgrTTUifq+2T2BoVu1WCaAuslxKoOW7Pe8GS36xm oTcKhw3rUWlD0utXbg47P8++PJKw7hbIxtjS9e52SeNwiNmZU4gZ9tw9dh/9BxJ+Mret Y8CA== X-Gm-Message-State: AHYfb5gXyLmQ25iTWhs+0TRRKt45MUuzlJKaAzluj/jWVaA7Vu1C6C3p 2SCTHG9LCHmik+10QvcjZVGjpPsiq4NZ X-Received: by 10.36.68.193 with SMTP id o184mr671690ita.59.1502856919390; Tue, 15 Aug 2017 21:15:19 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.10.71 with HTTP; Tue, 15 Aug 2017 21:15:18 -0700 (PDT) X-Originating-IP: [2603:300b:6:5100:d1c0:cd3e:37aa:d1eb] In-Reply-To: References: From: Warner Losh Date: Tue, 15 Aug 2017 22:15:18 -0600 X-Google-Sender-Auth: 3EyWCJk0ck8rFIFuACdcmyv03qI Message-ID: Subject: Re: 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: Wed, 16 Aug 2017 04:15:21 -0000 On Thu, Aug 10, 2017 at 10:03 PM, Warner Losh wrote: > Greetings, > > I've been circulating a document (the latest version you can find here > https://docs.google.com/document/d/1aK9IqF-60JPEbUeSAUAkYjF2W_ > 8EnmczFs6RqCT90Jg/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 y= ou > 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 possi= ble 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= =99s very > non-deterministic. The second step was added to add some determinism to t= he > 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= FreeBSD > 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 p= artition. > 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 b= oot > loader to use. If we can use that boot loader, we=E2=80=99re done. Oth= erwise, > ignore 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 lo= ad, > use it. This is in the form of a EFI device path (binary). If it is a = File > path that=E2=80=99s ZFS:yyyy, then boot from the Boot environment for = ZFS pool > yyyy. If :yyyy is omitted, use the first ZFS pool you find. > > It turns out that the path in EFI_LOAD_OPTIONS is really a list of paths. I believe it would be more robust to use that fact. The list will include boot1.efi, loader.efi and kernel. However, it could just as easily include only loader.efi and kernel. The exact interpretation of the extra path names is OS specific. If you want to boot ZFS, it can be encoded as File('ZFS') or File('ZFS:pool'). It's all OS specific. What to do about /? How do we find it? That's easy. It is the last path in the list that has a HD specifier (eg, the File part of the path, if present, is ignored). This also means you could pass in HD()/File('/efi/FreeBSD/boot1.efi'), HD()/File('/boot/loader.efi'), HD()/File('/boot/kernel/kernel'), HD(). In that case there's 4 partitions involved, we load different bits off each one. Or the last 3 could be the same (and the final one wouldn't be needed). It would also allow each phase of the loader to know where it is and find the next thing to load. so we don't need FreeBSD:BootLoaderXXX. > 1. > > If a ZFS pool exists with a bootable environment, boot it. > 2. > > 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. > 3. > > 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. > It would be more in line with the standard, it seems, to pass this in with the 'optional data'. If we had the thing being loaded interpret the data as a list of strings. The current loader uses the first string and passes the rest to the next loader. This would eliminate the need for BootArgumentsXXXX. > 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 almos= t implements this. > The BIOS loads that option, then deletes the BootNext env variable. Unles= s > 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 st= ep > 5. > > Open Issues: > > Allan Jude has raised some issues about ZFS. ZFS has it=E2=80=99s own way= to 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 take= s > 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... > With the above interpretation we wouldn't need any of this. You'd just create a new BootXXX and point BootNext at it. I'll update the doc with these, and am open to comments on them. Warner From owner-freebsd-arch@freebsd.org Wed Aug 16 07:48:54 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 D56A9DCB7BB for ; Wed, 16 Aug 2017 07:48:54 +0000 (UTC) (envelope-from avg@FreeBSD.org) 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 BF193745AB for ; Wed, 16 Aug 2017 07:48:54 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: by mailman.ysv.freebsd.org (Postfix) id BE61CDCB7B9; Wed, 16 Aug 2017 07:48:54 +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 BE066DCB7B8 for ; Wed, 16 Aug 2017 07:48:54 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citapm.icyb.net.ua (citapm.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 1CF67745A9 for ; Wed, 16 Aug 2017 07:48:50 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citapm.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id KAA10215; Wed, 16 Aug 2017 10:45:18 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1dht0w-000H9H-Lh; Wed, 16 Aug 2017 10:45:18 +0300 Subject: Re: Proposed Enhancements to the EFI booting To: Warner Losh , "freebsd-arch@freebsd.org" References: From: Andriy Gapon Message-ID: Date: Wed, 16 Aug 2017 10:44:24 +0300 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit 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: Wed, 16 Aug 2017 07:48:54 -0000 On 16/08/2017 07:15, Warner Losh wrote: > If you want to boot ZFS, it can be encoded as File('ZFS') or > File('ZFS:pool'). It's all OS specific. Just a note that it would be nice to be able to select a specific filesystem within a ZFS pool as well. That would provide a more robust alternative to zfsbootcfg on EFI systems. -- Andriy Gapon From owner-freebsd-arch@freebsd.org Wed Aug 16 14:55:41 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 4F35CDE06FD for ; Wed, 16 Aug 2017 14:55:41 +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 2A06C198F for ; Wed, 16 Aug 2017 14:55:41 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mailman.ysv.freebsd.org (Postfix) id 2617EDE06FC; Wed, 16 Aug 2017 14:55:41 +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 25BC5DE06FB for ; Wed, 16 Aug 2017 14:55:41 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x235.google.com (mail-it0-x235.google.com [IPv6:2607:f8b0:4001:c0b::235]) (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 E6140198B for ; Wed, 16 Aug 2017 14:55:40 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x235.google.com with SMTP id m34so18299807iti.1 for ; Wed, 16 Aug 2017 07:55:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=lbvRr5x7UKjjin/Qbm3OV7+vh3nKBqE3zbnNu+2APnw=; b=cgFfTYwDH69A4vLg4wxz8uPgt1+Y5wMtvPCg8WavDd3TY0ak2vjKOW6MA6JMghF1tr uWCmItrrKy4dJ0QoKPDM8PMby6l6GgIo3bLj5n4ELsaPeLwW+UbNkYLl4mXw3JY4v0PW 8p7owF37cyRUKQBArevNeVwcvIMlWNnVE+cvFYUGOmdWJZST85p6nFtJdFYX8EtYfaFD 4z7JRL+oVyqPUssVY8IFnbvw89oHNIiGQA7iYjtGlg7vm+3vTbeYwQAqjco/91INF6bF gaoEbEUDiViUx/SFT75RfLKMBIxtiZDL+ora6p/S/baJFaVY8KAYAkM/4hEbk5GUKdfO 5Vew== 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:in-reply-to:references:from :date:message-id:subject:to:cc; bh=lbvRr5x7UKjjin/Qbm3OV7+vh3nKBqE3zbnNu+2APnw=; b=T/tKlDugT06kydO9H+h9K39qUk2fgkFP5WnOhk0e6yWzr1pgmGt6s6dgTn3Eag0VZF Z/LMwPAjg7K+vDpdnon8LlHdIsJHTAHHpD801j8ylFa/BKfTVzq8Cf0OD5rrvOzxCEig xUsFVJ5gsopalby248+5i6iaM2YJ6X7/ik4SBWXgYFkeBpP5Hp+8n2pYsULsV2Yc9ex6 i50CJFNkkkNFuLbfJfH9r0u/7hojysHcamILkWHOugrqyijgu+Z4j0lDXcMXn6bB5pbG Fpwq6E5EZVMbCzL//UcSvmMgGaZsD3eAdd5arX1aZeQJxu4HABX1O8wFiRXbPcmE42Yr HIIw== X-Gm-Message-State: AHYfb5iYXN2G4+drskSF0S5ZIYX8phCdgd11MG69Ouy1uyvwMmRaw38z k9fCzEKdkq+QlzIq2emLYp9fkKg1wOVU X-Received: by 10.36.68.193 with SMTP id o184mr1967217ita.59.1502895340206; Wed, 16 Aug 2017 07:55:40 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.10.71 with HTTP; Wed, 16 Aug 2017 07:55:39 -0700 (PDT) X-Originating-IP: [50.253.99.174] In-Reply-To: References: From: Warner Losh Date: Wed, 16 Aug 2017 08:55:39 -0600 X-Google-Sender-Auth: ZXnNy4GZGDvtCGQYKeTbVxH10EU Message-ID: Subject: Re: Proposed Enhancements to the EFI booting To: Andriy Gapon Cc: "freebsd-arch@freebsd.org" Content-Type: text/plain; charset="UTF-8" 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: Wed, 16 Aug 2017 14:55:41 -0000 On Wed, Aug 16, 2017 at 1:44 AM, Andriy Gapon wrote: > On 16/08/2017 07:15, Warner Losh wrote: > > If you want to boot ZFS, it can be encoded as File('ZFS') or > > File('ZFS:pool'). It's all OS specific. > > Just a note that it would be nice to be able to select a specific > filesystem within a ZFS pool as well. That would provide a more robust > alternative to zfsbootcfg on EFI systems. > I concur. I'd like to be able to specify the whole path somehow. I'm looking for the standard way to do that. I also need a way to just say "Find a ZFS pool so we do what we do now" and "Find ZFS pool FRED and do what we do now" Someone (maybe you) on IRC suggested zfs:/pool/file/system:/path/to/file since that's what's used now. It doesn't look like a typical URI, but looking at RFC 3986 I see that it fits the ABNF at the end, as well as being congruent with some of the examples. Since there's no 'authority' section, it's fine. I'm not aware of needing any authority or credentials to access the pool, so I think that's fine. Warner