From owner-freebsd-current@FreeBSD.ORG  Sat Feb  9 16:00:57 2013
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Delivered-To: current@FreeBSD.org
Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115])
 by hub.freebsd.org (Postfix) with ESMTP id 05B257B9;
 Sat,  9 Feb 2013 16:00:57 +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 DB620CF;
 Sat,  9 Feb 2013 16:00:55 +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 SAA21480;
 Sat, 09 Feb 2013 18:00:54 +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 1U4CrF-00087B-Ql; Sat, 09 Feb 2013 18:00:53 +0200
Message-ID: <511672B5.5080300@FreeBSD.org>
Date: Sat, 09 Feb 2013 18:00:53 +0200
From: Andriy Gapon <avg@FreeBSD.org>
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64;
 rv:17.0) Gecko/20130121 Thunderbird/17.0.2
MIME-Version: 1.0
To: Andrey Zonov <zont@FreeBSD.org>
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>
 <CAF6rxgn7PRmBkx3FLnXfOjKzSHi1JEQQ_wc4273oHCmpTCjR1A@mail.gmail.com>
 <20130209140733.0b753c60@fabiankeil.de> <51166580.4080603@FreeBSD.org>
In-Reply-To: <51166580.4080603@FreeBSD.org>
X-Enigmail-Version: 1.4.6
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Cc: Eitan Adler <lists@eitanadler.com>, 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
 <freebsd-current.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-current>, 
 <mailto:freebsd-current-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-current>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Help: <mailto:freebsd-current-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-current>,
 <mailto:freebsd-current-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sat, 09 Feb 2013 16:00:57 -0000

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