From owner-freebsd-current@FreeBSD.ORG Sun Feb 10 16:37:34 2013 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id E09CFADA; Sun, 10 Feb 2013 16:37:34 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id A9D236FE; Sun, 10 Feb 2013 16:37:33 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id SAA28584; Sun, 10 Feb 2013 18:37:31 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1U4ZuF-000CCW-7K; Sun, 10 Feb 2013 18:37:31 +0200 Message-ID: <5117CCC9.4060705@FreeBSD.org> Date: Sun, 10 Feb 2013 18:37:29 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130121 Thunderbird/17.0.2 MIME-Version: 1.0 To: Pawel Jakub Dawidek Subject: Re: geli(8) breaks after a couple hours of uptime References: <20130207180153.GX35868@acme.spoerlein.net> <20130208095709.6ae61cff@fabiankeil.de> <20130208114825.GY35868@acme.spoerlein.net> <5114F390.4010302@FreeBSD.org> <20130209140733.0b753c60@fabiankeil.de> <51166580.4080603@FreeBSD.org> <511672B5.5080300@FreeBSD.org> <20130209233500.GH1375@garage.freebsd.pl> <51175162.3030401@FreeBSD.org> <20130210154449.GI1375@garage.freebsd.pl> In-Reply-To: <20130210154449.GI1375@garage.freebsd.pl> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Eitan Adler , Andrey Zonov , current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Feb 2013 16:37:34 -0000 on 10/02/2013 17:44 Pawel Jakub Dawidek said the following: > On Sun, Feb 10, 2013 at 09:50:58AM +0200, Andriy Gapon wrote: >> on 10/02/2013 01:35 Pawel Jakub Dawidek said the following: >>> geli(8) almost exclusively deals with sensitive data. Even mlocking >>> MAXPHYS would fail with current limits, but this is bad idea. >>> >>> With mlockall() I am sure I didn't miss anything - be it forgetting >>> about mlocking some buffer or zeroing it before munlock. I'm also sure >>> someone else who can modify geli(8) in the future won't miss anything >>> too. >> >> Well, the geli is not such a complex program really. It seems to use only two >> or so buffers for sensitive data. [...] > > Maybe it isn't very complex, but complex enough that you missed a dozen > or so buffers that would need mlocking (almost everything that is > bzero'ed), I haven't exactly missed them, because I only glanced over the code. > not to mention internal states for hash and encryption > algorithms that operate on blocks, so they can keep plain data until > their update method gather entire block. Encryption and HMAC calculation > is done by API used by both userland and kernel parts, so it would need > some ifdefs to make it work, thus further complicating entire thing. I think that things such as these are better be done in externally provided/controlled buffers. >> [...] As far as I can see geli deals only with some >> key management (reading keys, generating key from key material, etc). There is >> definitely no need to mlock the code, etc. > > I fully agree there is no need to mlock the code and I'd be happy to use > mlockall(2) flag that protects only the data. Until such flag is > introduced I'll keep mlocking everything. > >> I think that PAGE_SIZE (or at most a small multiple of it) should be sufficient. >> I don't think that we currently have (or expect to see in the near future) >> algorithms where keys with more than 4096 size provide any additional security. > > geli(8) deals just fine with files that are larger than buffers, so even > with smaller buffer it can read the data in few steps. > > The proposed patch is here if someone would like to give it a try: > > http://people.freebsd.org/~pjd/patches/geom_eli.c.patch > This is a very good start, IMHO. Thank you. -- Andriy Gapon