From owner-freebsd-hackers@freebsd.org Mon Mar 25 20:30:15 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 24DB2154CEC0; Mon, 25 Mar 2019 20:30:15 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B89C5862F1; Mon, 25 Mar 2019 20:30:14 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from John-Baldwins-MacBook-Pro-3.local (ralph.baldwin.cx [66.234.199.215]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: jhb) by smtp.freebsd.org (Postfix) with ESMTPSA id 562E92173; Mon, 25 Mar 2019 20:30:13 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Subject: Re: Adding a new efi-update-loader script: need help understanding Makefile.inc1 for "make installworld" To: Warner Losh Cc: "Rodney W. Grimes" , Konstantin Belousov , "freebsd-arch@freebsd.org" , FreeBSD Hackers , Rebecca Cran References: <20190324090103.GO1923@kib.kiev.ua> <201903250926.x2P9QgYK078736@gndrsh.dnsmgr.net> <2c1aef87-5408-7736-9039-7fc6a1214102@FreeBSD.org> From: John Baldwin Openpgp: preference=signencrypt Autocrypt: addr=jhb@FreeBSD.org; keydata= mQGiBETQ+XcRBADMFybiq69u+fJRy/0wzqTNS8jFfWaBTs5/OfcV7wWezVmf9sgwn8TW0Dk0 c9MBl0pz+H01dA2ZSGZ5fXlmFIsee1WEzqeJzpiwd/pejPgSzXB9ijbLHZ2/E0jhGBcVy5Yo /Tw5+U/+laeYKu2xb0XPvM0zMNls1ah5OnP9a6Ql6wCgupaoMySb7DXm2LHD1Z9jTsHcAQMD /1jzh2BoHriy/Q2s4KzzjVp/mQO5DSm2z14BvbQRcXU48oAosHA1u3Wrov6LfPY+0U1tG47X 1BGfnQH+rNAaH0livoSBQ0IPI/8WfIW7ub4qV6HYwWKVqkDkqwcpmGNDbz3gfaDht6nsie5Z pcuCcul4M9CW7Md6zzyvktjnbz61BADGDCopfZC4of0Z3Ka0u8Wik6UJOuqShBt1WcFS8ya1 oB4rc4tXfSHyMF63aPUBMxHR5DXeH+EO2edoSwViDMqWk1jTnYza51rbGY+pebLQOVOxAY7k do5Ordl3wklBPMVEPWoZ61SdbcjhHVwaC5zfiskcxj5wwXd2E9qYlBqRg7QeSm9obiBCYWxk d2luIDxqaGJARnJlZUJTRC5vcmc+iGAEExECACAFAkTQ+awCGwMGCwkIBwMCBBUCCAMEFgID AQIeAQIXgAAKCRBy3lIGd+N/BI6RAJ9S97fvbME+3hxzE3JUyUZ6vTewDACdE1stFuSfqMvM jomvZdYxIYyTUpC5Ag0ERND5ghAIAPwsO0B7BL+bz8sLlLoQktGxXwXQfS5cInvL17Dsgnr3 1AKa94j9EnXQyPEj7u0d+LmEe6CGEGDh1OcGFTMVrof2ZzkSy4+FkZwMKJpTiqeaShMh+Goj XlwIMDxyADYvBIg3eN5YdFKaPQpfgSqhT+7El7w+wSZZD8pPQuLAnie5iz9C8iKy4/cMSOrH YUK/tO+Nhw8Jjlw94Ik0T80iEhI2t+XBVjwdfjbq3HrJ0ehqdBwukyeJRYKmbn298KOFQVHO EVbHA4rF/37jzaMadK43FgJ0SAhPPF5l4l89z5oPu0b/+5e2inA3b8J3iGZxywjM+Csq1tqz hltEc7Q+E08AAwUIAL+15XH8bPbjNJdVyg2CMl10JNW2wWg2Q6qdljeaRqeR6zFus7EZTwtX sNzs5bP8y51PSUDJbeiy2RNCNKWFMndM22TZnk3GNG45nQd4OwYK0RZVrikalmJY5Q6m7Z16 4yrZgIXFdKj2t8F+x613/SJW1lIr9/bDp4U9tw0V1g3l2dFtD3p3ZrQ3hpoDtoK70ioIAjjH aIXIAcm3FGZFXy503DOA0KaTWwvOVdYCFLm3zWuSOmrX/GsEc7ovasOWwjPn878qVjbUKWwx Q4QkF4OhUV9zPtf9tDSAZ3x7QSwoKbCoRCZ/xbyTUPyQ1VvNy/mYrBcYlzHodsaqUDjHuW+I SQQYEQIACQUCRND5ggIbDAAKCRBy3lIGd+N/BCO8AJ9j1dWVQWxw/YdTbEyrRKOY8YZNwwCf afMAg8QvmOWnHx3wl8WslCaXaE8= Message-ID: Date: Mon, 25 Mar 2019 13:30:11 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:60.0) Gecko/20100101 Thunderbird/60.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: B89C5862F1 X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-6.96 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.96)[-0.960,0]; REPLY(-4.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0] 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:30:15 -0000 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. -- John Baldwin