GELI file systems unusable after "glabel label" operations
rsmith at xs4all.nl
Sat Jan 16 09:31:31 UTC 2010
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 =
> >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.
... N-5 N-4 N-3 N-2 N-1 N
| | | | | | geli |glabel|
Nested geom devices are the only way to keep the metadata safe.
Hope this helps,
[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
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-questions/attachments/20100116/766eac54/attachment.pgp
More information about the freebsd-questions