freebsd stable - Apr 2021 - geli - is it better to partition then encrypt, or vice versa ?

So, am building a zpool on some encrypted discs - and what I have done 
is to partition the disc with GPT add a single big partition, and 
encrypt that. So the pool is on nda1p1.eli.

But I could, of course, encrypt the disc first, and then partition the 
encrypted disc, or indded just put the zpool directly onto it.

Just wondering what the general consensus is as to the best way to go 
here ... if there is one! :-) What do other people do ?

-pete.

I encrypt the whole disk and then add it to the pool. No need to partition it.
If I remember correctly zfs prefers unpartitioned disks.

\\Clay
> On 17 Apr 2021, at 21:54, Pete French <petefrench at ingresso.co.uk>
wrote:
> 
> ?So, am building a zpool on some encrypted discs - and what I have done is
to partition the disc with GPT add a single big partition, and encrypt that. So
the pool is on nda1p1.eli.
> 
> But I could, of course, encrypt the disc first, and then partition the
encrypted disc, or indded just put the zpool directly onto it.
> 
> Just wondering what the general consensus is as to the best way to go here
... if there is one! :-) What do other people do ?
> 
> -pete.
> _______________________________________________
> freebsd-stable at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscribe at
freebsd.org"

On Sat, Apr 17, 2021 at 1:53 PM Pete French <petefrench at ingresso.co.uk>
wrote:
> So, am building a zpool on some encrypted discs - and what I have done
> is to partition the disc with GPT add a single big partition, and
> encrypt that. So the pool is on nda1p1.eli.
>
> But I could, of course, encrypt the disc first, and then partition the
> encrypted disc, or indded just put the zpool directly onto it.
>
> Just wondering what the general consensus is as to the best way to go
> here ... if there is one! :-) What do other people do ?
>
> -pete.
>
The answer depends on why you want to partition in the first place.  What
do you intend to store on those disks besides ZFS?  If the answer is
nothing, then don't bother partitioning; just write ZFS over GELI over the
whole disk.

(Also, it's worth asking why you want GELI, now that FreeBSD 13 supports
ZFS native crypto.  ZFS native crypto on RAIDZ has substantially better
write performance than RAIDZ on GELI.  However, if you're paranoid, then
GELI does provide better security; ZFS native crypto is vulnerable to some
kinds of watermarking attacks.)

On 4/17/2021 15:52, Pete French wrote:
> So, am building a zpool on some encrypted discs - and what I have done 
> is to partition the disc with GPT add a single big partition, and 
> encrypt that. So the pool is on nda1p1.eli.
>
> But I could, of course, encrypt the disc first, and then partition the 
> encrypted disc, or indded just put the zpool directly onto it.
>
> Just wondering what the general consensus is as to the best way to go 
> here ... if there is one! :-) What do other people do ?
>
IMHO one reason to partition first (and the reason I do it) is to 
prevent "drive attachment point hopping" from causing an unwelcome 
surprise if/when there is a failure or if, for some reason, you plug a 
drive into a different machine at some point.? If you partition and 
label, then geli init and attach at "/dev/gpt/the-label" you now can 
label the drive carrier with that and irrespective of the slot or 
adapter that gets connected to on whatever machine it will be in the 
same place.? If it fails this also means (assuming you labeled the 
carrier) you know which carrier to yank and replace. Yanking the wrong 
drive can be an unpleasant surprise.

This also makes "geli groups" trivial in /etc/rc.conf for attachment
at
boot time irrespective of whether they physically come up in the same 
place (again typically yes, but in the case of a failure or you plug it 
into a different adapter.....)

-- 
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/20210417/02ef9a47/attachment.bin>