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="YES"
geli_da0_keyfile0_type="da0:geli_keyfile0"
geli_da0_keyfile0_name="/boot/keys/da0.key0"
I haven't tested, but suspect this wouldn't work:
geli_gpt/foo_keyfile0_load="YES"
geli_gpt/foo_keyfile0_type="gpt/foo:geli_keyfile0"
geli_gpt/foo_keyfile0_name="/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
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-geom
To unsubscribe, send any mail to "[email protected]"
