* x86: randomize brk() and RLIMIT_DATA
@ 2007-10-25 13:41 Sami Farin
2007-10-25 14:13 ` Arjan van de Ven
0 siblings, 1 reply; 10+ messages in thread
From: Sami Farin @ 2007-10-25 13:41 UTC (permalink / raw)
To: Linux kernel Mailing List; +Cc: Jiri Kosina
[-- Attachment #1: Type: text/plain, Size: 484 bytes --]
Would be neat if randomized brk and setrlimit(RLIMIT_DATA, ...)
worked in a predictable way:
$ gcc brk.c -fPIC -pie -m64;./a.out;./a.out;./a.out
sbrk=0x7f721b815000 main=0x7f721af04860
sbrk succeeded (brk=0x7f721b909240)
sbrk=0x7fc3d77e2000 main=0x7fc3d66fa860
sbrk failed: Cannot allocate memory (brk=0x7fc3d77e2000)
sbrk=0x7f05b0615000 main=0x7f05af76b860
sbrk failed: Cannot allocate memory (brk=0x7f05b0615000)
--
Do what you love because life is too short for anything else.
[-- Attachment #2: brk.c --]
[-- Type: text/plain, Size: 692 bytes --]
#include <stdio.h>
#include <unistd.h>
#include <sys/time.h>
#include <sys/resource.h>
#include <errno.h>
#include <string.h>
int main(void)
{
void *p;
const struct rlimit rlim_data = {
.rlim_cur = 10 << 20,
.rlim_max = RLIM_INFINITY
};
int saved_errno;
p = sbrk(0);
fprintf(stderr, "sbrk=%p main=%p\n", p, &main);
if (setrlimit(RLIMIT_DATA, &rlim_data) == -1) {
fprintf(stderr, "setrlimit failed: %s\n", strerror(errno));
return 1;
}
if (sbrk(1 << 20) == (void*)-1) {
saved_errno = errno;
fprintf(stderr, "sbrk failed: %s (brk=%p)\n",
strerror(saved_errno), sbrk(0));
return 1;
} else {
fprintf(stderr, "sbrk succeeded (brk=%p)\n", sbrk(0));
return 0;
}
}
^ permalink raw reply [flat|nested] 10+ messages in thread* Re: x86: randomize brk() and RLIMIT_DATA
2007-10-25 13:41 x86: randomize brk() and RLIMIT_DATA Sami Farin
@ 2007-10-25 14:13 ` Arjan van de Ven
2007-10-25 14:46 ` Jiri Kosina
0 siblings, 1 reply; 10+ messages in thread
From: Arjan van de Ven @ 2007-10-25 14:13 UTC (permalink / raw)
To: Sami Farin; +Cc: Linux kernel Mailing List, Jiri Kosina
On Thu, 25 Oct 2007 16:41:24 +0300
Sami Farin <safari-kernel@safari.iki.fi> wrote:
> Would be neat if randomized brk and setrlimit(RLIMIT_DATA, ...)
> worked in a predictable way:
this isn't a valid case afaics; even on "traditional x86" (before we
changed the address space layout, or even today if you have an
unlimited stack rlimit) this isn't going to work. applications really
shouldn't use (s)brk() but malloc(); you have to be able to fall back
to mmap regardless of what you do.
>
> $ gcc brk.c -fPIC -pie -m64;./a.out;./a.out;./a.out
> sbrk=0x7f721b815000 main=0x7f721af04860
> sbrk succeeded (brk=0x7f721b909240)
> sbrk=0x7fc3d77e2000 main=0x7fc3d66fa860
> sbrk failed: Cannot allocate memory (brk=0x7fc3d77e2000)
> sbrk=0x7f05b0615000 main=0x7f05af76b860
> sbrk failed: Cannot allocate memory (brk=0x7f05b0615000)
>
--
If you want to reach me at my work email, use arjan@linux.intel.com
For development, discussion and tips for power savings,
visit http://www.lesswatts.org
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: x86: randomize brk() and RLIMIT_DATA
2007-10-25 14:13 ` Arjan van de Ven
@ 2007-10-25 14:46 ` Jiri Kosina
2007-10-25 17:19 ` Sami Farin
0 siblings, 1 reply; 10+ messages in thread
From: Jiri Kosina @ 2007-10-25 14:46 UTC (permalink / raw)
To: Arjan van de Ven; +Cc: Sami Farin, Linux kernel Mailing List
On Thu, 25 Oct 2007, Arjan van de Ven wrote:
> > Would be neat if randomized brk and setrlimit(RLIMIT_DATA, ...)
> > worked in a predictable way:
> this isn't a valid case afaics; even on "traditional x86" (before we
> changed the address space layout, or even today if you have an unlimited
> stack rlimit) this isn't going to work. applications really shouldn't
> use (s)brk() but malloc(); you have to be able to fall back to mmap
> regardless of what you do.
I tend to agree here with Arjan. However it probably would make no harm to
make at least a little bit consisten behavior of setrlimit(), though it
has a little use in such cases.
Sami, does the patch below work for you?
diff --git a/mm/mmap.c b/mm/mmap.c
index facc1a7..c7ade18 100644
--- a/mm/mmap.c
+++ b/mm/mmap.c
@@ -251,7 +251,8 @@ asmlinkage unsigned long sys_brk(unsigned long brk)
* not page aligned -Ram Gupta
*/
rlim = current->signal->rlim[RLIMIT_DATA].rlim_cur;
- if (rlim < RLIM_INFINITY && brk - mm->start_data > rlim)
+ if (rlim < RLIM_INFINITY && brk - mm->start_data -
+ (mm->start_brk - mm->end_data) > rlim)
goto out;
newbrk = PAGE_ALIGN(brk);
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: x86: randomize brk() and RLIMIT_DATA
2007-10-25 14:46 ` Jiri Kosina
@ 2007-10-25 17:19 ` Sami Farin
2007-10-26 10:44 ` [PATCH] [RFC] brk randomization: compute RLIMIT_DATA properly (was Re: x86: randomize brk() and RLIMIT_DATA) Jiri Kosina
0 siblings, 1 reply; 10+ messages in thread
From: Sami Farin @ 2007-10-25 17:19 UTC (permalink / raw)
To: Linux kernel Mailing List; +Cc: Jiri Kosina, Arjan van de Ven
On Thu, Oct 25, 2007 at 16:46:26 +0200, Jiri Kosina wrote:
> On Thu, 25 Oct 2007, Arjan van de Ven wrote:
>
> > > Would be neat if randomized brk and setrlimit(RLIMIT_DATA, ...)
> > > worked in a predictable way:
> > this isn't a valid case afaics; even on "traditional x86" (before we
> > changed the address space layout, or even today if you have an unlimited
> > stack rlimit) this isn't going to work. applications really shouldn't
> > use (s)brk() but malloc(); you have to be able to fall back to mmap
> > regardless of what you do.
>
> I tend to agree here with Arjan. However it probably would make no harm to
> make at least a little bit consisten behavior of setrlimit(), though it
> has a little use in such cases.
>
> Sami, does the patch below work for you?
Thanks, Jiri, now RLIMIT_DATA works as expected.
Using only RLIMIT_AS to limit processes' memory usage is not
very easy. It includes also libraries mapped read-only,
I have to check/modify the limits when I update/add
libraries,...
Amazingly, I found a patch which seems to be just what I need:
http://marc.info/?l=linux-mm&m=118402827803338&w=4
Seems like that is not going to -mm or mainstream...
--
Do what you love because life is too short for anything else.
^ permalink raw reply [flat|nested] 10+ messages in thread
* [PATCH] [RFC] brk randomization: compute RLIMIT_DATA properly (was Re: x86: randomize brk() and RLIMIT_DATA)
2007-10-25 17:19 ` Sami Farin
@ 2007-10-26 10:44 ` Jiri Kosina
2007-10-26 12:02 ` Hugh Dickins
0 siblings, 1 reply; 10+ messages in thread
From: Jiri Kosina @ 2007-10-26 10:44 UTC (permalink / raw)
To: Sami Farin, Andrew Morton
Cc: Linux kernel Mailing List, Jiri Kosina, Arjan van de Ven
On Thu, 25 Oct 2007, Sami Farin wrote:
> > > > Would be neat if randomized brk and setrlimit(RLIMIT_DATA, ...)
> > > > worked in a predictable way:
> > > this isn't a valid case afaics; even on "traditional x86" (before we
> > > changed the address space layout, or even today if you have an
> > > unlimited stack rlimit) this isn't going to work. applications
> > > really shouldn't use (s)brk() but malloc(); you have to be able to
> > > fall back to mmap regardless of what you do.
> > I tend to agree here with Arjan. However it probably would make no
> > harm to make at least a little bit consisten behavior of setrlimit(),
> > though it has a little use in such cases.
> > Sami, does the patch below work for you?
> Thanks, Jiri, now RLIMIT_DATA works as expected. Using only RLIMIT_AS to
> limit processes' memory usage is not very easy. It includes also
> libraries mapped read-only, I have to check/modify the limits when I
> update/add libraries,...
This patch is [RFC] as I am not sure whether it is worth it (see Arjan's
comment above).
From: Jiri Kosina <jkosina@suse.cz>
brk randomization: compute RLIMIT_DATA properly
In cases of heap area placed at randomly-generated offset from
mm->end_data (arch_randomize_brk()), we need to subtract the value of the
offset for setrlimit(RLIMIT_DATA) to work properly -- otherwise we count
the unoccupied memory between mm->end_data and mm->start_brk as occupied.
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
diff --git a/mm/mmap.c b/mm/mmap.c
index facc1a7..c7ade18 100644
--- a/mm/mmap.c
+++ b/mm/mmap.c
@@ -251,7 +251,8 @@ asmlinkage unsigned long sys_brk(unsigned long brk)
* not page aligned -Ram Gupta
*/
rlim = current->signal->rlim[RLIMIT_DATA].rlim_cur;
- if (rlim < RLIM_INFINITY && brk - mm->start_data > rlim)
+ if (rlim < RLIM_INFINITY && brk - mm->start_data -
+ (mm->start_brk - mm->end_data) > rlim)
goto out;
newbrk = PAGE_ALIGN(brk);
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] [RFC] brk randomization: compute RLIMIT_DATA properly (was Re: x86: randomize brk() and RLIMIT_DATA)
2007-10-26 10:44 ` [PATCH] [RFC] brk randomization: compute RLIMIT_DATA properly (was Re: x86: randomize brk() and RLIMIT_DATA) Jiri Kosina
@ 2007-10-26 12:02 ` Hugh Dickins
2007-10-26 12:16 ` Jiri Kosina
0 siblings, 1 reply; 10+ messages in thread
From: Hugh Dickins @ 2007-10-26 12:02 UTC (permalink / raw)
To: Jiri Kosina
Cc: Sami Farin, Andrew Morton, Linux kernel Mailing List,
Jiri Kosina, Arjan van de Ven
On Fri, 26 Oct 2007, Jiri Kosina wrote:
> On Thu, 25 Oct 2007, Sami Farin wrote:
> > > > > Would be neat if randomized brk and setrlimit(RLIMIT_DATA, ...)
> > > > > worked in a predictable way:
> > > > this isn't a valid case afaics; even on "traditional x86" (before we
> > > > changed the address space layout, or even today if you have an
> > > > unlimited stack rlimit) this isn't going to work. applications
> > > > really shouldn't use (s)brk() but malloc(); you have to be able to
> > > > fall back to mmap regardless of what you do.
> > > I tend to agree here with Arjan. However it probably would make no
> > > harm to make at least a little bit consisten behavior of setrlimit(),
> > > though it has a little use in such cases.
> > > Sami, does the patch below work for you?
> > Thanks, Jiri, now RLIMIT_DATA works as expected. Using only RLIMIT_AS to
> > limit processes' memory usage is not very easy. It includes also
> > libraries mapped read-only, I have to check/modify the limits when I
> > update/add libraries,...
>
> This patch is [RFC] as I am not sure whether it is worth it (see Arjan's
> comment above).
It is worth it.
Arjan's right that RLIMIT_DATA has difficulty making sense, but
you shouldn't be randomizing its breakage further with your patch.
>
>
> From: Jiri Kosina <jkosina@suse.cz>
>
> brk randomization: compute RLIMIT_DATA properly
>
> In cases of heap area placed at randomly-generated offset from
> mm->end_data (arch_randomize_brk()), we need to subtract the value of the
> offset for setrlimit(RLIMIT_DATA) to work properly -- otherwise we count
> the unoccupied memory between mm->end_data and mm->start_brk as occupied.
>
> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
>
> diff --git a/mm/mmap.c b/mm/mmap.c
> index facc1a7..c7ade18 100644
> --- a/mm/mmap.c
> +++ b/mm/mmap.c
> @@ -251,7 +251,8 @@ asmlinkage unsigned long sys_brk(unsigned long brk)
> * not page aligned -Ram Gupta
> */
> rlim = current->signal->rlim[RLIMIT_DATA].rlim_cur;
> - if (rlim < RLIM_INFINITY && brk - mm->start_data > rlim)
> + if (rlim < RLIM_INFINITY && brk - mm->start_data -
> + (mm->start_brk - mm->end_data) > rlim)
> goto out;
>
> newbrk = PAGE_ALIGN(brk);
I find the order in that test mysterious. Others might ask you to use
an intermediate variable, I don't care about that, but I would find
if (rlim < RLIM_INFINITY &&
(brk - mm->start_brk) + (mm->end_data - mm->start_data) > rlim)
much easier to understand.
Hugh
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] [RFC] brk randomization: compute RLIMIT_DATA properly (was Re: x86: randomize brk() and RLIMIT_DATA)
2007-10-26 12:02 ` Hugh Dickins
@ 2007-10-26 12:16 ` Jiri Kosina
2007-10-26 12:30 ` Hugh Dickins
0 siblings, 1 reply; 10+ messages in thread
From: Jiri Kosina @ 2007-10-26 12:16 UTC (permalink / raw)
To: Hugh Dickins, Andrew Morton
Cc: Sami Farin, Linux kernel Mailing List, Jiri Kosina, Arjan van de Ven
On Fri, 26 Oct 2007, Hugh Dickins wrote:
> > - if (rlim < RLIM_INFINITY && brk - mm->start_data > rlim)
> > + if (rlim < RLIM_INFINITY && brk - mm->start_data -
> > + (mm->start_brk - mm->end_data) > rlim)
> I find the order in that test mysterious.
I agree that the order you proposed is easier to understand on the first
sight.
From: Jiri Kosina <jkosina@suse.cz>
brk randomization: compute RLIMIT_DATA properly
In cases of heap area placed at randomly-generated offset from
mm->end_data (arch_randomize_brk()), we need to subtract the value of the
offset for setrlimit(RLIMIT_DATA) to work properly -- otherwise we count
the unoccupied memory between mm->end_data and mm->start_brk as occupied.
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
diff --git a/mm/mmap.c b/mm/mmap.c
index facc1a7..673ac7d 100644
--- a/mm/mmap.c
+++ b/mm/mmap.c
@@ -251,7 +251,8 @@ asmlinkage unsigned long sys_brk(unsigned long brk)
* not page aligned -Ram Gupta
*/
rlim = current->signal->rlim[RLIMIT_DATA].rlim_cur;
- if (rlim < RLIM_INFINITY && brk - mm->start_data > rlim)
+ if (rlim < RLIM_INFINITY && (brk - mm->start_brk) +
+ (mm->end_data - mm->start_data) > rlim)
goto out;
newbrk = PAGE_ALIGN(brk);
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] [RFC] brk randomization: compute RLIMIT_DATA properly (was Re: x86: randomize brk() and RLIMIT_DATA)
2007-10-26 12:16 ` Jiri Kosina
@ 2007-10-26 12:30 ` Hugh Dickins
2007-10-26 12:33 ` Jan Engelhardt
0 siblings, 1 reply; 10+ messages in thread
From: Hugh Dickins @ 2007-10-26 12:30 UTC (permalink / raw)
To: Jiri Kosina
Cc: Andrew Morton, Sami Farin, Linux kernel Mailing List,
Jiri Kosina, Arjan van de Ven
On Fri, 26 Oct 2007, Jiri Kosina wrote:
> On Fri, 26 Oct 2007, Hugh Dickins wrote:
>
> > > - if (rlim < RLIM_INFINITY && brk - mm->start_data > rlim)
> > > + if (rlim < RLIM_INFINITY && brk - mm->start_data -
> > > + (mm->start_brk - mm->end_data) > rlim)
> > I find the order in that test mysterious.
>
> I agree that the order you proposed is easier to understand on the first
> sight.
>
>
> From: Jiri Kosina <jkosina@suse.cz>
>
> brk randomization: compute RLIMIT_DATA properly
>
> In cases of heap area placed at randomly-generated offset from
> mm->end_data (arch_randomize_brk()), we need to subtract the value of the
> offset for setrlimit(RLIMIT_DATA) to work properly -- otherwise we count
> the unoccupied memory between mm->end_data and mm->start_brk as occupied.
>
> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Acked-by: Hugh Dickins <hugh@veritas.com>
>
> diff --git a/mm/mmap.c b/mm/mmap.c
> index facc1a7..673ac7d 100644
> --- a/mm/mmap.c
> +++ b/mm/mmap.c
> @@ -251,7 +251,8 @@ asmlinkage unsigned long sys_brk(unsigned long brk)
> * not page aligned -Ram Gupta
> */
> rlim = current->signal->rlim[RLIMIT_DATA].rlim_cur;
> - if (rlim < RLIM_INFINITY && brk - mm->start_data > rlim)
> + if (rlim < RLIM_INFINITY && (brk - mm->start_brk) +
> + (mm->end_data - mm->start_data) > rlim)
> goto out;
>
> newbrk = PAGE_ALIGN(brk);
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] [RFC] brk randomization: compute RLIMIT_DATA properly (was Re: x86: randomize brk() and RLIMIT_DATA)
2007-10-26 12:30 ` Hugh Dickins
@ 2007-10-26 12:33 ` Jan Engelhardt
2007-10-26 13:24 ` Hugh Dickins
0 siblings, 1 reply; 10+ messages in thread
From: Jan Engelhardt @ 2007-10-26 12:33 UTC (permalink / raw)
To: Hugh Dickins
Cc: Jiri Kosina, Andrew Morton, Sami Farin,
Linux kernel Mailing List, Jiri Kosina, Arjan van de Ven
On Oct 26 2007 13:30, Hugh Dickins wrote:
>> @@ -251,7 +251,8 @@ asmlinkage unsigned long sys_brk(unsigned long brk)
>> * not page aligned -Ram Gupta
>> */
>> rlim = current->signal->rlim[RLIMIT_DATA].rlim_cur;
>> - if (rlim < RLIM_INFINITY && brk - mm->start_data > rlim)
>> + if (rlim < RLIM_INFINITY && (brk - mm->start_brk) +
>> + (mm->end_data - mm->start_data) > rlim)
>> goto out;
>>
>> newbrk = PAGE_ALIGN(brk);
Parentheses around (brk - mm->start_brk) + (mm->end_data - mm->start_data)
not strictly necessary.
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] [RFC] brk randomization: compute RLIMIT_DATA properly (was Re: x86: randomize brk() and RLIMIT_DATA)
2007-10-26 12:33 ` Jan Engelhardt
@ 2007-10-26 13:24 ` Hugh Dickins
0 siblings, 0 replies; 10+ messages in thread
From: Hugh Dickins @ 2007-10-26 13:24 UTC (permalink / raw)
To: Jan Engelhardt
Cc: Jiri Kosina, Andrew Morton, Sami Farin,
Linux kernel Mailing List, Jiri Kosina, Arjan van de Ven
On Fri, 26 Oct 2007, Jan Engelhardt wrote:
> On Oct 26 2007 13:30, Hugh Dickins wrote:
> >> @@ -251,7 +251,8 @@ asmlinkage unsigned long sys_brk(unsigned long brk)
> >> * not page aligned -Ram Gupta
> >> */
> >> rlim = current->signal->rlim[RLIMIT_DATA].rlim_cur;
> >> - if (rlim < RLIM_INFINITY && brk - mm->start_data > rlim)
> >> + if (rlim < RLIM_INFINITY && (brk - mm->start_brk) +
> >> + (mm->end_data - mm->start_data) > rlim)
> >> goto out;
> >>
> >> newbrk = PAGE_ALIGN(brk);
>
> Parentheses around (brk - mm->start_brk) + (mm->end_data - mm->start_data)
> not strictly necessary.
Yes, but don't you find they make it easier to understand the expression?
Hugh
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2007-10-26 13:25 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2007-10-25 13:41 x86: randomize brk() and RLIMIT_DATA Sami Farin
2007-10-25 14:13 ` Arjan van de Ven
2007-10-25 14:46 ` Jiri Kosina
2007-10-25 17:19 ` Sami Farin
2007-10-26 10:44 ` [PATCH] [RFC] brk randomization: compute RLIMIT_DATA properly (was Re: x86: randomize brk() and RLIMIT_DATA) Jiri Kosina
2007-10-26 12:02 ` Hugh Dickins
2007-10-26 12:16 ` Jiri Kosina
2007-10-26 12:30 ` Hugh Dickins
2007-10-26 12:33 ` Jan Engelhardt
2007-10-26 13:24 ` Hugh Dickins
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®