Bug 174831 - [PATCH] geli(8) segfaults with the new locked memory limit default
Summary: [PATCH] geli(8) segfaults with the new locked memory limit default
Status: Closed FIXED
Alias: None
Product: Base System
Classification: Unclassified
Component: bin (show other bugs)
Version: Unspecified
Hardware: Any Any
: Normal Affects Some People
Assignee: Pawel Jakub Dawidek
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-12-30 13:40 UTC by Fabian Keil
Modified: 2014-10-20 10:23 UTC (History)
0 users

See Also:

Attachments
file.txt (1.07 KB, text/plain)
2012-12-30 13:40 UTC, Fabian Keil 		no flags Details
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Fabian Keil 2012-12-30 13:40:00 UTC 
Since the last login.conf update geli segfaults when called as ordinary user or with sudo.

fk@r500 ~ $sudo /sbin/geli attach /dev/label/test || tail -n 2 /var/log/messages
Dec 30 13:37:30 r500 kernel: [5043] pid 3521 (geli), uid 0: exited on signal 11
Dec 30 13:37:42 r500 sudo:       fk : TTY=pts/6 ; PWD=/home/fk ; USER=root ; COMMAND=/sbin/geli attach /dev/label/test

The problem seems to be the new locked memory limit default of 64K.

Executing geli from a root shell works as expected and setting vm.old_mlock=0 works around the problem.

Fix: The attached patch lets geli try to set the limit to 1024K which
seems to be sufficient to prevent the segmentation fault and
results in a proper error message if the user lacks the required
privileges.

Patch attached with submission follows:
How-To-Repeat: See description.
Comment 1 Ulrich Spörlein freebsd_committer freebsd_triage 2013-02-08 12:16:37 UTC 
While geli should definitely be fixed to provide a meaningful error
message instead of a crash, we also need to keep it working out of the
box.

For me, 256K seems to be enough to make it work, but I guess this is a
function of the used crypto algorithms and key sizes. Can you maybe
adapt the check to figure out how much memory actually needs to be
mlocked?

Once we come up with a better upper limit, the default in login.conf
should be bumped accordingly.
Comment 2 Andriy Gapon freebsd_committer freebsd_triage 2013-02-08 12:43:19 UTC 
on 08/02/2013 14:16 Ulrich Spörlein said the following:
> While geli should definitely be fixed to provide a meaningful error
> message instead of a crash, we also need to keep it working out of the
> box.
> 
> For me, 256K seems to be enough to make it work, but I guess this is a
> function of the used crypto algorithms and key sizes. Can you maybe
> adapt the check to figure out how much memory actually needs to be
> mlocked?
> 
> Once we come up with a better upper limit, the default in login.conf
> should be bumped accordingly.
> 

unlimited is a perfect limit.  No program won't complain.

-- 
Andriy Gapon
Comment 3 Fabian Keil 2013-03-21 12:22:56 UTC 
Ulrich Spörlein <uqs@FreeBSD.org> wrote:

> While geli should definitely be fixed to provide a meaningful error
> message instead of a crash, we also need to keep it working out of the
> box.


At least for me the problem was fixed in r248475.

Fabian
Comment 4 Andrey V. Elsukov freebsd_committer freebsd_triage 2013-06-18 14:34:38 UTC 
State Changed
From-To: open->patched

Patched in r248475.
Comment 5 Andrey V. Elsukov freebsd_committer freebsd_triage 2013-06-18 14:34:38 UTC 
Responsible Changed
From-To: freebsd-bugs->pjd

pjd@ fixed this.