[uClibc] Re: uclibc and heap randomisation (ET_EXEC)

[Joakim Tjernlund]

> On Mon, 30 Aug 2004, Joakim Tjernlund wrote:
> 
> > > On Sat, 14 Aug 2004, Peter S. Mazinger wrote:
> > > 
> > > > Hello!
> > > > 
> > > > The latest uclibc-cvs solved the heap randomisation issue on PAX enabled 
> > > > kernels
> > > 
> > > The attached patch killed again heap reandomisation (it was 
> > > applied to cvs between aug.27-30, don't know exactly).
> > > Is it really necessary?
> > > 
> > > Peter
> > 
> > Hmm, I removed that code by mistake and that broke procps. So I added
> > it again. Why does it break heap randomisation? I don't know if both
> > __environ and __curbrk is needed for procps. Maybe only one of
> > them is needed? Does heap randomisation need both of them to go away
> > or is it enough with __curbrk?
> 
> Only the brk part is the cause. To understand what is needed, 
> please look for (s)brk issues in the ml archive. I have no programming 
> knowledge, so I can't tell you more about it (look for PaX/PAX, some of 
> the mails where sent by me or by pageexec at freemail dot hu)
> 
> Peter

Did some checking in uClibc and it seems like all arches declare __curbrk to be NULL initilized,
except PPC and alpha which uses .comm in assembler to declare __curbrk and i don't know if .comm
implies it it should be zero

Almost all arches(not SPARC and ARM) tests if __curbrk is zero and if so 
does __curbrk = brk(0). 

Seems to me that the __curbrk stuff in ldso can go iff ARM and SPARC is fixed.

Possibly one could do __curbrk = brk(0) in ldso instead. Assuming the
static case is fixed in a similar way, all that testing in (s)brk() of
__curbrk being NULL could go.

I think Erik will have sort this out, I am in no way a (s)brk() expert.

To test, could somebody check if procps still works after removing the
__curbrk(but keeping the __environ) stuff in ldso.c?

 Jocke