From owner-svn-src-all@FreeBSD.ORG Thu Jan 17 14:00:41 2013 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 89578A12; Thu, 17 Jan 2013 14:00:41 +0000 (UTC) (envelope-from freebsd-listen@fabiankeil.de) Received: from smtprelay04.ispgateway.de (smtprelay04.ispgateway.de [80.67.31.31]) by mx1.freebsd.org (Postfix) with ESMTP id 99F69FA5; Thu, 17 Jan 2013 14:00:40 +0000 (UTC) Received: from [84.44.155.222] (helo=fabiankeil.de) by smtprelay04.ispgateway.de with esmtpsa (SSLv3:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1Tvq1C-000346-7J; Thu, 17 Jan 2013 15:00:34 +0100 Date: Thu, 17 Jan 2013 15:00:22 +0100 From: Fabian Keil To: Konstantin Belousov Subject: bin/174831: geli segfaults with the new locked memory limit default (was: svn commit: r245415 - stable/9/etc) Message-ID: <20130117150022.24373166@fabiankeil.de> In-Reply-To: <20130115212014.GD2522@kib.kiev.ua> References: <201301141058.r0EAwK4q044423@svn.freebsd.org> <20130114122640.152cb041@fabiankeil.de> <50F4464A.7000903@FreeBSD.org> <20130114200914.7f3272d2@fabiankeil.de> <50F5AB7B.6090903@FreeBSD.org> <20130115212014.GD2522@kib.kiev.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/7Vrf98vwCKV1FbgNXG+feJf"; protocol="application/pgp-signature" X-Df-Sender: Nzc1MDY3 Cc: Andrey Zonov , svn-src-all@freebsd.org, Andriy Gapon X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2013 14:00:41 -0000 --Sig_/7Vrf98vwCKV1FbgNXG+feJf Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Konstantin Belousov wrote: > On Tue, Jan 15, 2013 at 11:18:19PM +0400, Andrey Zonov wrote: > > On 1/14/13 11:09 PM, Fabian Keil wrote: > > > Andrey Zonov wrote: > > >=20 > > >> On 1/14/13 3:26 PM, Fabian Keil wrote: > > >>> Andrey Zonov wrote: > > >>> > > >>>> Author: zont > > >>>> Date: Mon Jan 14 10:58:20 2013 > > >>>> New Revision: 245415 > > >>>> URL: http://svnweb.freebsd.org/changeset/base/245415 > > >>>> > > >>>> Log: > > >>>> MFC r244383: > > >>>> - Set memorylocked limit to 64Kb for default login class. > > >>>> This prevents unprivileged users to lock too much memory. > > >>> > > >>> Note that this causes geli segfaults when using sudo: > > >>> http://www.freebsd.org/cgi/query-pr.cgi?pr=3D174831 > > >>> > > >> > > >> The change should not affect stable, because new behavior was turned= off > > >> in stable. > > >=20 > > > It's not exactly obvious, but by "this" I was referring to the change > > > in CURRENT. > > >=20 > >=20 > > The solution which you proposed was refused by kib@ (add to CC) when I > > proposed it earlier. > The limits purpose is to limit some resource usage. Having applications > that override the limits contradicts the user intent of keeping the > limits working. My "user intent" when running applications with sudo is that they do whatever is necessary to get the job done. geli usually only runs for a couple of seconds, there usually aren't lots of parallel geli executions and the limit will only be increased if geli is running with root privileges. I agree that applications shouldn't blindly increase limits without reason, but in this case I think a good reason exists. > As a workaround, you could set the limit for your user account. Or I could continue to use the patch ... The main problem I see here is that the user has to figure out the cause of the problem before a workaround can be applied. "pid 3521 (geli), uid 0: exited on signal 11" looks like a common application bug and gdb isn't particular useful to diagnose the problem either. > As a solution, change the offending application to only mlock() > the sensitive pages. E.g. gnupg already does this, probably because > it is portable. I agree that only mlock()ing the sensitive pages is a nice idea in theory. gnupg is an interesting example because it isn't able to lock the memory either: fk@r500 ~ $echo blafasel | gpg --encrypt -o /dev/null gpg: WARNING: using insecure memory! gpg: please see http://www.gnupg.org/documentation/faqs.html for more infor= mation The excerpt from gnupg-1.4.13/util/secmem.c's lock_pool(): if( uid ) { errno =3D EPERM; err =3D errno; } else { err =3D mlock( p, n ); if( err && errno ) err =3D errno; } n is 32768 here, but if I disable the now-bogus uid check or run gpg with sudo, mlock() returns -1 anyway and errno is ENOENT (like before the mlock() call). Apparently the mlock()ing even fails when gpg's s-bit is set now, although I'm reasonably sure that this used to work in the past (at least it suppressed the warning). Fabian --Sig_/7Vrf98vwCKV1FbgNXG+feJf Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlD4BAEACgkQBYqIVf93VJ09CwCgvBbwHzSsDBe8YllERYJPIicr qJIAoMcdKvkbnkadPTOW8OXlQ0E7XRJr =zlj8 -----END PGP SIGNATURE----- --Sig_/7Vrf98vwCKV1FbgNXG+feJf--