This is the mail archive of the
mailing list for the binutils project.
Re: Read-only data in ELF libraries may be remapped writable at runtime (upcoming NDSS'17 paper)
> Exactly. You might like to try git master or binutils-2_28-branch,
> which should be fixed for aarch64, arm, hppa, i386, metag,
> microblaze, mips, mips64, nios2, or1k, ppc, ppc64, s390, s390x, sparc,
> sparc64, tic6x, tilegx, tilepro and x86-64.
> Note that the fix is only effective when linking with -z relro.
Also fixed now in gold.
Nevertheless, I'd like to suggest that we're fixing the wrong problem.
Copy relocations have many problems, and I think we should focus more
on simply eliminating them entirely. The paper talks about that, but
only to the extent of using -fpic, which is overkill. It talks about
how Windows and macOS deal with the problem, but it overlooks some
other Unix platforms like HP-UX that do not use copy relocations at
On HP-UX, the compiler can be told to assume that any undefined data
symbol may be external to the load module, and generates an indirect
reference through the linkage table (aka, GOT). The linker is able to
rewrite the indirect reference as a direct reference if it determines
that the reference is within the same load module. The rewritten
sequence involves an extra register copy, but eliminates a much more
expensive memory load. The compiler can also make the opposite
assumption, and uses "#pragma external" to flag symbols that are known
to be external and should use the indirect sequence. All system header
files on HP-UX are decorated with these pragmas for all exported
A similar technique could be used on most other platforms that today
require copy relocations. On x86-64 today, both the Gnu ld and gold
already support a similar rewrite, converting an indirect load via the
GOT into a load effective address (LEA) instruction when the target
symbol is known to be local. All the compiler needs to do is:
(a) Provide an option that will generate the PIC sequence only for
non-local data references; and/or
(b) Treat "__attribute__ ((dllimport))" or "__declspec(dllimport)" as
a hint to generate the GOT-indirect sequence, and add dllimport
attributes to exported symbols in system header files. (This is
basically the Windows approach.)
P.S. Perhaps it's just because I'm a linker person, but I found the
title of the article a bit sensationalistic. The linker isn't
*betraying* anyone, and segregating constant data into read-only
memory is really more of an alarm system that sometimes keeps the
hackers at bay after they've already found a real bug in your code
(e.g., a buffer overrun). Useful, yes, but it's no different from any
other hardening tool that doesn't catch every vulnerability in your
P.P.S. For more background on copy relocations (probably more than you
want), see this thread that started on the binutils mailing list last
... continued into April ...
... then migrated over the the gcc list ...