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

["Zack Weinberg" <zack@owlfolio.org>]

On Wed, Apr 12, 2023, at 2:46 PM, stsp via Libc-alpha wrote:
> 12.04.2023 23:20, Rich Felker пишет:
>> On Wed, Apr 12, 2023 at 11:00:19PM +0500, stsp wrote:
>>> 12.04.2023 22:23, stsp пишет:
>>>> The same "lazy relocation" can even be applied to a regular
>>>> dlopen().
>>> Of course it can't, as dlopen() is expected to call library ctors.
>>> So only with an optional dlmem() flag such behavior should be
>>> performed, in which case dlsetbase() should also do the final
>>> relocation and ctors calling.
>> Have you not realized yet how far outside any concept of "reasonable"
>> this ever-expanding contract is?
>
> How can I realize that, if it was never explained? In fact, the only
> API review was from Szabolcs, and he just pointed to 2 problems that
> are seemingly solvable.

This discussion keeps going in circles.  You, Stas, think you aren't
getting any explanation for why your API proposals are being rejected.
Meanwhile, Szabolcs, Adhemerval, Carlos, Rich, etc. all think they ARE
giving you explanations for why they don't like this API.

Let me try to highlight specific issues from the feedback you've been
getting.  It appears to me that your *API* proposal -- not any details
of its implementation, the API itself -- is unacceptable *BECAUSE*:

* It introduces a callback from the dynamic loader into user code, that
  is to be run with an internal lock held. glibc does already have
  callbacks like that, but we do not want to introduce any more of
  them, period.
* It assumes that the dynamic loader will always, in the future, operate
  by creating a large initial mapping and then modifying protection
  flags on it.
* It assumes that it the dynamic loader is, and will always be, capable
  of taking a pointer to a block of memory -- no matter how it was
  originally allocated -- and then chopping its virtual memory map up to
  satisfy the requirements of the embedded ELF program header table,
  without breaking anything else.  [On this specific note, I foresee
  someone trying to write a dynamic module into memory allocated with
  memalign() or even plain old malloc(); calling dlmem() on this is very
  likely to apply PROT_NONE to address ranges containing malloc
  metadata!]

Carlos also gave you the specific feedback that he thinks an API
structured around handing the dynamic loader a file descriptor, not a
pointer, would be much more likely to be accepted.  Your response to
this was "dlmem() can optionally preserve the destination mapping, which
is not possible by definition with any file-based API."  I accept that
_you_ think that, but I don't think it's true, myself.  If your goal is
to force a shared library to be loaded into memory with specific
characteristics, I can think of at least two designs that ought to be
able to achieve that goal while still starting from the same place as
fdlopen().  For instance, maybe we could have an fdlopen variant that
called callback functions instead of mmap() and mprotect().  Unlike
your dlmem_premap_t, I think it ought to be possible to avoid doing
those specific operations with any locks held.

zw