Date: Wed, 19 Sep 2012 13:33:45 +0400 From: Andrey Zonov <zont@FreeBSD.org> To: Konstantin Belousov <kostikbel@gmail.com> Cc: Andriy Gapon <avg@freebsd.org>, freebsd-arch@freebsd.org Subject: Re: [patch] unprivileged mlock(2) Message-ID: <50599179.4020505@FreeBSD.org> In-Reply-To: <20120917123719.GS37286@deviant.kiev.zoral.com.ua> References: <503DD433.2030108@FreeBSD.org> <201208290906.q7T96C9j032802@gw.catspoiler.org> <20120829092318.GW33100@deviant.kiev.zoral.com.ua> <503F2D24.8050103@FreeBSD.org> <50463026.8000506@FreeBSD.org> <504653CD.2000707@FreeBSD.org> <5046F4E0.6000606@FreeBSD.org> <50561223.7060709@FreeBSD.org> <20120917123719.GS37286@deviant.kiev.zoral.com.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
[-- Attachment #1 --] On 9/17/12 4:37 PM, Konstantin Belousov wrote: > On Sun, Sep 16, 2012 at 09:53:39PM +0400, Andrey Zonov wrote: >> On 9/5/12 10:44 AM, Andriy Gapon wrote: >>> on 04/09/2012 22:17 Andrey Zonov said the following: >>>> On 9/4/12 8:45 PM, Andriy Gapon wrote: >>>>> on 30/08/2012 12:06 Andrey Zonov said the following: >>>>>> Hi, >>>>>> >>>>>> So, I've got the first version of the patch (attached) which fixes >>>>>> memory locked limit checking and accounting. >>>>> >>>>> Andrey, >>>>> >>>>> your mlock.patch looks good to me, but I haven't verified pieces under >>>>> RACCT. Please try to get a review from a person who is knee-deep in the >>>>> VM code like alc or your mentor. >>>>> >>>> >>>> Thanks for review! >>>> >>>>> The code should also be sent for vetoing to security@. Not sure if you >>>>> would get a review there, but absence of nays would be good. >>>>> >>>>> When the code is ready to be committed, please remember about >>>>> memorylocked=unlimited in the default entry of the default login.conf. A >>>>> big warning about it will have to be posted (in UPDATING and >>>>> current@/stable@ at the very least). >>>>> >>>> >>>> After that amd(8), geli(8) and watchdogd(8) will be broken, because they >>>> call mlockall(2). ntpd(8) won't, it already raises its RLIMIT_MEMLOCK. I >>>> will prepare patches for raising limits if there is no other solution. >>> >>> Thanks for working on this. >>> BTW, I am not sure why those applications would get broken... >>> We could/should still have memorylocked=unlimited for the 'root' class. >>> Or is it about something else? >>> >> >> Hmm, I thought that root login class commented out. >> >>>>> Thank you very much for doing this work. >>>>> >>>>> P.S. It would probably make sense to provide some HTTP home for this >>>>> patch as well. >>>>> >>>> >>>> Updated patch is here [1]. >>>> >>>> [1] http://people.freebsd.org/~zont/mlock1.patch >>>> >>> >>> Thank you! >>> One additional thing - we probably should retire PRIV_VM_MLOCK and >>> PRIV_VM_MUNLOCK. That would include making changes to >>> sys/i386/ibcs2/ibcs2_misc.c and sys/ofed/drivers/infiniband/core/umem.c. >>> >> >> They are useful for jails as trasz@ mentioned on IRC. >> >>> P.S. PRIV_VM_MUNLOCK _privilege_ feels a little bit weird. I wonder what was >>> the intended use for it (if any)... >>> >> >> So, here is the second version of the patch [1]. >> >> [1] http://people.freebsd.org/~zont/mlock2.patch > > In priv_check_cred(), s/to unprivileged/for unprivileged/. > > In vm_mmap(), on RLIMIT_VMEM failure, racct change shall be rolled back. > > I am not sure why e.g. sys_obreak() forces racct limits instead of obeing. > Thanks for review. Updated patch is here [1]. [1] http://people.freebsd.org/~zont/patches/mlock3.patch -- Andrey Zonov [-- Attachment #2 --] -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJQWZF8AAoJEBWLemxX/CvTXJsH/3SZbso6ufnDCgDqjfPsPCTB zKDVZoIrYwW+E5OOVWSInlyqEFghvZNSUfqqWxQtzdukmbxK5UrQettHeIhXSuib Ke5STyVorGSYArL3cVhbSqJ+ZKwMmFuOLP5y9Y7sdsm3M0SUtnT01lVbcR7On4JE QILHY4GZR5SEo525CcOs3+uxEyczqOVv3jDn7Yt7BBmIkeIE9+rpngJamjp/7E9q hHKkQGbPuxUUxW2I402Y1wSkdXQqNSIT3evSY3vTw9CMKcH9BWQANq1ZG5G6GPr/ BkKa0IUWqK923Ulof0wX1uNKtlwyr0OZuKTJV5081fCKKRHxXIJj9e7UbUxeFJ8= =RSW8 -----END PGP SIGNATURE-----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?50599179.4020505>