Proposal for STT_GNU_IFUNC and R_*_IRELATIVE
Ulrich Drepper
drepper@redhat.com
Wed May 27 19:40:00 GMT 2009
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
H.J. Lu wrote:
> I got
>
> 00000000004005ac <main>:
> 4005ac: 55 push %rbp
> 4005ad: 48 89 e5 mov %rsp,%rbp
> 4005b0: bf fd ff ff ff mov $0xfffffffd,%edi
> 4005b5: e8 00 00 00 00 callq 4005ba <main+0xe>
> 4005ba: b8 00 00 00 00 mov $0x0,%eax
> 4005bf: c9 leaveq
>
> Relocation section '.rela.ifunc.dyn' at offset 0x430 contains 1 entries:
> Offset Info Type Sym. Value Sym. Name + Addend
> 0000004005b6 000400000002 R_X86_64_PC32 foo() foo - 4
>
> Dynamic linker will lookup STT_GNU_IFUNC foo and resolve
> R_X86_64_PC32. But dynamic linker will segfaut as soon as
> it tries to run foo () since the text segment isn't executable
> when it is changed to PROT_READ|PROT_WRITE before
> updating the text segment.
Exactly. We must never write to a text segment. Making a text segment
writable is simply no option. It's not even possible with the
appropriate security policy in place.
Really: text relocations are no solutions. Ever. No new extension must
rely on writable text segments.
> Certain static executables like kernel may
> have
>
> call STT_GNU_IFUNC foo
>
> where the best foo will be selected at boot time for a given hardware.
> PLT/GOT isn't needed here.
This doesn't matter. Either a PLT slot has a IRELATIVE relocation
attached (no lookup, no dynamic selection) or it is a traditional PLT
jump at which point at the first call ld.so will relocate the GOT entry.
- --
⧠Ulrich Drepper ⧠Red Hat, Inc. ⧠444 Castro St ⧠Mountain View, CA â
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
iEYEARECAAYFAkodlNoACgkQ2ijCOnn/RHRblQCdFSUC6y35miwG+KeFCDMu+lKa
ZWQAn1lZg+KQVQ+NG29OlngxsmQ1grq2
=fOna
-----END PGP SIGNATURE-----
More information about the Libc-alpha
mailing list