Date: Sat, 5 Mar 2011 23:20:43 +0100 From: Terje Elde <terje@elde.net> To: freebsd-geom@freebsd.org Subject: Using both GELI and labels on bootdevices Message-ID: <FD6C05CF-57BF-4866-AEDE-ABE736354074@elde.net>
next in thread | raw e-mail | index | archive | help
Hi,
I'd like to use both GELI and GPT labels on boot devices. There are two =
reasons for this:
a) The usual benefits of labels, being able jump between AHCI and other =
drivers, being able to toss a drive in an enclose and use it just the =
same, etc, and
b) I find it comfortable to match the name of keyfiles to labels, =
rather than (possibly temporary) devicenames or something else.
Normal way of loading keyfiles at boot would be:
geli_da0_keyfile0_load=3D"YES"
geli_da0_keyfile0_type=3D"da0:geli_keyfile0"
geli_da0_keyfile0_name=3D"/boot/keys/da0.key0"
I haven't tested, but suspect this wouldn't work:
geli_gpt/foo_keyfile0_load=3D"YES"
geli_gpt/foo_keyfile0_type=3D"gpt/foo:geli_keyfile0"
geli_gpt/foo_keyfile0_name=3D"/boot/keys/foo.key"
So what I did was toss something like this in loader.rc:
load_geli -n 0 gpt/foo /boot/keys/foo.key
To be completely honest, I find the syntax way more comfortable as well.
And it also works quite well.
The downside is that since /dev/gpt/foo and /dev/da0 is the exact same =
device/partition, GELI will taste both, see the bootflag, and offer to =
pass it a phassphrase for both, while I only can (because the keyfile is =
only set for one) and want to enable one of them. This means I have to =
go through devicecount*password_tries failed attempts at mounting the =
devices before actually getting them mounted through the labels.
One possible solution to this would be to store a flag in GELIs metadata =
about a keyfile being used, and only offer it on boot if the keyfile has =
been loaded. I think that would be a bad idea for two reasons:
a) This would be similar for passphrase-only devices as well, and
b) It would leak the use of a keyfile, which would be bad.
Two variants of a solution I'd like though, are:
a) Being able to pass an include or exclude list or filter to GELI, =
restricting which devices are considered for attachment on boot,
b) Being able to pass a flag having GELI only consider =
devices/partitions directly or through labels or
a) seems like a workable option, while b) would make it impossible to =
mix and match, and I suppose it would break some of the modularity of =
GEOM that we all like so much
I haven't toyed too much with GEOMs internals yet, but if there's a way =
for GELI to cleanly check if a direct device has a label attached to it, =
then using a global flag to disable boot attach attempts from devices =
that also has labels could perhaps be a workable solution, though I =
suspect it might be considered a philosophy and bloat issue?
Any reason not to allow passing an include or exclude list or filter to =
GELI?
Just some thoughts, combining GELI and GPT labels carries a lot of =
potential for comfortable and adminfriendly encrypted devices, if it =
wasn't for this one little thing...
(please do point of if I've missed something obvious...)
Terje
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?FD6C05CF-57BF-4866-AEDE-ABE736354074>