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)
pgpWo80zoDjvn.pgp
Description: PGP signature