Date: Fri, 22 Jan 2010 03:08:00 -0600 (CST) From: Scott Bennett <bennett@cs.niu.edu> To: rsmith@xs4all.nl Cc: freebsd-questions@freebsd.org Subject: Re: GELI file systems unusable after "glabel label" operations Message-ID: <201001220908.o0M980UG017425@mp.cs.niu.edu>
next in thread | raw e-mail | index | archive | help
On Sat, 16 Jan 2010 10:31:22 +0100 Roland Smith <rsmith@xs4all.nl>
wrote:
>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
Why is that stored in the last sector of the device, rather than in the
key file? What is the purpose of the key file if not to hold that type of
information?
>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...
...unless, of course, the two had been designed to use different parts
of the "last sector" for their own purposes, but also to avoid damaging the
other's data when altering their own.
>
>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.
>
Thanks for the explanation. However, if the key information is stored
in the "last sector" rather than in the key file, then I guess I'm totally
confused about how GELI works.
Scott Bennett, Comm. ASMELG, CFIAG
**********************************************************************
* Internet: bennett at cs.niu.edu *
*--------------------------------------------------------------------*
* "A well regulated and disciplined militia, is at all times a good *
* objection to the introduction of that bane of all free governments *
* -- a standing army." *
* -- Gov. John Hancock, New York Journal, 28 January 1790 *
**********************************************************************
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201001220908.o0M980UG017425>