Re: mlock and jail

From: Bruno Lauzé <brunolauze_at_msn.com>
Date: Thu, 2 Feb 2017 03:29:53 +0000
Thanks you.

The app in fact is dotnet https://github.com/dotnet/coreclr

And since it's already possible to cap overall memory with rctl ( -- jail:httpd:memoryuse:deny=2G/jail -- or -- jail:httpd:memorylocked:deny=1G/jail  -- ) it seems correct to say the lock weight could only be within those limits?


But right now memorylocked rctl does apply since prison is denied mlock. I might be missing something. Thanks for your help.


By the way, FreeBSD would gain a lot pushing for dotnet support as it did with Java in the days.

________________________________
From: Xin LI <delphij_at_gmail.com>
Sent: February 1, 2017 8:31:35 PM
To: Bruno Lauzé
Cc: freebsd-current
Subject: Re: mlock and jail

I like this idea.

Note that potentially your patch would make it possible for a jailed
root to DoS the whole system by locking too much of pages in memory.
I think it would be sensible to provide a per-jail flag to enable
doing it, or better, have some finer grained control (e.g. per jail
quota of permitted locked pages).

Why did the application want to lock pages in main memory, though?

On Wed, Feb 1, 2017 at 3:52 PM, Bruno Lauzé <brunolauze_at_msn.com> wrote:
>
> I would like to ask if there is a reason I would have to applythe  patch below to make an application work in a jail.
> And who's bad? the app too intrusive or the bsd not flexible enough (allow.mlock?)
>
>
> Index: sys/kern/kern_jail.c
> ===================================================================
> --- sys/kern/kern_jail.c        (revision 313033)
> +++ sys/kern/kern_jail.c        (working copy)
> _at__at_ -3340,6 +3340,11 _at__at_
>         case PRIV_PROC_SETLOGINCLASS:
>                 return (0);
>
>
> +        case PRIV_VM_MADV_PROTECT:
> +        case PRIV_VM_MLOCK:
> +        case PRIV_VM_MUNLOCK:
> +                return (0);
> +
>         default:
>
>
> _______________________________________________
> freebsd-current_at_freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_freebsd.org"
Received on Thu Feb 02 2017 - 02:31:01 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:10 UTC