Re: [PATCH 1/3] elf: Allow dlopen of filter object to work [BZ #16272]

[Florian Weimer <fweimer at redhat dot com>]

* David Kilroy:

[Changes related to inserting the filtee before the filter]

>>These changes look reasonable to me.
>
> That's good to know. I tried a few different things before I realised I needed
> to fix up the relocations as well.

>>> diff --git a/elf/dl-open.c b/elf/dl-open.c
>>> index a9fd4cb..7fcfdc0 100644
>>> --- a/elf/dl-open.c
>>> +++ b/elf/dl-open.c
>>> @@ -305,22 +305,25 @@ dl_open_worker (void *a)
>>>       allows IFUNC relocations to work and it also means copy
>>>       relocation of dependencies are if necessary overwritten.  */
>>>    unsigned int nmaps = 0;
>>> -  struct link_map *l = new;
>>> +  unsigned int j = 0;
>>> +  struct link_map *l =  new->l_initfini[0];
>>>    do
>>>      {
>>>        if (! l->l_real->l_relocated)
>>>       ++nmaps;
>>> -      l = l->l_next;
>>> +      l = new->l_initfini[++j];
>>>      }
>>>    while (l != NULL);
>>> +  /* Stack allocation is limited by the number of loaded objects.  */
>>>    struct link_map *maps[nmaps];
>>>    nmaps = 0;
>>> -  l = new;
>>> +  j = 0;
>>> +  l = new->l_initfini[0];
>>>    do
>>>      {
>>>        if (! l->l_real->l_relocated)
>>>       maps[nmaps++] = l;
>>> -      l = l->l_next;
>>> +      l = new->l_initfini[++j];
>>>      }
>>>    while (l != NULL);
>>>    _dl_sort_maps (maps, nmaps, NULL, false);
>>
>>I have much more trouble ascertaining whether this change is correct.
>>Are we certain that new->l_initfini is not a subset of the maps that
>>have been loaded?
>
> That is something I'm not sure about (yet). I'll look into this further. My
> reasoning for switching to using l_initfini was that the filtee's constructors
> were crashing, and clearly anything that needed initialisation ought to be
> relocated first.

In an off-list discussion, Carlos also had some concerns about the state
of filter support.  Based on the Solaris documentation,

  <https://docs.oracle.com/cd/E23824_01/html/819-0690/chapter4-4.html>

it seems to me that filters are mostly a link editor feature.  Sorting
the filtee prior to the filter appears to be the right thing to do.
However, what seems to be missing currently is ignoring the filter
during symbol binding.  I think if the filter contains symbols that are
not present in the filtee, it is possible to bind them.  That does not
seem to match the documented Solaris behavior.

The Solaris documentation does not mention symbol filtering
(constraining the set of exported symbols) at run time.  This kind of
filtering is achieved at run time because the link editor only looks at
symbols in the filter and does not consult the filtee.

On GNU, I think we support this via a linker script which specifies a
link-time object with a link-time ABI (typically a subset of the
run-time ABI).  Therefore, filter support is redundant.

David, have you ever used filters on Solaris?  Can you comment on the
expected behavior for them?

Thanks,
Florian