Re: [PATCH v9 0/13] implement dlmem() function

[stsp <stsp2@yandex.ru>]

Hello,

05.04.2023 13:51, Szabolcs Nagy пишет:
> this is a known bug.
>
> (audit is special because it is not an api for applications
> but for tooling that hooks into dynamic linker internals,
> it has its own abi versioning so we can break the abi more
> easily and those tools are expected to cope with it. it is
> necessarily exposing internals, so new hooks are more likely
> acceptable there, but that's not true for apis designed for
> application use.)
>
> a much bigger issue is calling user ctors under the
> dynamic linker lock which did cause issues in practice.
>
> another issue is calling malloc under locks when malloc
> can be interposed (likewise it caused issues in practice).
>
> i did not say glibc was clean from these problems, but
> that does not mean we want to add more to it.
OK, in an attempt to address these concerns
I am currently trying to implement an entirely
different approach.
The basic idea is that dlmem() can leave an
object unrelocated. This is a small change,
relocation is currently done in dl_open_worker_begin().
But I can do it upon a subsequent call of an
any dlfcn function with the handle of that object,
by just checking the l->relocated flag that is
already present in the link_map struct.
The same "lazy relocation" can even be
applied to a regular dlopen().

Now the trick is that when you have an
unrelocated object, you can move it by
hands to the desired address (preserving
the page protection, that's easy) and call
dlsetbase(handle, address);
to update a couple of link-map pointers.
dlsetbase() would fail if the object is
already relocated, so it should be called
right after dlmem() or dlopen(), or not called
at all if you don't need to alter the solib
location.
To get a mapaddr and maplength of a loaded
solib I am going to add a trivial getters for the
needed values from a link-map. These are
only needed if one wants to move the loaded
unrelocated solib.

That still fits my use-case very well, doesn't
require a callback and doesn't require the user
to know the maplength beforehand.
So it would seem to address all of your concerns,
and overall seems a much simpler approach.
But it would require an additional dlsetaddr()
trivial function and a few link-map getters,
besides dlmem() itself.

Would this approach be viable?