From owner-freebsd-geom@FreeBSD.ORG Mon Dec 30 22:07:15 2013 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B02A3D31 for ; Mon, 30 Dec 2013 22:07:15 +0000 (UTC) Received: from anubis.delphij.net (anubis.delphij.net [IPv6:2001:470:1:117::25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 8F77D1514 for ; Mon, 30 Dec 2013 22:07:15 +0000 (UTC) Received: from zeta.ixsystems.com (unknown [69.198.165.132]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by anubis.delphij.net (Postfix) with ESMTPSA id 0085E268E7; Mon, 30 Dec 2013 14:07:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=delphij.net; s=anubis; t=1388441235; bh=cvUpAfRHpSXYZMJtC69CmAI/2ttElrl2yIFKbM1x2Xg=; h=Date:From:Reply-To:To:Subject:References:In-Reply-To; b=M0m6mKXrNxqXjM2fuR7qDAntajtBiAg0Ie8lfPXEp1V1K972S7fBP6iWW3CcK/Oo1 9oYfclRUV3xvZZ7IZDVSFFYOVdy0cow+i7GMV57RCR7N+p+vVeFH2CbnU054gQujk6 Bzm/+a4mt9Rckp8qv0wkLCMNGrrbPC12L6cvPWng= Message-ID: <52C1EE92.1020704@delphij.net> Date: Mon, 30 Dec 2013 14:07:14 -0800 From: Xin Li Organization: The FreeBSD Project MIME-Version: 1.0 To: Isaac Huff , freebsd-geom@freebsd.org Subject: Re: GELI safe to reboot without detach? References: In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: d@delphij.net List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Dec 2013 22:07:15 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 12/30/13 13:40, Isaac Huff wrote: > Is it necessary from a reliability and/or security standpoint to > detach GELI volumes before rebooting? Specifically, if I unmount > the filesystem, but do not detach (and disable auto-detach) - do I > risk data corruption or leakage of private keys during a normal > reboot process? Data corruption -- no. geli(4) does not rewrite its metadata at runtime unless when doing rare operations like rekey, etc., so you don't have a lot of chance overwriting them. Leakage of private keys -- depends, but in most cases no. What 'geli detach' does is essentially wiping out the in-core copy of private key. By rebooting without detaching, it is possible that geli(4) leave the private key in memory. Note that this in most scenarios do not necessarily facilitate an actual attack because on most systems the BIOS would zero out all physical memory on boot, even when it doesn't, the booting OS has to be very careful not to reuse these memory in order to be able to retrieve the encryption keys. > Are there any risks at all to rebooting without detach? I have > been searching the list archives and can't seem to find a statement > either way. In theory, it's possible that a compromised BIOS or boot sector would be able to get your geli(4) keys if there is no detach prior to reboot. However I wouldn't be too concerned with this because that means your operating system is likely to be compromised already, too, and injecting code there is much easier than dumping all memory then find out the secret. That's ssaid, not detaching geli provider is not a very good idea but the consequence for average people is very limited. Cheers, - -- Xin LI https://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJSwe6SAAoJEJW2GBstM+ns4/8P/1ZB+EeqnhLdj8Bb2UQShRCC x9lXaFasS6kDjiVZ5Ssm3Q0/18MVFqfGNEf7dt+M6666+xl44mRDYI4AFV8ZLSq8 5INq9kt5tZdes4NP4+0R3HBFxPevoPNDxJ6Bincl6ydLTmNGSHy9eQqGfhYke6Mw 0GZnYMEfn8bnaz53wIAZe4dlYphWJGS67XmhlWUIvV21RvAE6lIrAsLKv8NCu8d2 st2jexAntC/pBOc+ZGVLI7qkWT/gNeMl2QetF0e2u2PxXXaMaZScADhJrkrrEC7f sWpxWd6F86hW3qaYtYZ+IwcYJmMZkdjHJgXtbDPkYZ/LuW2/3ZuOdC4ui2YFHxJY PxRkzaGon0fAdD8LM328DFdf6VC3Dq3FvKSMMXnWFB7p/3XmaAGQ4t1d997Kl6BZ rL0Le6MjqJ7Tg3025YB/iGe4/Ddf/c5xvgHYtouPDDzD3h50aK454G7Gasm3izUh pPjsT4IHD6hPPGL7oeuWSc1bzJPCyavnSdOXzdpDUxRfq1Zk8f+SXaKkA/DGdPlk XFxag7G8LPqQDseZ46Bc+/1uxIp5ufO+wgF+9tvn87AFTQFSD4S8dyR/esyqofI1 UOh3fIjeY+uEhRPSeqY4iHZWUP2vEI7oO1m+4T0yB04HOkjm+poNsdyBfL3aPsTv +O+FxD7zz4KoSNgu5LeQ =QRco -----END PGP SIGNATURE-----