From owner-freebsd-arch@freebsd.org Sat Dec 16 01:09:20 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 B7FA3E91A16 for ; Sat, 16 Dec 2017 01:09:20 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x22a.google.com (mail-it0-x22a.google.com [IPv6:2607:f8b0:4001:c0b::22a]) (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 79E7B6E19E for ; Sat, 16 Dec 2017 01:09:20 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x22a.google.com with SMTP id u62so22686250ita.2 for ; Fri, 15 Dec 2017 17:09:20 -0800 (PST) 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=Bt3k6aG5cstyBZeHXhvsMpVKCf4I8/NA0/Dqe5aZHtk=; b=HLrvy7xWYutNNZl3/NTtJnVfOiKpDeKc/5OeTZpkanlKne7t4nCBGhHv9tES8ecA9R XUPTrIkbdporzPV3L2TFgHy1r1HoyGncq1s3sVzOVkYNbfrLK1uwfNurUPCXJAy8dyUm elKTFvhM8RR2TPyoNwLhipMTcbGE1LOWfHThqHtMNUjJtMUhx6ztfQkWUufauSGHkg8f LBu2aieyv61ZuVgX8uDe6ypSkNo7bnAb0vAqUqd2ugbNM9QIWXrjsi1syFdYTSmCLE6Z LRJvm2dXblU+9xNXdbSM8c2I+fUEOqKE/JdvGTPeg8N4emImWtGfpngCodeQOw+7WpRZ RMkQ== 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=Bt3k6aG5cstyBZeHXhvsMpVKCf4I8/NA0/Dqe5aZHtk=; b=UFgbRnRXtJBi0LJDlK3/oZBaMg8ZB7q9RWldUKrZgMJN56VgRG0omTGfMlPty6yICM M88AcquCRDDUT58UkyXzDbNYDJiJuzhwnI7VH7VeqYi6g1QH9HZ1UR/W0zcD/55KVky0 HxrbE7cNSklgH3Tt7Fgm3m7h7h+/L3pvdSDGCAHzKIjuAALG9XR4yj2pNGlojBKvrSL1 qFwT3C3A05VThR7JUuorldltMvR9WWWUx8vLP+6i3lcFh5cAWsfg1WaQi4ni9Z4n38OZ aAyPSpzBVotqYFubvbrCz8VRxgmhyx7hY1PfvgwtbJVuLzm4ETHXu6Z6aq09FH6TDQLe hMPQ== X-Gm-Message-State: AKGB3mJVyiXCalo6DNQDa+COQ6lKKR48zfgFD+exqcHhjtbbzDR/I83Q 5BCg1CuEGu860ZOX3EawgEchkmTloM0UT3lulTIimg== X-Google-Smtp-Source: ACJfBoskIaP6rLDfT68EdmnIvK+OnpdxyEy8eVp28+CWc509xCIn4FYbM7giLCnqGx3S+ZXXCJrUcGnk6MwKIPbvuDE= X-Received: by 10.36.147.193 with SMTP id y184mr3606006itd.64.1513386559684; Fri, 15 Dec 2017 17:09:19 -0800 (PST) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.108.204 with HTTP; Fri, 15 Dec 2017 17:09:18 -0800 (PST) X-Originating-IP: [2607:fb90:6f64:50fc:8dcb:1f9d:9ad:1368] Received: by 10.79.108.204 with HTTP; Fri, 15 Dec 2017 17:09:18 -0800 (PST) In-Reply-To: <1fa7edde-6ac0-1d4f-e75a-503b23a5d4dc@metricspace.net> References: <1fa7edde-6ac0-1d4f-e75a-503b23a5d4dc@metricspace.net> From: Warner Losh Date: Fri, 15 Dec 2017 18:09:18 -0700 X-Google-Sender-Auth: G3ZPA5QzZ0nbXKElwhp10z_Ml64 Message-ID: Subject: Re: loader.efi architecture for replacing boot1.efi To: Eric McCorkle Cc: freebsd-arch@freebsd.org, Warner Losh , Allan Jude Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Dec 2017 01:09:20 -0000 On Dec 15, 2017 5:57 PM, "Eric McCorkle" wrote: I have posted a review which begins to move loader.efi in the direction of replacing boot1.efi. The review can be found here: https://reviews.freebsd.org/D13497 This patch enables loader.efi to be installed to /efi/boot/BOOTX64.EFI on the ESP. It implements what I envision being the last-resort fallback mechanism, but this is enough to allow it to boot a FreeBSD system. This will move to /efi/freebsd/loader.efi It also preserves the existing behavior, so as not to break anyone's install. The *eventual* procedure for initial partition selection looks like this: 1) See if the boot loader arguments directly specify a kernel and/or partition, use that if they do. This should be second. Uefi variables Trump all. 2) If not, then attempt to read EFI vars to determine the boot location 3) If no EFI vars are defined, and no partition was specified, fall back to looking for an installed system on devices This is fine, so long as it is only on the device that the loader loaded from. 4) At the very last, do the legacy (what loader.efi currently does) behavior. This is bogus. It violates the uefi boot loader protocol. We must abandon this legacy behavior. The behavior is actively harmful since something random will boot. This has caused actual operational issues at Netflix. Guessing is really bad. Step (3) is done by attempting to stat /boot/loader.conf and /boot/kernel. First, all partitions on the same disk are searched, then all remaining partitions are searched. This should allow mechanisms like EFI vars and command-line args to work without interference from the fallback mechanisms. However, it also provides robustness in the face of failure modes and uninitialized systems (I personally ran into a problem a while back with a linux system, where I couldn't boot with EFI, because the EFI vars weren't set, because I couldn't set them if I couldn't boot with EFI; had to use Shell.efi to sort out the mess...) More importantly, it provides a seamless transition from the way things are now to the way we want things to be. Please provide comments and feedback. Please listen when I say searching all devices is actively harmful. The uefi boot manager, which I'm in the process of bringing in, offers a way to specifically say what you want to boot. If someone needs something complicated, they must use that moving forward. Part of what makes the protocol work is loaders giving up early so the next one on the list can be tried. Warner