[uClibc] mips dynamic section marked RWE

[Peter S. Mazinger]

On Thu, 11 Nov 2004, Ned Ludd wrote:

> On Thu, 2004-11-11 at 14:48, Erik Andersen wrote:
> > On Thu Nov 11, 2004 at 08:15:13PM +0100, Peter S. Mazinger wrote:
> > > On Thu, 11 Nov 2004, Erik Andersen wrote:
> > > 
> > > > On Thu Nov 11, 2004 at 06:42:18PM +0100, Peter S. Mazinger wrote:
> > > > > Hello!
> > > > > 
> > > > > Does anyone have an idea why the dynamic section on mips[el] is marked RWE 
> > > > > (on other archs it is RW). Is it necessary or is it a toolchain problem 
> > > > > only?
> > > > 
> > > > As I recall, that was done on mips[el] since we were having
> > > > problems making gdb work.  I suspect that setting things RWE
> > > > is no longer necessary.  Care to revert that and confirm that
> > > > gdb still works?
> > > 
> > > How/what to revert?
> > 
> > It turns out that the mprotect call I was thinking of has already
> > been reverted.  And because I wasn't reading carefully it turns
> > out I didn't answer your question at all...  :-)
> > 
> > I have no idea why this happens.  I see nothing causing it in the
> > kernel, or in uClibc/ldso/ldso/.  The mips ABI (SysV ABI, MIPS
> > Supplement, 3rd Edition) only shows .dynamic as type SHF_ALLOC
> > (section occupies memory during process execution), and doesn't
> > show READ, WRITE, or EXEC...
> 
> It's probably coming from the toolchain/binutils marking it this way.
> Seems mips native/cross uClibc/glibc big/little endian built ELF's show
> up the same way.
> 

An answer I have gotten that clears this and another marking issue:
Peter S. Mazinger wrote:
> On mips the dynamic section has RWE marking (both glibc and uclibc), so it 
> seems to be a toolchain issue. On other archs this is RW. Is there some 
> mips specific reason for it? Is it intentional?

The mips dynamic linkers traditionally expect RWE, I think the GNU tools
follow that for compatibility reasons.

> Another curious thing,
> PT_GNU_STACK gets also RWE (tested only uclibc) and I am sure that I use 
> -Wa,--noexecstack for all asm files, the rest should be marked by binutils 
> itself, unless found some part in code, where execstack has to enabled 
> (but the C codebase is common w/ other archs, and the E marking does not 
> happen) Any exec built gets RWE, I have also tried to use 
> -Wa,--noexecstack -Wl,-z,noexecstack, no change either.
> 
> Could you please tell me if this is normal or where should I look?

>From the hardware POV, the classic MIPS MMU has only "valid" and "dirty"
bits. Dirty means the page is writable, valid means it is accessible at
all. Mapping this to ELF flags means that executable implies readable,
and writeable implies both executable and readable. So, at least for now,
a non-executable stack can't be implemented.

Peter

-- 
Peter S. Mazinger <ps dot m at gmx dot net>           ID: 0xA5F059F2
Key fingerprint = 92A4 31E1 56BC 3D5A 2D08  BB6E C389 975E A5F0 59F2