This is the mail archive of the
newlib@sourceware.org
mailing list for the newlib project.
Re: [uClinux-dev] Re: brk(2) and stack pointer
Jivin Shaun Jackman lays it down ...
> On 4/28/06, Russell King - ARM Linux <linux@arm.linux.org.uk> wrote:
> >Why do you need to care about this? I suspect if you do care about it,
> >you're in for all sorts of games - think about the case where you
> >malloc some memory for a stack, and then use clone() to create a new
> >thread whose stack is in that malloc'd memory. That would quite
> >probably be below the current brk, so with your code would cause
> >brk() to fail.
>
> I agree that there's too many gotchas to check for stack-smashing
> reliably. However, I like Jamie Lokier's idea of checking if the stack
> point is contained within the new sbrk block. This is almost certainly
> an unallowed condition.
>
> >The default stack which the kernel gives you will be contained within
> >one "VMA", and the zero'd data segment (edata to brk) will be within
> >another - the two of which will not ever be allowed to overlap. So
> >you can consider that this case is dealt with by the kernel.
>
> I was thinking specifically of the uClinux nommu case. I think bFLT
> binaries, at least, locate the stack immediately after the bss and
> heap.
brk, when implemented under uClinux only gives you access to a small
amount of memory. Typically that below the stack and above the BSS.
The space you get is the slack space from the kernel allocator, so it
can be anything from none up.
Typically, brk is not used on uClinux systems, though some malloc
implementations have used it to get the absolute most out of the RAM,
most tend to stick with mmap allocation,
Cheers,
Davidm
--
David McCullough, david_mccullough@securecomputing.com, Ph:+61 734352815
Secure Computing - SnapGear http://www.uCdot.org http://www.cyberguard.com