klibc - Jul 2023 - Bug#1040981: klibc-utils: segfault executing armhf binaries under qemu-user

Michael Tokarev dixit:
> commit 6fd5944980f4ccee728ce34bdaffc117db50b34d
>From the comment, it reserves 16 MiB after the main executable.
In klibc/armhf, however, the main executable starts around
0x00010000 whereas the interpreter starts after that, around
0x00380000?

Perhaps the fix here would be to see if the interpreter comes
within 16 MiB past the main executable?s end, and if so, to
move the break (I wasn?t aware stuff on GNU/Linux still uses
that!) to start after the interpreter instead.

The BSD manpage begins with?
DESCRIPTION
     The brk() and sbrk() functions are historical curiosities left over from
     earlier days before the advent of virtual memory management.
? so? oh well.

Anyway, while my proposed fix in theory moves the ?end of the
process? data segment? to behind the interpreter instead of
behind the main executable, processes are not supposed to use
it in combination with _end, only the returned pointers. It?s
something to at least consider. Will you forward this upstream?


Given how this both constraints executables? sizes and perhaps
has effects on other loaders, perhaps the klibc upstream could
consider switching to using linker scripts or at least move the
respective text bas?s, on all architectures, so that the main
executable comes after the interpreter.

This will of course not help bookworm users but, perhaps, it is
something, again, to consider, at least.


bye,
//mirabilos
-- 
This space for rent.

https://paypal.me/mirabilos to support my work.

Control: forwarded -1
https://lists.nongnu.org/archive/html/qemu-devel/2023-07/msg03138.html

14.07.2023 23:07, Thorsten Glaser wrote:
> Michael Tokarev dixit:
> 
>> commit 6fd5944980f4ccee728ce34bdaffc117db50b34d
> 
>  From the comment, it reserves 16 MiB after the main executable.
> 
> In klibc/armhf, however, the main executable starts around
> 0x00010000 whereas the interpreter starts after that, around
> 0x00380000?
Aren't it happens on all architectures, not just armhf?
I had an impression it is not arch-specific. $subject
mentions armhf only, but I think somewhere in the discussion
it's been said all architectures are affected?  Ok.
> Perhaps the fix here would be to see if the interpreter comes
> within 16 MiB past the main executable?s end, and if so, to
> move the break (I wasn?t aware stuff on GNU/Linux still uses
> that!) to start after the interpreter instead.
> 
> The BSD manpage begins with?
> DESCRIPTION
>       The brk() and sbrk() functions are historical curiosities left over
from
>       earlier days before the advent of virtual memory management.
> ? so? oh well.
That's lovely.  There's another change for brk() pending in qemu right
now (to make it page-aligned; and no, it does not fix this issue).
I guess it is not just curiocities :)
> Anyway, while my proposed fix in theory moves the ?end of the
> process? data segment? to behind the interpreter instead of
> behind the main executable, processes are not supposed to use
> it in combination with _end, only the returned pointers. It?s
> something to at least consider. Will you forward this upstream?
Yeah, already did, was just waiting for it to appear in the archives
for the URL.

Thank you!

/mjt