From nobody@FreeBSD.org  Sun Dec 30 13:39:17 2012
Return-Path: <nobody@FreeBSD.org>
Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52])
	by hub.freebsd.org (Postfix) with ESMTP id 0ADD6CCB
	for <freebsd-gnats-submit@FreeBSD.org>; Sun, 30 Dec 2012 13:39:17 +0000 (UTC)
	(envelope-from nobody@FreeBSD.org)
Received: from red.freebsd.org (red.freebsd.org [IPv6:2001:4f8:fff6::22])
	by mx1.freebsd.org (Postfix) with ESMTP id CA45F8FC12
	for <freebsd-gnats-submit@FreeBSD.org>; Sun, 30 Dec 2012 13:39:16 +0000 (UTC)
Received: from red.freebsd.org (localhost [127.0.0.1])
	by red.freebsd.org (8.14.5/8.14.5) with ESMTP id qBUDdG1S038254
	for <freebsd-gnats-submit@FreeBSD.org>; Sun, 30 Dec 2012 13:39:16 GMT
	(envelope-from nobody@red.freebsd.org)
Received: (from nobody@localhost)
	by red.freebsd.org (8.14.5/8.14.5/Submit) id qBUDdGTb038253;
	Sun, 30 Dec 2012 13:39:16 GMT
	(envelope-from nobody)
Message-Id: <201212301339.qBUDdGTb038253@red.freebsd.org>
Date: Sun, 30 Dec 2012 13:39:16 GMT
From: Fabian Keil <fk@fabiankeil.de>
To: freebsd-gnats-submit@FreeBSD.org
Subject: [PATCH] geli segfaults with the new locked memory limit default
X-Send-Pr-Version: www-3.1
X-GNATS-Notify:

>Number:         174831
>Category:       bin
>Synopsis:       [PATCH] geli(8) segfaults with the new locked memory limit default
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    pjd
>State:          patched
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Sun Dec 30 13:40:00 UTC 2012
>Closed-Date:    
>Last-Modified:  Tue Jun 18 13:36:21 UTC 2013
>Originator:     Fabian Keil
>Release:        HEAD
>Organization:
>Environment:
FreeBSD r500.local 10.0-CURRENT FreeBSD 10.0-CURRENT #536 r+d9956e5: Wed Dec 26 16:42:41 CET 2012     fk@r500.local:/usr/obj/usr/src/sys/ZOEY  amd64

>Description:
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.

>How-To-Repeat:
See description.
>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:

From 4aa5fe7e0b70a0c437fbcbebec4e7cc89c7afa2c Mon Sep 17 00:00:00 2001
From: Fabian Keil <fk@fabiankeil.de>
Date: Sun, 30 Dec 2012 13:48:15 +0100
Subject: [PATCH] Let eli_protect() make sure the locked memory limit is high
 enough

Prevents segmentation faults with the new locked memory
limit default for ordinary users (64K).
---
 sbin/geom/class/eli/geom_eli.c | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/sbin/geom/class/eli/geom_eli.c b/sbin/geom/class/eli/geom_eli.c
index cfd8897..06dadac 100644
--- a/sbin/geom/class/eli/geom_eli.c
+++ b/sbin/geom/class/eli/geom_eli.c
@@ -272,6 +272,14 @@ eli_protect(struct gctl_req *req)
 		    strerror(errno));
 		return (-1);
 	}
+	/* Make sure the locked memory limit is high enough. */
+	rl.rlim_cur = 1024 * 1024;
+	rl.rlim_max = 1024 * 1024;
+	if (setrlimit(RLIMIT_MEMLOCK, &rl) == -1) {
+		gctl_error(req, "Cannot set locked memory limit: %s.",
+		    strerror(errno));
+		return (-1);
+	}
 	/* Disable swapping. */
 	if (mlockall(MCL_FUTURE) == -1) {
 		gctl_error(req, "Cannot lock memory: %s.", strerror(errno));
-- 
1.8.0.2



>Release-Note:
>Audit-Trail:

From: =?UTF-8?Q?Ulrich_Sp=C3=B6rlein?= <uqs@FreeBSD.org>
To: bug-followup@FreeBSD.org, fk@fabiankeil.de, zont@FreeBSD.org, 
	avg@FreeBSD.org
Cc:  
Subject: Re: bin/174831: [PATCH] geli(8) segfaults with the new locked memory
 limit default
Date: Fri, 8 Feb 2013 13:16:37 +0100

 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.

From: Andriy Gapon <avg@FreeBSD.org>
To: =?UTF-8?B?VWxyaWNoIFNww7ZybGVpbg==?= <uqs@FreeBSD.org>
Cc: bug-followup@FreeBSD.org, fk@fabiankeil.de, zont@FreeBSD.org
Subject: Re: bin/174831: [PATCH] geli(8) segfaults with the new locked memory
 limit default
Date: Fri, 08 Feb 2013 14:43:19 +0200

 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

From: Fabian Keil <fk@fabiankeil.de>
To: Ulrich =?UTF-8?B?U3DDtnJsZWlu?= <uqs@FreeBSD.org>
Cc: bug-followup@FreeBSD.org, zont@FreeBSD.org, avg@FreeBSD.org
Subject: Re: bin/174831: [PATCH] geli(8) segfaults with the new locked
 memory limit default
Date: Thu, 21 Mar 2013 13:22:56 +0100

 --Sig_/SMtRhBh.4eognLO1lbvMmEB
 Content-Type: text/plain; charset=UTF-8
 Content-Transfer-Encoding: quoted-printable
 
 Ulrich Sp=C3=B6rlein <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
 
 --Sig_/SMtRhBh.4eognLO1lbvMmEB
 Content-Type: application/pgp-signature; name=signature.asc
 Content-Disposition: attachment; filename=signature.asc
 
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v2.0.19 (FreeBSD)
 
 iQIcBAEBCAAGBQJRSvurAAoJEGkYIpGLojccan8P/0NaiULt6daumU5EUC4D+Sj4
 mggQom2feu6Z9OsDjt9G0Dk2zuXM6ht//Xx62/NEuwtpNWw/WKxNS9eD7KWZ/Qtq
 9eRy+NjMXkq6p4YZlaonWFn245lAbYfmMsBi84oxk95DHXil63gL+CGTI7MahyP3
 yc1OlAUrqPvcP4AvKlNADLwkgqsXI5lhb34oWMYKeJVna6kscJQzqMWTcXQqr8wF
 bXjf1+twoKTAirNKzCDOt2rTqTPCuAHyT6q+Qw7M8h5b9a8yeKVFaGkTI8XvEOFl
 vfdE22SHiGcPJQglMoyIbq06Hsj9jRxyYfeddRiOY9+XwzST1TGUnnLZW0rCB8ns
 PN89C4WxzsqDNqFRjWFIgJDdNIgZIlb6kUKNiN989ds3lMXn5vMy2nYs8nIJjSsZ
 +omSOSQLRjYfWVSvR9NF+Wd7QatcdCIMvvXWSO8sRbUrFYskevOvUXVcdmFRUurT
 rWnotc4N0VYFy8HJjpCU29V4O9a+ZyJZCSuiQ5iR3klTAONjaLCSJfNoklpDBPz7
 fY6RIJG4Bfs9MGx4PLE5gFcKcLq22bkdWSvwBMM8SKk7wIbA5DUpAdR19M+YKNI5
 nASlqFtDsEebr8SZZsqLsfeXRx/0by+EVAZ7MqwkmxrkHTvvNUujcFdUyFu1n1sx
 KG+rEPR9PDKDf3KOE5KJ
 =GgiC
 -----END PGP SIGNATURE-----
 
 --Sig_/SMtRhBh.4eognLO1lbvMmEB--
State-Changed-From-To: open->patched 
State-Changed-By: ae 
State-Changed-When: Tue Jun 18 13:34:38 UTC 2013 
State-Changed-Why:  
Patched in r248475. 


Responsible-Changed-From-To: freebsd-bugs->pjd 
Responsible-Changed-By: ae 
Responsible-Changed-When: Tue Jun 18 13:34:38 UTC 2013 
Responsible-Changed-Why:  
pjd@ fixed this. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=174831 
>Unformatted:
