Date: Sun, 10 Feb 2019 11:01:59 -0700 From: Ian Lepore <ian@freebsd.org> To: Karl Denninger <karl@denninger.net> Cc: freebsd-stable@freebsd.org, Allan Jude <allanjude@freebsd.org> Subject: Re: Fwd: Serious ZFS Bootcode Problem (GPT NON-UEFI) Message-ID: <398cae11ff6b81d0bc1dbdcd54f64eb97b2c812a.camel@freebsd.org> In-Reply-To: <3fd7f001-879c-7b1e-3d1a-d2939ac07d9c@denninger.net> References: <911d001f-9e33-0521-51fe-f7d1383dfc62@denninger.net> <CANCZdfp0QaXodmYBp9Eox9Ca5kyQibCXw5rRTwsO-mCjApYswA@mail.gmail.com> <b11ec38c-1c6a-6e92-810c-4d2fe3e8df3d@freebsd.org> <a107a4f5-2851-191a-5f8c-a4cd44c98458@denninger.net> <16c56c89ff8a3d89164d9152f6c38687dcba99b5.camel@freebsd.org> <3fd7f001-879c-7b1e-3d1a-d2939ac07d9c@denninger.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 2019-02-10 at 11:54 -0600, Karl Denninger wrote: > On 2/10/2019 11:50, Ian Lepore wrote: > > On Sun, 2019-02-10 at 11:37 -0600, Karl Denninger wrote: > > > On 2/10/2019 09:28, Allan Jude wrote: > > > > Are you sure it is non-UEFI? As the instructions you followed, > > > > overwriting da0p1 with gptzfsboot, will make quite a mess if > > > > that > > > > happens to be the EFI system partition, rather than the > > > > freebsd- > > > > boot > > > > partition. > > > > > > [...] > > > > > > BTW am I correct that gptzfsboot did *not* get the ability to > > > read > > > geli-encrypted pools in 12.0? The UEFI loader does know how > > > (which I'm > > > using on my laptop) but I was under the impression that for non- > > > UEFI > > > systems you still needed the unencrypted boot partition from > > > which to > > > load the kernel. > > > > > > > Nope, that's not correct. GELI support was added to the boot and > > loader > > programs for both ufs and zfs in freebsd 12. You must set the geli > > '-g' > > option to be prompted for the passphrase while booting (this is > > separate from the '-b' flag that enables mounting the encrypted > > partition as the rootfs). You can use "geli configure -g" to turn > > on > > the flag on any existing geli partition. > > > > -- Ian > > Excellent - this will eliminate the need for me to run down the > foot-shooting that occurred in my update script since the unencrypted > kernel partition is no longer needed at all. That also significantly > reduces the attack surface on such a machine (although you could > still > tamper with the contents of freebsd-boot of course.) > > The "-g" flag I knew about from experience in putting 12 on my X1 > Carbon > (which works really well incidentally; the only issue I'm aware of is > that there's no 5Ghz WiFi support.) > One thing that is rather unfortunate... if you have multiple geli encrypted partitions that all have the same passphrase, you will be required to enter that passphrase twice while booting -- once in gpt[zfs]boot, then again during kernel startup when the rest of the drives/partitions get tasted by geom. This is because APIs within the boot process got changed to pass keys instead of the passphrase itself from one stage of booting to the next, and the fallout of that is the key for the rootfs is available to the kernel for mountroot, but the passphrase is not available to the system when geom is probing all the devices, so you get prompted for it again. -- Ian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?398cae11ff6b81d0bc1dbdcd54f64eb97b2c812a.camel>