clone() and Glibc

[Frederico Silva Correa <fscorrea@inf.ufrgs.br>]

Dear developers of the GNU libc:

At the quality of a novice, recently graduated in CS (despite familiarized 
with both C and C++), I found myself puzzled by a little issue.

Glibc provides a wrapper for the clone() system call, which receives 
parameters in the following order:

- a pointer to the function "func" to be run by the child thread;
- a base address for the child stack (we'll be back here), since I'm passing 
CLONE_VM, therefore sharing memory thus unable to reuse the parent thread's 
stack addresses;
- 0x100 or the flag CLONE_VM;
- a pointer to the arguments to be passed to "func" and run with the child 
thread.

Automatic storage local variables are usually placed into the stack, which 
remains more or less a fixed value, decided when the application is run, is 
that correct?
Very well. What, then, would be a stack frame whose "base address" I myself 
malloc'd (at the HEAP) then arbitrarily decided that space --- again, a 
priori in the heap --- to be treated like a stack frame pertaining to the 
child thread.

How am I supposed to interpret all of this? The space allocated at the heap 
need to be freed in the first place? Is this so-called "stack" on the heap? 
Or is it a regular stack frame? What about the potential threatens related to 
e.g. ret2plt and format string attacks?

I'd be very pleased to have these questions clarified, both as a language 
enthusiast and as an user with security worries.

Thanks in advance.

-- 
Frederico Corrêa - 118775