RE: [PATCH v2 0/3] elf: Allow dlopen of filter object to work [BZ #16272]

[David Kilroy <David dot Kilroy at arm dot com>]

Hi,

I looked further at the implementation that uses new->l_prev to find the
filtee objects that need relocation (intending to submit that version).
It turns out that this is problematic.

The dlfcn/tst-rec-dlopen (recursive dlopen in interposed malloc) test
highlighted that during a recursive dlopen, there are non-filtee objects in
new->l_prev that aren't ready to be relocated.

With my modifications I see the test do something like:

dlopen("moddummy1")
  malloc()
    dlopen("moddummy2")
      dummy2()
    dlclose()
  malloc()
    dlopen("moddummy2")
      dummy2()
    dlclose()
  moddummy1 assigned to new (and global namespace?)
  malloc()
    dlopen("moddummy2")
      ->segfault attempting to relocate moddummy1 and moddummy2

If we wanted to use new->l_prev, we would need to be able to identify which
objects in the list were filtee objects loaded by the current object. It may
be simpler just to keep a list of the filtee objects.

l_initfini effectively has this list already - so I think that's the
appropriate solution.



Thanks,

Dave.


> -----Original Message-----
> From: David Kilroy <David.Kilroy@arm.com>
> Sent: 06 November 2019 16:04
> To: libc-alpha@sourceware.org; David Kilroy <David.Kilroy@arm.com>
> Cc: nd <nd@arm.com>
> Subject: RE: [PATCH v2 0/3] elf: Allow dlopen of filter object to work
> [BZ #16272]
> 
> Hi,
> 
> Ping. Just checking what the general feeling is about this patchset.
> 
> If it helps, I've locally tested a version which scans backwards
> through
> new->l_prev and constructs map from the earliest non-relocated object
> (instead
> of the current object). This passes the test. Would this version be
> preferred?
> 
> 
> 
> Thanks,
> 
> Dave.
> 
> Note: for the test case the walk of ->l_prev hits:
> elf/tst-filterobj-lib.so
> elf/ld-linux-x86-64.so.2
> libc.so.6
> dlfcn/libdl.so.2
> linux-vdso.1
> ""                <- an object that doesn't have a ->l_name
> 
> > -----Original Message-----
> > From: libc-alpha-owner at sourceware dot org <libc-alpha-owner at
> > sourceware dot org> On Behalf Of David Kilroy
> > Sent: 24 October 2019 11:34
> > To: libc-alpha at sourceware dot org
> > Cc: nd <nd at arm dot com>
> > Subject: [PATCH v2 0/3] elf: Allow dlopen of filter object to work
> [BZ
> > #16272]
> >
> > This series fixes up the patchset for the comments raised so far.
> > Patches 2 and 3 are unchanged.
> >
> > v2:
> >  - code formatting fixups
> >  - add dependency of test output on filtee library
> >  - tests changed to use the test framework
> >
> > The main outstanding question is whether it is valid to use
> l_initfini
> > to do the relocations, or whether we need to stick to following
> > new->l_next (and new->l_prev). I'm reasonably confident that
> > l_initfini contains all the objects in new->l_next. See
> > https://sourceware.org/ml/libc-alpha/2019-10/msg00659.html
> >
> > The majority of the discussion on this series has been around how
> > filter objects are specified, and the alternatives to using filter
> > objects. The most persuasive is to use a version_script to specify
> the
> > ABI in the link library (.so), and setup the soname symlink (.so.1)
> to
> > point to the filtee. This relies on:
> >
> > * library versioning being used.
> >
> > * dlopen() calls must use the soname.
> >
> > * if there are multiple implementors, they need to be consistent in
> >   versioning the library.
> >
> > I think these are reasonable requirements, though may be difficult to
> > ensure in the field.
> >
> > Independent of the alternatives, I'd still like to advocate fixing
> > dlopen for filter objects. glibc currently works (with various
> > provisos) with filter objects when the application is linked against
> > one. Not being able to work with the same library via dlopen is
> > unexpected.
> >
> > David Kilroy (3):
> >   elf: Allow dlopen of filter object to work [BZ #16272]
> >   elf: avoid redundant sort in dlopen
> >   elf: avoid stack allocation in dl_open_worker
> >
> >  elf/Makefile               | 13 +++++++++++--
> >  elf/dl-deps.c              | 35 ++++++++++++++++++++++++++---------
> >  elf/dl-open.c              | 32 +++++++++++++++-----------------
> >  elf/tst-filterobj-dlopen.c | 39
> > +++++++++++++++++++++++++++++++++++++++
> >  elf/tst-filterobj-flt.c    | 24 ++++++++++++++++++++++++
> >  elf/tst-filterobj-lib.c    | 24 ++++++++++++++++++++++++
> >  elf/tst-filterobj-lib.h    | 18 ++++++++++++++++++
> >  elf/tst-filterobj.c        | 36 ++++++++++++++++++++++++++++++++++++
> >  8 files changed, 193 insertions(+), 28 deletions(-)
> >  create mode 100644 elf/tst-filterobj-dlopen.c
> >  create mode 100644 elf/tst-filterobj-flt.c
> >  create mode 100644 elf/tst-filterobj-lib.c
> >  create mode 100644 elf/tst-filterobj-lib.h
> >  create mode 100644 elf/tst-filterobj.c
> >
> > --
> > 2.7.4