[klibc] Bug#1040981: klibc-utils: segfault executing armhf binaries under qemu-user

[Michael Tokarev]

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