Hi All, On Sun, May 18, 2008 at 7:16 PM, Mulyadi Santosa <[EMAIL PROTECTED]> wrote:
> Hi man... > > On Sun, May 18, 2008 at 5:08 PM, Shyamal Shukla <[EMAIL PROTECTED]> > wrote: > > Hi All, > > > > All Linux processes seem to be starting with the virtual address > > 0x8048000. As i see, this value has been hard coded in the linker script. > I > > expected the stack/heap to be lying in the virtual address range 0 - > > 0x08048000. However on printing the address of a local variable, I found > it > > to be lying towards the end of user space addresses 0xb0000000 - > > 0xc0000000. Hence the stack is expected to be lying at the end of the > user > > address space. > > >>yeah, stack (in x86) usually grow downwards from quite high address. > >>IMO this is done to give stack the widest virtually contigous room > >>possible > > > The heap also extends from where the bss ends. > > >>yeah, it grows upward (in x86)...again in the highest address > >>possible...to give widest room possible. But for heap, it can be > >>composed of discontigous VMA..... > > > Dynamic libraries ld-linux.so and libc.so also start from 0x40000000 > > onwards. > > >>yeah...however address space layout randomization, especially one that > >>is implemented in grsecurity could change the rule of the game. The > >>condition: the libs and the binary are compiled as completely safe to > >>be relocated > > > In that case, what is it that resides at addresses 0 - 0x8048000. The > first > > page starting at 0x0 can be marked empty to prohibit usage of 0x0 as a > > usable address, but what about other addresses in this range? > > >>i think libc is now put there...to provide something called ascii > >>armor. Please google for this term first so you can read thoroughly... > >>i forgot the whole definition..sorry. What could be the rationale behind not using addresses 0x0 - 0x08048000 in previous versions. Kernel version 2.4 also shows libc to be at address 0x40xxxxxx i.e. above 1GB address Regards, Shyamal -- Linux - because life is too short for reboots...
