From owner-freebsd-arch@freebsd.org Fri Oct 27 01:22:29 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 6E482E580F5; Fri, 27 Oct 2017 01:22:29 +0000 (UTC) (envelope-from eric@metricspace.net) Received: from mail.metricspace.net (mail.metricspace.net [IPv6:2001:470:1f11:617::107]) by mx1.freebsd.org (Postfix) with ESMTP id 45B6671252; Fri, 27 Oct 2017 01:22:29 +0000 (UTC) (envelope-from eric@metricspace.net) Received: from [IPv6:2001:470:1f11:617:3210:b3ff:fe77:ca3f] (unknown [IPv6:2001:470:1f11:617:3210:b3ff:fe77:ca3f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: eric) by mail.metricspace.net (Postfix) with ESMTPSA id B0CE01308; Fri, 27 Oct 2017 01:22:28 +0000 (UTC) Subject: Re: New behaviors for loader.efi To: Warner Losh Cc: "freebsd-arch@freebsd.org" , "freebsd-hackers@freebsd.org" , Warner Losh References: <87ceccf2-09fb-1adb-6304-649961cae2d4@metricspace.net> From: Eric McCorkle Message-ID: <74106a34-c82c-d9c5-d1bf-7128236d0378@metricspace.net> Date: Thu, 26 Oct 2017 21:22:28 -0400 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit 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: Fri, 27 Oct 2017 01:22:29 -0000 On 10/26/2017 11:19, Warner Losh wrote: > So long as it's a backup method, that's fine. It occurs to me that it > might be useful for removable media where you can't count on EFI env > vars and you are bootstrapping such that you need the args (serial > console is the canonical case). Worth noting: some implementations (lenovo, for example) do sketchy things with their EFI vars, and others can lose their state from disconnecting the battery, etc. So I think a backup like this is necessary. > The fallback mechanism should try too hard though. Trying hard gets in > the way of many things. The biggest one being when I have multiple disks > in a system that have multiple copies of the OS. You want the fallback > mechanism to try as limited a number of things as possible then FAIL so > we can go to the next BootXXXX in the boot order. So long as the guesses > are super limited, and/or only done done when we don't specify something > explicit, then that's OK. > > So the change from the present would be: > > (1) If a second path is specified in the BootXXXX option, then boot it > (might want to look in the list to generalize this, but for the moment > that's an enhancement). If we fail to boot an explicit path, fail back > to the EFI boot manager. We were told to do something explicitly, and we > couldn't do that, so we shouldn't go guessing (this includes ZFS BE, > UFS, etc) > (2) If no path is specified and if we come from a UFS or ZFS partition > (the boot1.efi vector), then try to boot the kernel off of that > partition. If that fails, then fail the boot back to EFI boot manager. > (3) If no path is specified and there's ZFS BE we can boot from, boot > that (fail if we can't) > (4) if no path is specified and we can find a UFS partition on the > current disk, boot that (fail if we can't) This sounds good (assuming 4 also searches for ZFS) > I'll try to find some time today to update the boot document and to try > to draw in points you have in your chain of trust documents because > that's also important. It might also be worth bringing in the 'self > contained load env' work that I know is going on elsewhere (basically, > you load a loader with a MD burned into it and boot from that, with the > entire loader.efi signed such that the shim-loader that floating around > can load and verify it -- a lite version of the stuff you are working on). I'm going to update the trust infrastructure paper with some of the ideas from the discussion, but the salient points should remain the same.