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
signature.asc
Description: This is a digitally signed message part
