From owner-freebsd-arch@freebsd.org Wed Oct 18 03:16:14 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 9B139E4DF6E for ; Wed, 18 Oct 2017 03:16:14 +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 7460167DC9 for ; Wed, 18 Oct 2017 03:16:14 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mailman.ysv.freebsd.org (Postfix) id 730BBE4DF6B; Wed, 18 Oct 2017 03:16:14 +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 6FEDBE4DF6A for ; Wed, 18 Oct 2017 03:16:14 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x234.google.com (mail-it0-x234.google.com [IPv6:2607:f8b0:4001:c0b::234]) (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 3508267DC8 for ; Wed, 18 Oct 2017 03:16:14 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x234.google.com with SMTP id 72so4751662itk.3 for ; Tue, 17 Oct 2017 20:16:14 -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=s/TI3fvzfPQWL1xNaLS/qKyC+6n9eI9vwdInADuuRTc=; b=QFV7HzE/2/TeZ60RxlywacgaCGH+rYrnNS6jUDy3sVABVV6QdRUTFWf6BkpNufV8y5 MNDf01QJYBza4yRdoeKRErILr0U2FBi2eEm1w4EeaMVYZnQbCpcxCnG72aEx81OmMRWD yQxXGWfzX0x7wJcNjpqFikhGgIvX3b2SoU0EdTWlvJCgm1Uv+TxWd/GGBoyGS6WxNIeU OxRipEvdAtC5qhF6SBo+iZXxRov681XfqxpZXenEeqXZUFUnin7P/FYJkNnLLHFk2uoe aTw9O6TTpbDZ6/aPwfsKA76usmP4CtjQnDS06A1DpCkNPzvn1+TmqTYSUyWUGmTT4WcJ W3dg== 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=s/TI3fvzfPQWL1xNaLS/qKyC+6n9eI9vwdInADuuRTc=; b=DPa2oO7zYjMwWvhe3jeNyJzpgjAp0aQ31s+y9l1c5fecV+dI6bvg6cTgi4XFkIzI6w 6hBzh878XgEMi1axwoh6L7f2j62mDLADZocCR9Uj2CnnE66mJPTnJEYhbb6zfYBzQlex 3irMUGCgX1+2obLFZhmdEMs8E4rSPecBY3AKXxAlKbAqRq4Pwixs23kFJflAtTZNau0Q YBl4vd65SVduSZw6gv56HsBBRdEf2F1ykC63XLX+B1BgnEcg5sCu+gIZh5lVWv8ZFh1y gNdcjmnsvVtiLfIzbOAaYwdTmPJZI9fxRsmEAG3PqAGYXtXj9p1o8AucZ+OwMNB6p51D CRXw== X-Gm-Message-State: AMCzsaV6kktmNKOM6wVF28IwT0LeZWASC4GPpPyTbiYuNaS4E0Gn1Txr bHULwdy4PivkBk4Xj2s+l1GJ4RmO2TIQrRA9YnT9lg== X-Google-Smtp-Source: ABhQp+Tq/3T2umRj0OAKQCObV9mvtdQ6tQHwkgiK/CI7BS1nMr7yEpuaQs6FoQVb1Id6P5ohtdIF7O5gPepTYhiXiK8= X-Received: by 10.36.94.129 with SMTP id h123mr7679014itb.64.1508296573153; Tue, 17 Oct 2017 20:16:13 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.57.22 with HTTP; Tue, 17 Oct 2017 20:16:12 -0700 (PDT) X-Originating-IP: [2603:300b:6:5100:2569:27e9:4f44:7434] In-Reply-To: References: From: Warner Losh Date: Tue, 17 Oct 2017 21:16:12 -0600 X-Google-Sender-Auth: mqpY2gWPMD57anRApg9U7eZMooQ Message-ID: Subject: Re: boot1.efi future To: Julian Elischer 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, 18 Oct 2017 03:16:14 -0000 On Tue, Oct 17, 2017 at 8:54 PM, Julian Elischer 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