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>