* check-textrel
@ 2006-03-02 4:11 David S. Miller
2006-03-02 4:42 ` check-textrel Roland McGrath
2006-03-02 7:41 ` check-textrel Jakub Jelinek
0 siblings, 2 replies; 5+ messages in thread
From: David S. Miller @ 2006-03-02 4:11 UTC (permalink / raw)
To: libc-hacker
I just noticed the elf/check-textrel test is failing on
sparc. It complains because the third segment of all the
shared objects are writable and executable.
This turns out to be the .tdata section.
LOAD off 0x0014e478 vaddr 0x0015e478 paddr 0x0015e478 align 2**16
filesz 0x00004984 memsz 0x00007268 flags rwx
...
17 .tdata 00000008 0015e478 0015e478 0014e478 2**2
CONTENTS, ALLOC, LOAD, DATA, THREAD_LOCAL
Probably some binutils issue?
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: check-textrel
2006-03-02 4:11 check-textrel David S. Miller
@ 2006-03-02 4:42 ` Roland McGrath
2006-03-02 5:16 ` check-textrel David S. Miller
2006-03-02 6:12 ` check-textrel David S. Miller
2006-03-02 7:41 ` check-textrel Jakub Jelinek
1 sibling, 2 replies; 5+ messages in thread
From: Roland McGrath @ 2006-03-02 4:42 UTC (permalink / raw)
To: David S. Miller; +Cc: libc-hacker
> I just noticed the elf/check-textrel test is failing on
> sparc. It complains because the third segment of all the
> shared objects are writable and executable.
>
> This turns out to be the .tdata section.
>
> LOAD off 0x0014e478 vaddr 0x0015e478 paddr 0x0015e478 align 2**16
> filesz 0x00004984 memsz 0x00007268 flags rwx
> ...
> 17 .tdata 00000008 0015e478 0015e478 0014e478 2**2
> CONTENTS, ALLOC, LOAD, DATA, THREAD_LOCAL
>
> Probably some binutils issue?
That should be PT_TLS, not PT_LOAD.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: check-textrel
2006-03-02 4:42 ` check-textrel Roland McGrath
@ 2006-03-02 5:16 ` David S. Miller
2006-03-02 6:12 ` check-textrel David S. Miller
1 sibling, 0 replies; 5+ messages in thread
From: David S. Miller @ 2006-03-02 5:16 UTC (permalink / raw)
To: roland; +Cc: libc-hacker
From: Roland McGrath <roland@redhat.com>
Date: Wed, 1 Mar 2006 20:41:54 -0800 (PST)
> > This turns out to be the .tdata section.
> >
> > LOAD off 0x0014e478 vaddr 0x0015e478 paddr 0x0015e478 align 2**16
> > filesz 0x00004984 memsz 0x00007268 flags rwx
> > ...
> > 17 .tdata 00000008 0015e478 0015e478 0014e478 2**2
> > CONTENTS, ALLOC, LOAD, DATA, THREAD_LOCAL
> >
> > Probably some binutils issue?
>
> That should be PT_TLS, not PT_LOAD.
Ok, my binutils was a little crufty, I'm retesting with current
binutils.
Thanks.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: check-textrel
2006-03-02 4:42 ` check-textrel Roland McGrath
2006-03-02 5:16 ` check-textrel David S. Miller
@ 2006-03-02 6:12 ` David S. Miller
1 sibling, 0 replies; 5+ messages in thread
From: David S. Miller @ 2006-03-02 6:12 UTC (permalink / raw)
To: roland; +Cc: libc-hacker
From: Roland McGrath <roland@redhat.com>
Date: Wed, 1 Mar 2006 20:41:54 -0800 (PST)
> > This turns out to be the .tdata section.
> >
> > LOAD off 0x0014e478 vaddr 0x0015e478 paddr 0x0015e478 align 2**16
> > filesz 0x00004984 memsz 0x00007268 flags rwx
> > ...
> > 17 .tdata 00000008 0015e478 0015e478 0014e478 2**2
> > CONTENTS, ALLOC, LOAD, DATA, THREAD_LOCAL
> >
> > Probably some binutils issue?
>
> That should be PT_TLS, not PT_LOAD.
Even with current binutils, it's still there, but then I noticed
this (this is for libc.so):
Program Header:
PHDR off 0x00000034 vaddr 0x00000034 paddr 0x00000034 align 2**2
filesz 0x00000140 memsz 0x00000140 flags r-x
INTERP off 0x00149428 vaddr 0x00149428 paddr 0x00149428 align 2**3
filesz 0x00000018 memsz 0x00000018 flags r--
LOAD off 0x00000000 vaddr 0x00000000 paddr 0x00000000 align 2**16
filesz 0x0014e015 memsz 0x0014e015 flags r-x
LOAD off 0x0014e478 vaddr 0x0015e478 paddr 0x0015e478 align 2**16
filesz 0x00004984 memsz 0x00007268 flags rwx
DYNAMIC off 0x0014ff18 vaddr 0x0015ff18 paddr 0x0015ff18 align 2**2
filesz 0x000000e8 memsz 0x000000e8 flags rw-
NOTE off 0x00000174 vaddr 0x00000174 paddr 0x00000174 align 2**2
filesz 0x00000020 memsz 0x00000020 flags r--
TLS off 0x0014e478 vaddr 0x0015e478 paddr 0x0015e478 align 2**2
filesz 0x00000008 memsz 0x0000002c flags r--
EH_FRAME off 0x00149440 vaddr 0x00149440 paddr 0x00149440 align 2**2
filesz 0x000010c4 memsz 0x000010c4 flags r--
STACK off 0x00000000 vaddr 0x00000000 paddr 0x00000000 align 2**2
filesz 0x00000000 memsz 0x00000000 flags rw-
RELRO off 0x0014e478 vaddr 0x0015e478 paddr 0x0015e478 align 2**0
filesz 0x00001b88 memsz 0x00001b88 flags r-x
Note the second LOAD and the one TLS are at the same location, same
off and vaddr, yet different alignment, different filesz and different
memsz.
RELRO is at the same offset too, again different filesz and memsz.
17 .tdata 00000008 0015e478 0015e478 0014e478 2**2
CONTENTS, ALLOC, LOAD, DATA, THREAD_LOCAL
18 .tbss 00000024 0015e480 0015e480 0014e480 2**2
ALLOC, THREAD_LOCAL
19 .fini_array 00000004 0015e480 0015e480 0014e480 2**2
CONTENTS, ALLOC, LOAD, DATA
20 .ctors 0000000c 0015e484 0015e484 0014e484 2**2
CONTENTS, ALLOC, LOAD, DATA
21 .dtors 00000008 0015e490 0015e490 0014e490 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
22 __libc_subfreeres 00000054 0015e498 0015e498 0014e498 2**2
CONTENTS, ALLOC, LOAD, DATA
23 __libc_atexit 00000004 0015e4ec 0015e4ec 0014e4ec 2**2
CONTENTS, ALLOC, LOAD, DATA
24 __libc_thread_subfreeres 00000008 0015e4f0 0015e4f0 0014e4f0 2**2
CONTENTS, ALLOC, LOAD, DATA
25 .data.rel.ro 00001a20 0015e4f8 0015e4f8 0014e4f8 2**2
CONTENTS, ALLOC, LOAD, DATA
26 .dynamic 000000e8 0015ff18 0015ff18 0014ff18 2**2
CONTENTS, ALLOC, LOAD, DATA
27 .got 000023d8 00160000 00160000 00150000 2**2
CONTENTS, ALLOC, LOAD, DATA
28 .plt 00000124 001623d8 001623d8 001523d8 2**2
CONTENTS, ALLOC, LOAD, CODE
29 .data 000008fc 00162500 00162500 00152500 2**3
CONTENTS, ALLOC, LOAD, DATA
30 .bss 000028e0 00162e00 00162e00 00152dfc 2**3
ALLOC
Hmmm...
Part of the big LOAD segment is the .plt, which does need to be
executable and writable.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: check-textrel
2006-03-02 4:11 check-textrel David S. Miller
2006-03-02 4:42 ` check-textrel Roland McGrath
@ 2006-03-02 7:41 ` Jakub Jelinek
1 sibling, 0 replies; 5+ messages in thread
From: Jakub Jelinek @ 2006-03-02 7:41 UTC (permalink / raw)
To: David S. Miller; +Cc: libc-hacker
On Wed, Mar 01, 2006 at 08:12:00PM -0800, David S. Miller wrote:
>
> I just noticed the elf/check-textrel test is failing on
> sparc. It complains because the third segment of all the
> shared objects are writable and executable.
>
> This turns out to be the .tdata section.
>
> LOAD off 0x0014e478 vaddr 0x0015e478 paddr 0x0015e478 align 2**16
> filesz 0x00004984 memsz 0x00007268 flags rwx
> ...
> 17 .tdata 00000008 0015e478 0015e478 0014e478 2**2
> CONTENTS, ALLOC, LOAD, DATA, THREAD_LOCAL
>
> Probably some binutils issue?
Actually, SPARC ABI issue. On i?86/x86_64/etc., there is
a separate .got.plt section (writable, non-executable) and .plt
section (non-writable, executable), on ppc32 there used to be
the same thing as on SPARC, i.e. .plt is both writable and executable,
ld.so changes instructions in .plt rather than some pointer that
.plt insns use, but now we have -msecure-plt alternative
which is also W^X.
Ulrich added the W^X test to elf/check-textrel for security reasons,
but I guess we just should have a whitelist of architectures that
are known with their ABI to be !(W^X). sparc/sparc64/(ppc32 if not
using -msecure-plt)/alpha/ at least.
i?86/x86_64/ppc64/s390/s390x/arm/cris/sh are ok.
Jakub
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2006-03-02 7:41 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2006-03-02 4:11 check-textrel David S. Miller
2006-03-02 4:42 ` check-textrel Roland McGrath
2006-03-02 5:16 ` check-textrel David S. Miller
2006-03-02 6:12 ` check-textrel David S. Miller
2006-03-02 7:41 ` check-textrel Jakub Jelinek
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).