<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, May 24, 2017 at 9:21 AM, Rafael Avila de Espindola <span dir="ltr"><<a href="mailto:rafael.espindola@gmail.com" target="_blank">rafael.espindola@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">Roland McGrath <<a href="mailto:mcgrathr@google.com">mcgrathr@google.com</a>> writes:<br>
<br>
> Rafael mentioned "something with aux vectors", but I don't know what he<br>
> had in mind.  The ElfNN_auxv_t kind of auxiliary vector in many Unix-like<br>
> systems' ELF ABIs is a one-way channel of information at program loading<br>
> time, not a way that the dynamic linker can record something to be seen<br>
> later.  (For example, on Linux, /proc/$pid/auxv and NT_AUXV notes in core<br>
> files are a snapshot of the bits given the program on startup, not a dump<br>
> gleaned from the program's memory where it could have modified them.)<br>
<br>
</span>The suggestion is from Joerg actually:<br>
<br>
------------------------------<wbr>---------------------------<br>
Systems that want to support this new mechanism reserve an AUX vector<br>
similar to AT_BASE and let the dynamic linker fill it in. No space<br>
required in the executable that way.<br>
------------------------------<wbr>---------------------------<br>
<br>
It sound similar, no? Both are a way of passing a pointer to the<br>
process. Once the process has a pointer to what now is pointed by<br>
DT_DEBUG it can walk it as it does now.<br>
<span class=""><br>
> For Fuchsia, we're set on having read-only .dynamic in our ABI.  We'd be<br>
> happy to have DT_DEBUG_INDIRECT and would make our runtime support it if<br>
> it got added to the tools.  But we don't actually care about it enough to<br>
> make the effort to get consensus on a generic ELF ABI number assignment<br>
> and formalization of the ABI for our own sake.<br>
<br>
</span>This is something I don't understand. With a read only .dynamic *and* a<br>
AT_BASE like mechanism you end up with a DSO whose rw section is only<br>
what the user requested. But DT_DEBUG_INDIRECT you still have a linker<br>
created rw section. Is there anything about .dynamic that makes it<br>
particularly harmful as rw?</blockquote><div><br></div><div>Yeah, I think that is my question too. As Roland said, if we would start over, we would make .dynamic read-only, and I totally agree with that. But writable .dynamic sections don't seem that bad that we want to create a new switch to make it read-only. At least it is not very clear to me that what we can get by doing that.</div><div><br></div><div>Potential security improvement seems very small given that we have the relro mechanism. Saving one page per an ELF module seems small, and it is probably zero cost on Fuchsia as you guys don't write anything to a page containing .dynamic regardless of presence of DT_DEBUG. The only clear benefit I can think of is, since Fuchsia doesn't write anything to .dynamic, it is semantically more clean if we actually mark it read-only. But it doesn't seem like a practical benefit.</div></div></div></div>