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

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

Michael Tokarev dixit:
>>
>> 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?
bullseye/amd64:

0x00200000 interp
0x00400000 main executable

So no, this applies only to some architectures, but not because?
> I had an impression it is not arch-specific. $subject
? it?s arch-specific but because klibc memory map is, so the
effect only occurs on those arches where klibc puts the interp
before the main executable.

This is unfortunately hard to grep for, because?

usr/klibc/arch/arm/MCONFIG:KLIBCSHAREDFLAGS = $(LD_IMAGE_BASE_OPT) 0x380000

? this applies to the interp, but for the main executables
it uses the linker?s default AFAICT.

There is?

usr/klibc/arch/arm64/MCONFIG:KLIBCLDFLAGS  = $(LD_IMAGE_BASE_OPT) 0x00400000
usr/klibc/arch/arm64/MCONFIG:KLIBCSHAREDFLAGS = $(LD_IMAGE_BASE_OPT) 0x0200000

? which does transfer to main at 00400000 interp at 00200000 respectively,
but only arm64 and ?x32?, which really builds as amd64, do that.

And Itanic uses a linker script, putting the interp at
0x2000000000000000 (which seems to be standard for ia64).
0x40000000000001c8 is the beginning of the main executable
there, from analysing the built binaries.

It would be more robust if klibc always specified both.

But, as I said earlier, this won?t help bookworm and earlier
so fixing this in qemu is appreciated ;-)
>> 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 :)
Perhaps. In the BSD world, malloc has been always using mmap for
ages, especially as the kernel randomises anon mmap addresses.
>> 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.
I meant the suggested fix. I?m not sure people over there will
dig through all of the analysis and discussion here? but maybe
a tl;dr could be posted there as well?

Thanks,
//mirabilos
-- 
?It is inappropriate to require that a time represented as
 seconds since the Epoch precisely represent the number of
 seconds between the referenced time and the Epoch.?
	-- IEEE Std 1003.1b-1993 (POSIX) Section B.2.2.2