[prev in list] [next in list] [prev in thread] [next in thread] 

List:       freebsd-hackers
Subject:    Re: New behaviors for loader.efi
From:       Eric McCorkle <eric () metricspace ! net>
Date:       2017-10-27 1:22:28
Message-ID: 74106a34-c82c-d9c5-d1bf-7128236d0378 () metricspace ! net
[Download RAW message or body]

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.
_______________________________________________
freebsd-hackers@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"
[prev in list] [next in list] [prev in thread] [next in thread]