freebsd stable - Feb 2019 - Fwd: Serious ZFS Bootcode Problem (GPT NON-UEFI)

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.)

-- 
Karl Denninger
karl at denninger.net <mailto:karl at denninger.net>
/The Market Ticker/
/[S/MIME encrypted email preferred]/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4897 bytes
Desc: S/MIME Cryptographic Signature
URL:
<http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20190210/4a0de9e2/attachment.bin>

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