GELI file systems unusable after "glabel label" operations

[Roland Smith]

On Sat, Jan 16, 2010 at 12:38:14AM -0600, Scott Bennett wrote:
> >2) Create the geli device /dev/daXsYP.eli, and then create a label on that,
> >   yielding /dev/label/bar. [not sure what the utility of this is, since the
> >   label will only appear after the geil provider has been attached]
> >
>      The important point here is that one of the above methods must be used
> *before* the file system is created and the data loaded into it.  Attempting
> either method *after* data are loaded will result in loss of the data.

Maybe not immediately, but since both the filesystem and geom can use the last
sector, there will be trouble. :-) The examples in the glabel manpage should
how to set up a label correctly.

>      Perhaps this provides a possible recovery method.  As you read it,
> would it be possible to build an altered version of geli(8) that would simply
> use the existing key file without generating a new one to do a "geli init"
> operation?  If so, it would certainly be worth my trouble to do that.

In theory it is possible, I guess. But the salt is 512 bytes long. So it can
have 2^512 different values. That is 1.340×10^154 different values, and you'd
have to test them all. And by testing I mean use the modified 'geli init' to
generate a key, and then try if the key works, i.e. check if the relevant
sector decrypted with that key yields a valid UFS2 superblock. Suppose you
wrote a program capable of testing 10^9 keys every second, which sounds like
quite alot to me. It would still be running for 2^512/1e9/(3600*24*365) =
4.25×10^137 years! So in practice, this is a hopeless task.

> >And I think that the proper way to nest geoms is too obvious (at least for =
> >the
> >developers/maintainers) to explicitly list in the handbook. If you know that
> >geoms store metadata in their last sector, the proper way to nest them is to
> >use the different devices for each geom "stage", so that each has their own
> >metadata sector.
> 
>      Well, it wasn't at all obvious to me, and reading the parts that mention
> metadata being written to the last sector suggests, if anything, that labeling
> and encryption are incompatible because both write to the "last sector", i.e.,
> to the *same* sector.  The idea of the "last sector" being different for the
> two operations is not at all apparent.

Well, it should be different, otherwise they overwrite the same sector. Ipso
facto you should nest providers...

Say you want to have a labeled, encrypted device on /dev/da0s1d. First, you
create the label;

    glabel label ‐v foo /dev/da0s1d

A device /dev/label/foo now appears. This device is one sector smaller than
/dev/da0s1d, because the last sector of /dev/da0s1d is used for the glabel
metadata. Now we want to create an encrypted device, so we do:

     geli init -l 256 /dev/label/foo
     geli attach /dev/label/foo

This will create /dev/label/foo.eli. Again, /dev/label/foo.eli is one sector
smaller than /dev/label/foo, because the last sector of /dev/label/foo
contains the geli metadata.

If one uses

    geli init -l 256 /dev/da0s1d
     geli attach /dev/da0s1d

this will create and attach /dev/da0s1d.eli, but /dev/label/foo will be destroyed,
because 'geli init' overwrites glabel's metadata!

Below I've tried to sketch the last sectors of the device, with the extents of
the geom-ed devices and the location of the metadata below.

-------------------------------------------------- /dev/da0s1d
  ...    N-5    N-4    N-3    N-2     N-1    N
|      |      |      |      |      | geli |glabel|
------------------------------------------ /dev/label/foo
----------------------------------- /dev/label/foo.eli

Nested geom devices are the only way to keep the metadata safe.

Hope this helps,

Roland
-- 
R.F.Smith                                   http://www.xs4all.nl/~rsmith/
[plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated]
pgp: 1A2B 477F 9970 BA3C 2914  B7CE 1277 EFB0 C321 A725 (KeyID: C321A725)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-questions/attachments/20100116/766eac54/attachment.pgp