From owner-freebsd-geom@FreeBSD.ORG Sun Jun 10 08:15:38 2012 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DE8F3106566B for ; Sun, 10 Jun 2012 08:15:38 +0000 (UTC) (envelope-from pawel@dawidek.net) Received: from mail.dawidek.net (60.wheelsystems.com [83.12.187.60]) by mx1.freebsd.org (Postfix) with ESMTP id 2403F8FC0A for ; Sun, 10 Jun 2012 08:15:38 +0000 (UTC) Received: from localhost (89-73-195-149.dynamic.chello.pl [89.73.195.149]) by mail.dawidek.net (Postfix) with ESMTPSA id A932F8D0; Sun, 10 Jun 2012 10:15:36 +0200 (CEST) Date: Sun, 10 Jun 2012 10:13:40 +0200 From: Pawel Jakub Dawidek To: "John W. O'Brien" Message-ID: <20120610081337.GL1379@garage.freebsd.pl> References: <4FD3B8D5.7030906@saltant.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="UUMz/kfoogzZ9WLZ" Content-Disposition: inline In-Reply-To: <4FD3B8D5.7030906@saltant.com> X-OS: FreeBSD 10.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-geom@freebsd.org Subject: Re: Scope and purpose of each kind geli key 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: Sun, 10 Jun 2012 08:15:38 -0000 --UUMz/kfoogzZ9WLZ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Jun 09, 2012 at 04:57:57PM -0400, John W. O'Brien wrote: > I recently started using geli and found it necessary to read a bunch > of source code to supplement the manpages and Handbook sections. In > particular, there are several different kinds of keys (and sources of > key material), but they are not clearly differentiated in the docs. Of > course, one need not understand the entire geli architecture and > theory of operation in order to use it, but a bit more context would > make things easier. >=20 > So, the purpose of this inquiry is twofold: first, to sanity check > what I think I learned from my studies; second, to find out if others > would find it useful for me to take a swipe at integrating this > information into the docs. I think this is great you decided to document it and I'll do my best to help. I'd also like to see such description to be available easly and I'd be happy to add it to GELI manual page or create dedicated manual page with detailed documentation how it works. > Master Key > - ---------- >=20 > There is exactly one Master Key per provider, and it never changes for > the life of the provider. It is generated in userland upon init (or > onetime) and the user can select the key length (-l). The Master Key is always 1024 bits long (128 bytes). We split it into two parts. First part (first 64 bytes) is called IV Key and is used for IV generations when encryption algorithm is used in CBC mode. The IV Key is _not_ used when encryption algorithm is used in XTS mode. For CBC mode IV is generated by calculating SHA256 from IV Key concatenated with eight bytes that consist byte offset of the block we are encrypting. For XTS mode we use raw byte offset of the block. The second part of the Master Key (next 64 bytes) is used directly or indirectly (depending on the configuration) for data encryption and optionally for data authentication. It is called Data Key. There are three cases here: 1. Single encryption key, no authentication (single encryption key was used in older GELI versions). In this case the Data Key is used directly to encrypt all the data. IV is generated as described above. 2. Single encryption key with authentication. In this case encryption key and authentication key are calculated with: Encryption-Key =3D HMAC_SHA512(Data-Key, 0x10) Authentication-Key =3D HMAC_SHA512(Data-Key, 0x11) The Encryption-Key is used to encrypt all the data. IV is calculated as described above. 3. Multiple encryption keys. If authentication is enabled, the Authentication-Key is calculated as described in point 2. When multiple keys are used, Encryption Key is calculated with: Encryption-Key =3D HMAC_SHA512(Data-Key, "ekey"+keyno) Where keyno is eight bytes array that contains key number. Key number is incremented every 2^20 sectors of the GELI provider. XXX: This is how it should work, but while looking at the code now I realized that not the Data Key, but IV Key was used to generate Encryption Keys. For XTS mode this is totally fine, as the IV Key was unused anyway. For CBC mode this should also be fine, as IV Key is not used the same way for IV generation and for Encryption Keys generation. But I'll correct that still. > Up to two, encrypted copies of the Master Key can be stored in the > provider metadata. Each copy is encrypted with a Key Encrypting Key > derived from a User Key. >=20 >=20 > Storage Key > - ----------- >=20 > The Storage Key(s) are deterministically derived by the kernel and > cached in memory during operation. Each is generated from the Master > Key and is based on the block offset. The total number of Storage Keys > used by a given provider depends on the size of the provider; one > Storage Key per 2^20 blocks. A block's offset is used as an > Initialization Vector (IV) when encrypting or decrypting its data with > the applicable Storage Key. >=20 >=20 > User Key > - -------- >=20 > Upon init, attach, setkey, and resume, the user provides a User Key > comprised of one or more User Key components; files (-k, -K), a > passphrase, or stored passphrases (-j, -J). All components are > processed in userland to generate a Key Encrypting Key which is used > to access one of the two, encrypted Master Key copies stored in the > provider metadata. It would probably be worth noting that passphrase (either entered by hand or provided with -j/-J options) is strengthened with PKCS#2 PBKDF2 function based on SHA512 algorithm. > Key Encrypting Key > - ------------------ >=20 > Each Key Encrypting Key is generated from a User Key and used to > encrypt a copy of the Master Key on init or setkey, and to decrypt a > copy of the Master Key on attach, setkey, or resume. >=20 >=20 > For my sake and the sake of future mailing list archaeologists, are > there any errors or significant ambiguities in my description? Once > I've addressed any problems, would this, or something like it, be a > welcome addition to the manpage and/or the Handbook? If so, is the > level sufficient, or would more detail about salt, hashes, and so > forth be appropriate? This is very welcome. And more details are even more welcome:) Thanks! --=20 Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://tupytaj.pl --UUMz/kfoogzZ9WLZ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAk/UVzEACgkQForvXbEpPzRUcwCg8kn/cRnB7KrEXoHQHT4B8uOf kX8AnRUzz1Eexph292SRcwgduIJjkPrc =MURF -----END PGP SIGNATURE----- --UUMz/kfoogzZ9WLZ-- From owner-freebsd-geom@FreeBSD.ORG Mon Jun 11 11:07:23 2012 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 708C21065680 for ; Mon, 11 Jun 2012 11:07:23 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 517F68FC0C for ; Mon, 11 Jun 2012 11:07:23 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q5BB7NiR053299 for ; Mon, 11 Jun 2012 11:07:23 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q5BB7MBq053297 for freebsd-geom@FreeBSD.org; Mon, 11 Jun 2012 11:07:22 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 11 Jun 2012 11:07:22 GMT Message-Id: <201206111107.q5BB7MBq053297@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-geom@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-geom@FreeBSD.org 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: Mon, 11 Jun 2012 11:07:23 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- f kern/165745 geom [geom] geom_multipath page fault on removed drive o kern/165428 geom [glabel][patch] Add xfs support to glabel o kern/164254 geom [geom] gjournal not stopping on GPT partitions o kern/164252 geom [geom] gjournal overflow o kern/164143 geom [geom] Partition table not recognized after upgrade R8 a kern/163020 geom [geli] [patch] enable the Camellia-XTS on GEOM ELI o kern/162010 geom [geli] panic: Provider's error should be set (error=0) o kern/161979 geom [geom] glabel doesn't update after newfs, and glabel s o kern/161752 geom [geom] glabel(8) doesn't get gpt label change o bin/161677 geom gpart(8) Probably bug in gptboot o kern/160562 geom [geom][patch] Allow to insert new component to geom_ra o kern/160409 geom [geli] failed to attach provider f kern/159595 geom [geom] [panic] panic on gmirror unload in vbox [regres p kern/158398 geom [headers] [patch] includes o kern/158197 geom [geom] geom_cache with size>1000 leads to panics o kern/157879 geom [libgeom] [regression] ABI change without version bump o kern/157863 geom [geli] kbdmux prevents geli passwords from being enter o kern/157739 geom [geom] GPT labels with geom_multipath o kern/157724 geom [geom] gpart(8) 'add' command must preserve gap for sc o kern/157723 geom [geom] GEOM should not process 'c' (raw) partitions fo o kern/157108 geom [gjournal] dumpon(8) fails on gjournal providers o kern/155994 geom [geom] Long "Suspend time" when reading large files fr o kern/154226 geom [geom] GEOM label does not change when you modify them o kern/150858 geom [geom] [geom_label] [patch] glabel(8) is not compatibl o kern/150626 geom [geom] [gjournal] gjournal(8) destroys label o kern/150555 geom [geom] gjournal unusable on GPT partitions o kern/150334 geom [geom] [udf] [patch] geom label does not support UDF o kern/149762 geom volume labels with rogue characters o bin/149215 geom [panic] [geom_part] gpart(8): Delete linux's slice via o kern/147667 geom [gmirror] Booting with one component of a gmirror, the o kern/145818 geom [geom] geom_stat_open showing cached information for n o kern/145042 geom [geom] System stops booting after printing message "GE o kern/143455 geom gstripe(8) in RELENG_8 (31st Jan 2010) broken o kern/142563 geom [geom] [hang] ioctl freeze in zpool o kern/141740 geom [geom] gjournal(8): g_journal_destroy concurrent error o kern/140352 geom [geom] gjournal + glabel not working o kern/135898 geom [geom] Severe filesystem corruption - large files or l o kern/134113 geom [geli] Problem setting secondary GELI key o kern/133931 geom [geli] [request] intentionally wrong password to destr o bin/132845 geom [geom] [patch] ggated(8) does not close files opened a o bin/131415 geom [geli] keystrokes are unregulary sent to Geli when typ o kern/131353 geom [geom] gjournal(8) kernel lock o kern/129674 geom [geom] gjournal root did not mount on boot o kern/129645 geom gjournal(8): GEOM_JOURNAL causes system to fail to boo o kern/129245 geom [geom] gcache is more suitable for suffix based provid o kern/127420 geom [geom] [gjournal] [panic] Journal overflow on gmirrore o kern/124973 geom [gjournal] [patch] boot order affects geom_journal con o kern/124969 geom gvinum(8): gvinum raid5 plex does not detect missing s o kern/123962 geom [panic] [gjournal] gjournal (455Gb data, 8Gb journal), o kern/123122 geom [geom] GEOM / gjournal kernel lock o kern/122738 geom [geom] gmirror list "losts consumers" after gmirror de o kern/122067 geom [geom] [panic] Geom crashed during boot o kern/121364 geom [gmirror] Removing all providers create a "zombie" mir o kern/120091 geom [geom] [geli] [gjournal] geli does not prompt for pass o kern/115856 geom [geli] ZFS thought it was degraded when it should have o kern/115547 geom [geom] [patch] [request] let GEOM Eli get password fro f kern/113957 geom [gmirror] gmirror is intermittently reporting a degrad o kern/113837 geom [geom] unable to access 1024 sector size storage o kern/113419 geom [geom] geom fox multipathing not failing back o kern/107707 geom [geom] [patch] [request] add new class geom_xbox360 to o kern/94632 geom [geom] Kernel output resets input while GELI asks for o kern/90582 geom [geom] [panic] Restore cause panic string (ffs_blkfree o bin/90093 geom fdisk(8) incapable of altering in-core geometry o kern/87544 geom [gbde] mmaping large files on a gbde filesystem deadlo o bin/86388 geom [geom] [geom_part] periodic(8) daily should backup gpa o kern/84556 geom [geom] [panic] GBDE-encrypted swap causes panic at shu o kern/79251 geom [2TB] newfs fails on 2.6TB gbde device o kern/79035 geom [vinum] gvinum unable to create a striped set of mirro o bin/78131 geom gbde(8) "destroy" not working. 69 problems total. From owner-freebsd-geom@FreeBSD.ORG Mon Jun 11 17:22:17 2012 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 52BA3106566B for ; Mon, 11 Jun 2012 17:22:17 +0000 (UTC) (envelope-from steven.haber@isilon.com) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by mx1.freebsd.org (Postfix) with ESMTP id 0897B8FC15 for ; Mon, 11 Jun 2012 17:22:16 +0000 (UTC) Received: from hop04-l1d11-si03.isus.emc.com (HOP04-L1D11-SI03.isus.emc.com [10.254.111.23]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q5BHJX7W003081 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 11 Jun 2012 13:19:33 -0400 Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.222.130]) by hop04-l1d11-si03.isus.emc.com (RSA Interceptor) for ; Mon, 11 Jun 2012 13:19:24 -0400 Received: from seacasht01.desktop.isilon.com (seacasht01.isilon.com [137.69.159.79]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q5BHJLLq004871 for ; Mon, 11 Jun 2012 13:19:22 -0400 Received: from seaxch01.isilon.com (137.69.158.60) by SEACASHT01.desktop.isilon.com (137.69.159.79) with Microsoft SMTP Server id 14.2.298.4; Mon, 11 Jun 2012 10:19:20 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 11 Jun 2012 10:19:07 -0700 Message-ID: <56CE86D6660FF84498426FA7A33170B4033672EF@seaxch01.desktop.isilon.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Geom / destroy_dev() deadlock Thread-Index: Ac1H9k6wBIuqsGqISD6SyAxkH7DByQ== From: Steven Haber To: X-EMM-MHVC: 1 Subject: Geom / destroy_dev() deadlock 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: Mon, 11 Jun 2012 17:22:17 -0000 Hey FreeBSD devs, I hope this is the right forum for this. I haven't used the FreeBSD mailing lists before. I'm a relatively new hire at EMC Isilon. We are using FreeBSD 7.0 as the basis for our scale-out NAS product line. We are frequently hitting the deadlock described here: http://lists.freebsd.org/pipermail/freebsd-geom/2010-February/003888.htm l The race is that destroy_dev() sleeps indefinitely waiting for thread references to drop from a dev. In the case of geom, we hold the topology lock the whole time we're in the dev layer. In devfs_open() and devfs_close(), we take a ref on the dev before calling into to geom. The proposed solution of destroy_dev_sched() makes sense to me. I am trying to understand the necessity of Alexander Motin's additional changes. destroy_dev_tq() holds the devmtx during the destroy and devfs uses this lock to take refs before calling into geom. To me it seems we should be able to protect the cdev with just the devmtx, provided consumers of d_close(), d_open(), etc. ref and rel the dev appropriately. Steven Haber Software Engineer, EMC Isilon (206) 753-1526 From owner-freebsd-geom@FreeBSD.ORG Mon Jun 11 20:43:38 2012 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 7FE2C106564A for ; Mon, 11 Jun 2012 20:43:38 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id EF9EE8FC17 for ; Mon, 11 Jun 2012 20:43:37 +0000 (UTC) Received: from skuns.kiev.zoral.com.ua (localhost [127.0.0.1]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id q5BKhYK1047538; Mon, 11 Jun 2012 23:43:34 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5) with ESMTP id q5BKhYOJ050836; Mon, 11 Jun 2012 23:43:34 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5/Submit) id q5BKhYEw050835; Mon, 11 Jun 2012 23:43:34 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 11 Jun 2012 23:43:34 +0300 From: Konstantin Belousov To: Steven Haber Message-ID: <20120611204334.GH2337@deviant.kiev.zoral.com.ua> References: <56CE86D6660FF84498426FA7A33170B4033672EF@seaxch01.desktop.isilon.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="wj9ZLJVQDRFjGSdK" Content-Disposition: inline In-Reply-To: <56CE86D6660FF84498426FA7A33170B4033672EF@seaxch01.desktop.isilon.com> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.0 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-geom@freebsd.org Subject: Re: Geom / destroy_dev() deadlock 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: Mon, 11 Jun 2012 20:43:38 -0000 --wj9ZLJVQDRFjGSdK Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jun 11, 2012 at 10:19:07AM -0700, Steven Haber wrote: > Hey FreeBSD devs, >=20 > I hope this is the right forum for this. I haven't used the FreeBSD > mailing lists before. I'm a relatively new hire at EMC Isilon. We are > using FreeBSD 7.0 as the basis for our scale-out NAS product line. We > are frequently hitting the deadlock described here: >=20 > http://lists.freebsd.org/pipermail/freebsd-geom/2010-February/003888.htm > l >=20 > The race is that destroy_dev() sleeps indefinitely waiting for thread > references to drop from a dev. In the case of geom, we hold the topology > lock the whole time we're in the dev layer. In devfs_open() and > devfs_close(), we take a ref on the dev before calling into to geom. >=20 > The proposed solution of destroy_dev_sched() makes sense to me. I am > trying to understand the necessity of Alexander Motin's additional > changes. destroy_dev_tq() holds the devmtx during the destroy and devfs > uses this lock to take refs before calling into geom. To me it seems we > should be able to protect the cdev with just the devmtx, provided > consumers of d_close(), d_open(), etc. ref and rel the dev > appropriately. devmtx is mutex. If taken, then cdevsw methods would be unable to sleep. --wj9ZLJVQDRFjGSdK Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAk/WWHUACgkQC3+MBN1Mb4ip4QCgg1nSt1hXHR3ef0jlEtVv9iQa GgYAnj2nwSOtFkYgJogIG0ErN5gJfvBI =ikZO -----END PGP SIGNATURE----- --wj9ZLJVQDRFjGSdK-- From owner-freebsd-geom@FreeBSD.ORG Mon Jun 11 21:16:35 2012 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7E61E106564A for ; Mon, 11 Jun 2012 21:16:35 +0000 (UTC) (envelope-from steven.haber@isilon.com) Received: from mexforwardwc.lss.emc.com (mexforwardwc.lss.emc.com [137.69.117.200]) by mx1.freebsd.org (Postfix) with ESMTP id 56DC28FC18 for ; Mon, 11 Jun 2012 21:16:35 +0000 (UTC) Received: from scl02-01d02-si01.isus.emc.com (scl02-01d02-si01.isus.emc.com [137.69.225.84]) by mexforwardwc.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q5BLGSYx021314 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 11 Jun 2012 14:16:28 -0700 Received: from mailhubwc.lss.emc.com (mailhubscprd03.lss.emc.com [137.69.224.145]) by scl02-01d02-si01.isus.emc.com (RSA Interceptor); Mon, 11 Jun 2012 14:16:14 -0700 Received: from seacasht01.desktop.isilon.com (seacasht01.isilon.com [137.69.159.79]) by mailhubwc.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q5BLGDnj007542; Mon, 11 Jun 2012 14:16:13 -0700 Received: from seaxch01.isilon.com (137.69.158.60) by SEACASHT01.desktop.isilon.com (137.69.159.79) with Microsoft SMTP Server id 14.2.298.4; Mon, 11 Jun 2012 14:16:13 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 11 Jun 2012 14:15:56 -0700 Message-ID: <56CE86D6660FF84498426FA7A33170B403367535@seaxch01.desktop.isilon.com> In-Reply-To: <20120611204334.GH2337@deviant.kiev.zoral.com.ua> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Geom / destroy_dev() deadlock Thread-Index: Ac1IEvIdDnPTEOlqTKuQLQBRuTmuGQAAhtFA References: <56CE86D6660FF84498426FA7A33170B4033672EF@seaxch01.desktop.isilon.com> <20120611204334.GH2337@deviant.kiev.zoral.com.ua> From: Steven Haber To: Konstantin Belousov X-EMM-MHVC: 1 Cc: freebsd-geom@freebsd.org Subject: RE: Geom / destroy_dev() deadlock 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: Mon, 11 Jun 2012 21:16:35 -0000 > On Mon, Jun 11, 2012 at 10:19:07AM -0700, Steven Haber wrote: >> Hey FreeBSD devs, >> =20 >> I hope this is the right forum for this. I haven't used the FreeBSD >> mailing lists before. I'm a relatively new hire at EMC Isilon. We are >> using FreeBSD 7.0 as the basis for our scale-out NAS product line. We >> are frequently hitting the deadlock described here: >>=20 >> http://lists.freebsd.org/pipermail/freebsd-geom/2010-February/003888.htm >> l >>=20 >> The race is that destroy_dev() sleeps indefinitely waiting for thread >> references to drop from a dev. In the case of geom, we hold the topology >> lock the whole time we're in the dev layer. In devfs_open() and >> devfs_close(), we take a ref on the dev before calling into to geom. >>=20 >> The proposed solution of destroy_dev_sched() makes sense to me. I am >> trying to understand the necessity of Alexander Motin's additional >> changes. destroy_dev_tq() holds the devmtx during the destroy and devfs >> uses this lock to take refs before calling into geom. To me it seems we >> should be able to protect the cdev with just the devmtx, provided >> consumers of d_close(), d_open(), etc. ref and rel the dev >> appropriately. > From: Konstantin Belousov > Sent: Monday, June 11, 2012 1:44 PM > To: Steven Haber > Cc: freebsd-geom@freebsd.org > Subject: Re: Geom / destroy_dev() deadlock > devmtx is mutex. If taken, then cdevsw methods would be unable to sleep. To clarify, I'm not suggesting additional locking with devmtx. Currently we use the devmtx to take thread references on the dev. destroy_devl() sleeps until there are no references. I don't see why it matters if we a foreground destroy (current code, destroy_dev()) or scheduled destroy (using destroy_dev_sched()) since the devmtx combined with thread refs should guarantee we are never in the cdevsw methods during a destroy. I think that the single routine change is sufficient, and I can't seem to cause any sort of crash on my system with that change in place. Steven From owner-freebsd-geom@FreeBSD.ORG Mon Jun 11 21:56:25 2012 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5C49C1065672 for ; Mon, 11 Jun 2012 21:56:25 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id D20778FC12 for ; Mon, 11 Jun 2012 21:56:24 +0000 (UTC) Received: from skuns.kiev.zoral.com.ua (localhost [127.0.0.1]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id q5BLuBit064554; Tue, 12 Jun 2012 00:56:11 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5) with ESMTP id q5BLuBVV051250; Tue, 12 Jun 2012 00:56:11 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5/Submit) id q5BLuANZ051249; Tue, 12 Jun 2012 00:56:10 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 12 Jun 2012 00:56:10 +0300 From: Konstantin Belousov To: Steven Haber Message-ID: <20120611215610.GJ2337@deviant.kiev.zoral.com.ua> References: <56CE86D6660FF84498426FA7A33170B4033672EF@seaxch01.desktop.isilon.com> <20120611204334.GH2337@deviant.kiev.zoral.com.ua> <56CE86D6660FF84498426FA7A33170B403367535@seaxch01.desktop.isilon.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="1y6imfT/xHuCvpN0" Content-Disposition: inline In-Reply-To: <56CE86D6660FF84498426FA7A33170B403367535@seaxch01.desktop.isilon.com> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.0 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-geom@freebsd.org Subject: Re: Geom / destroy_dev() deadlock 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: Mon, 11 Jun 2012 21:56:25 -0000 --1y6imfT/xHuCvpN0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jun 11, 2012 at 02:15:56PM -0700, Steven Haber wrote: > > On Mon, Jun 11, 2012 at 10:19:07AM -0700, Steven Haber wrote: > >> Hey FreeBSD devs, > >> =20 > >> I hope this is the right forum for this. I haven't used the FreeBSD > >> mailing lists before. I'm a relatively new hire at EMC Isilon. We are > >> using FreeBSD 7.0 as the basis for our scale-out NAS product line. We > >> are frequently hitting the deadlock described here: > >>=20 > >> > http://lists.freebsd.org/pipermail/freebsd-geom/2010-February/003888.htm > >> l > >>=20 > >> The race is that destroy_dev() sleeps indefinitely waiting for thread > >> references to drop from a dev. In the case of geom, we hold the > topology > >> lock the whole time we're in the dev layer. In devfs_open() and > >> devfs_close(), we take a ref on the dev before calling into to geom. > >>=20 > >> The proposed solution of destroy_dev_sched() makes sense to me. I am > >> trying to understand the necessity of Alexander Motin's additional > >> changes. destroy_dev_tq() holds the devmtx during the destroy and > devfs > >> uses this lock to take refs before calling into geom. To me it seems > we > >> should be able to protect the cdev with just the devmtx, provided > >> consumers of d_close(), d_open(), etc. ref and rel the dev > >> appropriately. >=20 >=20 > > From: Konstantin Belousov > > Sent: Monday, June 11, 2012 1:44 PM > > To: Steven Haber > > Cc: freebsd-geom@freebsd.org > > Subject: Re: Geom / destroy_dev() deadlock >=20 > > devmtx is mutex. If taken, then cdevsw methods would be unable to > sleep. >=20 > To clarify, I'm not suggesting additional locking with devmtx. Currently > we use the devmtx to take thread references on the dev. destroy_devl() > sleeps until there are no references. I don't see why it matters if we a > foreground destroy (current code, destroy_dev()) or scheduled destroy > (using destroy_dev_sched()) since the devmtx combined with thread refs > should guarantee we are never in the cdevsw methods during a destroy. I > think that the single routine change is sufficient, and I can't seem to > cause any sort of crash on my system with that change in place. I do not understand what you are proposing. Could you, please, show the patch ? --1y6imfT/xHuCvpN0 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAk/WaXoACgkQC3+MBN1Mb4jUZQCfb8r5eZb05xwMDF66lxjE5r8f N6wAn2XgXP/DP8Pu+9vQssIu4XBiEh6s =ejXU -----END PGP SIGNATURE----- --1y6imfT/xHuCvpN0-- From owner-freebsd-geom@FreeBSD.ORG Mon Jun 11 22:28:06 2012 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id EF282106566C for ; Mon, 11 Jun 2012 22:28:06 +0000 (UTC) (envelope-from steven.haber@isilon.com) Received: from mexforwardwc.lss.emc.com (mexforwardwc.lss.emc.com [137.69.117.200]) by mx1.freebsd.org (Postfix) with ESMTP id C79318FC12 for ; Mon, 11 Jun 2012 22:28:06 +0000 (UTC) Received: from scl02-01d02-si01.isus.emc.com (scl02-01d02-si01.isus.emc.com [137.69.225.84]) by mexforwardwc.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q5BMS67u016101 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 11 Jun 2012 15:28:06 -0700 Received: from mailhubwc.lss.emc.com (mailhubscprd02.lss.emc.com [137.69.224.75]) by scl02-01d02-si01.isus.emc.com (RSA Interceptor); Mon, 11 Jun 2012 15:27:52 -0700 Received: from seacasht01.desktop.isilon.com (seacasht01.isilon.com [137.69.159.79]) by mailhubwc.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q5BMRqVe005547; Mon, 11 Jun 2012 15:27:52 -0700 Received: from seaxch01.isilon.com (137.69.158.60) by SEACASHT01.desktop.isilon.com (137.69.159.79) with Microsoft SMTP Server id 14.2.298.4; Mon, 11 Jun 2012 15:27:51 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 11 Jun 2012 15:27:39 -0700 Message-ID: <56CE86D6660FF84498426FA7A33170B403429115@seaxch01.desktop.isilon.com> In-Reply-To: <20120611215610.GJ2337@deviant.kiev.zoral.com.ua> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Geom / destroy_dev() deadlock Thread-Index: Ac1IHRE10CKhtsqGSi+pmXihpPeo6wAA6eRg References: <56CE86D6660FF84498426FA7A33170B4033672EF@seaxch01.desktop.isilon.com> <20120611204334.GH2337@deviant.kiev.zoral.com.ua> <56CE86D6660FF84498426FA7A33170B403367535@seaxch01.desktop.isilon.com> <20120611215610.GJ2337@deviant.kiev.zoral.com.ua> From: Steven Haber To: Konstantin Belousov X-EMM-MHVC: 1 Cc: freebsd-geom@freebsd.org Subject: RE: Geom / destroy_dev() deadlock 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: Mon, 11 Jun 2012 22:28:07 -0000 > On Mon, Jun 11, 2012 at 02:15:56PM -0700, Steven Haber wrote: > > > On Mon, Jun 11, 2012 at 10:19:07AM -0700, Steven Haber wrote: > > > > Hey FreeBSD devs, > > > > =20 > > > > I hope this is the right forum for this. I haven't used the FreeBSD > > > > mailing lists before. I'm a relatively new hire at EMC Isilon. We are > > > > using FreeBSD 7.0 as the basis for our scale-out NAS product line. We > > > > are frequently hitting the deadlock described here: > > > >=20 > > > > > > http://lists.freebsd.org/pipermail/freebsd-geom/2010-February/003888.htm l > > > >=20 > > > > The race is that destroy_dev() sleeps indefinitely waiting for thread > > > > references to drop from a dev. In the case of geom, we hold the > > topology > > > > lock the whole time we're in the dev layer. In devfs_open() and > > > > devfs_close(), we take a ref on the dev before calling into to geom. > > > >=20 > > > > The proposed solution of destroy_dev_sched() makes sense to me. I am > > > > trying to understand the necessity of Alexander Motin's additional > > > > changes. destroy_dev_tq() holds the devmtx during the destroy and > > devfs > > > > uses this lock to take refs before calling into geom. To me it seems > > we > > > > should be able to protect the cdev with just the devmtx, provided > > > > consumers of d_close(), d_open(), etc. ref and rel the dev > > > > appropriately. > >=20 > >=20 > > > From: Konstantin Belousov > > > Sent: Monday, June 11, 2012 1:44 PM > > > To: Steven Haber > > > Cc: freebsd-geom@freebsd.org > > > Subject: Re: Geom / destroy_dev() deadlock > >=20 > > > devmtx is mutex. If taken, then cdevsw methods would be unable to > > sleep. > >=20 > > To clarify, I'm not suggesting additional locking with devmtx. Currently > > we use the devmtx to take thread references on the dev. destroy_devl() > > sleeps until there are no references. I don't see why it matters if we a > > foreground destroy (current code, destroy_dev()) or scheduled destroy > > (using destroy_dev_sched()) since the devmtx combined with thread refs > > should guarantee we are never in the cdevsw methods during a destroy. I > > think that the single routine change is sufficient, and I can't seem to > > cause any sort of crash on my system with that change in place. > From: Konstantin Belousov > Sent: Monday, June 11, 2012 2:56 PM > To: Steven Haber > Cc: freebsd-geom@freebsd.org > Subject: Re: Geom / destroy_dev() deadlock > I do not understand what you are proposing. Could you, please, show > the patch ? --- src/sys/geom/geom_dev.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/sys/geom/geom_dev.c b/src/sys/geom/geom_dev.c index 38251e1..787235a 100644 --- a/src/sys/geom/geom_dev.c +++ b/src/sys/geom/geom_dev.c @@ -497,7 +497,7 @@ g_dev_orphan(struct g_consumer *cp) =20 /* Destroy the struct cdev *so we get no more requests */ unit =3D dev2unit(dev); - destroy_dev(dev); + destroy_dev_sched(dev); free_unr(unithdr, unit); =20 /* Wait for the cows to come home */ --=20 Steven From owner-freebsd-geom@FreeBSD.ORG Mon Jun 11 22:53:09 2012 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A20E9106566C for ; Mon, 11 Jun 2012 22:53:09 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 1B45A8FC08 for ; Mon, 11 Jun 2012 22:53:08 +0000 (UTC) Received: from skuns.kiev.zoral.com.ua (localhost [127.0.0.1]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id q5BMr49b076695; Tue, 12 Jun 2012 01:53:05 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5) with ESMTP id q5BMr4O9052488; Tue, 12 Jun 2012 01:53:04 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5/Submit) id q5BMr4qB052487; Tue, 12 Jun 2012 01:53:04 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 12 Jun 2012 01:53:04 +0300 From: Konstantin Belousov To: Steven Haber Message-ID: <20120611225304.GK2337@deviant.kiev.zoral.com.ua> References: <56CE86D6660FF84498426FA7A33170B4033672EF@seaxch01.desktop.isilon.com> <20120611204334.GH2337@deviant.kiev.zoral.com.ua> <56CE86D6660FF84498426FA7A33170B403367535@seaxch01.desktop.isilon.com> <20120611215610.GJ2337@deviant.kiev.zoral.com.ua> <56CE86D6660FF84498426FA7A33170B403429115@seaxch01.desktop.isilon.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="EMQjp+MvU6EBGjHc" Content-Disposition: inline In-Reply-To: <56CE86D6660FF84498426FA7A33170B403429115@seaxch01.desktop.isilon.com> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.0 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-geom@freebsd.org Subject: Re: Geom / destroy_dev() deadlock 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: Mon, 11 Jun 2012 22:53:09 -0000 --EMQjp+MvU6EBGjHc Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jun 11, 2012 at 03:27:39PM -0700, Steven Haber wrote: > > I do not understand what you are proposing. Could you, please, show > > the patch ? >=20 > --- > src/sys/geom/geom_dev.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) >=20 > diff --git a/src/sys/geom/geom_dev.c b/src/sys/geom/geom_dev.c > index 38251e1..787235a 100644 > --- a/src/sys/geom/geom_dev.c > +++ b/src/sys/geom/geom_dev.c > @@ -497,7 +497,7 @@ g_dev_orphan(struct g_consumer *cp) > =20 > /* Destroy the struct cdev *so we get no more requests */ > unit =3D dev2unit(dev); > - destroy_dev(dev); > + destroy_dev_sched(dev); > free_unr(unithdr, unit); > =20 > /* Wait for the cows to come home */ Did you noted the comment above the block you changing ? The patch would cause races allowing arbitrary kernel memory corruption. The moment when the cdev is destroyed is somewhere in future, while structures that the cdev reference are freed synchronously. I tried to put some safety measures into destroy_dev_sched(9), namely CDP_SCHED_DTR flag that somewhat reduces the possibility of usermode accessing cdev after destroy_dev_sched(), but this cannot be eliminated entirely. --EMQjp+MvU6EBGjHc Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAk/WdtAACgkQC3+MBN1Mb4jpDQCgiBoVnAOan9YOILDSohRzV8HC uFIAn1QA/tyJRtL/xtZm7chlsJtltTcE =8EDz -----END PGP SIGNATURE----- --EMQjp+MvU6EBGjHc-- From owner-freebsd-geom@FreeBSD.ORG Tue Jun 12 00:21:47 2012 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 B56B1106566B; Tue, 12 Jun 2012 00:21:47 +0000 (UTC) (envelope-from john@saltant.com) Received: from hapkido.dreamhost.com (hapkido.dreamhost.com [66.33.216.122]) by mx1.freebsd.org (Postfix) with ESMTP id 88A548FC08; Tue, 12 Jun 2012 00:21:47 +0000 (UTC) Received: from homiemail-a95.g.dreamhost.com (caiajhbdcbef.dreamhost.com [208.97.132.145]) by hapkido.dreamhost.com (Postfix) with ESMTP id BC79BF9; Mon, 11 Jun 2012 17:24:30 -0700 (PDT) Received: from homiemail-a95.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a95.g.dreamhost.com (Postfix) with ESMTP id 677231E05C; Mon, 11 Jun 2012 17:21:41 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=saltant.com; h=message-id:date :from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=saltant.com; b=Rqs0UEPFS0c82DhRxNGa0m1duVDJ6tD2YHSjqdl5b42vYSTekrHZJlPImUl2B dv3LpQDUVVcW6XNpwvcL2E0D5GjOKFBsMs7Qpg5FkCZvqpdhd1/FB2+fVy+VBMgI ZCm37r49tv8VjAmrhT2qAuTiEUH4kT00ljAr/8Sp/HBQqU= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=saltant.com; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; s=saltant.com; bh=iZJcu DAzyM3/Lhn5wCLnTs/jTic=; b=ST+VI1o+qJy++YjHThLRem8wZmZfGWR0xWCDL yjFAjMTgp9xblFw7TyMaXlKRh5/h9lnDt2+ZMko48zqU/f86XuidywADmRLg0TlW h79WGu1jDGb2Ci8pSI8+jzmkJlxvabX8cOQ0r8xLyny5/Vfq30cWy+Fg5k4VQZP7 vUDF3Q= Received: from imago.y.saltant.net (vice.saltant.net [96.227.187.16]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: john@saltant.com) by homiemail-a95.g.dreamhost.com (Postfix) with ESMTPSA id 2640F1E00D; Mon, 11 Jun 2012 17:21:41 -0700 (PDT) Message-ID: <4FD68B94.4050200@saltant.com> Date: Mon, 11 Jun 2012 20:21:40 -0400 From: "John W. O'Brien" Organization: Saltant Solutions User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: Pawel Jakub Dawidek References: <4FD3B8D5.7030906@saltant.com> <20120610081337.GL1379@garage.freebsd.pl> In-Reply-To: <20120610081337.GL1379@garage.freebsd.pl> X-Enigmail-Version: 1.5pre Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-geom@freebsd.org Subject: Re: Scope and purpose of each kind geli key 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: Tue, 12 Jun 2012 00:21:47 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 06/10/2012 04:13 AM, Pawel Jakub Dawidek wrote: > I think this is great you decided to document it and I'll do my > best to help. I'd also like to see such description to be available > easly and I'd be happy to add it to GELI manual page or create > dedicated manual page with detailed documentation how it works. Thank you! I'm excited to finally give a little something back to FreeBSD. My preference is to start by preparing changes to the existing geli(8) manpage and section 19.16.2 of the Handbook. These will be light-weight changes focused on clarifying at a conceptual level which keys exist, where, and how a user can interact with them. I like the idea of adding a dedicated manpage with much more detailed documentation, but I will defer that for now and hopefully return to it later. Eventually, I would love to make supporting diagrams. All in good time. >> Master Key - ---------- >> >> There is exactly one Master Key per provider, and it never >> changes for the life of the provider. It is generated in userland >> upon init (or onetime) and the user can select the key length >> (-l). > > The Master Key is always 1024 bits long (128 bytes). Ah, of course. Since no part of the Master Key is used as direct input to the selected block cipher, its length is independent of the key length specified by -l. > [...] The second part of the Master Key (next 64 bytes) is used > directly or indirectly (depending on the configuration) for data > encryption and optionally for data authentication. It is called > Data Key. s/Storage Key/Data Key/g Got it. > [...] It would probably be worth noting that passphrase (either > entered by hand or provided with -j/-J options) is strengthened > with PKCS#2 PBKDF2 function based on SHA512 algorithm. ACK. Is the order significant in which multiple User Key components are given on the command line? > [..] This is very welcome. And more details are even more > welcome:) I appreciate your help. It may take me a while to get up to speed on the necessary markup languages, and to find my way around the documentation development workflow. I don't have a ton of time to devote, but I want to do a good job. Regards, John -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJP1ouRAAoJEEdKvTwaez9wqUMH/0I/P9sun1003x4oJCEbYfqn Vr1MYLhY2pesNNxNJmNlSoJ25DG6t9/ycsxbtXdX3eXCA3iFgqkrzJhKQyRMJsoT VQDFx6C6Hiidz/C99qIHWE9+/ZcivtQVthIN/+ztZRgFInARShRaoUYegABt1N0E MjfJAi2M0lNjKtKhUkUVj/y7vuuktvaki3D3qrb77+A7zELuC0CcDnr8VmnFZTuD /Y1T5wfvdibhwYjN9p3KH7LP44anqA89UX4LzvawckRT8HDcxeD2XWPZ4Q5isuFe kMGXUjyxd/1dfD5XQBD+O1nzeYXVUTZPoWyXJdj5qyZ74Cc3p+vQzzejoAsGhFc= =NACu -----END PGP SIGNATURE----- From owner-freebsd-geom@FreeBSD.ORG Wed Jun 13 12:30:17 2012 Return-Path: Delivered-To: freebsd-geom@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1F3EF1065675 for ; Wed, 13 Jun 2012 12:30:17 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [69.147.83.40]) by mx1.freebsd.org (Postfix) with ESMTP id 09B518FC12 for ; Wed, 13 Jun 2012 12:30:17 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q5DCUGJo014188 for ; Wed, 13 Jun 2012 12:30:16 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q5DCUGbR014185; Wed, 13 Jun 2012 12:30:16 GMT (envelope-from gnats) Date: Wed, 13 Jun 2012 12:30:16 GMT Message-Id: <201206131230.q5DCUGbR014185@freefall.freebsd.org> To: freebsd-geom@FreeBSD.org From: Thomas Steen Rasmussen Cc: Subject: Re: kern/157863: [geli] kbdmux prevents geli passwords from being entered properly on boot X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Thomas Steen Rasmussen List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2012 12:30:17 -0000 The following reply was made to PR kern/157863; it has been noted by GNATS. From: Thomas Steen Rasmussen To: bug-followup@FreeBSD.org, rsimmons0@gmail.com, stable@freebsd.org Cc: Subject: Re: kern/157863: [geli] kbdmux prevents geli passwords from being entered properly on boot Date: Wed, 13 Jun 2012 14:19:40 +0200 Hello, Just to let everyone know that this is still an issue. I am trying to install FreeBSD 9.0 amd64 on a Lenovo X121e and I can't get it to accept the geli passphrase during boot. I've confirmed using kern.geom.eli.visible_passphrase=1 that the passphrase is correct, and the same passphrase is accepted when the system is booted up. I've tried disabling kbdmux in /boot/device.hints like the PR said, but that didn't help. I also tried disabling atkbd and atkbdc without any luck, infact I couldn't type anything at all when disabling those. Any hints or suggestions to what I might try ? I have another 9-stable laptop that mounts a geli volume at boot, no idea why that one works and this new one doesn't. Thanks in advance, /Thomas Steen Rasmussen From owner-freebsd-geom@FreeBSD.ORG Wed Jun 13 13:10:11 2012 Return-Path: Delivered-To: freebsd-geom@hub.freebsd.org Received: from mx1.freebsd.org (unknown [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 603781065672 for ; Wed, 13 Jun 2012 13:10:11 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [69.147.83.40]) by mx1.freebsd.org (Postfix) with ESMTP id 4BA568FC15 for ; Wed, 13 Jun 2012 13:10:11 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q5DDAAWd057190 for ; Wed, 13 Jun 2012 13:10:11 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q5DDAAFM057189; Wed, 13 Jun 2012 13:10:10 GMT (envelope-from gnats) Date: Wed, 13 Jun 2012 13:10:10 GMT Message-Id: <201206131310.q5DDAAFM057189@freefall.freebsd.org> To: freebsd-geom@FreeBSD.org From: Fabian Keil Cc: Subject: Re: kern/157863: [geli] kbdmux prevents geli passwords from being entered properly on boot X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Fabian Keil List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2012 13:10:11 -0000 The following reply was made to PR kern/157863; it has been noted by GNATS. From: Fabian Keil To: Thomas Steen Rasmussen Cc: bug-followup@FreeBSD.org, rsimmons0@gmail.com, stable@freebsd.org Subject: Re: kern/157863: [geli] kbdmux prevents geli passwords from being entered properly on boot Date: Wed, 13 Jun 2012 15:01:57 +0200 --Sig_/jm6NxO_vQgiPA42WSE/jqH/ Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Thomas Steen Rasmussen wrote: > Just to let everyone know that this is still an issue. >=20 > I am trying to install FreeBSD 9.0 amd64 on a Lenovo X121e and I > can't get it to accept the geli passphrase during boot. I've confirmed > using kern.geom.eli.visible_passphrase=3D1 that the passphrase is > correct, and the same passphrase is accepted when the system is > booted up. >=20 > I've tried disabling kbdmux in /boot/device.hints like the PR said, > but that didn't help. I also tried disabling atkbd and atkbdc without > any luck, infact I couldn't type anything at all when disabling those. If disabling kbdmux doesn't help, it sounds like a different issue to me. > Any hints or suggestions to what I might try ? I have another 9-stable > laptop that mounts a geli volume at boot, no idea why that one works > and this new one doesn't. Are you using the password together with a keyfile? I've misconfigured the keyfile in loader.conf in the past, which results in the valid password not being accepted. Obviously the setup then magically works later on when the keyfile is specified correctly on the command line. If you aren't using keyfiles, you could try setting up an USB stick with geli, to confirm that the same media works on one laptop, but doesn't on the other. Fabian --Sig_/jm6NxO_vQgiPA42WSE/jqH/ Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAk/Yj0sACgkQBYqIVf93VJ1sMQCgrrw4AUCzDoohr2ILzk9xKYu6 IosAmwUmEvoKKeOeILOsLvmQb+BcIUU9 =liCA -----END PGP SIGNATURE----- --Sig_/jm6NxO_vQgiPA42WSE/jqH/-- From owner-freebsd-geom@FreeBSD.ORG Wed Jun 13 13:30:17 2012 Return-Path: Delivered-To: freebsd-geom@hub.freebsd.org Received: from mx1.freebsd.org (unknown [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 39E651065673 for ; Wed, 13 Jun 2012 13:30:17 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [69.147.83.40]) by mx1.freebsd.org (Postfix) with ESMTP id 231B88FC1A for ; Wed, 13 Jun 2012 13:30:17 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q5DDUHb8075606 for ; Wed, 13 Jun 2012 13:30:17 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q5DDUGHR075603; Wed, 13 Jun 2012 13:30:16 GMT (envelope-from gnats) Date: Wed, 13 Jun 2012 13:30:16 GMT Message-Id: <201206131330.q5DDUGHR075603@freefall.freebsd.org> To: freebsd-geom@FreeBSD.org From: Thomas Steen Rasmussen Cc: Subject: Re: kern/157863: [geli] kbdmux prevents geli passwords from being entered properly on boot X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Thomas Steen Rasmussen List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2012 13:30:17 -0000 The following reply was made to PR kern/157863; it has been noted by GNATS. From: Thomas Steen Rasmussen To: Fabian Keil Cc: bug-followup@FreeBSD.org, rsimmons0@gmail.com, stable@freebsd.org Subject: Re: kern/157863: [geli] kbdmux prevents geli passwords from being entered properly on boot Date: Wed, 13 Jun 2012 15:20:26 +0200 On 13-06-2012 15:01, Fabian Keil wrote: > Thomas Steen Rasmussen wrote: > >> Just to let everyone know that this is still an issue. >> >> I am trying to install FreeBSD 9.0 amd64 on a Lenovo X121e and I >> can't get it to accept the geli passphrase during boot. I've confirmed >> using kern.geom.eli.visible_passphrase=1 that the passphrase is >> correct, and the same passphrase is accepted when the system is >> booted up. >> >> I've tried disabling kbdmux in /boot/device.hints like the PR said, >> but that didn't help. I also tried disabling atkbd and atkbdc without >> any luck, infact I couldn't type anything at all when disabling those. > > If disabling kbdmux doesn't help, it sounds like a different issue to me. You are right, shame on me for polluting an innocent PR with unrelated stuff. More info below. > >> Any hints or suggestions to what I might try ? I have another 9-stable >> laptop that mounts a geli volume at boot, no idea why that one works >> and this new one doesn't. > > Are you using the password together with a keyfile? Yes I am. > I've misconfigured the keyfile in loader.conf in the past, > which results in the valid password not being accepted. > > Obviously the setup then magically works later on when the > keyfile is specified correctly on the command line. This (a small typo in keyfile in loader.conf) was the problem, and I need to get my eyes examined :-) geli could be better at explaining the problem though. Thank you Fabian! Just what I needed. Apologies for the noise, Thomas Steen Rasmussen From owner-freebsd-geom@FreeBSD.ORG Thu Jun 14 23:33:42 2012 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (unknown [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D71121065670 for ; Thu, 14 Jun 2012 23:33:42 +0000 (UTC) (envelope-from rsimmons0@gmail.com) Received: from mail-vb0-f54.google.com (mail-vb0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 8BAD18FC0A for ; Thu, 14 Jun 2012 23:33:42 +0000 (UTC) Received: by vbmv11 with SMTP id v11so1790802vbm.13 for ; Thu, 14 Jun 2012 16:33:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=1pQ/sVA8wowM2H0AZje1UB+Gqup0D+wiUci3AFEY6C4=; b=AAXY6C0JPgDOOCCOojdxK9X0O717gnOL9c1FaTKSRGOfrtXDZBHjfzgT4jHtwsApFw hXMZAMVBz90Fm1qHyJCy4+aCRbtfSZhzjz7QZxnxKaQYApo3lTiM3OHwQuxzO5UPAUSr JzvkNeI4BURFZjATUstE8enzL8f3aJOHSHrx+i0IS9FWs1QVSb8cMA/qwfCl16sN4lyD W6/Hesgi4KjOuqVSB0oKnFrrT2KaQpNl0XCxbEgupK98Tne7ZdFkCLzm5CCyVA/8Lp7c EWaAKNF7CUNE3ht9j1m+OTr1Fna1dMldLox6drulPveA2PnnHeNZuk3egXR7nSVEdCpA TrUg== MIME-Version: 1.0 Received: by 10.52.176.232 with SMTP id cl8mr1692736vdc.115.1339716816509; Thu, 14 Jun 2012 16:33:36 -0700 (PDT) Received: by 10.52.113.97 with HTTP; Thu, 14 Jun 2012 16:33:36 -0700 (PDT) Date: Thu, 14 Jun 2012 19:33:36 -0400 Message-ID: From: Robert Simmons To: freebsd-geom@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Pre-boot authentication / geli-aware bootcode 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: Thu, 14 Jun 2012 23:33:42 -0000 I posted this question to security, but all I got back was the sound of crickets... Would it be possible to make FreeBSD's bootcode aware of geli encrypted volumes? I would like to enter the password and begin decryption so that the kernel and /boot are inside the encrypted volume. Ideally the only unencrypted area of the disk would be the gpt protected mbr and the bootcode. I know that Truecrypt is able to do something like this with its truecrypt boot loader, is something like this possible with FreeBSD without using Truecrypt? From owner-freebsd-geom@FreeBSD.ORG Fri Jun 15 09:31:52 2012 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A2793106566C for ; Fri, 15 Jun 2012 09:31:52 +0000 (UTC) (envelope-from a@carniajeu.com) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 62E1F8FC08 for ; Fri, 15 Jun 2012 09:31:52 +0000 (UTC) Received: by obcni5 with SMTP id ni5so4802786obc.13 for ; Fri, 15 Jun 2012 02:31:51 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:x-originating-ip:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding:x-gm-message-state; bh=cWldynrJZnkdnnt0cZI+NxUYAgwbCNXusAyQJcNDAJI=; b=ZQ09sOS5yt+mbeJyXHSEXitET1CCif8VqiAZLW9AF1Ea3eN6O0Bk/bgEqJPXINTHjT OmGaOmkC8O/G1i+CGnq3vhA8gnRgcYHnPXwDb45FzuCtwsGQOLt1CN2v4NJLv2DiCI+0 OKWBDPhvQB6h2d5XXSFWQei0dQK0rhel7YN64Nbh+VvaLQPaHIIGg1oY8XdTdtQGJbyv tplYLOdZY308Jw0wvuXVpzPs9iS2e9Uh3GfA3Y50HmU4As1bpccQlgfFF0CLJtkvE5pw ZYKSFPUF7mZCa72HIliUHef3+vJExKCyAHjbRaybeuQMK9Zl3IXfR7ulbEqr5NCYSjiQ rM6Q== MIME-Version: 1.0 Received: by 10.60.3.234 with SMTP id f10mr5062083oef.66.1339752711711; Fri, 15 Jun 2012 02:31:51 -0700 (PDT) Sender: a@carniajeu.com Received: by 10.182.15.67 with HTTP; Fri, 15 Jun 2012 02:31:51 -0700 (PDT) X-Originating-IP: [46.53.195.43] In-Reply-To: References: Date: Fri, 15 Jun 2012 12:31:51 +0300 X-Google-Sender-Auth: 6WH_6nSCww5T89wV7TbCye8v9rg Message-ID: From: Alaksiej Carniajeu To: Robert Simmons Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQm2+KowHtURLW4e3F8XKaKXLd5e4S7g4IK58W7wM+ex82Y0oNqwDtsmo6/xa69bZivhP0iY Cc: freebsd-geom@freebsd.org Subject: Re: Pre-boot authentication / geli-aware bootcode 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: Fri, 15 Jun 2012 09:31:52 -0000 Hi, It's not possible. But, you could have your /boot on a bootable usbstick, together with some keyfiles, and start from it. From security point of view, it is even better, than the whole drive encryption TrueCrypt offers, because the former relies on password only. On Fri, Jun 15, 2012 at 2:33 AM, Robert Simmons wrote= : > I posted this question to security, but all I got back was the sound > of crickets... > > Would it be possible to make FreeBSD's bootcode aware of geli encrypted v= olumes? > > I would like to enter the password and begin decryption so that the > kernel and /boot are inside the encrypted volume. =A0Ideally the only > unencrypted area of the disk would be the gpt protected mbr and the > bootcode. > > I know that Truecrypt is able to do something like this with its > truecrypt boot loader, is something like this possible with FreeBSD > without using Truecrypt? > _______________________________________________ > freebsd-geom@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-geom > To unsubscribe, send any mail to "freebsd-geom-unsubscribe@freebsd.org" From owner-freebsd-geom@FreeBSD.ORG Fri Jun 15 11:04:28 2012 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (unknown [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C21FE1065686; Fri, 15 Jun 2012 11:04:28 +0000 (UTC) (envelope-from john@saltant.com) Received: from homiemail-a27.g.dreamhost.com (mailbigip.dreamhost.com [208.97.132.5]) by mx1.freebsd.org (Postfix) with ESMTP id 5A3A88FC08; Fri, 15 Jun 2012 11:04:28 +0000 (UTC) Received: from homiemail-a27.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a27.g.dreamhost.com (Postfix) with ESMTP id 2EC73598060; Fri, 15 Jun 2012 04:04:22 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=saltant.com; h=message-id:date :from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=saltant.com; b=LlvKtZCD2C6JURnxK4+G8qh5JlCovg2Eqoy5pStn2dKccx8ezIl50x63kQ8Mp MGWNJOS8h8Nn8TrhG1C37MBmjTy/oHrCyatqat9FQLgdXuFcxRIAFc2hQ8UgPTpt Sux8KBI92nIjyjf02ahzeV4DnCjC+CwYfLR+dy5n8Iq69M= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=saltant.com; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; s=saltant.com; bh=4O4K1 a3hoXcgGsYpoIyFG6GtpJw=; b=Kd5cV5FNm9wF/sMoM+oSQZuY+y67CNk0vnA8l kSA+49J5y1PPr/2f4cVyuYMAiGBsVOtf8ZoJooR8i7xCFlIe9WrtE6vOmQP5KFiL 9CIxDh3V5aKrVNKUbzwyMc7QbShmYWQKeJaUE0D6MeKbBN7kuKHCvyNnJVlt774c g/nNGo= Received: from imago.y.saltant.net (vice.saltant.net [96.227.187.16]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: john@saltant.com) by homiemail-a27.g.dreamhost.com (Postfix) with ESMTPSA id D2DB359805F; Fri, 15 Jun 2012 04:04:21 -0700 (PDT) Message-ID: <4FDB16B4.4060705@saltant.com> Date: Fri, 15 Jun 2012 07:04:20 -0400 From: "John W. O'Brien" Organization: Saltant Solutions User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: Pawel Jakub Dawidek References: <4FD3B8D5.7030906@saltant.com> <20120610081337.GL1379@garage.freebsd.pl> In-Reply-To: <20120610081337.GL1379@garage.freebsd.pl> X-Enigmail-Version: 1.5pre Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-geom@freebsd.org Subject: Re: Scope and purpose of each kind geli key 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: Fri, 15 Jun 2012 11:04:29 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 06/10/2012 04:13 AM, Pawel Jakub Dawidek wrote: > On Sat, Jun 09, 2012 at 04:57:57PM -0400, John W. O'Brien wrote: >> I recently started using geli and found it necessary to read a >> bunch of source code to supplement the manpages and Handbook >> sections. In particular, there are several different kinds of >> keys (and sources of key material), but they are not clearly >> differentiated in the docs. Of course, one need not understand >> the entire geli architecture and theory of operation in order to >> use it, but a bit more context would make things easier. >> >> So, the purpose of this inquiry is twofold: first, to sanity >> check what I think I learned from my studies; second, to find out >> if others would find it useful for me to take a swipe at >> integrating this information into the docs. > > I think this is great you decided to document it and I'll do my > best to help. I'd also like to see such description to be available > easly and I'd be happy to add it to GELI manual page or create > dedicated manual page with detailed documentation how it works. Ready to entertain comments on the man page round from freebsd-geom@ or pjd@. docs/169089 [geli] [PATCH] geli(8) needs clarity concerning key scope/type/purpose http://www.freebsd.org/cgi/query-pr.cgi?pr=169089 Thank you, John -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJP2xawAAoJEEdKvTwaez9wv54H/iGHOOG/A5N+jCLmthlmYf5r 1vNg5o+7MizMlakA2j8KDu/KJLA2fKRyd3ai6NCISPvxj1yZkzPNqCeK7DqQk01C tX5HC+WdpVy5M8oNAwvXzFlRn6gakzFq1wENODAMYkOY/Iu+JaPfcnmohInYxx0B sAqyGegNvlgJyIgRrq828iadtJTFrbabxrK4qNMBCnlu+xkXh+V2JNtZhKR0Jqsm W7dPJELivpp5FjRyv43209VSZt0lSGMwp9sO4RV9E3mQ/FQ15nVHO+Ml//9V8Tnw a/oJSmcn1Q43Qo/E4D+4P6vsbHR/pt4cj80GGpXbzc0Qws1Zp+3kWjkU/yEkago= =P6tV -----END PGP SIGNATURE----- From owner-freebsd-geom@FreeBSD.ORG Fri Jun 15 20:11:28 2012 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 39C891065672 for ; Fri, 15 Jun 2012 20:11:28 +0000 (UTC) (envelope-from pawel@dawidek.net) Received: from mail.dawidek.net (60.wheelsystems.com [83.12.187.60]) by mx1.freebsd.org (Postfix) with ESMTP id E27BF8FC12 for ; Fri, 15 Jun 2012 20:11:27 +0000 (UTC) Received: from localhost (89-73-195-149.dynamic.chello.pl [89.73.195.149]) by mail.dawidek.net (Postfix) with ESMTPSA id E4099F8E; Fri, 15 Jun 2012 22:11:20 +0200 (CEST) Date: Fri, 15 Jun 2012 22:09:24 +0200 From: Pawel Jakub Dawidek To: "John W. O'Brien" Message-ID: <20120615200924.GE1399@garage.freebsd.pl> References: <4FD3B8D5.7030906@saltant.com> <20120610081337.GL1379@garage.freebsd.pl> <4FDB16B4.4060705@saltant.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Q0rSlbzrZN6k9QnT" Content-Disposition: inline In-Reply-To: <4FDB16B4.4060705@saltant.com> X-OS: FreeBSD 10.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-geom@freebsd.org Subject: Re: Scope and purpose of each kind geli key 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: Fri, 15 Jun 2012 20:11:28 -0000 --Q0rSlbzrZN6k9QnT Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jun 15, 2012 at 07:04:20AM -0400, John W. O'Brien wrote: > Ready to entertain comments on the man page round from freebsd-geom@ > or pjd@. >=20 > docs/169089 > [geli] [PATCH] geli(8) needs clarity concerning key scope/type/purpose > http://www.freebsd.org/cgi/query-pr.cgi?pr=3D169089 Thanks. Could you send the patch here, in your mail? It would be easier to comment on selected parts only. At a glance content seems ok, you just need to polish style a bit. For example in manual pages period ends the line - new setence has to start from new line. You also didn't merge some short lines after your changes. Maybe you could fix that and resend there patch here for final review? --=20 Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://tupytaj.pl --Q0rSlbzrZN6k9QnT Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAk/blnMACgkQForvXbEpPzTMKQCdGxNji0YzTB6c2J1SsNN2rJ4P rmQAoMy1XEtnrOtr+QSz42TC+4OcI4OH =tpFb -----END PGP SIGNATURE----- --Q0rSlbzrZN6k9QnT-- From owner-freebsd-geom@FreeBSD.ORG Fri Jun 15 20:22:19 2012 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A42851065672 for ; Fri, 15 Jun 2012 20:22:19 +0000 (UTC) (envelope-from rsimmons0@gmail.com) Received: from mail-vc0-f182.google.com (mail-vc0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id 5B2ED8FC0A for ; Fri, 15 Jun 2012 20:22:19 +0000 (UTC) Received: by vcbfy7 with SMTP id fy7so2333257vcb.13 for ; Fri, 15 Jun 2012 13:22:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=vpfzP1M8UkRl36O2ajSz5N6Oq0++aeARZdYUvpgdJow=; b=WXXli1Mqk+PuGemhoY9uvcjMcQtEaIeaSR0MoNFBohnOiBzK2sH0dasKx2ZICRBr0V xqXDsabqdRz9v4f6ymuaAJl37foQkGhzP5XOkSzJM0P+7WslBkxSUSUaAz00inYUINhu 52XOKteoJHwXia3yFiTLDqu0o0qBHG3SPfZMGWEaeZgujbIxaCArPfYaK1BdtNzrLe6k 29Q+vEnG9buceuNbsE+Dl/R2Bs3zPL0iEz0Igkv+bNuyC3HyVYC9XdFXMrBnV+jI4ui1 JDt0obEATTFqOucwFjvIMInHUS7ibiP2YX2z2/BfhAzPEezte62fKKUt682XBkEZM88M vjCw== MIME-Version: 1.0 Received: by 10.52.88.176 with SMTP id bh16mr2933903vdb.132.1339791738245; Fri, 15 Jun 2012 13:22:18 -0700 (PDT) Received: by 10.52.113.97 with HTTP; Fri, 15 Jun 2012 13:22:18 -0700 (PDT) In-Reply-To: References: Date: Fri, 15 Jun 2012 16:22:18 -0400 Message-ID: From: Robert Simmons To: freebsd-geom@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: Pre-boot authentication / geli-aware bootcode 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: Fri, 15 Jun 2012 20:22:19 -0000 On Fri, Jun 15, 2012 at 5:31 AM, Alaksiej Carniajeu wrote: > Hi, > > It's not possible. But, you could have your /boot on a bootable > usbstick, together with some keyfiles, and start from it. From > security point of view, it is even better, than the whole drive > encryption TrueCrypt offers, because the former relies on password > only. This is what I thought. Now, if I wanted to add this functionality, I would need to modify: /head/sys/boot/i386/pmbr/pmbr.s and /head/sys/boot/i386/gptboot/gptboot.c Right? From owner-freebsd-geom@FreeBSD.ORG Fri Jun 15 20:26:56 2012 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 16C441065672 for ; Fri, 15 Jun 2012 20:26:56 +0000 (UTC) (envelope-from pawel@dawidek.net) Received: from mail.dawidek.net (60.wheelsystems.com [83.12.187.60]) by mx1.freebsd.org (Postfix) with ESMTP id BBE168FC08 for ; Fri, 15 Jun 2012 20:26:55 +0000 (UTC) Received: from localhost (89-73-195-149.dynamic.chello.pl [89.73.195.149]) by mail.dawidek.net (Postfix) with ESMTPSA id 6C82FF98; Fri, 15 Jun 2012 22:26:54 +0200 (CEST) Date: Fri, 15 Jun 2012 22:24:58 +0200 From: Pawel Jakub Dawidek To: Robert Simmons Message-ID: <20120615202458.GH1399@garage.freebsd.pl> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Cgrdyab2wu3Akvjd" Content-Disposition: inline In-Reply-To: X-OS: FreeBSD 10.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-geom@freebsd.org Subject: Re: Pre-boot authentication / geli-aware bootcode 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: Fri, 15 Jun 2012 20:26:56 -0000 --Cgrdyab2wu3Akvjd Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jun 15, 2012 at 04:22:18PM -0400, Robert Simmons wrote: > On Fri, Jun 15, 2012 at 5:31 AM, Alaksiej Carniajeu wrot= e: > > Hi, > > > > It's not possible. But, you could have your /boot on a bootable > > usbstick, together with some keyfiles, and start from it. From > > security point of view, it is even better, than the whole drive > > encryption TrueCrypt offers, because the former relies on password > > only. >=20 > This is what I thought. Now, if I wanted to add this functionality, I > would need to modify: > /head/sys/boot/i386/pmbr/pmbr.s > and > /head/sys/boot/i386/gptboot/gptboot.c I'd leave pmbr.s alone, it is definiately too early to play with decryption. You need to modify gptboot and loader for UFS or gptzfsboot and zfsloader for ZFS. --=20 Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://tupytaj.pl --Cgrdyab2wu3Akvjd Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAk/bmhoACgkQForvXbEpPzQItQCdFBl4Y/iNxyEe5DwSI6SqkfqH 40MAoMvHlxHlKosMDCYSfHbzdbNkF01k =H+Ne -----END PGP SIGNATURE----- --Cgrdyab2wu3Akvjd-- From owner-freebsd-geom@FreeBSD.ORG Fri Jun 15 20:41:41 2012 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D0326106566B for ; Fri, 15 Jun 2012 20:41:41 +0000 (UTC) (envelope-from rsimmons0@gmail.com) Received: from mail-vc0-f182.google.com (mail-vc0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id 85A178FC08 for ; Fri, 15 Jun 2012 20:41:41 +0000 (UTC) Received: by vcbfy7 with SMTP id fy7so2343702vcb.13 for ; Fri, 15 Jun 2012 13:41:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=tvpQDlFf1NKtbaLb4hrgkP91j9Y44lSf6jFa0Iz2YQc=; b=QiWZpn1/w90mktKsVgFv9wpLRegtE091gCfj8j61YcR1Dfl5BRmOVd9LkT7+/3Lw1W Q+avrNkFKo5O2UIhGqrIisXo0OSpsKQJ9IDvr3kkTVUBKvBRNBxkBQ33rjjA4tiDrgsQ ydv+szSZ6CY/JXy7ZrpPtGvtY5lOMd1d6qKzeh0dQVmbn/SKZkA/v3/Mrku4ABMYMwyz 471ZkpXfPQoRQ441elAgLvNHcO2pg6CiNbWeyp1+KO1lPe0F4zWpL2/NpUfXVCTtRRE7 fhnqKtb57of4N0oTDWq4zXde/d1Fxv2LhUydUxs4Val/9dbeTlZeCE/BKCDCFfgJHGp3 Uu3Q== MIME-Version: 1.0 Received: by 10.220.108.1 with SMTP id d1mr3719470vcp.19.1339792900689; Fri, 15 Jun 2012 13:41:40 -0700 (PDT) Received: by 10.52.113.97 with HTTP; Fri, 15 Jun 2012 13:41:40 -0700 (PDT) In-Reply-To: <20120615202458.GH1399@garage.freebsd.pl> References: <20120615202458.GH1399@garage.freebsd.pl> Date: Fri, 15 Jun 2012 16:41:40 -0400 Message-ID: From: Robert Simmons To: freebsd-geom@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: Pre-boot authentication / geli-aware bootcode 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: Fri, 15 Jun 2012 20:41:41 -0000 On Fri, Jun 15, 2012 at 4:24 PM, Pawel Jakub Dawidek wrot= e: > On Fri, Jun 15, 2012 at 04:22:18PM -0400, Robert Simmons wrote: >> On Fri, Jun 15, 2012 at 5:31 AM, Alaksiej Carniajeu wro= te: >> > Hi, >> > >> > It's not possible. But, you could have your /boot on a bootable >> > usbstick, together with some keyfiles, and start from it. From >> > security point of view, it is even better, than the whole drive >> > encryption TrueCrypt offers, because the former relies on password >> > only. >> >> This is what I thought. =A0Now, if I wanted to add this functionality, I >> would need to modify: >> /head/sys/boot/i386/pmbr/pmbr.s >> and >> /head/sys/boot/i386/gptboot/gptboot.c > > I'd leave pmbr.s alone, it is definiately too early to play with > decryption. You need to modify gptboot and loader for UFS or gptzfsboot > and zfsloader for ZFS. All of the decryption work is handled by the geom_eli kernel module, correct? I would assume that looking at the code in /head/sys/geom/eli and seeing how it's done there would be a good place to start. From owner-freebsd-geom@FreeBSD.ORG Fri Jun 15 22:16:59 2012 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 9794C106566B; Fri, 15 Jun 2012 22:16:59 +0000 (UTC) (envelope-from john@saltant.com) Received: from homiemail-a97.g.dreamhost.com (caiajhbdcbbj.dreamhost.com [208.97.132.119]) by mx1.freebsd.org (Postfix) with ESMTP id 63A0F8FC12; Fri, 15 Jun 2012 22:16:59 +0000 (UTC) Received: from homiemail-a97.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a97.g.dreamhost.com (Postfix) with ESMTP id 24A3128606F; Fri, 15 Jun 2012 15:16:53 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=saltant.com; h=message-id:date :from:mime-version:to:cc:subject:references:in-reply-to: content-type; q=dns; s=saltant.com; b=DKNHCYwA+igRoZWWgKA1F5ZQQ8 5J3lN3ohhOoy+zg4v0LrixSQfmcDAGXec2m2JwktA5wBBR8MKjdKT3PahHMSvgVg /tDwxM35Tw+wRLZrWeRoFTz4Cfgrbub5wH6nCUtYFzEd3nM9cWc2y9jr4dSsi/Cs pY9UHFyOnneB9FHR8= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=saltant.com; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to: content-type; s=saltant.com; bh=N3BaAVgVWh6ToauSJhrNxoLcVuI=; b= oZofgxH+QgfXxeQI2TJbHd3BRjjKsN+YoROLRE6n5VPDPM3tg5/tCjL3uQV6+Vbp GmFsB/XVjGSMRVk76K9rOTJxE3g4Dag//RaXCLcj3zFc3MvKSO2z0kPFRnN8VY+U r8zue0K76ZypUfSZ7Sy0Ly/tPyOO21Du9ELmb35M04I= Received: from imago.y.saltant.net (vice.saltant.net [96.227.187.16]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: john@saltant.com) by homiemail-a97.g.dreamhost.com (Postfix) with ESMTPSA id 98F18286057; Fri, 15 Jun 2012 15:16:52 -0700 (PDT) Message-ID: <4FDBB453.9060806@saltant.com> Date: Fri, 15 Jun 2012 18:16:51 -0400 From: "John W. O'Brien" Organization: Saltant Solutions User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: Pawel Jakub Dawidek References: <4FD3B8D5.7030906@saltant.com> <20120610081337.GL1379@garage.freebsd.pl> <4FDB16B4.4060705@saltant.com> <20120615200924.GE1399@garage.freebsd.pl> In-Reply-To: <20120615200924.GE1399@garage.freebsd.pl> X-Enigmail-Version: 1.5pre Content-Type: multipart/mixed; boundary="------------040109030201030204020602" Cc: freebsd-geom@freebsd.org Subject: Re: Scope and purpose of each kind geli key 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: Fri, 15 Jun 2012 22:16:59 -0000 This is a multi-part message in MIME format. --------------040109030201030204020602 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 06/15/2012 04:09 PM, Pawel Jakub Dawidek wrote: > On Fri, Jun 15, 2012 at 07:04:20AM -0400, John W. O'Brien wrote: >> Ready to entertain comments on the man page round from >> freebsd-geom@ or pjd@. >> >> docs/169089 [geli] [PATCH] geli(8) needs clarity concerning key >> scope/type/purpose >> http://www.freebsd.org/cgi/query-pr.cgi?pr=169089 > > Thanks. Could you send the patch here, in your mail? It would be > easier to comment on selected parts only. At a glance content seems > ok, you just need to polish style a bit. For example in manual > pages period ends the line - new setence has to start from new > line. You also didn't merge some short lines after your changes. > Maybe you could fix that and resend there patch here for final > review? Gladly. Those details of the preferred man page style were not evident. Amusingly, I actually started by merging all short lines, which would have been wrong because of the new sentence rule. Then I overrode myself because of an ingrained drive to minimize the diff, and un-merged everything. In any case, I think I caught all (new) style violations in the attached revision. Cheers, John -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJP27RTAAoJEEdKvTwaez9w/fMIAKuyvqYtFI2wgfcrtS4z4IeV 7dx1RTjXfMOta1SZ8dIVMzdjwfDA3mOHiGTO3fElBGDcNu46wMRb5ebXlMvRla0D MBuKOsnbghjGsbTxAsU4IpL+yFH4GzK4N0QKFiK49iKHevsjsCupUxhO8HjbrvD+ V2lZINAv92dooJ1RtsO/ZUbE71PlRJRYUh7e6wg9HRKplj9ToygTB1o6e2hRMzKe JBH3GEr2sknvhA5YUu8KQX81wyPEukAXF08JKm+nVkQgiEf4BxvsLK1ir3sf9TpC Ege4nVuBwcAKrcsZyIYw5sUqmBqpEgHFmLoiAN+37PY3GhdXcJyCRg1PZGsfMbU= =XVlQ -----END PGP SIGNATURE----- --------------040109030201030204020602 Content-Type: text/plain; charset=UTF-8; name="patch-head_sbin_geom_class_eli_geli.8-1.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="patch-head_sbin_geom_class_eli_geli.8-1.txt" Index: geli.8 =================================================================== --- geli.8 (revision 236978) +++ geli.8 (working copy) @@ -24,7 +24,7 @@ .\" .\" $FreeBSD$ .\" -.Dd April 28, 2012 +.Dd June 15, 2012 .Dt GELI 8 .Os .Sh NAME @@ -58,7 +58,7 @@ .Op Fl i Ar iterations .Op Fl J Ar newpassfile .Op Fl K Ar newkeyfile -.Op Fl l Ar keylen +.Op Fl l Ar datakeylen .Op Fl s Ar sectorsize .Op Fl V Ar version .Ar prov @@ -83,7 +83,7 @@ .Op Fl d .Op Fl a Ar aalgo .Op Fl e Ar ealgo -.Op Fl l Ar keylen +.Op Fl l Ar datakeylen .Op Fl s Ar sectorsize .Ar prov .Nm @@ -186,14 +186,15 @@ or .Nm HMAC/SHA512 . .It -Can create a key from a couple of components (user entered passphrase, random -bits from a file, etc.). +Can create a User Key from up to two, piecewise components: a passphrase +entered via prompt or read from one or more passfiles; a keyfile read from +one or more files. .It Allows encryption of the root partition. The user will be asked for the passphrase before the root file system is mounted. .It -The passphrase of the user is strengthened with: +Strengthens the passphrase component of the User Key with: .Rs .%A B. Kaliski .%T "PKCS #5: Password-Based Cryptography Specification, Version 2.0." @@ -201,7 +202,7 @@ .%N 2898 .Re .It -Allows the use of two independent keys (e.g., a +Allows the use of two independent User Keys (e.g., a .Qq "user key" and a .Qq "company key" ) . @@ -210,8 +211,8 @@ .Nm performs simple sector-to-sector encryption. .It -Allows Master Keys to be backed up and restored, -so that if a user has to quickly destroy his keys, +Allows the encrypted Master Key to be backed up and restored, +so that if a user has to quickly destroy key material, it is possible to get the data back by restoring keys from backup. .It @@ -219,8 +220,8 @@ (so users do not have to remember to detach providers after unmounting the file systems). .It -Allows attaching a provider with a random, one-time key - useful for swap -partitions and temporary file systems. +Allows attaching a provider with a random, one-time Master Key - +useful for swap partitions and temporary file systems. .It Allows verification of data integrity (data authentication). .It @@ -233,7 +234,8 @@ .Bl -tag -width ".Cm configure" .It Cm init Initialize the provider which needs to be encrypted. -Here you can set up the cryptographic algorithm to use, key length, etc. +Here you can set up the cryptographic algorithm to use, Data Key length, +etc. The last sector of the provider is used to store metadata. The .Cm init @@ -289,37 +291,58 @@ The default and recommended algorithm is .Nm AES-XTS . .It Fl i Ar iterations -Number of iterations to use with PKCS#5v2. +Number of iterations to use with PKCS#5v2 when processing User Key +passphrase component. If this option is not specified, .Nm will find the number of iterations which is equal to 2 seconds of crypto work. If 0 is given, PKCS#5v2 will not be used. +PKCS#5v2 processing is performed once, after all parts of the passphrase +component have been read. .It Fl J Ar newpassfile -Specifies a file which contains the passphrase or its part. +Specifies a file which contains the passphrase component of the User Key +(or part of it). If .Ar newpassfile is given as -, standard input will be used. Only the first line (excluding new-line character) is taken from the given file. -This argument can be specified multiple times. +This argument can be specified multiple times, which has the effect of +reassembling a single passphrase split across multiple files. +Cannot be combined with the +.Fl P +option. .It Fl K Ar newkeyfile -Specifies a file which contains part of the key. +Specifies a file which contains the keyfile component of the User Key +(or part of it). If .Ar newkeyfile is given as -, standard input will be used. -This argument can be specified multiple times. -.It Fl l Ar keylen -Key length to use with the given cryptographic algorithm. -If not given, the default key length for the given algorithm is used, which is: -128 for -.Nm AES-XTS , -.Nm AES-CBC , -.Nm Blowfish-CBC -and -.Nm Camellia-CBC -and 192 for -.Nm 3DES-CBC . +This argument can be specified multiple times, which has the effect of +reassembling a single keyfile split across multiple keyfile parts. +.It Fl l Ar datakeylen +Data Key length to use with the given cryptographic algorithm. +If the length is not specified, the selected algorithm uses its +.Em default +key length. +.Bl -ohang -offset indent +.It Nm AES-XTS +.Em 128 , +256 +.It Nm AES-CBC , Nm Camilla-CBC +.Em 128 , +192, +256 +.It Nm Blowfish-CBC +.Em 128 ++ n * 32, for n=[0..10] +.It Nm 3DES-CBC +.Em 192 +.El .It Fl P -Do not use passphrase as the key component. +Do not use a passphrase as a component of the User Key. +Cannot be combined with the +.Fl J +option. .It Fl s Ar sectorsize Change decrypted provider's sector size. Increasing the sector size allows increased performance, @@ -337,9 +360,9 @@ .El .It Cm attach Attach the given provider. -The master key will be decrypted using the given -passphrase/keyfile and a new GEOM provider will be created using the given -provider's name with an +The encrypted Master Key will be loaded from the metadata and decrypted +using the given passphrase/keyfile and a new GEOM provider will be created +using the given provider's name with an .Qq .eli suffix. .Pp @@ -357,28 +380,33 @@ .Cm detach subcommand. .It Fl j Ar passfile -Specifies a file which contains the passphrase or its part. +Specifies a file which contains the passphrase component of the User Key +(or part of it). For more information see the description of the .Fl J option for the .Cm init subcommand. .It Fl k Ar keyfile -Specifies a file which contains part of the key. +Specifies a file which contains the keyfile component of the User Key +(or part of it). For more information see the description of the .Fl K option for the .Cm init subcommand. .It Fl p -Do not use passphrase as the key component. +Do not use a passphrase as a component of the User Key. +Cannot be combined with the +.Fl j +option. .It Fl r Attach read-only provider. It will not be opened for writing. .El .It Cm detach Detach the given providers, which means remove the devfs entry -and clear the keys from memory. +and clear the Master Key and Data Keys from memory. .Pp Additional options include: .Bl -tag -width ".Fl f" @@ -391,7 +419,7 @@ last time even if it was only opened for reading. .El .It Cm onetime -Attach the given providers with random, one-time keys. +Attach the given providers with a random, one-time (ephemeral) Master Key. The command can be used to encrypt swap partitions or temporary file systems. .Pp Additional options include: @@ -414,8 +442,8 @@ For more information, see the description of the .Cm attach subcommand. -.It Fl l Ar keylen -Key length to use with the given cryptographic algorithm. +.It Fl l Ar datakeylen +Data Key length to use with the given cryptographic algorithm. For more information, see the description of the .Cm init subcommand. @@ -439,15 +467,18 @@ Remove the BOOT flag from the given providers. .El .It Cm setkey -Change or setup (if not yet initialized) selected key. -There is one master key, which can be encrypted with two independent user keys. +Install a copy of the Master Key into the selected slot, encrypted with +a new User Key. +If the selected slot is populated, replace the existing copy. +A provider has one Master Key, which can be stored in one or both slots, +each encrypted with an independent User Key. With the .Cm init subcommand, only key number 0 is initialized. -The key can always be changed: for an attached provider, +The User Key can be changed at any time: for an attached provider, for a detached provider, or on the backup file. When a provider is attached, the user does not have to provide -an old passphrase/keyfile. +an existing passphrase/keyfile. .Pp Additional options include: .Bl -tag -width ".Fl J Ar newpassfile" @@ -458,44 +489,54 @@ .Cm setkey subcommand, only one key has to be defined and this key must be changed. .It Fl j Ar passfile -Specifies a file which contains the old passphrase or its part. +Specifies a file which contains the passphrase component of a current User Key +(or part of it). .It Fl J Ar newpassfile -Specifies a file which contains the new passphrase or its part. +Specifies a file which contains the passphrase component of the new User Key +(or part of it). .It Fl k Ar keyfile -Specifies a file which contains part of the old key. +Specifies a file which contains the keyfile component of a current User Key +(or part of it). .It Fl K Ar newkeyfile -Specifies a file which contains part of the new key. +Specifies a file which contains the keyfile component of the new User Key +(or part of it). .It Fl n Ar keyno -Specifies the number of the key to change (could be 0 or 1). +Specifies the index number of the Master Key copy to change (could be 0 or 1). If the provider is attached and no key number is given, the key used for attaching the provider will be changed. If the provider is detached (or we are operating on a backup file) -and no key number is given, the key decrypted with the passphrase/keyfile -will be changed. +and no key number is given, the first Master Key copy to be successfully +decrypted with the provided User Key passphrase/keyfile will be changed. .It Fl p -Do not use passphrase as the old key component. +Do not use a passphrase as a component of the current User Key. +Cannot be combined with the +.Fl j +option. .It Fl P -Do not use passphrase as the new key component. +Do not use a passphrase as a component of the new User Key. +Cannot be combined with the +.Fl J +option. .El .It Cm delkey -Destroy (overwrite with random data) the selected key. +Destroy (overwrite with random data) the selected Master Key copy. If one is destroying keys for an attached provider, the provider -will not be detached even if all keys are destroyed. +will not be detached even if all copies of the Master Key are destroyed. It can even be rescued with the .Cm setkey -subcommand. +subcommand because the Master Key is still in memory. .Pp Additional options include: .Bl -tag -width ".Fl a Ar keyno" .It Fl a -Destroy all keys (does not need +Destroy all copies of the Master Key (does not need .Fl f option). .It Fl f Force key destruction. -This option is needed to destroy the last key. +This option is needed to destroy the last copy of the Master Key. .It Fl n Ar keyno -Specifies the key number. +Specifies the index number of the Master Key copy. If the provider is attached and no key number is given, the key used for attaching the provider will be destroyed. If provider is detached (or we are operating on a backup file) the key number @@ -503,8 +544,8 @@ .El .It Cm kill This command should be used only in emergency situations. -It will destroy all the keys on a given provider and will detach it forcibly -(if it is attached). +It will destroy all copies of the Master Key on a given provider and will +detach it forcibly (if it is attached). This is absolutely a one-way command - if you do not have a metadata backup, your data is gone for good. In case the provider was attached with the @@ -542,8 +583,8 @@ .El .It Cm suspend Suspend device by waiting for all inflight requests to finish, clearing all -sensitive information (like keys) from kernel memory, and blocking all -further I/O requests until the +sensitive information (like the Master Key and Data Keys) from kernel memory, +and blocking all further I/O requests until the .Cm resume subcommand is executed. This functionality is useful for laptops: when one wants to suspend a @@ -553,8 +594,8 @@ the .Cm suspend subcommand can be used. -Any access to the encrypted device will be blocked until the keys are -recovered through the +Any access to the encrypted device will be blocked until the Master Key is +reloaded through the .Cm resume subcommand. Thus there is no need to close nor unmount anything. @@ -584,21 +625,26 @@ Additional options include: .Bl -tag -width ".Fl j Ar passfile" .It Fl j Ar passfile -Specifies a file which contains the passphrase or its part. +Specifies a file which contains the passphrase component of the User Key +(or part of it). For more information see the description of the .Fl J option for the .Cm init subcommand. .It Fl k Ar keyfile -Specifies a file which contains part of the key. +Specifies a file which contains the keyfile component of the User Key +(or part of it). For more information see the description of the .Fl K option for the .Cm init subcommand. .It Fl p -Do not use passphrase as the key component. +Do not use a passphrase as a component of the User Key. +Cannot be combined with the +.Fl j +option. .El .It Cm resize Inform @@ -626,6 +672,9 @@ subcommand will print metadata version used by each of them. .It Cm clear Clear metadata from the given providers. +.Em WARNING : +This will erase with zeros the encrypted Master Key copies stored in the +metadata. .It Cm dump Dump metadata stored on the given providers. .It Cm list @@ -647,6 +696,36 @@ .It Fl v Be more verbose. .El +.Sh KEY SUMMARY +.Ss Master Key +Upon +.Cm init , +the +.Nm +utility generates a random Master Key for the provider. +The Master Key never changes during the lifetime of the provider. +Each copy of the provider metadata, active or backed up to a file, can store +up to two, independently-encrypted copies of the Master Key. +.Ss User Key +Each stored copy of the Master Key is encrypted with a User Key, which +is generated by the +.Nm +utility from a passphrase and/or a keyfile. +The +.Nm +utility first reads all parts of the keyfile in the order specified on the +command line, then reads all parts of the stored passphrase in the order +specified on the command line. +If no passphrase parts are specified, the system prompts the user to enter +the passphrase. +The passphrase is optionally strengthened by PKCS#5v2. +The User Key is a digest computed over the concatenated keyfile and passphrase. +.Ss Data Key +During operation, one or more Data Keys are deterministically derived by +the kernel from the Master Key and cached in memory. +The number of Data Keys used by a given provider, and the way they are +derived, depend on the GELI version and whether the provider is configured to +use data authentication. .Sh SYSCTL VARIABLES The following .Xr sysctl 8 @@ -677,7 +756,7 @@ This variable should be set in .Pa /boot/loader.conf . .It Va kern.geom.eli.overwrites : No 5 -Specifies how many times the Master-Key will be overwritten +Specifies how many times the Master Key will be overwritten with random values when it is destroyed. After this operation it is filled with zeros. .It Va kern.geom.eli.visible_passphrase : No 0 @@ -699,18 +778,19 @@ crypto requests with one interrupt. The crypto card and the driver has to support this feature. .It Va kern.geom.eli.key_cache_limit : No 8192 -Specifies how many encryption keys to cache. +Specifies how many Data Keys to cache. The default limit (8192 keys) will allow caching of all keys for a 4TB provider with 512 byte sectors and will take around 1MB of memory. .It Va kern.geom.eli.key_cache_hits -Reports how many times we were looking up a key and it was already in cache. -This sysctl is not updated for providers that need less keys than the limit -specified in +Reports how many times we were looking up a Data Key and it was already in +cache. +This sysctl is not updated for providers that need fewer Data Keys than +the limit specified in .Va kern.geom.eli.key_cache_limit . .It Va kern.geom.eli.key_cache_misses -Reports how many times we were looking up a key and it was not in cache. -This sysctl is not updated for providers that need fewer keys than the limit +Reports how many times we were looking up a Data Key and it was not in cache. +This sysctl is not updated for providers that need fewer Data Keys than the limit specified in .Va kern.geom.eli.key_cache_limit . .El @@ -738,7 +818,7 @@ # geli detach da2.eli .Ed .Pp -Create an encrypted provider, but use two keys: +Create an encrypted provider, but use two User Keys: one for your employee and one for you as the company's security officer (so it's not a tragedy if the employee .Qq accidentally @@ -760,7 +840,7 @@ # dd if=/dev/random of=/mnt/pendrive/keys/`hostname` bs=64 count=1 # geli init -P -K /mnt/pendrive/keys/`hostname` /dev/ad0s1e # geli backup /dev/ad0s1e /mnt/pendrive/backups/`hostname` -(use key number 0, so the encrypted Master Key will be overwritten by this) +(use key number 0, so the encrypted Master Key will be re-encrypted by this) # geli setkey -n 0 -k /mnt/pendrive/keys/`hostname` /dev/ad0s1e (allow the user to enter his passphrase) Enter new passphrase: @@ -776,8 +856,8 @@ .Pp The example below shows how to configure two providers which will be attached on boot (before the root file system is mounted). -One of them is using passphrase and three keyfiles and the other is using only a -keyfile: +One of them is using passphrase and three keyfile parts and the other is +using only a keyfile in one part: .Bd -literal -offset indent # dd if=/dev/random of=/dev/da0 bs=1m # dd if=/dev/random of=/boot/keys/da0.key0 bs=32k count=1 --------------040109030201030204020602 Content-Type: application/octet-stream; name="patch-head_sbin_geom_class_eli_geli.8-1.txt.sig" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="patch-head_sbin_geom_class_eli_geli.8-1.txt.sig" iQEcBAABAgAGBQJP27RTAAoJEEdKvTwaez9wKM8H+wX2rtl3V2Utwc/uH+qD+uQevdhq8kEF Jw5n6SaFpY07k64LVXHxmz5N1mPARJkzlmHC7vHXLywnhmIZPvByOSD8E7Niv27htbvTT19g NL2S86MbgYlte4af/6C2W28IuIKH+Lpfygn7PukQFAiFXWWMdJ3xg2ypgEpZtAkNl6vljfBS UuoTn+w7kdMURSmGq/fZ5oJscNOJFCV4Cl+KkkLQtowAI/eKqa5tXmVcB2vcidAlwIdHwyQg OtvDGi6GrbG3+bjz901qmZwIf+D6JiCEOSZA+PUiCULYy+jv0EVgW7u990mtwypJ5lI/0jhS SaV3gszDHRc9DPM2fqhKGOQ= --------------040109030201030204020602--