From owner-freebsd-geom@FreeBSD.ORG Mon Dec 30 11:06:45 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 8F652F20 for ; Mon, 30 Dec 2013 11:06:45 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 7A72E10F3 for ; Mon, 30 Dec 2013 11:06:45 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id rBUB6jbT058081 for ; Mon, 30 Dec 2013 11:06:45 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id rBUB6jpl058079 for freebsd-geom@FreeBSD.org; Mon, 30 Dec 2013 11:06:45 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 30 Dec 2013 11:06:45 GMT Message-Id: <201312301106.rBUB6jpl058079@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 Subject: Current problem reports assigned to freebsd-geom@FreeBSD.org X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list 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 11:06:45 -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 -------------------------------------------------------------------------------- o kern/183866 geom [geom] graid cannot remove loader detected BIOS RAIDS o kern/183803 geom [geom] FreeBSD 10 Beta 2 geom module does not understa o kern/181704 geom [geom] ggatec crash the system when I write something o kern/179889 geom [geli] geli stopped work after updating RELEASE 9.* so o kern/178684 geom gpart(8) cannot get my GEOM tree o kern/178359 geom [geom] [patch] geom_eli: support external metadata o kern/176744 geom [geom] [patch] BIO_FLUSH not recorded by devstats o kern/170038 geom [geom] geom_mirror always starts degraded after reboot o kern/169539 geom [geom] [patch] fix ability to run gmirror on MSI MegaR a bin/169077 geom bsdinstall(8) does not use partition labels in /etc/fs 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/162690 geom [geom] gpart label changes only take effect after a re 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 bin/161807 geom [patch] add option for explicitly specifying metadata 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/160409 geom [geli] failed to attach provider f kern/159595 geom [geom] [panic] panic on gmirror unload in vbox [regres f kern/159414 geom [isp] isp(4)+gmultipath(8) : removing active fiber pat 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 bin/154570 geom [patch] gvinum(8) can't be built as part of the kernel 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/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 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. 80 problems total. From owner-freebsd-geom@FreeBSD.ORG Mon Dec 30 21:40:26 2013 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EE5CD50F for ; Mon, 30 Dec 2013 21:40:26 +0000 (UTC) Received: from mail-ob0-f171.google.com (mail-ob0-f171.google.com [209.85.214.171]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B77D212E0 for ; Mon, 30 Dec 2013 21:40:26 +0000 (UTC) Received: by mail-ob0-f171.google.com with SMTP id wp18so12121995obc.16 for ; Mon, 30 Dec 2013 13:40:25 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=iDpRc9EpQtyhWmzPyLcu/7+V940JgIAfhxrUXQezpdA=; b=KV0ptweOks3MIkv7lOElIt5E8Fp9BY9Mmztd1f7rNzZ6qEF/nCVyuzdJw36q0cCDSU rFNUzRpptxlL6bSS7C8hVXHz59PcHxaH3K923ABkBo1TkDTOTYFIDXz0YmOUIkYvy/0I qk/+47WhT1z7V/yY99+B6d30Aq0ZkVOylk1N//eDhRPmzO9KeRAhqQREEx41nFybrBm4 BO2+eim1K2jurkxJUrYxuGzn5mBdQODmurMkVivWJMiwP5oh1gbZQWKb8jAIpQHzimZY JJlh0noSRGvKBA/h1rjc0JI8aWijLJptVa5B/cLr8+6IdHBQLpp+qUTdzNMfLT+yG+OX GHdQ== X-Gm-Message-State: ALoCoQk3nHDeQP/GtuacJRem4OJuh0DUun1P3L2HVdXVSVCF/tOLl5eOq727wWdhfomqKS2P8wpv MIME-Version: 1.0 X-Received: by 10.60.80.137 with SMTP id r9mr13194741oex.30.1388439625506; Mon, 30 Dec 2013 13:40:25 -0800 (PST) Received: by 10.76.123.35 with HTTP; Mon, 30 Dec 2013 13:40:25 -0800 (PST) Date: Mon, 30 Dec 2013 16:40:25 -0500 Message-ID: Subject: GELI safe to reboot without detach? From: Isaac Huff To: freebsd-geom@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list 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 21:40:27 -0000 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? 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. Thank you, Isaac Huff 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----- From owner-freebsd-geom@FreeBSD.ORG Mon Dec 30 22:58:54 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 9381912E for ; Mon, 30 Dec 2013 22:58:54 +0000 (UTC) Received: from mail.tdx.com (mail.tdx.com [62.13.128.18]) by mx1.freebsd.org (Postfix) with ESMTP id 1CC3A18C2 for ; Mon, 30 Dec 2013 22:58:53 +0000 (UTC) Received: from study64.tdx.co.uk (study64.tdx.co.uk [62.13.130.231]) (authenticated bits=0) by mail.tdx.com (8.14.3/8.14.3/) with ESMTP id rBUMwh9H066925 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 30 Dec 2013 22:58:45 GMT Date: Mon, 30 Dec 2013 22:58:43 +0000 From: Karl Pielorz To: freebsd-geom@freebsd.org Subject: HAST + GELI? Message-ID: X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list 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:58:54 -0000 Hi All, As I don't currently have the requisite two boxes to try this... Is it likely / possible you can use HAST with GELI? - i.e. to have a highly available, but encrypted-on-disk device? If so are you better of creating GELI devices (i.e. .eli) and running HAST on those, or creating HAST devices - and running GELI on those? Thanks, -Karl From owner-freebsd-geom@FreeBSD.ORG Mon Dec 30 23:24:54 2013 Return-Path: Delivered-To: freebsd-geom@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C1569797 for ; Mon, 30 Dec 2013 23:24:54 +0000 (UTC) Received: from mail.tdx.com (mail.tdx.com [62.13.128.18]) by mx1.freebsd.org (Postfix) with ESMTP id 899B11A5E for ; Mon, 30 Dec 2013 23:24:54 +0000 (UTC) Received: from study64.tdx.co.uk (study64.tdx.co.uk [62.13.130.231]) (authenticated bits=0) by mail.tdx.com (8.14.3/8.14.3/) with ESMTP id rBUNOqlc069822 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 30 Dec 2013 23:24:53 GMT Date: Mon, 30 Dec 2013 23:24:52 +0000 From: Karl Pielorz To: Miroslav Lachman <000.fbsd@quip.cz>, freebsd-geom@FreeBSD.org Subject: Re: Is TRIM working with gmirror? Message-ID: <18C59233568D3A475FF0D843@study64.tdx.co.uk> In-Reply-To: <52A90049.7050001@quip.cz> References: <52A90049.7050001@quip.cz> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list 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 23:24:54 -0000 --On 12 December 2013 01:16:09 +0100 Miroslav Lachman <000.fbsd@quip.cz> wrote: > Is TRIM working on gmirror? > > I have FreeBSD 8.4-RELEASE-p1 amd64 GENERIC machine with 2x SSDs: ... > But there is a WARNING at boot: > > WARNING: /ssd_db: TRIM flag on fs but disk does not confirm that it > supports TRIM > > The filesystem is classic UFS2. > > Is TRIM supported throught gmirror, or not? I think 8.4 is way too old for this. I have a number of 9.2 boxes - and even on those, TRIM doesn't propagate through gmirror *yet* (at the time, which is a few months ago I seem to remember reading 'It should work soon' - but 9.2 doesn't appear to). You can use gstat to show if any calls to BIO_DELETE are being made - i.e. gstat -d On the systems here the 'd/s' (which afaik is 'BIO_DELETE/second') remains stubbornly at zero :( The flipside is with decent SSD's these days TRIM isn't quite so important... Some may even argue that *not* issuing heaps of BIO_DELETE on the I/O channel is actually faster - so long as the SSD has time to play catchup and isn't pegged all the time, I think they may be right :-) -Karl From owner-freebsd-geom@FreeBSD.ORG Tue Dec 31 22:03:47 2013 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3357E7E6 for ; Tue, 31 Dec 2013 22:03:47 +0000 (UTC) Received: from cargobay.net (cargobay.net [162.220.58.155]) by mx1.freebsd.org (Postfix) with ESMTP id 10DF513D7 for ; Tue, 31 Dec 2013 22:03:46 +0000 (UTC) Received: from [192.168.0.16] (unknown [65.35.151.3]) by cargobay.net (Postfix) with ESMTPSA id A746E1D84; Tue, 31 Dec 2013 22:03:06 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) Subject: Re: HAST + GELI? From: "Chad J. Milios" X-Mailer: iPhone Mail (11B554a) In-Reply-To: Date: Tue, 31 Dec 2013 17:03:33 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <49C17592-B51C-42E5-BF04-8BC4D97DA108@ccsys.com> References: To: Karl Pielorz Cc: "freebsd-geom@freebsd.org" X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Dec 2013 22:03:47 -0000 Either way works great. Both ways have their benefits, pains and pitfalls. I= t depends on your use case, configuration, hardware, adversaries, etc. Like m= ost security solutions, the devil, and weaknesses, lay in the details, like n= etwork engineering and key management. Care to elaborate for us? By the way, I'll just point out, always, and now more so than ever in light o= f NSA and TAO, that full disk encryption is not the magic bullet we'd hope. A= bout all you should expect from GELI is that it makes hard drive _disposal_ s= afer and easier at a drives EOL, and even then not totally so. That being sa= id, there is a worthwhile benefit _possible_ to achieve in the use case of a= portable device and many a data breach would have been prevented by proper a= pplication of GELI in that circumstance. "Highly available" servers have a lot less practical use for GELI especially= if either is colocated. If both of your HAST nodes are in your own faciliti= es and you have a tight and practiced mayday procedure, perhaps in addition t= o an automated system to trigger panic mode, it has some very good merit. In other cases software based full disk encryption is really only going to t= hwart or inconvenience the weakest of adversaries, which of course may be al= l you need or the best you can hope for. I use GELI almost everywhere and I'= ve deployed it both ways with HAST depending on the situation. Neither can b= e credited as the reason I get any sleep at night (simple exhaustion and uni= mportance in the cosmic scale are what do it for me) though they can certain= ly have their place in a well thought out security plan/procedure, if such a= thing exists. > On Dec 30, 2013, at 5:58 PM, Karl Pielorz wrote: >=20 >=20 > Hi All, >=20 > As I don't currently have the requisite two boxes to try this... Is it lik= ely / possible you can use HAST with GELI? - i.e. to have a highly available= , but encrypted-on-disk device? >=20 > If so are you better of creating GELI devices (i.e. .eli) and running HAST= on those, or creating HAST devices - and running GELI on those? >=20 > Thanks, >=20 > -Karl > _______________________________________________ > 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"