Re: [PATCH] ld.so: Handle read-only dynamic section gracefully [BZ #28340]

[Siddhesh Poyarekar <siddhesh@sourceware.org>]

On 9/17/21 9:14 AM, Florian Weimer wrote:
> * Siddhesh Poyarekar:
> 
>> On 9/17/21 8:29 AM, H.J. Lu wrote:
>>> On Thu, Sep 16, 2021 at 7:47 PM Siddhesh Poyarekar
>>> <siddhesh@sourceware.org> wrote:
>>>>
>>>> On 9/17/21 3:41 AM, H.J. Lu wrote:
>>>>>> 2. Do we want to leave .dynamic unrelocated for read-only DYNAMIC or
>>>>>> should we instead allocate an array to write relocated addresses in
>>>>>> there, like we did for vdso?
>>>>>
>>>>> My patch removed the hack for vDSO to leave the read-only
>>>>> PT_DYNAMIC segment unrelocated.
>>>>
>>>> Presuming that your rationale for this is your response from your other
>>>> email:
>>>>
>>>>> Non-glibc consumers of
>>>>> PT_DYNAMIC segment need to handle it differently for these non-ABI
>>>>> conforming binaries.
>>>>
>>>> could you qualify this a bit more?  My reading of the spec[1] suggests
>>>> that the spec is silent on whether the .dynamic entries should be
>>>> writable, it merely says that the dynamic linker reads d_un.d_ptr and
>>>> adds the memory base address to it when referring to those addresses.
>>>> So calling them non-conforming seems wrong.
>>>>
>>> I was referring to
>>> extern ElfW(Dyn) _DYNAMIC[];
>>> On x86-64, _DYNAMIC entries are normally relocated.  But for
>>> read-only
>>> DSOs, they are unrelocated.   It isn't a problem for ld.so since it doesn't
>>> use it.
>>
>> OK, then we've traditionally had an inconsistency between the contents
>> of _DYNAMIC and l_info and this change would make that difference go
>> away.  It's still a user-visible change as far as consumers of l_info
>> (through dl_iterate_phdr) are concerned.
>>
>> Why not just allocate a writable table for read-only DSOs and put the
>> relocated entries there, pointing the l_info[...] pointer to it?  That
>> will ensure that the change is user-invisible.
> 
> l_info isn't an exported field, is it?  So this wouldn't make a
> difference.

Hmm, I thought it was but then on re-reading dl_iterate_phdr, it's only 
possible to read through _DYNAMIC via the program headers.

In that case I think H. J.'s latest patch seems fine in principle.  I 
could do a proper review if you don't see any other issues here.

Siddhesh