Date: Sat, 16 Jan 2010 10:31:22 +0100 From: Roland Smith <rsmith@xs4all.nl> To: Scott Bennett <bennett@cs.niu.edu> Cc: freebsd-questions@freebsd.org Subject: Re: GELI file systems unusable after "glabel label" operations Message-ID: <20100116093122.GA64132@slackbox.xs4all.nl> In-Reply-To: <201001160638.o0G6cEj8029478@mp.cs.niu.edu> References: <201001160638.o0G6cEj8029478@mp.cs.niu.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
--M9NhX3UHpAaciwkO Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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 th= at, > > 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 us= ed > *before* the file system is created and the data loaded into it. Attempt= ing > 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 l= ast 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 si= mply > 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=C3=9710^154 different values, an= d 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) =3D 4.25=C3=9710^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 f= or =3D > >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 i= s to > >use the different devices for each geom "stage", so that each has their = own > >metadata sector. >=20 > Well, it wasn't at all obvious to me, and reading the parts that men= tion > metadata being written to the last sector suggests, if anything, that lab= eling > 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 =E2=80=90v 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 des= troyed, 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 --=20 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) --M9NhX3UHpAaciwkO Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEARECAAYFAktRh2oACgkQEnfvsMMhpyUabQCfZsu9sxI5tguPiZhyM8BE9MiH zW8AoIcHknnazQwO2SkopyWWxgn1TL6R =a1Ye -----END PGP SIGNATURE----- --M9NhX3UHpAaciwkO--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20100116093122.GA64132>