[patch] unprivileged mlock(2)

Konstantin Belousov kostikbel at gmail.com
Mon Sep 17 12:37:27 UTC 2012


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 at .  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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-arch/attachments/20120917/c905ef58/attachment.pgp


More information about the freebsd-arch mailing list