From owner-freebsd-hackers@freebsd.org Mon Mar 25 20:41:30 2019 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1A032154D641 for ; Mon, 25 Mar 2019 20:41:30 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qk1-x72d.google.com (mail-qk1-x72d.google.com [IPv6:2607:f8b0:4864:20::72d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id ACAF486C90 for ; Mon, 25 Mar 2019 20:41:29 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qk1-x72d.google.com with SMTP id b74so6237472qkg.9 for ; Mon, 25 Mar 2019 13:41:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=QLkpG0JhvO0oH/Uv5/GxXzCVnUdEo3TcGGtNZrpnLeY=; b=yj6Z+Ar64xjzrNuoZjhKi9VM5NEGuR1Xt9yeZEKnQjFOsGwd1XpQJVn40rrE+HORrq Au5Ducf+YtctWYnRPMAHqvasZR3s2zNb3fDd5flV84kUViorm6/lNkCTtN4MGVcNhHJl bB1KH3Df1PXcNIG3ynJGSeIBi+Rb33oJT4iqwU4Pst9x0gjXKM9eCH1i5ed1q0K6pH2Z D59ZSTdEaG22NEOgys3YEWwzMyZhYE3u/yOnALeeLyHynKeUznqLL1L/l4el0HbSQG0O q44/MMpL+GK29y1UMGHGFN5P7hRGNf2XAB9PtGhsvNa6HVXqwFwl5C7GOmmXn6vmgZm5 fwQA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=QLkpG0JhvO0oH/Uv5/GxXzCVnUdEo3TcGGtNZrpnLeY=; b=nM+Mr2qdA1dvSdF5BD2G68KE2zsvAWxTZPhPZ/CiK9tw78XG56egVlSmeRM3X/oXqS 5eNms/4i9+1njatLINb+9a7eTF0IojNDgejftrvzg6III9O0IkZX4UpjF49CYipy9VTh Dp3qa8WxY4H86o8r3jJJHu2Lg8eoY2rltz2g7AoxnMkh44H0o40s3BvLKqR/OC2nN3Ny U6eJ9CKsedtx6RDLrGcY6uRwkAFKLbevowC7kXWA+WDMFd5RywLcZom/UcfH3d9b4OmP dJz9lObiebsCuI9/JTpRrVYb2wiAXjEpCFm1flenYPjgm9bSY8Kgc1FizBZthoXRxGiP oosw== X-Gm-Message-State: APjAAAWse2coBDeOH17cyGxdfyj4sIFC5s0pJfHiLpiF4f7OhQvLbuEP YUEWPdNVmkCpXM0cJ3EHKifSWMg4rHOKO3vtUNCL4w== X-Google-Smtp-Source: APXvYqyTppDY8D8ZcN/rAYyiQccixLSWDC3zZgDIr1m02RFQUvp3WdFnE2vCpHXN1DGemD1bHwhFqpa5EayZOAHSEwU= X-Received: by 2002:a05:620a:132b:: with SMTP id p11mr21713731qkj.279.1553546488966; Mon, 25 Mar 2019 13:41:28 -0700 (PDT) MIME-Version: 1.0 References: <20190324090103.GO1923@kib.kiev.ua> <201903250926.x2P9QgYK078736@gndrsh.dnsmgr.net> <2c1aef87-5408-7736-9039-7fc6a1214102@FreeBSD.org> In-Reply-To: From: Warner Losh Date: Mon, 25 Mar 2019 14:41:17 -0600 Message-ID: Subject: Re: Adding a new efi-update-loader script: need help understanding Makefile.inc1 for "make installworld" To: John Baldwin Cc: "Rodney W. Grimes" , Konstantin Belousov , "freebsd-arch@freebsd.org" , FreeBSD Hackers , Rebecca Cran X-Rspamd-Queue-Id: ACAF486C90 X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-6.98 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.98)[-0.984,0]; REPLY(-4.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Mar 2019 20:41:30 -0000 On Mon, Mar 25, 2019 at 2:30 PM John Baldwin wrote: > On 3/25/19 12:27 PM, Warner Losh wrote: > > On Mon, Mar 25, 2019, 12:34 PM John Baldwin wrote: > > > >> On 3/25/19 8:05 AM, Warner Losh wrote: > >>> We started installing /boot/loader with install world in FreeBSD -3.x > and > >>> it has affected the boot ability that whole time... in the early days > of > >>> loader, the kernel loader handoff protocol was immature enough to need > a > >>> matched kernel. But that period lasted only a few months... loader has > >>> also been weird in other ways as well, since some embedded systems used > >> the > >>> one in its, while others needed an extra step. As UEFI support has > >> matured > >>> we're finding there are several issues around it as well where updating > >> the > >>> ESP needs to be tied to updating /boot for the system to work > sometimes. > >> It > >>> has grown more complex over time, so we should separate. It's been a > >> little > >>> weird on all the non x86 platforms to different degrees, but now that > our > >>> main platform is affected it's become clear we may need to change. > >>> > >>> But we need to do so carefully as this violates POLA in a huge way, as > >> well > >>> as needing doc changes in a bajillion places. > >> > >> I think we should treat files on the ESP the same way we treat other > boot > >> blocks. installworld should continue to install the latest version into > >> /boot (e.g. /boot/boot that holds UFS boot1 + boot2), but then some > other > >> tool is used by the user to copy the updated loader.efi into the ESP. > >> > >> I think the main difference here is that traditionally other boot blocks > >> didn't change very often, so no one really needed to update it them > >> post-install. loader.efi changes often enough we probably need to > document > >> updating the ESP as an optional step in the upgrade process. I think > >> having an automagical script will probably go sideways, but > standardizing > >> where to mounting the ESP (or ESPs when doing RAID mirroring, etc.) > means > >> we can provide a script with defaults (or instructions) that work with > >> the standardized approach. > >> > > > > I think we need to have some automation in place. Something very specific > > and concrete. Otherwise we run the risk of updating the support files > > without updating loader.efi, possibly breaking boot if we wanted to add a > > new API to lua that the startup scripts call. Without an update of > > loader.efi, this generates an error. > > > > I view /efi/boot/* as boot blocks, for these purposes, bit /efi/freebsd > as > > fair game to update. So there is some nuance here we need to take into > > account and avoid absolutes about the BSP. > > Hmm, I guess we considered it a bad idea to store all the support scripts > (not loader.conf, but all the 4th/lua) on the esp beside the loader? That > would make the ESP bits be a self-contained, consistent snapshot. > loader.efi > could perhaps prefer to find those files on the partition it was loaded > from > (you know that IIRC since when you are executed as an EFI app you get a > pointer to your Image and it has a backpointer to the device you came from > I thought) before looking for them on the root filesystem? This would let > it still work when boot1.efi lives on the ESP instead, and also in the case > that you just copied loader.efi into the ESP without the support scripts. > Yea, now we're far into the weeds of dynamic design, and I'm not sure this is a good idea at all. Every time we've tried to pivot with a "just do X" it's burned us on this stuff. I hate the idea of just adding one ore layer of complexity as well, though to be honest, there may be some need to have some standardized fallback for the horrific UEFI implementations that are out there which are deficient in a number of ways that would lead us to needing some not uefi variable fallack mechanism. I'd hate to design that and then have another wart looking for this stuff, as well as users needing to do weird stuff to read in loader.conf and modifying it (more POLA violation if we move it to the ESP, for example). I've not had a chance to connect all the dots, but the few I've tried strong suggest this idea may not hunt. Let's step back and do a complete design doc. I've started writing one up and will post it when I'm done. Warner