Date: Sun, 10 Feb 2013 09:50:58 +0200 From: Andriy Gapon <avg@FreeBSD.org> To: Pawel Jakub Dawidek <pjd@FreeBSD.org> Cc: Eitan Adler <lists@eitanadler.com>, Andrey Zonov <zont@FreeBSD.org>, current@FreeBSD.org Subject: Re: geli(8) breaks after a couple hours of uptime Message-ID: <51175162.3030401@FreeBSD.org> In-Reply-To: <20130209233500.GH1375@garage.freebsd.pl> 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> <CAF6rxgn7PRmBkx3FLnXfOjKzSHi1JEQQ_wc4273oHCmpTCjR1A@mail.gmail.com> <20130209140733.0b753c60@fabiankeil.de> <51166580.4080603@FreeBSD.org> <511672B5.5080300@FreeBSD.org> <20130209233500.GH1375@garage.freebsd.pl>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?51175162.3030401>