From owner-freebsd-geom@FreeBSD.ORG Sat Mar 5 22:20:46 2011 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1A4A2106564A for ; Sat, 5 Mar 2011 22:20:46 +0000 (UTC) (envelope-from terje@elde.net) Received: from keepquiet.net (keepquiet.net [IPv6:2a01:4f8:130:84c1::deaf:babe]) by mx1.freebsd.org (Postfix) with ESMTP id D1F988FC08 for ; Sat, 5 Mar 2011 22:20:45 +0000 (UTC) Received: from [10.130.10.194] (cm-84.209.214.220.getinternet.no [84.209.214.220]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) (Authenticated sender: terje@elde.net) by keepquiet.net (Postfix) with ESMTPSA id C4CCE2E128 for ; Sat, 5 Mar 2011 23:20:44 +0100 (CET) From: Terje Elde Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Sat, 5 Mar 2011 23:20:43 +0100 Message-Id: To: freebsd-geom@freebsd.org Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) Subject: Using both GELI and labels on bootdevices X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Mar 2011 22:20:46 -0000 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