Prev: configuring serial port
Next: Where can I find the corresponding code for shell utliities
From: CICAP on 19 Jul 2010 05:55
I know this program is buggy, but I was trying to understand why it
shows this behavior on linux kernel
2.6.32:

#include <stdio.h>
#include <stdlib.h>

int main (int argc, char **argv)
{
int a[10];
printf("%d\n", a[1000]);
return 0;
}

execution 1: 1668312366
execution 2: 0
execution 3: segmentation fault
execution 4: 0
etc...

After disabling ASLR on my kernel, the behavior isn't random anymore.
What is exacting happening on the stack address?
From: Nicolas George on 19 Jul 2010 06:17
CICAP wrote in message
<de7ba55b-fe3f-4197-9c7d-cb8f87e98e6e(a)u26g2000yqu.googlegroups.com>:
> After disabling ASLR on my kernel, the behavior isn't random anymore.
> What is exacting happening on the stack address?

If you thought of disabling ASLR, I do not understand what you need.

You could try, in your program, to display the address of a[1000] and dump
/proc/self/maps to see exactly in which segment it falls.
From: Xavier Roche on 19 Jul 2010 07:36
CICAP wrote:
> After disabling ASLR on my kernel, the behavior isn't random anymore.
> What is exacting happening on the stack address?

You are accessing memory beyond the stack (beyond the top of the stack
actually, as the stack pointer decreases as you allocate memory on it -
it means that a[1000] is outside the reserved stack address space),
hence the behaviour is undefined. On a fixed layout, the behavior will
be fixed (such as crash if the space is unreserved, or random garbage if
the space is part of some global variables space). On a random space
layout, I suppose the behavior is.. random.
From: CICAP on 21 Jul 2010 15:16
On 19 Lug, 13:36, Xavier Roche <xro...(a)free.fr.NOSPAM.invalid> wrote:
> CICAP wrote:
> > After disabling ASLR on my kernel, the behavior isn't random anymore.
> > What is exacting happening on the stack address?
>
> You are accessing memory beyond the stack (beyond the top of the stack
> actually, as the stack pointer decreases as you allocate memory on it -
> it means that a[1000] is outside the reserved stack address space),
> hence the behaviour is undefined. On a fixed layout, the behavior will
> be fixed (such as crash if the space is unreserved, or random garbage if
> the space is part of some global variables space). On a random space
> layout, I suppose the behavior is.. random.

I have another question: running following program I get segm fault on
different value of "x" after every execution:

void f(int x) {
printf("%d", x);
f(x + 1);
}

int main(...) {
f(0);
return 0;
}

Then if I disable ASLR the segm fault happens always on the same value
of 'x'. Does this mean that ASLR implementation change stack size
randomly? I mean, it's normal that stack address change...but stack
size too?
From: Ersek, Laszlo on 22 Jul 2010 15:20
On Wed, 21 Jul 2010, CICAP wrote:

> I have another question: running following program I get segm fault on
> different value of "x" after every execution:
>
> void f(int x) {
> printf("%d", x);
> f(x + 1);
> }
>
> int main(...) {
> f(0);
> return 0;
> }
>
> Then if I disable ASLR the segm fault happens always on the same value
> of 'x'. Does this mean that ASLR implementation change stack size
> randomly? I mean, it's normal that stack address change...but stack size
> too?

(Since nobody seems to have answered yet, I'll try to.)

If that "ASLR" thingy mapped N pages for the stack at a different page
boundary each time, but it also placed the user-visible base address of
the stack at a random offset into the first page, that might cause you to
see what you see.

(x_max - x_min) * frame_size <= page_size

could be an indicator of this happening.

lacos
 | 
Pages: 1
Prev: configuring serial port
Next: Where can I find the corresponding code for shell utliities