Allow small amount of memory be mlock()'ed by unprivileged process?

Bruce Evans brde at optusnet.com.au
Thu May 17 09:59:55 UTC 2012


On Wed, 16 May 2012, Artem Belevich wrote:

> On Wed, May 16, 2012 at 3:36 PM, Eitan Adler <lists at eitanadler.com> wrote:
>> On 16 May 2012 18:32, Adrian Chadd <adrian at freebsd.org> wrote:
>>> .. what's to stop a fork() bomb from grabbing all pages?
>>
>> <quote>+ possibly limiting the number of pages per user, à la
>> maxprocperuid.</quote>
>
> Shouldn't RLIMIT_NPROC already limit the damage?

Products of limits are too large to actually be useful as limits in
most cases.  RLIMIT_NPROC usually gives the same limit as maxprocperuid.
E.g., on 2 very different systems I have handy both are 5547.  Then
the open file limit is 11095 on the smaller system (1GB RAM) and 3000
on the larger system (2GB RAM).  The product of 5507 and 11095 is > 58M.
There is no way the data structures for that many files can fit in 1GB
RAM.  So the limit is enough for normal operation but is useless for
defending against fork bombs.

Even if you have a small limit on the number of pages per user and a
small number of users, the product may be large, and vm needs to reserve
this number of pages so that it doesn't run out when doing more-critical
operations.  It might be able to preserve its reservations
(v_free_reserved, v_pageout_fre_min and v_interrupt_free_min) by reducing
the limit on the number of locked pages for each user and all users when
under pressure, but then unprivileged pages that have already grabbed and
locked pages could damage privileged processes later.

Bruce


More information about the freebsd-arch mailing list