Unfortunately, the RLIMIT_DATA setrlimit appears to be ignored by the
mmap() system call, which is used by malloc in most recent Linux
distributions. Older Linux distributions and other Unixes use the brk()
system call for malloc.
I checked the kernel source of 2.0.36 and 2.2.12 and found that brk()
does check the RLIMIT_DATA limit, but saw no mention of it in the mmap()
call.
So I'm assuming that mmap() is still broken in terms of enforcing
RLIMIT_DATA.
DS
> > > [ryan@stargate ryan]$ ulimit -a
> > > ...
> > > virtual memory (kbytes) 3072
> > ^^^^ this is the important limit!
Stuart Cunningham <stu...@dtm.com.au> writes:
> Going by the bash source, the "virtual memory" limit is merely the
> addition
> of DATA and STACK space (RLIMIT_DATA + RLIMIT_STACK).
The bash source doesn't have much to do with this -- the Linux kernel
(like others) provides a separate RLIMIT_AS resource limit and this
happens to be controlled by `ulimit -v' in bash.
This limit is totally separate from RLIMIT_DATA or RLIMIT_STACK and
controls the maximum amount of memory (or rather address apace, hence
RLIMIT_AS) mapped in the process.
I stand by my original comment that this is the important limit if
resource exhaustion attacks are to be prevented. It would be nice if
this would be a per-user and not per-process limit. (Work is going on
about this..)
> There is no
> virtual memory limit in the setrlimit() system call, so the RLIMIT_DATA
> limit is the appropriate one to use if you wish to limit the memory
> usage of a process.
>
> Unfortunately, the RLIMIT_DATA setrlimit appears to be ignored by the
> mmap() system call, which is used by malloc in most recent Linux
> distributions. Older Linux distributions and other Unixes use the brk()
> system call for malloc.
Yes, this is true, and the fact that mmap() isn't affected by
RLIMIT_DATA is the same as on other Unices.
> I checked the kernel source of 2.0.36 and 2.2.12 and found that brk()
> does check the RLIMIT_DATA limit, but saw no mention of it in the mmap()
> call.
> So I'm assuming that mmap() is still broken in terms of enforcing
> RLIMIT_DATA.
No, all it means IMHO is that you have to use RLIMIT_AS rather than
RLIMIT_DATA to enforce memory limits safely. Even if malloc()
wouldn't use mmap() internally it would be trivial to call mmap()
directly in a malicious memory-hogging process.
Regards,
Wolfram.
> Stuart Cunningham <stu...@dtm.com.au> writes:
>
> > Going by the bash source, the "virtual memory" limit is merely the
> > addition
> > of DATA and STACK space (RLIMIT_DATA + RLIMIT_STACK).
>
> The bash source doesn't have much to do with this -- the Linux kernel
> (like others) provides a separate RLIMIT_AS resource limit and this
> happens to be controlled by `ulimit -v' in bash.
Sorry, I was reading the source for bash-1.14.7 which is the default version
installed on Redhat 6.1. bash-2.03 does support the RLIMIT_AS resource of
setrlimit, however the manpages for setrlimit on Redhat 6.1 still does not
mention RLIMIT_AS (man-pages-1.26). Where does one find up to date
documentation on system calls?
Now that I'm using bash-2.03 I can avoid the problems of malloc bombs.
Thank you.
> bash-2.03 does support the RLIMIT_AS resource of
> setrlimit, however the manpages for setrlimit on Redhat 6.1 still does not
> mention RLIMIT_AS (man-pages-1.26). Where does one find up to date
> documentation on system calls?
As always, in the kernel source :-/. You are correct, this seems to
be missing from man-pages-1.26. I'm just submitting a patch so that
RLIMIT_AS is at least mentioned in the getrlimit(2) page.
Regards,
Wolfram.
thanks, please bear with me, if my questions are not too intelligent.
clownfish
In article <38041B5B...@dtm.com.au>,
Stuart Cunningham <stu...@dtm.com.au> wrote:
> > > [ryan@stargate ryan]$ ulimit -a
> > > ...
> > > virtual memory (kbytes) 3072
> > ^^^^ this is the important limit!
> Going by the bash source, the "virtual memory" limit is merely the
> addition
> of DATA and STACK space (RLIMIT_DATA + RLIMIT_STACK). There is no
> virtual memory limit in the setrlimit() system call, so the
RLIMIT_DATA
> limit is the appropriate one to use if you wish to limit the memory
> usage of a process.
>
> Unfortunately, the RLIMIT_DATA setrlimit appears to be ignored by the
> mmap() system call, which is used by malloc in most recent Linux
> distributions. Older Linux distributions and other Unixes use the
brk()
> system call for malloc.
>
> I checked the kernel source of 2.0.36 and 2.2.12 and found that brk()
> does check the RLIMIT_DATA limit, but saw no mention of it in the
mmap()
> call.
> So I'm assuming that mmap() is still broken in terms of enforcing
> RLIMIT_DATA.
>
>
Sent via Deja.com http://www.deja.com/
Before you buy.
: thanks, please bear with me, if my questions are not too intelligent.
If you think they are not too intelligent, then what are you doing with
1.5GB of ram? Hire me instead.
Peter
what is your problem!?
who says that i have 1.5GB of RAM, and who says that i am a sys admin.
I am just trying to find a fast and quick answer cause i disagree with
my sys admin.
so, what is the answer?
clownfish
In article <7udkh4$5tp$3...@fantasma.gsyc.inf.uc3m.es>,
But ... is there a way to limit the total VM
used by all processes owned by a single user?
Rich.
--
ri...@annexia.org | Free email for life at: http://www.postmaster.co.uk/
BiblioTech Ltd, Unit 2 Piper Centre, 50 Carnwath Road, London, SW6 3EG.
+44 171 384 6917 | Click here to play XRacer: http://xracer.annexia.org/
--- Original message content Copyright © 1999 Richard Jones ---
> But ... is there a way to limit the total VM
> used by all processes owned by a single user?
Not presently, but the lack of per-user ulimits is an obvious hole so it
is being actively worked on IIRC.
--
`I'm glad you want me to be happy. I'd like you to be happy too.'
--- Nat Lanza, while flaming Larry McVoy on linux-kernel