From owner-freebsd-current@FreeBSD.ORG Sun Feb 10 07:51:07 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 C1C87150; Sun, 10 Feb 2013 07:51:07 +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 7FFB0D6B; Sun, 10 Feb 2013 07:51:06 +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 JAA26101; Sun, 10 Feb 2013 09:50:58 +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 1U4Rgg-000BhS-GC; Sun, 10 Feb 2013 09:50:58 +0200 Message-ID: <51175162.3030401@FreeBSD.org> Date: Sun, 10 Feb 2013 09:50:58 +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: <20130207141833.GA15884@acme.spoerlein.net> <20130207153322.5c371beb@fabiankeil.de> <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> In-Reply-To: <20130209233500.GH1375@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 07:51:07 -0000 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. 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. > geli(8) is relatively simple program, it doesn't allocate megabytes of > memory for different pruposes and just needs few pages for sensitive > data. As I said most of the memory it uses is for sensitive data. Right, except for code (from geli and from shared libraries) and other stuff that is really not sensitive at all. > The obvious problem is allocating MAXPHYS on the stack. This has to be > changed, especially that we may want to rise MAXPHYS in the future. Yes, I do not see any relation between what geli does and MAXPHYS. > Other than that I expect thing would be tuned properly so that geli(8) > can work by default. I'm happy to use smaller buffers than MAXPHYS - > keyfiles are far smaller usually than 128kB, so there shouldn't be any > issue with this. 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. -- Andriy Gapon