[PATCH] D33251: [lld][ELF]Add option to make .dynamic read only

[Rafael Avila de Espindola via llvm-commits]

Roland McGrath <mcgrathr at google.com> writes:

> Rafael mentioned "something with aux vectors", but I don't know what he
> had in mind.  The ElfNN_auxv_t kind of auxiliary vector in many Unix-like
> systems' ELF ABIs is a one-way channel of information at program loading
> time, not a way that the dynamic linker can record something to be seen
> later.  (For example, on Linux, /proc/$pid/auxv and NT_AUXV notes in core
> files are a snapshot of the bits given the program on startup, not a dump
> gleaned from the program's memory where it could have modified them.)

The suggestion is from Joerg actually:

---------------------------------------------------------
Systems that want to support this new mechanism reserve an AUX vector
similar to AT_BASE and let the dynamic linker fill it in. No space
required in the executable that way.
---------------------------------------------------------

It sound similar, no? Both are a way of passing a pointer to the
process. Once the process has a pointer to what now is pointed by
DT_DEBUG it can walk it as it does now.

> For Fuchsia, we're set on having read-only .dynamic in our ABI.  We'd be
> happy to have DT_DEBUG_INDIRECT and would make our runtime support it if
> it got added to the tools.  But we don't actually care about it enough to
> make the effort to get consensus on a generic ELF ABI number assignment
> and formalization of the ABI for our own sake.

This is something I don't understand. With a read only .dynamic *and* a
AT_BASE like mechanism you end up with a DSO whose rw section is only
what the user requested. But DT_DEBUG_INDIRECT you still have a linker
created rw section. Is there anything about .dynamic that makes it
particularly harmful as rw?

Cheers,
Rafael