Re: disable-cap-mlock

[Andrea Arcangeli <andrea@suse.de>]

On Thu, Apr 01, 2004 at 06:21:27PM -0800, Chris Wright wrote:
> Ah, yes I see what you are saying.  This is the same issue with normal
> pages and SHM_LOCK that I mentioned earlier, I believe.  I don't see the
> best solution, because once you detach w/out any destroy, there could be
> nobody to assign the accounting to.  Do you agree?

yes, rlimit just can't account for shmget(SHM_HUGETLB) and
shmctl(SHM_LOCK) either, because it can only account the stuff that you
temporarily have in the address space.

the exploit is simply to shmget tons of 2M hugepage segments, and to
shmat/shmdt all of them, then you'll pin N times those 2M largepages,
and they will not be accounted anywhere allowing anybody to pin as much
memory as they want.

Both shmctl(SHM_LOCK) and shmget(SHM_HUGETLB) cannot be allowed in
function of any rlimit check, a system wide sysctl (as we implemented)
or some other method (can be implemented in userspace too of course, as
Andrew suggested) is needed for that. Using rlimit for that is broken
and in turn insecure.

the rlimit however works fine for _mlock_.

the fundamental difference between mlock and SHM_LOCK/SHM_HUGETLBFS is
that mlock is about locking pages in the address space, after the
address space is unmapped the mlock is gone too, so when the rlimit is
ok with it, you can mlock more ram. SHM_LOCK/SHM_HUGETLB is about
allocating physical pages, the mapping in the address space has no
effect on those, those pages will never be released after the mapping
is gone. So the rlimit can't help here.