UFS, GPT Label and GELI

[markfisher]

Hi

I'm trying to partition and encrypt my SSD for my new desktop with gpart(8) and geli(8) using gpt and ufs. I'm using FreeBSD 10.

1. I've seen others create geli(8) partition of the entire hard drive first and then partition it using gpart(8) for /, /tmp, /var, ... I just want to know what is the advantage of this setup over partition the hard drive first and then encrypt each partition?
   
   Link: https://forums.freebsd.org/viewtopic.php?&t=29652
   
2. I've read online that inside the /boot/loader.conf for specifying geli(8) key location, I can use gpt labels, for example:
   

   geli_gpt-label_keyfile0_load="YES"
   geli_gpt-label_keyfile0_type="gpt/gpt-label:geli_keyfile0"
   geli_gpt-label_keyfile0_name="/boot/geli.key"
   
   vfs.root.mountfrom="ufs:/dev/gpt/gpt-label.eli"

   Link: http://lists.freebsd.org/pipermail/freebsd-geom/2012-May/005243.html
   
   I did this on a virtual machine and looked at dmesg(8) and I found out:
   

   ...
   GEOM_ELI: Found no key files in loader.conf for ada0p1
   GEOM_ELI: Found no key files in loader.conf for ada0p2
   ...
   GEOM_ELI: Found no key files in loader.conf for diskid/DISK-ID1
   GEOM_ELI: Found no key files in loader.conf for diskid/DISK-ID2
   ...
   GEOM_ELI: Device gpt/gpt-label.eli created.
   GEOM_ELI: Encryption: ...
   ...

   Is this a normal way of geli(8) trying to find a key by looking at partition name first and then DISK-ID and at the end looks at gpt-label?

Thanks in advance.

 

[asteriskRoss]

I've seen others create geli(8) partition of the entire hard drive first and then partition it using gpart(8) for /, /tmp, /var, ... I just want to know what is the advantage of this setup over partition the hard drive first and then encrypt each partition?

You certainly could create multiple GELI devices if you wanted. I have used that approach by necessity when I needed one of my filesystems on a different physical disk. Managing fewer GELI devices means fewer keys and/or pass phrases and fewer lines in configuration files. You would need to do some testing to see whether there is a significant performance difference. I believe that GELI can now batch writes, which could give a performance gain; I imagine that batching would not be possible if the write was split across multiple GELI providers (that is, if you had encrypted partitions separately).

Is this a normal way of geli(8) trying to find a key by looking at partition name first and then DISK-ID and at the end looks at gpt-label?

I have seen the same behaviour, though not found it documented in the geli(8) man page. I also wanted to use GPT labels to avoid the risk of my disks being renumbered, but resorted to using device labels (like ada0p1 in your example) for any GELI devices that need to be mounted before the root partition is mounted. You could dig through the source code to confirm and consider submitting a request (on Bugzilla) for a change. A configuration option in /boot/loader.conf to specify the search order could be a solution. I found that GPT labels worked fine for GELI devices mounted after the root partition that I configured in /etc/rc.conf.