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

[stsp <stsp2@yandex.ru>]

05.04.2023 13:51, Szabolcs Nagy пишет:
> The 04/05/2023 12:29, stsp wrote:
>> Hi Szabolcs,
>>
>> 03.04.2023 17:01, Szabolcs Nagy пишет:
>>> a user callback must not run in a context where libc
>>> internals are exposed (e.g. under internal locks).
>> I checked that part a bit more, and so far
>> my findings are (let me know if they are wrong):
>> - That code indeed works under dl_load_lock,
>>    but it calls audit callbacks rather freely, and
>>    I don't see it releasing the lock before calling
>>    the user audit callbacks.
>>
>> - dl_iterate_phdr() seems to be calling the user
>>    callback under dl_load_write_lock lock.
> 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,
I had the version of the patch that
added an audit callback instead of
the direct callback.
Do you think that's going to be better?
In that case the dlmem() API is only
documented for the basic tasks of loading
a solib from memory.
Audit module can then add an advanced
functionality, but its not going to be a
part of glibc.
The problems around documenting maplength
are not available in such an impl, since
that became internal to an audit callback.


> in any case dlmem has way too many issues beyond
> the locking one, the fact that you don't document
> nor understand the issues around the huge interface
> boundary it creates does not help either.
I understand the problem around maplength,
and I wonder if getting back to an audit
callback may be a solution to this and all
the other problems you mentioned.
Essentially in this case glibc has only a very
small and simple call, and the rest is implemented
by an author of an audit module.