Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.debian.bugs.dist > #1154438
| From | Ben Hutchings <ben@decadent.org.uk> |
|---|---|
| Newsgroups | linux.debian.bugs.dist |
| Subject | Bug#1040981: klibc-utils: segfault executing armhf binaries under qemu-user |
| Date | 2023-07-15 23:50 +0200 |
| Message-ID | <GRVjj-up6-9@gated-at.bofh.it> (permalink) |
| References | (8 earlier) <GRxqF-fo5-3@gated-at.bofh.it> <GRxAl-fsI-1@gated-at.bofh.it> <GRziN-gxF-7@gated-at.bofh.it> <GRdih-2QS-3@gated-at.bofh.it> <GRziN-gxF-7@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
[Multipart message — attachments visible in raw view] - view raw
On Fri, 2023-07-14 at 22:08 +0000, Thorsten Glaser wrote:
> 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.
You mean after, but it's more specific than that in practice.
> 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.
[...]
It would be a little more robust, and certainly easier to understand.
Here's what we have now:
Architecture klibc base (hex) Exec base (hex) Offset (MiB)
---------------------------------------------------------------------
alpha 1_c0000000 1_20000000* -2_560
arm [THUMB=y] 380000 10000** -3
arm [THUMB=n] 1800000 10000** -24
arm64 200000 400000 2
i386 6000000 8000000* 32
ia64 20000000_00000000 40000000_00000000** 2_199_023_255_552
loongarch64 1_27E00000 1_20000000* -126
m68k b0000000 80000000* -768
mips 200000 400000* 2
mips64 1_2FE00000 1_20000000* -254
parisc 40001000 10000** -1_024
ppc f800000 10000000* 8
ppc64 f000000 10000000* 16
riscv64 200000 10000* -2
s390 40000000 400000** -1_020
s390x 40000000 1000000** -1_008
sh 200000 400000* 2
sparc 40000000 10000* -1_024
sparc64 80000000 100000* -2_047
x86_64 200000 400000 2
* Assumption commented in MCONFIG.
** Observed with objdump.
In 12 cases (a majority), the offset between klibc.so and the
executable is negative. However, only riscv64 and arm with THUMB=y
have such small negative offsets (-2 and -3.4375 MiB respectively)
which I suppose puts them more at risk from this bug.
The Debian package is built with THUMB=y for armhf but not armel, which
seems like a mistake because the Arm EABI requires Thumb support.
Ben.
--
Ben Hutchings
The generation of random numbers is too important to be left to chance.
- Robert Coveyou
Back to linux.debian.bugs.dist | Previous | Next — Previous in thread | Find similar | Unroll thread
Bug#1040981: klibc-utils: Segmentation fault while executin klibc binaries in armhf architecture under qemu-user Thorsten Glaser <tg@debian.org> - 2023-07-14 00:50 +0200
Bug#1040981: klibc-utils: segfault executing armhf binaries under qemu-user Thorsten Glaser <tg@debian.org> - 2023-07-14 02:20 +0200
Bug#1040981: klibc-utils: segfault executing armhf binaries under qemu-user Helge Deller <deller@gmx.de> - 2023-07-14 06:20 +0200
Bug#1040981: klibc-utils: Segmentation fault while executin klibc binaries in armhf architecture under qemu-user Ben Hutchings <ben@decadent.org.uk> - 2023-07-14 15:30 +0200
Bug#1040981: klibc-utils: Segmentation fault while executin klibc binaries in armhf architecture under qemu-user Michael Tokarev <mjt@tls.msk.ru> - 2023-07-14 15:40 +0200
Bug#1040981: klibc-utils: segfault executing armhf binaries under qemu-user Thorsten Glaser <tg@debian.org> - 2023-07-14 20:50 +0200
Bug#1040981: klibc-utils: segfault executing armhf binaries under qemu-user Michael Tokarev <mjt@tls.msk.ru> - 2023-07-14 21:40 +0200
Bug#1040981: klibc-utils: segfault executing armhf binaries under qemu-user Thorsten Glaser <tg@debian.org> - 2023-07-14 22:20 +0200
Bug#1040981: klibc-utils: segfault executing armhf binaries under qemu-user Michael Tokarev <mjt@tls.msk.ru> - 2023-07-14 22:30 +0200
Bug#1040981: klibc-utils: segfault executing armhf binaries under qemu-user Thorsten Glaser <tg@debian.org> - 2023-07-15 00:20 +0200
Bug#1040981: klibc-utils: segfault executing armhf binaries under qemu-user Ben Hutchings <ben@decadent.org.uk> - 2023-07-15 23:50 +0200
csiph-web