Date: Sat, 09 Feb 2013 18:00:53 +0200 From: Andriy Gapon <avg@FreeBSD.org> To: Andrey Zonov <zont@FreeBSD.org> Cc: Eitan Adler <lists@eitanadler.com>, current@FreeBSD.org Subject: Re: geli(8) breaks after a couple hours of uptime Message-ID: <511672B5.5080300@FreeBSD.org> In-Reply-To: <51166580.4080603@FreeBSD.org> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
on 09/02/2013 17:04 Andrey Zonov said the following: > On 2/9/13 5:07 PM, Fabian Keil wrote: >> >> This would at least prevent the segfault. >> > > I see two possibilities to get segfault: > - no checking for result from memory allocation functions > - too big stack > > I have no found any broken memory allocation checking, but I found two > big objects on the stack. One is buf[MAXPHYS] in eli_genkey_files() and > another is passbuf[MAXPHYS] in eli_genkey_passphrase(). If we change > these two to malloc(), then we can handle error from malloc(), print > some useful message and prevent segfault. I'd rather do what Kostik suggested and Fabian mentioned: instead of mlockall(MCL_FUTURE) the code should mlock only the (explicitly designated) buffers that can contain sensitive data. -- Andriy Gapon
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?511672B5.5080300>