From owner-freebsd-geom@FreeBSD.ORG Sun Sep 28 13:04:01 2014 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4D31B996 for ; Sun, 28 Sep 2014 13:04:01 +0000 (UTC) Received: from mail.dawidek.net (garage.dawidek.net [91.121.88.72]) by mx1.freebsd.org (Postfix) with ESMTP id 17440F1F for ; Sun, 28 Sep 2014 13:04:00 +0000 (UTC) Received: from localhost (unknown [195.24.50.132]) by mail.dawidek.net (Postfix) with ESMTPSA id 028443AA; Sun, 28 Sep 2014 15:03:59 +0200 (CEST) Date: Sun, 28 Sep 2014 15:05:47 +0200 From: Pawel Jakub Dawidek To: Karl Pielorz Subject: Re: GELI created on a GPT labelled partition doesn't work 2nd time around... Message-ID: <20140928130547.GD1620@garage.freebsd.pl> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-OS: FreeBSD 11.0-CURRENT amd64 User-Agent: Mutt/1.5.22 (2013-10-16) Cc: freebsd-geom@freebsd.org X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Sep 2014 13:04:01 -0000 On Mon, Sep 15, 2014 at 09:50:49PM +0100, Karl Pielorz wrote: > > Hi, > > I just installed a FreeBSD 10.0-STABLE system where I: > > - Created a GPT partition on da0, with a label of, say 'abcdef' > > - Did a 'geli init / geli attach' on that GPT label, i.e. > geli init -s 4096 -K abcdef.key -l 256 -P /dev/gpt/abcdef > > - Attached to that: > geli attach -k abcdef.key -p /dev/gpt/abcdef > > This correctly gives me '/dev/gpt/abcdef.eli' The *first* time I did this I > then did: > > gpart create -s gpt /dev/gpt/abcdef.eli > > Which worked - and then went on to create a partition and use it for ZFS. > > After a while I decided to re-do the disks (switching out '-l 256' to use > the default key size). > > But now I'm stuck - I can: > > - Create a GPT partition with label on the underlying device, e.g. as > before, create a GPT partition on da0 with a label of 'abcdef' > > - 'geli init' and 'geli attach' to that label - and I get a corresponding > .eli device - e.g. '/dev/gpt/abcdef.eli' - but I can't do anything with > that device now: > > gpart create -s gpt /dev/gpt/abcdef.eli > gpart: provider: Device not configured > > I can't read, or write to it either: > > dd if=/dev/gpt/abcdef.eli | strings > dd: /dev/gpt/abcdef.eli: Invalid argument > 0+0 records in > 0+0 records out > 0 bytes transferred in 0.000059 secs (0 bytes/sec) Could you provide the output of: # diskinfo -v /dev/gpt/abcdef.eli > No errors are output anywhere - and the geli 'attach' to the first label > succeeds (and I get a corresponding .eli device) - but it doesn't "work". > > Any ideas? > > I know this worked once (when the disks were 'new') - as I still have it in > my scroll back. I've tried all incantations of 'gpart destroy' and 'geli > clean' - but no matter what I do (including rebooting), I can't get this to > work again. > > If I use geli on the raw da0 device - I end up with 'da0.eli' - and I *can* > access / GPT partition that, but it no longer works applying GELI to a > label (but, like I said - I was able to do this once!) -- Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://mobter.com From owner-freebsd-geom@FreeBSD.ORG Sun Sep 28 13:13:32 2014 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 00D7BC98 for ; Sun, 28 Sep 2014 13:13:31 +0000 (UTC) Received: from mail.dawidek.net (garage.dawidek.net [91.121.88.72]) by mx1.freebsd.org (Postfix) with ESMTP id 8134DC for ; Sun, 28 Sep 2014 13:13:30 +0000 (UTC) Received: from localhost (unknown [195.24.50.132]) by mail.dawidek.net (Postfix) with ESMTPSA id A00FC3B2; Sun, 28 Sep 2014 15:13:29 +0200 (CEST) Date: Sun, 28 Sep 2014 15:15:16 +0200 From: Pawel Jakub Dawidek To: Karl Denninger Subject: Re: Attempt to add multiple device attachment to "geli attach" Message-ID: <20140928131516.GE1620@garage.freebsd.pl> References: <54076871.5010405@denninger.net> <54076CFE.5010308@denninger.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54076CFE.5010308@denninger.net> X-OS: FreeBSD 11.0-CURRENT amd64 User-Agent: Mutt/1.5.22 (2013-10-16) Cc: freebsd-geom@freebsd.org X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Sep 2014 13:13:32 -0000 Hi Karl, I like the idea. I myself currently use a script which obtains the passphrase: echo -n "Enter passphrase: " stty -echo read pass stty echo echo And then iterates over all providers I want to attach and uses -j option to provide the key for the attach subcommand. To make it integral part of geli and to be complete we would need to add support for multiple providers to the following subcommands: init, attach, onetime, setkey, delkey and resume. On Wed, Sep 03, 2014 at 02:33:18PM -0500, Karl Denninger wrote: > Never mind... I know what I missed -- the key generation that is passed > in is dependent on the metadata read from the userspace. > > More work to do here.... will have to pass a separate key structure for > each disk and it will also require some more work in the userspace > command area so it doesn't prompt a second time for a password. > > I'll post the completed patch set once I have it if people here think it > would be interesting. > > On 9/3/2014 14:13, Karl Denninger wrote: > > I'm aware of the potential issues here in terms of keying risks, but > > there are plenty of reasons to support this capability with the > > largest one being ZFS volumes that you wish to run encrypted. > > > > Take the following: > > > > label/pool0 > > label/pool1 > > label/pool2 > > label/pool3 > > > > (all relative to /dev, of course) > > > > These are all gpt partitions on different devices (typically full > > disks less labels.) You "geli init" them and then attach them and > > build a raidz2 pool on that. > > > > OK, now the system is rebooted. If you use the rc.conf file's option > > to request geli passwords during the boot you had better not screw up > > three times for only ONE of these volumes or the pool WILL come up > > degraded! Needless to say that's not nice. It's even worse if it's a > > raidz pool, you blow it, you reattach that disk and allow it to > > resilver *and take a disk error on the remaining drives during the > > resilver* -- now you're completely hosed. > > > > So, here's the idea -- if you use the same password and/or keyfile for > > ALL of the volumes then either they ALL mount (if you get it right) or > > NONE of them mount (if you get it wrong.) Now the pool won't import > > if you get it wrong and you're safe from the risk of taking a forced > > resilver and potential data loss. > > > > The geom subclass command has a simple "nargs" test (must be "1") in > > the attach command; I replaced that with "nargs < 1" for the error > > case. Now I can pass multiple devices to the kernel's geom handler > > and they get passed to the kernel ctl handler. > > > > The following patch should, I believe, work -- but it doesn't. The > > first disk attaches but the second one that was init'd with the same > > passphrase fails. > > > > As near as I can tell the key components are not picked up off the > > metadata until the geom driver gets ahold of it -- and thus the second > > decryption attempt should work since on the second iteration through > > the code grabs the key parameters off the request a second time. > > > > But I'm obviously missing something because the second volume returns > > "Wrong key for ...." > > > > Ideas? > > > > Patch is relative to /usr/src/sys/geom/eli: > > > > *** g_eli_ctl.c.orig Wed Sep 3 13:11:52 2014 > > --- g_eli_ctl.c Wed Sep 3 13:19:15 2014 > > *************** > > *** 60,65 **** > > --- 60,68 ---- > > int *nargs, *detach, *readonly; > > int keysize, error; > > u_int nkey; > > + char param[16]; > > + > > + u_int count; > > > > g_topology_assert(); > > > > *************** > > *** 68,74 **** > > gctl_error(req, "No '%s' argument.", "nargs"); > > return; > > } > > ! if (*nargs != 1) { > > gctl_error(req, "Invalid number of arguments."); > > return; > > } > > --- 71,77 ---- > > gctl_error(req, "No '%s' argument.", "nargs"); > > return; > > } > > ! if (*nargs < 1) { > > gctl_error(req, "Invalid number of arguments."); > > return; > > } > > *************** > > *** 84,147 **** > > gctl_error(req, "No '%s' argument.", "readonly"); > > return; > > } > > > > ! name = gctl_get_asciiparam(req, "arg0"); > > ! if (name == NULL) { > > ! gctl_error(req, "No 'arg%u' argument.", 0); > > ! return; > > ! } > > ! if (strncmp(name, "/dev/", strlen("/dev/")) == 0) > > ! name += strlen("/dev/"); > > ! pp = g_provider_by_name(name); > > ! if (pp == NULL) { > > ! gctl_error(req, "Provider %s is invalid.", name); > > ! return; > > ! } > > ! error = g_eli_read_metadata(mp, pp, &md); > > ! if (error != 0) { > > ! gctl_error(req, "Cannot read metadata from %s (error=%d).", > > ! name, error); > > ! return; > > ! } > > ! if (md.md_keys == 0x00) { > > ! bzero(&md, sizeof(md)); > > ! gctl_error(req, "No valid keys on %s.", pp->name); > > ! return; > > ! } > > ! > > ! key = gctl_get_param(req, "key", &keysize); > > ! if (key == NULL || keysize != G_ELI_USERKEYLEN) { > > ! bzero(&md, sizeof(md)); > > ! gctl_error(req, "No '%s' argument.", "key"); > > ! return; > > ! } > > ! > > ! error = g_eli_mkey_decrypt(&md, key, mkey, &nkey); > > ! bzero(key, keysize); > > ! if (error == -1) { > > ! bzero(&md, sizeof(md)); > > ! gctl_error(req, "Wrong key for %s.", pp->name); > > ! return; > > ! } else if (error > 0) { > > ! bzero(&md, sizeof(md)); > > ! gctl_error(req, "Cannot decrypt Master Key for %s (error=%d).", > > ! pp->name, error); > > ! return; > > ! } > > ! G_ELI_DEBUG(1, "Using Master Key %u for %s.", nkey, pp->name); > > ! > > ! if (*detach && *readonly) { > > bzero(&md, sizeof(md)); > > - gctl_error(req, "Options -d and -r are mutually exclusive."); > > - return; > > } > > - if (*detach) > > - md.md_flags |= G_ELI_FLAG_WO_DETACH; > > - if (*readonly) > > - md.md_flags |= G_ELI_FLAG_RO; > > - g_eli_create(req, mp, pp, &md, mkey, nkey); > > - bzero(mkey, sizeof(mkey)); > > - bzero(&md, sizeof(md)); > > } > > > > static struct g_eli_softc * > > --- 87,152 ---- > > gctl_error(req, "No '%s' argument.", "readonly"); > > return; > > } > > + for (count = 0; count < *nargs; count++) { > > + snprintf(param, sizeof(param), "arg%d", count); > > + name = gctl_get_asciiparam(req, param); > > + if (name == NULL) { > > + gctl_error(req, "No 'arg%u' argument.", count); > > + return; > > + } > > + if (strncmp(name, "/dev/", strlen("/dev/")) == 0) > > + name += strlen("/dev/"); > > + pp = g_provider_by_name(name); > > + if (pp == NULL) { > > + gctl_error(req, "Provider %s is invalid.", name); > > + return; > > + } > > + error = g_eli_read_metadata(mp, pp, &md); > > + if (error != 0) { > > + gctl_error(req, "Cannot read metadata from %s (error=%d).", > > + name, error); > > + return; > > + } > > + if (md.md_keys == 0x00) { > > + bzero(&md, sizeof(md)); > > + gctl_error(req, "No valid keys on %s.", pp->name); > > + return; > > + } > > + > > + key = gctl_get_param(req, "key", &keysize); > > + if (key == NULL || keysize != G_ELI_USERKEYLEN) { > > + bzero(&md, sizeof(md)); > > + gctl_error(req, "No '%s' argument.", "key"); > > + return; > > + } > > > > ! error = g_eli_mkey_decrypt(&md, key, mkey, &nkey); > > ! bzero(key, keysize); > > ! if (error == -1) { > > ! bzero(&md, sizeof(md)); > > ! gctl_error(req, "Wrong key for %s.", pp->name); > > ! return; > > ! } else if (error > 0) { > > ! bzero(&md, sizeof(md)); > > ! gctl_error(req, "Cannot decrypt Master Key for %s > > (error=%d).", > > ! pp->name, error); > > ! return; > > ! } > > ! G_ELI_DEBUG(1, "Using Master Key %u for %s.", nkey, pp->name); > > ! > > ! if (*detach && *readonly) { > > ! bzero(&md, sizeof(md)); > > ! gctl_error(req, "Options -d and -r are mutually > > exclusive."); > > ! return; > > ! } > > ! if (*detach) > > ! md.md_flags |= G_ELI_FLAG_WO_DETACH; > > ! if (*readonly) > > ! md.md_flags |= G_ELI_FLAG_RO; > > ! g_eli_create(req, mp, pp, &md, mkey, nkey); > > ! bzero(mkey, sizeof(mkey)); > > bzero(&md, sizeof(md)); > > } > > } > > > > static struct g_eli_softc * > > > > > > ------------------------ > > > > -- > -- Karl > karl@denninger.net > > -- Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://mobter.com From owner-freebsd-geom@FreeBSD.ORG Sun Sep 28 14:24:11 2014 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 29802886 for ; Sun, 28 Sep 2014 14:24:11 +0000 (UTC) Received: from fs.denninger.net (wsip-70-169-168-7.pn.at.cox.net [70.169.168.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "NewFS.denninger.net", Issuer "NewFS.denninger.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id C190984B for ; Sun, 28 Sep 2014 14:24:09 +0000 (UTC) Received: from [192.168.1.40] (localhost [127.0.0.1]) by fs.denninger.net (8.14.9/8.14.8) with ESMTP id s8SENw1P096668 for ; Sun, 28 Sep 2014 09:23:58 -0500 (CDT) (envelope-from karl@denninger.net) Received: from [192.168.1.40] (TLS/SSL) [192.168.1.40] by Spamblock-sys (LOCAL/AUTH); Sun Sep 28 09:23:58 2014 Message-ID: <542819DE.3050709@denninger.net> Date: Sun, 28 Sep 2014 09:23:26 -0500 From: Karl Denninger User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 MIME-Version: 1.0 To: freebsd-geom@freebsd.org Subject: Re: Attempt to add multiple device attachment to "geli attach" References: <54076871.5010405@denninger.net> <54076CFE.5010308@denninger.net> <20140928131516.GE1620@garage.freebsd.pl> In-Reply-To: <20140928131516.GE1620@garage.freebsd.pl> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms080506060502070701000604" X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Sep 2014 14:24:11 -0000 This is a cryptographically signed message in MIME format. --------------ms080506060502070701000604 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Yes, I wrote a script to handle it in the meantime as well. The way the geli command is architected it is rather difficult to do properly in the code itself.... On 9/28/2014 8:15 AM, Pawel Jakub Dawidek wrote: > Hi Karl, > > I like the idea. I myself currently use a script which obtains the > passphrase: > > echo -n "Enter passphrase: " > stty -echo > read pass > stty echo > echo > > And then iterates over all providers I want to attach and uses -j optio= n > to provide the key for the attach subcommand. > > To make it integral part of geli and to be complete we would need to ad= d > support for multiple providers to the following subcommands: init, > attach, onetime, setkey, delkey and resume. > > On Wed, Sep 03, 2014 at 02:33:18PM -0500, Karl Denninger wrote: >> Never mind... I know what I missed -- the key generation that is passe= d=20 >> in is dependent on the metadata read from the userspace. >> >> More work to do here.... will have to pass a separate key structure fo= r=20 >> each disk and it will also require some more work in the userspace=20 >> command area so it doesn't prompt a second time for a password. >> >> I'll post the completed patch set once I have it if people here think = it=20 >> would be interesting. >> >> On 9/3/2014 14:13, Karl Denninger wrote: >>> I'm aware of the potential issues here in terms of keying risks, but = >>> there are plenty of reasons to support this capability with the=20 >>> largest one being ZFS volumes that you wish to run encrypted. >>> >>> Take the following: >>> >>> label/pool0 >>> label/pool1 >>> label/pool2 >>> label/pool3 >>> >>> (all relative to /dev, of course) >>> >>> These are all gpt partitions on different devices (typically full=20 >>> disks less labels.) You "geli init" them and then attach them and=20 >>> build a raidz2 pool on that. >>> >>> OK, now the system is rebooted. If you use the rc.conf file's option= =20 >>> to request geli passwords during the boot you had better not screw up= =20 >>> three times for only ONE of these volumes or the pool WILL come up=20 >>> degraded! Needless to say that's not nice. It's even worse if it's = a=20 >>> raidz pool, you blow it, you reattach that disk and allow it to=20 >>> resilver *and take a disk error on the remaining drives during the=20 >>> resilver* -- now you're completely hosed. >>> >>> So, here's the idea -- if you use the same password and/or keyfile fo= r=20 >>> ALL of the volumes then either they ALL mount (if you get it right) o= r=20 >>> NONE of them mount (if you get it wrong.) Now the pool won't import = >>> if you get it wrong and you're safe from the risk of taking a forced = >>> resilver and potential data loss. >>> >>> The geom subclass command has a simple "nargs" test (must be "1") in = >>> the attach command; I replaced that with "nargs < 1" for the error=20 >>> case. Now I can pass multiple devices to the kernel's geom handler=20 >>> and they get passed to the kernel ctl handler. >>> >>> The following patch should, I believe, work -- but it doesn't. The=20 >>> first disk attaches but the second one that was init'd with the same = >>> passphrase fails. >>> >>> As near as I can tell the key components are not picked up off the=20 >>> metadata until the geom driver gets ahold of it -- and thus the secon= d=20 >>> decryption attempt should work since on the second iteration through = >>> the code grabs the key parameters off the request a second time. >>> >>> But I'm obviously missing something because the second volume returns= =20 >>> "Wrong key for ...." >>> >>> Ideas? >>> >>> Patch is relative to /usr/src/sys/geom/eli: >>> >>> *** g_eli_ctl.c.orig Wed Sep 3 13:11:52 2014 >>> --- g_eli_ctl.c Wed Sep 3 13:19:15 2014 >>> *************** >>> *** 60,65 **** >>> --- 60,68 ---- >>> int *nargs, *detach, *readonly; >>> int keysize, error; >>> u_int nkey; >>> + char param[16]; >>> + >>> + u_int count; >>> >>> g_topology_assert(); >>> >>> *************** >>> *** 68,74 **** >>> gctl_error(req, "No '%s' argument.", "nargs"); >>> return; >>> } >>> ! if (*nargs !=3D 1) { >>> gctl_error(req, "Invalid number of arguments."); >>> return; >>> } >>> --- 71,77 ---- >>> gctl_error(req, "No '%s' argument.", "nargs"); >>> return; >>> } >>> ! if (*nargs < 1) { >>> gctl_error(req, "Invalid number of arguments."); >>> return; >>> } >>> *************** >>> *** 84,147 **** >>> gctl_error(req, "No '%s' argument.", "readonly"); >>> return; >>> } >>> >>> ! name =3D gctl_get_asciiparam(req, "arg0"); >>> ! if (name =3D=3D NULL) { >>> ! gctl_error(req, "No 'arg%u' argument.", 0); >>> ! return; >>> ! } >>> ! if (strncmp(name, "/dev/", strlen("/dev/")) =3D=3D 0) >>> ! name +=3D strlen("/dev/"); >>> ! pp =3D g_provider_by_name(name); >>> ! if (pp =3D=3D NULL) { >>> ! gctl_error(req, "Provider %s is invalid.", name); >>> ! return; >>> ! } >>> ! error =3D g_eli_read_metadata(mp, pp, &md); >>> ! if (error !=3D 0) { >>> ! gctl_error(req, "Cannot read metadata from %s (error=3D%d).= ", >>> ! name, error); >>> ! return; >>> ! } >>> ! if (md.md_keys =3D=3D 0x00) { >>> ! bzero(&md, sizeof(md)); >>> ! gctl_error(req, "No valid keys on %s.", pp->name); >>> ! return; >>> ! } >>> ! >>> ! key =3D gctl_get_param(req, "key", &keysize); >>> ! if (key =3D=3D NULL || keysize !=3D G_ELI_USERKEYLEN) { >>> ! bzero(&md, sizeof(md)); >>> ! gctl_error(req, "No '%s' argument.", "key"); >>> ! return; >>> ! } >>> ! >>> ! error =3D g_eli_mkey_decrypt(&md, key, mkey, &nkey); >>> ! bzero(key, keysize); >>> ! if (error =3D=3D -1) { >>> ! bzero(&md, sizeof(md)); >>> ! gctl_error(req, "Wrong key for %s.", pp->name); >>> ! return; >>> ! } else if (error > 0) { >>> ! bzero(&md, sizeof(md)); >>> ! gctl_error(req, "Cannot decrypt Master Key for %s (error=3D= %d).", >>> ! pp->name, error); >>> ! return; >>> ! } >>> ! G_ELI_DEBUG(1, "Using Master Key %u for %s.", nkey, pp->name); >>> ! >>> ! if (*detach && *readonly) { >>> bzero(&md, sizeof(md)); >>> - gctl_error(req, "Options -d and -r are mutually exclusive."= ); >>> - return; >>> } >>> - if (*detach) >>> - md.md_flags |=3D G_ELI_FLAG_WO_DETACH; >>> - if (*readonly) >>> - md.md_flags |=3D G_ELI_FLAG_RO; >>> - g_eli_create(req, mp, pp, &md, mkey, nkey); >>> - bzero(mkey, sizeof(mkey)); >>> - bzero(&md, sizeof(md)); >>> } >>> >>> static struct g_eli_softc * >>> --- 87,152 ---- >>> gctl_error(req, "No '%s' argument.", "readonly"); >>> return; >>> } >>> + for (count =3D 0; count < *nargs; count++) { >>> + snprintf(param, sizeof(param), "arg%d", count); >>> + name =3D gctl_get_asciiparam(req, param); >>> + if (name =3D=3D NULL) { >>> + gctl_error(req, "No 'arg%u' argument.", count); >>> + return; >>> + } >>> + if (strncmp(name, "/dev/", strlen("/dev/")) =3D=3D 0) >>> + name +=3D strlen("/dev/"); >>> + pp =3D g_provider_by_name(name); >>> + if (pp =3D=3D NULL) { >>> + gctl_error(req, "Provider %s is invalid.", name); >>> + return; >>> + } >>> + error =3D g_eli_read_metadata(mp, pp, &md); >>> + if (error !=3D 0) { >>> + gctl_error(req, "Cannot read metadata from %s (error=3D= %d).", >>> + name, error); >>> + return; >>> + } >>> + if (md.md_keys =3D=3D 0x00) { >>> + bzero(&md, sizeof(md)); >>> + gctl_error(req, "No valid keys on %s.", pp->name); >>> + return; >>> + } >>> + >>> + key =3D gctl_get_param(req, "key", &keysize); >>> + if (key =3D=3D NULL || keysize !=3D G_ELI_USERKEYLEN) { >>> + bzero(&md, sizeof(md)); >>> + gctl_error(req, "No '%s' argument.", "key"); >>> + return; >>> + } >>> >>> ! error =3D g_eli_mkey_decrypt(&md, key, mkey, &nkey); >>> ! bzero(key, keysize); >>> ! if (error =3D=3D -1) { >>> ! bzero(&md, sizeof(md)); >>> ! gctl_error(req, "Wrong key for %s.", pp->name); >>> ! return; >>> ! } else if (error > 0) { >>> ! bzero(&md, sizeof(md)); >>> ! gctl_error(req, "Cannot decrypt Master Key for %s=20 >>> (error=3D%d).", >>> ! pp->name, error); >>> ! return; >>> ! } >>> ! G_ELI_DEBUG(1, "Using Master Key %u for %s.", nkey, pp->nam= e); >>> ! >>> ! if (*detach && *readonly) { >>> ! bzero(&md, sizeof(md)); >>> ! gctl_error(req, "Options -d and -r are mutually=20 >>> exclusive."); >>> ! return; >>> ! } >>> ! if (*detach) >>> ! md.md_flags |=3D G_ELI_FLAG_WO_DETACH; >>> ! if (*readonly) >>> ! md.md_flags |=3D G_ELI_FLAG_RO; >>> ! g_eli_create(req, mp, pp, &md, mkey, nkey); >>> ! bzero(mkey, sizeof(mkey)); >>> bzero(&md, sizeof(md)); >>> } >>> } >>> >>> static struct g_eli_softc * >>> >>> >>> ------------------------ >>> >> --=20 >> -- Karl >> karl@denninger.net >> >> > > --=20 Karl Denninger karl@denninger.net /The Market Ticker/ --------------ms080506060502070701000604 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFTzCC BUswggQzoAMCAQICAQgwDQYJKoZIhvcNAQEFBQAwgZ0xCzAJBgNVBAYTAlVTMRAwDgYDVQQI EwdGbG9yaWRhMRIwEAYDVQQHEwlOaWNldmlsbGUxGTAXBgNVBAoTEEN1ZGEgU3lzdGVtcyBM TEMxHDAaBgNVBAMTE0N1ZGEgU3lzdGVtcyBMTEMgQ0ExLzAtBgkqhkiG9w0BCQEWIGN1c3Rv bWVyLXNlcnZpY2VAY3VkYXN5c3RlbXMubmV0MB4XDTEzMDgyNDE5MDM0NFoXDTE4MDgyMzE5 MDM0NFowWzELMAkGA1UEBhMCVVMxEDAOBgNVBAgTB0Zsb3JpZGExFzAVBgNVBAMTDkthcmwg RGVubmluZ2VyMSEwHwYJKoZIhvcNAQkBFhJrYXJsQGRlbm5pbmdlci5uZXQwggIiMA0GCSqG SIb3DQEBAQUAA4ICDwAwggIKAoICAQC5n2KBrBmG22nVntVdvgKCB9UcnapNThrW1L+dq6th d9l4mj+qYMUpJ+8I0rTbY1dn21IXQBoBQmy8t1doKwmTdQ59F0FwZEPt/fGbRgBKVt3Quf6W 6n7kRk9MG6gdD7V9vPpFV41e+5MWYtqGWY3ScDP8SyYLjL/Xgr+5KFKkDfuubK8DeNqdLniV jHo/vqmIgO+6NgzPGPgmbutzFQXlxUqjiNAAKzF2+Tkddi+WKABrcc/EqnBb0X8GdqcIamO5 SyVmuM+7Zdns7D9pcV16zMMQ8LfNFQCDvbCuuQKMDg2F22x5ekYXpwjqTyfjcHBkWC8vFNoY 5aFMdyiN/Kkz0/kduP2ekYOgkRqcShfLEcG9SQ4LQZgqjMpTjSOGzBr3tOvVn5LkSJSHW2Z8 Q0dxSkvFG2/lsOWFbwQeeZSaBi5vRZCYCOf5tRd1+E93FyQfpt4vsrXshIAk7IK7f0qXvxP4 GDli5PKIEubD2Bn+gp3vB/DkfKySh5NBHVB+OPCoXRUWBkQxme65wBO02OZZt0k8Iq0i4Rci WV6z+lQHqDKtaVGgMsHn6PoeYhjf5Al5SP+U3imTjF2aCca1iDB5JOccX04MNljvifXgcbJN nkMgrzmm1ZgJ1PLur/ADWPlnz45quOhHg1TfUCLfI/DzgG7Z6u+oy4siQuFr9QT0MQIDAQAB o4HWMIHTMAkGA1UdEwQCMAAwEQYJYIZIAYb4QgEBBAQDAgWgMAsGA1UdDwQEAwIF4DAsBglg hkgBhvhCAQ0EHxYdT3BlblNTTCBHZW5lcmF0ZWQgQ2VydGlmaWNhdGUwHQYDVR0OBBYEFHw4 +LnuALyLA5Cgy7T5ZAX1WzKPMB8GA1UdIwQYMBaAFF3U3hpBZq40HB5VM7B44/gmXiI0MDgG CWCGSAGG+EIBAwQrFilodHRwczovL2N1ZGFzeXN0ZW1zLm5ldDoxMTQ0My9yZXZva2VkLmNy bDANBgkqhkiG9w0BAQUFAAOCAQEAZ0L4tQbBd0hd4wuw/YVqEBDDXJ54q2AoqQAmsOlnoxLO 31ehM/LvrTIP4yK2u1VmXtUumQ4Ao15JFM+xmwqtEGsh70RRrfVBAGd7KOZ3GB39FP2TgN/c L5fJKVxOqvEnW6cL9QtvUlcM3hXg8kDv60OB+LIcSE/P3/s+0tEpWPjxm3LHVE7JmPbZIcJ1 YMoZvHh0NSjY5D0HZlwtbDO7pDz9sZf1QEOgjH828fhtborkaHaUI46pmrMjiBnY6ujXMcWD pxtikki0zY22nrxfTs5xDWGxyrc/cmucjxClJF6+OYVUSaZhiiHfa9Pr+41okLgsRB0AmNwE f6ItY3TI8DGCBQowggUGAgEBMIGjMIGdMQswCQYDVQQGEwJVUzEQMA4GA1UECBMHRmxvcmlk YTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3RlbXMgTExDMRwwGgYD VQQDExNDdWRhIFN5c3RlbXMgTExDIENBMS8wLQYJKoZIhvcNAQkBFiBjdXN0b21lci1zZXJ2 aWNlQGN1ZGFzeXN0ZW1zLm5ldAIBCDAJBgUrDgMCGgUAoIICOzAYBgkqhkiG9w0BCQMxCwYJ KoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNDA5MjgxNDIzMjZaMCMGCSqGSIb3DQEJBDEW BBRwVlMjAl6HeYi2KmEab3VQKnfjJzBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjAL BglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFA MAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIG0BgkrBgEEAYI3EAQxgaYwgaMwgZ0xCzAJBgNV BAYTAlVTMRAwDgYDVQQIEwdGbG9yaWRhMRIwEAYDVQQHEwlOaWNldmlsbGUxGTAXBgNVBAoT EEN1ZGEgU3lzdGVtcyBMTEMxHDAaBgNVBAMTE0N1ZGEgU3lzdGVtcyBMTEMgQ0ExLzAtBgkq hkiG9w0BCQEWIGN1c3RvbWVyLXNlcnZpY2VAY3VkYXN5c3RlbXMubmV0AgEIMIG2BgsqhkiG 9w0BCRACCzGBpqCBozCBnTELMAkGA1UEBhMCVVMxEDAOBgNVBAgTB0Zsb3JpZGExEjAQBgNV BAcTCU5pY2V2aWxsZTEZMBcGA1UEChMQQ3VkYSBTeXN0ZW1zIExMQzEcMBoGA1UEAxMTQ3Vk YSBTeXN0ZW1zIExMQyBDQTEvMC0GCSqGSIb3DQEJARYgY3VzdG9tZXItc2VydmljZUBjdWRh c3lzdGVtcy5uZXQCAQgwDQYJKoZIhvcNAQEBBQAEggIACsYte+fzOD1SJBAJstc80a5kh6ZX alarfmBXaShRdbic39Xc6p4q6pbd+W0ZCZ0CF1X3xjm6j3Jvxjow42N2VcKQVJdenkicDKKi 5HgmyXs2a48mtUdopki/OzHWHVFsMauTv6kQGiI303h/bG+4O0vb4t1UfldZOBDOq7yI/pGy 0bfq4ZtH7rAYrUwfxzwYpL8C0XHkICyrdz5/MoOSCTfraoY1XdyQ6c8P2JpZ6bxVBdtMykRC R3I/R5Lz15geuZbc7TtzvVrOZJR5GLzTDeCNizzLSPvVl4tCvurjVM2sTOqq6eotJAE+gcp3 ygD0TEuN903eeHDDlBsLiDPTonB2b4IjG8hxRF/YMbswJdw92VtB5b7rngyILXFFlZ3fEpqj yAss1imqtpVgkduPmoz3HOEEnS8+jrNZJSBDX71FNI83H2cyEK9RM0aJYWYLWgTamX35Qsnx dNEtpRDccUem40ZWK7Dpxt1C6iGJek6uwXg4ZrZF2RynuNSvuwJ3kCIIfbo/zjr0+nODtvUG U9wVUmuhrgzJtN1sIXT6xDA5UuN9vReumpPO38t4d5tkZz2tj5FR/5yopcX8ECq5uqCws9Ld +CqLcfxQ29Xj6k62nU6WW7dcRtwkHt7BBh64DrnsK8f0Bbgsci+q4USm71eY2Ak2zM8cybkg jlWpIq4AAAAAAAA= --------------ms080506060502070701000604-- From owner-freebsd-geom@FreeBSD.ORG Tue Sep 30 08:41:03 2014 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F18092D2; Tue, 30 Sep 2014 08:41:03 +0000 (UTC) Received: from mail.tdx.com (mail.tdx.com [62.13.128.18]) by mx1.freebsd.org (Postfix) with ESMTP id 99C5F20D; Tue, 30 Sep 2014 08:41:03 +0000 (UTC) Received: from Mail-PC.tdx.co.uk (storm.tdx.co.uk [62.13.130.251]) (authenticated bits=0) by mail.tdx.com (8.14.3/8.14.3/) with ESMTP id s8U8etbB041855 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Sep 2014 09:40:56 +0100 (BST) Date: Tue, 30 Sep 2014 09:40:55 +0100 From: Karl Pielorz To: Pawel Jakub Dawidek Subject: Re: GELI created on a GPT labelled partition doesn't work 2nd time around... Message-ID: <5A6D15305F99246DAE25673C@Mail-PC.tdx.co.uk> In-Reply-To: <20140928130547.GD1620@garage.freebsd.pl> References: <20140928130547.GD1620@garage.freebsd.pl> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: freebsd-geom@freebsd.org X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Sep 2014 08:41:04 -0000 --On 28 September 2014 15:05 +0200 Pawel Jakub Dawidek wrote: > Could you provide the output of: > > # diskinfo -v /dev/gpt/abcdef.eli Sure, after GPTing, geli init / geli attach - the running the above gives: " /dev/gpt/abcdef.eli 4096 # sectorsize 750155304960 # mediasize in bytes (699G) 183143385 # mediasize in sectors 0 # stripesize 0 # stripeoffset 11400 # Cylinders according to firmware. 255 # Heads according to firmware. 63 # Sectors according to firmware. WD-WCAPT0430257s0s0 # Disk ident. " In the interim - I wrote a script which matches the drives serial numbers, with keys - and does a 'geli attach' on the raw disk (e.g. /dev/da0) - this results in da0.eli, which can then be GPT partitioned etc. Trying to run anything 'against' /dev/gpt/abcdef.eli results in, e.g. # gpart create -s gpt /dev/gpt/abcdef.eli gpart: provider: Device not configured or, dd if=/dev/gpt/abcdef.eli of=/dev/null bs=1k count=1000 dd: /dev/gpt/abcdef.eli: Invalid argument If I repeat the above steps without the initial GPT partition (i.e. against /dev/da0) - I end up with '/dev/da0.eli' - which I can then GPT fine etc. -Karl From owner-freebsd-geom@FreeBSD.ORG Tue Sep 30 13:54:47 2014 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CCDD6A5F; Tue, 30 Sep 2014 13:54:47 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "funkthat.com", Issuer "funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 8CBFBE5B; Tue, 30 Sep 2014 13:54:46 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id s8UDsk1f044191 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Sep 2014 06:54:46 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id s8UDsjrE044190; Tue, 30 Sep 2014 06:54:45 -0700 (PDT) (envelope-from jmg) Date: Tue, 30 Sep 2014 06:54:45 -0700 From: John-Mark Gurney To: Karl Pielorz Subject: Re: GELI created on a GPT labelled partition doesn't work 2nd time around... Message-ID: <20140930135445.GB43300@funkthat.com> Mail-Followup-To: Karl Pielorz , Pawel Jakub Dawidek , freebsd-geom@freebsd.org References: <20140928130547.GD1620@garage.freebsd.pl> <5A6D15305F99246DAE25673C@Mail-PC.tdx.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5A6D15305F99246DAE25673C@Mail-PC.tdx.co.uk> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Tue, 30 Sep 2014 06:54:46 -0700 (PDT) Cc: Pawel Jakub Dawidek , freebsd-geom@freebsd.org X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Sep 2014 13:54:47 -0000 Karl Pielorz wrote this message on Tue, Sep 30, 2014 at 09:40 +0100: > > > --On 28 September 2014 15:05 +0200 Pawel Jakub Dawidek > wrote: > > >Could you provide the output of: > > > > # diskinfo -v /dev/gpt/abcdef.eli > > Sure, after GPTing, geli init / geli attach - the running the above gives: > > " > /dev/gpt/abcdef.eli > 4096 # sectorsize > 750155304960 # mediasize in bytes (699G) > 183143385 # mediasize in sectors > 0 # stripesize > 0 # stripeoffset > 11400 # Cylinders according to firmware. > 255 # Heads according to firmware. > 63 # Sectors according to firmware. > WD-WCAPT0430257s0s0 # Disk ident. > " > > In the interim - I wrote a script which matches the drives serial numbers, > with keys - and does a 'geli attach' on the raw disk (e.g. /dev/da0) - this > results in da0.eli, which can then be GPT partitioned etc. > > Trying to run anything 'against' /dev/gpt/abcdef.eli results in, e.g. > > # gpart create -s gpt /dev/gpt/abcdef.eli > gpart: provider: Device not configured > > or, > > dd if=/dev/gpt/abcdef.eli of=/dev/null bs=1k count=1000 > dd: /dev/gpt/abcdef.eli: Invalid argument > > If I repeat the above steps without the initial GPT partition (i.e. against > /dev/da0) - I end up with '/dev/da0.eli' - which I can then GPT fine etc. gpt doesn't let you do gpt in gpt.. which explains why you can't create the second level of gpt... Why do you want/need to partition again? You could possibly use bsd as the second layer... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-geom@FreeBSD.ORG Tue Sep 30 14:25:04 2014 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9CD96A2B; Tue, 30 Sep 2014 14:25:04 +0000 (UTC) Received: from forward6l.mail.yandex.net (forward6l.mail.yandex.net [IPv6:2a02:6b8:0:1819::6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "forwards.mail.yandex.net", Issuer "Certum Level IV CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 50B6624C; Tue, 30 Sep 2014 14:25:04 +0000 (UTC) Received: from smtp18.mail.yandex.net (smtp18.mail.yandex.net [95.108.252.18]) by forward6l.mail.yandex.net (Yandex) with ESMTP id 0972814E0E61; Tue, 30 Sep 2014 18:24:51 +0400 (MSK) Received: from smtp18.mail.yandex.net (localhost [127.0.0.1]) by smtp18.mail.yandex.net (Yandex) with ESMTP id 7594218A00E3; Tue, 30 Sep 2014 18:24:51 +0400 (MSK) Received: from 84.201.166.31-vpn.dhcp.yndx.net (84.201.166.31-vpn.dhcp.yndx.net [84.201.166.31]) by smtp18.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id iHV9T4tQKy-OoYKJR3j; Tue, 30 Sep 2014 18:24:50 +0400 (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client certificate not present) X-Yandex-Uniq: d174449d-231f-42c7-a54f-6cae04340100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1412087090; bh=DHyJxltPPlATSAADrPZEqrhN5mK6FAWa8ekNq8tEHgc=; h=Message-ID:Date:From:User-Agent:MIME-Version:To:Subject: References:In-Reply-To:X-Enigmail-Version:Content-Type: Content-Transfer-Encoding; b=UH1cEjO5yJ1mN4k9GdDk5V4ZSqQUokrW2Qdub4Z+3wGRQdSlYvC0r/cPCbniudHgP cR0sJz/B9uzOWnYDSnFFe1+zCj3y4fkQFanM6UDs4Cr+nFqPkpWRtlHgbyl1F0DHHu QRmssP27SlDoJrbDKkwOX2YPl8YCmtPqPBNE55d8= Authentication-Results: smtp18.mail.yandex.net; dkim=pass header.i=@yandex.ru Message-ID: <542ABCAD.8000008@yandex.ru> Date: Tue, 30 Sep 2014 18:22:37 +0400 From: "Andrey V. Elsukov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Karl Pielorz , Pawel Jakub Dawidek , freebsd-geom@freebsd.org Subject: Re: GELI created on a GPT labelled partition doesn't work 2nd time around... References: <20140928130547.GD1620@garage.freebsd.pl> <5A6D15305F99246DAE25673C@Mail-PC.tdx.co.uk> <20140930135445.GB43300@funkthat.com> In-Reply-To: <20140930135445.GB43300@funkthat.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Sep 2014 14:25:04 -0000 On 30.09.2014 17:54, John-Mark Gurney wrote: >> If I repeat the above steps without the initial GPT partition (i.e. against >> /dev/da0) - I end up with '/dev/da0.eli' - which I can then GPT fine etc. > > gpt doesn't let you do gpt in gpt.. which explains why you can't > create the second level of gpt... > > Why do you want/need to partition again? You could possibly use bsd > as the second layer... I think bsd in gpt may have problem with booting. -- WBR, Andrey V. Elsukov From owner-freebsd-geom@FreeBSD.ORG Tue Sep 30 14:37:07 2014 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 135B5E2E; Tue, 30 Sep 2014 14:37:07 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "funkthat.com", Issuer "funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id DC8D13B0; Tue, 30 Sep 2014 14:37:06 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id s8UEb4nw044837 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Sep 2014 07:37:04 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id s8UEb4HU044836; Tue, 30 Sep 2014 07:37:04 -0700 (PDT) (envelope-from jmg) Date: Tue, 30 Sep 2014 07:37:04 -0700 From: John-Mark Gurney To: "Andrey V. Elsukov" Subject: Re: GELI created on a GPT labelled partition doesn't work 2nd time around... Message-ID: <20140930143704.GE43300@funkthat.com> Mail-Followup-To: "Andrey V. Elsukov" , Karl Pielorz , Pawel Jakub Dawidek , freebsd-geom@freebsd.org References: <20140928130547.GD1620@garage.freebsd.pl> <5A6D15305F99246DAE25673C@Mail-PC.tdx.co.uk> <20140930135445.GB43300@funkthat.com> <542ABCAD.8000008@yandex.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <542ABCAD.8000008@yandex.ru> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Tue, 30 Sep 2014 07:37:05 -0700 (PDT) Cc: Pawel Jakub Dawidek , Karl Pielorz , freebsd-geom@freebsd.org X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Sep 2014 14:37:07 -0000 Andrey V. Elsukov wrote this message on Tue, Sep 30, 2014 at 18:22 +0400: > On 30.09.2014 17:54, John-Mark Gurney wrote: > >> If I repeat the above steps without the initial GPT partition (i.e. against > >> /dev/da0) - I end up with '/dev/da0.eli' - which I can then GPT fine etc. > > > > gpt doesn't let you do gpt in gpt.. which explains why you can't > > create the second level of gpt... > > > > Why do you want/need to partition again? You could possibly use bsd > > as the second layer... > > I think bsd in gpt may have problem with booting. Maybe, but since our boot blocks can't handle geli, that isn't an issue, though apparently grub can now boot from geli, so not sure if grub could handle it... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-geom@FreeBSD.ORG Tue Sep 30 15:00:05 2014 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0BC84A39 for ; Tue, 30 Sep 2014 15:00:05 +0000 (UTC) Received: from mail.dawidek.net (garage.dawidek.net [91.121.88.72]) by mx1.freebsd.org (Postfix) with ESMTP id C934188E for ; Tue, 30 Sep 2014 15:00:04 +0000 (UTC) Received: from localhost (58.wheelsystems.com [83.12.187.58]) by mail.dawidek.net (Postfix) with ESMTPSA id 5EDA7B16; Tue, 30 Sep 2014 17:00:02 +0200 (CEST) Date: Tue, 30 Sep 2014 17:01:51 +0200 From: Pawel Jakub Dawidek To: Karl Pielorz Subject: Re: GELI created on a GPT labelled partition doesn't work 2nd time around... Message-ID: <20140930150151.GB1702@garage.freebsd.pl> References: <20140928130547.GD1620@garage.freebsd.pl> <5A6D15305F99246DAE25673C@Mail-PC.tdx.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5A6D15305F99246DAE25673C@Mail-PC.tdx.co.uk> X-OS: FreeBSD 11.0-CURRENT amd64 User-Agent: Mutt/1.5.22 (2013-10-16) Cc: freebsd-geom@freebsd.org X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Sep 2014 15:00:05 -0000 On Tue, Sep 30, 2014 at 09:40:55AM +0100, Karl Pielorz wrote: > > > --On 28 September 2014 15:05 +0200 Pawel Jakub Dawidek > wrote: > > > Could you provide the output of: > > > > # diskinfo -v /dev/gpt/abcdef.eli > > Sure, after GPTing, geli init / geli attach - the running the above gives: > > " > /dev/gpt/abcdef.eli > 4096 # sectorsize > 750155304960 # mediasize in bytes (699G) > 183143385 # mediasize in sectors > 0 # stripesize > 0 # stripeoffset > 11400 # Cylinders according to firmware. > 255 # Heads according to firmware. > 63 # Sectors according to firmware. > WD-WCAPT0430257s0s0 # Disk ident. > " > > In the interim - I wrote a script which matches the drives serial numbers, > with keys - and does a 'geli attach' on the raw disk (e.g. /dev/da0) - this > results in da0.eli, which can then be GPT partitioned etc. > > Trying to run anything 'against' /dev/gpt/abcdef.eli results in, e.g. > > # gpart create -s gpt /dev/gpt/abcdef.eli > gpart: provider: Device not configured > > or, > > dd if=/dev/gpt/abcdef.eli of=/dev/null bs=1k count=1000 > dd: /dev/gpt/abcdef.eli: Invalid argument This fails because your gpt/abcdef.eli is configured with 4k sectors. Try: dd if=/dev/gpt/abcdef.eli of=/dev/null bs=4k count=1000 > If I repeat the above steps without the initial GPT partition (i.e. against > /dev/da0) - I end up with '/dev/da0.eli' - which I can then GPT fine etc. Note sure if GPT problem is due to 4k sector or because as jmg@ mentioned it checks for GPT in GPT configuration - a check we may be able to relax. -- Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://mobter.com From owner-freebsd-geom@FreeBSD.ORG Tue Sep 30 21:20:16 2014 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2E384EB0; Tue, 30 Sep 2014 21:20:16 +0000 (UTC) Received: from mail.tdx.com (mail.tdx.com [62.13.128.18]) by mx1.freebsd.org (Postfix) with ESMTP id C8793ED4; Tue, 30 Sep 2014 21:20:15 +0000 (UTC) Received: from study64.tdx.co.uk (study64.tdx.co.uk [62.13.130.231]) (authenticated bits=0) by mail.tdx.com (8.14.3/8.14.3/) with ESMTP id s8ULKCxA039244 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Sep 2014 22:20:12 +0100 (BST) Date: Tue, 30 Sep 2014 22:20:12 +0100 From: Karl Pielorz To: John-Mark Gurney Subject: Re: GELI created on a GPT labelled partition doesn't work 2nd time around... Message-ID: <681D2CABAA14DC8E36AA60F0@study64.tdx.co.uk> In-Reply-To: <20140930135445.GB43300@funkthat.com> References: <20140928130547.GD1620@garage.freebsd.pl> <5A6D15305F99246DAE25673C@Mail-PC.tdx.co.uk> <20140930135445.GB43300@funkthat.com> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: Pawel Jakub Dawidek , freebsd-geom@freebsd.org X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Sep 2014 21:20:16 -0000 --On 30 September 2014 06:54:45 -0700 John-Mark Gurney wrote: > gpt doesn't let you do gpt in gpt.. which explains why you can't > create the second level of gpt... > > Why do you want/need to partition again? You could possibly use bsd > as the second layer... Ok, if GPT in GPT isn't supported - I can live with that. Annoyingly - the setup did work *once* when I first did it - but didn't subsequently... I've kind of worked around the problem now by using shell script to do the GELI attach - which gets a list of all drives on the system - then ties them by serial number (fetched from the drive) to their keys. I needed to do this as the drives can 'move' (so da6 this boot, may not be da6 next boot). This also happens when new drives are added to the controller (others may get 'shuffled' aside next boot). Using GPT let me abstract that away (by giving each drive a GPT labeled partition the same as it's serial number, which is written on the caddy). I've already tried wiring the bays down - but you can't with this controller :( The attach-2-serial-number workaround works for now - and at least I know why GPT doesn't work (reliably/at all now!) when nested. -Karl From owner-freebsd-geom@FreeBSD.ORG Wed Oct 1 08:10:15 2014 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C27FE622; Wed, 1 Oct 2014 08:10:15 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "funkthat.com", Issuer "funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 9B3CDA66; Wed, 1 Oct 2014 08:10:15 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id s918AEac055862 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 1 Oct 2014 01:10:15 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id s918AE5s055861; Wed, 1 Oct 2014 01:10:14 -0700 (PDT) (envelope-from jmg) Date: Wed, 1 Oct 2014 01:10:14 -0700 From: John-Mark Gurney To: Karl Pielorz Subject: Re: GELI created on a GPT labelled partition doesn't work 2nd time around... Message-ID: <20141001081014.GP43300@funkthat.com> Mail-Followup-To: Karl Pielorz , Pawel Jakub Dawidek , freebsd-geom@freebsd.org References: <20140928130547.GD1620@garage.freebsd.pl> <5A6D15305F99246DAE25673C@Mail-PC.tdx.co.uk> <20140930135445.GB43300@funkthat.com> <681D2CABAA14DC8E36AA60F0@study64.tdx.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <681D2CABAA14DC8E36AA60F0@study64.tdx.co.uk> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Wed, 01 Oct 2014 01:10:15 -0700 (PDT) Cc: Pawel Jakub Dawidek , freebsd-geom@freebsd.org X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Oct 2014 08:10:16 -0000 Karl Pielorz wrote this message on Tue, Sep 30, 2014 at 22:20 +0100: > --On 30 September 2014 06:54:45 -0700 John-Mark Gurney > wrote: > > >gpt doesn't let you do gpt in gpt.. which explains why you can't > >create the second level of gpt... > > > >Why do you want/need to partition again? You could possibly use bsd > >as the second layer... > > Ok, if GPT in GPT isn't supported - I can live with that. Annoyingly - the > setup did work *once* when I first did it - but didn't subsequently... > > I've kind of worked around the problem now by using shell script to do the > GELI attach - which gets a list of all drives on the system - then ties > them by serial number (fetched from the drive) to their keys. > > I needed to do this as the drives can 'move' (so da6 this boot, may not be > da6 next boot). This also happens when new drives are added to the > controller (others may get 'shuffled' aside next boot). Using GPT let me > abstract that away (by giving each drive a GPT labeled partition the same > as it's serial number, which is written on the caddy). I've already tried > wiring the bays down - but you can't with this controller :( So, I've been using glabel and gpt labels for this... I have a script that does: (cd $keydir && for i in *.key; do geli attach -p -k "$i" "label/${i%.key}" geli attach -p -k "$i" "gpt/${i%.key}" done) || exit 5 > The attach-2-serial-number workaround works for now - and at least I know > why GPT doesn't work (reliably/at all now!) when nested. We definately need to think about how to manage keys in a better, more reliable way on FreeBSD... Your serial number way is one way to handle it, though it appears that there is also an md5 hash that you can obtain via geli dump... Though this hash will change if you change keys on the device... So, you could possible use this instead of serial numbers... We might want to create a random uuid or we could do a uuid based upon the WWN + geom path to the provider and in that case would be globally unique and solve the "problem" of when a geli drive is duplicated that we'd have the same uuid for potentially two different sets of data... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-geom@FreeBSD.ORG Fri Oct 3 15:21:52 2014 Return-Path: Delivered-To: freebsd-geom@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 842BDBAF for ; Fri, 3 Oct 2014 15:21:52 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6B254C15 for ; Fri, 3 Oct 2014 15:21:52 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id s93FLqaJ024990 for ; Fri, 3 Oct 2014 15:21:52 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-geom@FreeBSD.org Subject: [Bug 131415] [geli] keystrokes are unregulary sent to Geli when typing passphrase Date: Fri, 03 Oct 2014 15:21:52 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: bin X-Bugzilla-Version: 7.1-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: nefar@otherware.org X-Bugzilla-Status: In Discussion X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-geom@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Oct 2014 15:21:52 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=131415 nefar@otherware.org changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |nefar@otherware.org --- Comment #2 from nefar@otherware.org --- What's the status on this? For me it accepts no keystrokes at all. The boot installer works with USB, and if I choose not to install geli during boot, the keyboard works as well. it's only during the geli prompt I have no recourse for an input mechanism since my motherboard does not support os/2 ports. As such, I am unable to use encryption (grrr). See attached screenshot -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-geom@FreeBSD.ORG Fri Oct 3 15:22:21 2014 Return-Path: Delivered-To: freebsd-geom@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 77D8EBF6 for ; Fri, 3 Oct 2014 15:22:21 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5F372C2B for ; Fri, 3 Oct 2014 15:22:21 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id s93FML0Q025572 for ; Fri, 3 Oct 2014 15:22:21 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-geom@FreeBSD.org Subject: [Bug 131415] [geli] keystrokes are unregulary sent to Geli when typing passphrase Date: Fri, 03 Oct 2014 15:22:21 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: bin X-Bugzilla-Version: 7.1-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: nefar@otherware.org X-Bugzilla-Status: In Discussion X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-geom@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: attachments.created Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Oct 2014 15:22:21 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=131415 --- Comment #3 from nefar@otherware.org --- Created attachment 147936 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=147936&action=edit geli prompting I have two keyboards installed here. None of them will recognize my typing. I've tried several. -- You are receiving this mail because: You are the assignee for the bug.