[uClibc] Re: uclibc and heap randomisation (ET_EXEC)
Joakim.Tjernlund at lumentis.se
Mon Aug 30 21:19:35 UTC 2004
> 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)
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?
More information about the uClibc