From owner-freebsd-arch@freebsd.org Wed Oct 18 14:26:22 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 24BC4E3A5B6 for ; Wed, 18 Oct 2017 14:26:22 +0000 (UTC) (envelope-from kris@ixsystems.com) Received: from mx.ixsystems.com (mx.ixsystems.com [12.229.62.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN ".", Issuer "." (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id E0C427F86A for ; Wed, 18 Oct 2017 14:26:21 +0000 (UTC) (envelope-from kris@ixsystems.com) Received: from localhost (localhost.localdomain [127.0.0.1]) by mx.ixsystems.com (Postfix) with ESMTP id 3yHDrY181GzCpch for ; Wed, 18 Oct 2017 07:26:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ixsystems.com; h=content-language:content-transfer-encoding:content-type :content-type:in-reply-to:mime-version:user-agent:date:date :message-id:from:from:references:subject:subject:received :received:received:received:received:received:received; s=dkim; t=1508336768; x=1510151169; bh=1f+jgWOjhkHE3kxDQpE6/WbVpXSfb0pa kkzcX0zpSyE=; b=ba7jRJjFDRySCx12GMieihMnaqWpWsxtOoDnSUrLrerh1kXE 35pLskmtKoW3pJAQxuKuNKSg+q3n5g9R/CSJRtD18V8PdZ6v9U/22fxNinT5Ra3v +qzEPnqDWxu/lhmrHzJfJfVzynYIc0Mog+qwkR6zat7/EuLOyrYWeLiX5+aroZSB KXp8BBLy9ykvWF6p+Zh+ClYk3ZYxtsiz7ygDGwgfLIbm42JtXDy7y6FGwrfYW3LG TKLDL0vgBgsvk/FI3iAQqgZc/5sy1RVjj2O0FfoAAaak9ZMcV3cRBn76ta5WcuBo AjYr4AkkppEFhZfm/+JfbVLvm98lFMlJoMlCdQ== X-Amavis-Modified: Mail body modified (using disclaimer) - mx.ixsystems.com X-Virus-Scanned: Scrollout F1 at ixsystems.com Received: from mx.ixsystems.com ([127.0.0.1]) by localhost (mx.ixsystems.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id dbSA4XYKHwce for ; Wed, 18 Oct 2017 07:26:08 -0700 (PDT) Received: from zm01.ixsystems.com (unknown [10.246.0.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.ixsystems.com (Postfix) with ESMTPS id 3yHDrJ3yYXzCqQX for ; Wed, 18 Oct 2017 07:26:08 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zm01.ixsystems.com (Postfix) with ESMTP id 88A081A11FA for ; Wed, 18 Oct 2017 07:26:08 -0700 (PDT) Received: from zm01.ixsystems.com ([127.0.0.1]) by localhost (zm01.ixsystems.com [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id X47Ls8niBjs5 for ; Wed, 18 Oct 2017 07:26:08 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zm01.ixsystems.com (Postfix) with ESMTP id 249DE1A11FB for ; Wed, 18 Oct 2017 07:26:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at ixsystems.com Received: from zm01.ixsystems.com ([127.0.0.1]) by localhost (zm01.ixsystems.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id QR_NtLDcvTsp for ; Wed, 18 Oct 2017 07:26:08 -0700 (PDT) Received: from [10.231.1.89] (unknown [10.231.1.89]) by zm01.ixsystems.com (Postfix) with ESMTPSA id DD5761A11FA for ; Wed, 18 Oct 2017 07:26:07 -0700 (PDT) Subject: Re: boot1.efi future To: freebsd-arch@freebsd.org References: From: Kris Moore Message-ID: Date: Wed, 18 Oct 2017 10:26:05 -0400 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US 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, 18 Oct 2017 14:26:22 -0000 On 10/18/2017 10:15, Eric McCorkle wrote: > 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" >> > _______________________________________________ > 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" +1 here. We still use boot1.efi in TrueOS but if retiring that brings with it the aforementioned improvements, then bring it on! -- Kris Moore Director of Engineering iXsystems Enterprise Storage & Servers Driven By Open Source