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

[stsp]

Hello,

03.04.2023 17:01, Szabolcs Nagy пишет:
> these are all *internals*, there is nothing in the
> public api (or even elf spec) that says this is how
> this should be done.

Yes, OTOH of course its reasonable to expect
that the solib's mapping size's upper limit can
be estimated before doing the actual mapping.
So I rely on such estimation code which is already
there.

Maybe it would be a solution to add another
function that will return such a size estimation?
Well, I am sure this also have dozens of down-sides...

>>> and libc apis are exposed to not use locks that have
>>> lock ordering requirement wrt the dynamic linker
>>> internal lock. (e.g. we could add such a lock in mmap
>>> or shm_open since they are not required to be as-safe.
>>> so your callback can deadlock in a future glibc).
>> Well you probably can't add such a lock into mmap(),
>> as the loader calls mmap() anyway. Premap callback
>> just does the same thing.
> no, the loader does not call the public mmap libc api.
> it calls internal __mmap that may behave differently.
>
> the current implementation does not impose any
> requirement on the public mmap symbol.

An option may be to pass a premap callback
with a pointers to such __mmap, __ftruncate. But
of course not the best option again. :(

> a user callback must not run in a context where libc
> internals are exposed (e.g. under internal locks).
> if you do that you need very strong justification
> and very careful specification of the api. (moving
> the callback outside the dynlinker locks or passing
> down flags instead of a callback would solve this
> particular issue.)

I considered passing flags and fd.
This makes things much less flexible, but
the real problem here is to set the relocation
address. premap callback just returns it
after doing the mapping of a requested size.
Without knowing the estimated size beforehand,
you unfortunately can't easily go that route. :(
The func to get the estimated size, could help.


> there are so many unexplained details here.. we have
> to guess what you have in mind. (should tls also end
> up in shared memory? what if the libc wants to generate
> executable code per module for instrumentation? e.g.
> for PLT hooking, should that go to the shared mapping
> too? what if the malloc implementation reuses bits of
> memory from shared libs they waste due to page alignment
> is that legal? we can answer these questions if you
> either specify the interface contracts or the point of
> all of this, but right now it's anybody's guess.)

No, no, its much simpler! :)
I just put _entire_ solib into a shared mapping.
I do not care about tls or anything.
All I do is create the initial large mapping, that
remains unaffected by the loader. Even the
inter-segment gaps you mentioned, or the
anonymously mapped parts like .bss - just all
go into that initial shared mapping. Which is
why I haven't described such details. That are
simply not important in that case.

> libc will likely not include an api to load libs into
> shared memory. (e.g. aarch64 has features that work on
> anon or file backed memory but not on shared memory and
> some systems may prevent it for security reasons, so
> this has at least portability problems, but it also
> clearly constrains the implementation.)

Well, from the API stand-point its not mapping
into a shared memory. Its mapping into where's
the premap callback decided. Can we assume
that the premap callback is responsible to not
do stupid things on aarch64, where mapping
to shared memory will not work as expected?


> you can load a shared lib / generate code that does
> not use normal libc shared library abi, but can
> call into libc (or some other library) or can be
> called from normal libraries. this is kind of what
> jits do.

I wanted to load a solib and get its DT_NEEDED
deps all resolved. If I had some way of linking
things with my patched, statically built libc, that
would work. Maybe I can rip off the glibc loader
and somehow build it separately, etc. So what
you say, may work, but seems like a tremendous
task of either writing a full loader or ripping off
the one from glibc...
And even that route will only allow me to use
such libs in a separate NS, as in base NS it
won't have a link-map visible by glibc. But
having that in a separate NS is acceptable for
my needs, so eventually I may go that route
if all else fails.


> there is probably a reason why that api got rejected
> and likely the same reason applies to dlmem.
Likely, but I just thought having an android
extensions in, is not so bad for glibc (of course
its not me to decide). So having a building block
that supports dlopen_with_offset() being externally
implemented, looked like a tasty thing for glibc,
but perhaps it wasn't the case.