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

[Rafael Avila de Espindola via llvm-commits]

Rui Ueyama <ruiu at google.com> writes:

>> > 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?
>
>
> 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.
>
> 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.

I like the idea of opening a path to having it fully read only in the
future. By fully read only I mean replacing DT_DEBUG with something that
doesn't involve writing to the mapped file.

Since that is what Fuchsia is doing, I would support the the last patch
adding the option and omitting DT_DEBUG if it is used.

I agree that there is not much value is extending the mips way to other
architectures.

Cheers,
Rafael