[PATCH v2] dl: Use "adr" assembler command to get proper load address on ARM

Florian Weimer fweimer@redhat.com
Mon Oct 18 11:35:35 GMT 2021


* Szabolcs Nagy:

> i don't know much about pelinking, but i'd expect that ld.so
> has to be prelinked for it to work:
>
> if the kernel can load ld.so anywhere it will conflict with
> other libraries that prelinking allocated to a fixed location.

I think ld.so can back out prelinking if it detects any conflicts.
(ld.so doesn't use MAP_FIXED for the initial ET_DYN mapping even when
prelinking.)

> instead ld.so has to be prelinked to an offset that comes after
> all other prelinked libraries in the system, then the kernel
> will place it after all other libraries at runtime.
>
> i don't have a prelinked system to check if this is the case.

I tried on glibc 2.12-based system with prelink enabled and got this:

# ldd /bin/bash
	linux-vdso.so.1 =>  (0x00007ffc7e798000)
	libtinfo.so.5 => /lib64/libtinfo.so.5 (0x0000003da9800000)
	libdl.so.2 => /lib64/libdl.so.2 (0x0000003da7400000)
	libc.so.6 => /lib64/libc.so.6 (0x0000003da7800000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f8dc919c000)
# ldd /bin/bash
	linux-vdso.so.1 =>  (0x00007ffef3bf4000)
	libtinfo.so.5 => /lib64/libtinfo.so.5 (0x0000003da9800000)
	libdl.so.2 => /lib64/libdl.so.2 (0x0000003da7400000)
	libc.so.6 => /lib64/libc.so.6 (0x0000003da7800000)
	/lib64/ld-linux-x86-64.so.2 (0x00007ff9e66a6000)
# eu-readelf -d /lib64/ld-linux-x86-64.so.2

Dynamic segment contains 25 entries:
 Addr: 0x0000003da7220df0  Offset: 0x020df0  Link to section: [ 5] '.dynstr'
  Type              Value
  SONAME            Library soname: [ld-linux-x86-64.so.2]
  HASH              0x0000003da70001f0
  GNU_HASH          0x0000003da70002a8
  STRTAB            0x0000003da7000608
  SYMTAB            0x0000003da7000380
  STRSZ             380 (bytes)
  SYMENT            24 (bytes)
  PLTGOT            0x0000003da7220f80
  PLTRELSZ          144 (bytes)
  PLTREL            RELA
  JMPREL            0x0000003da7000a30
  RELA              0x0000003da7000868
  RELASZ            456 (bytes)
  RELAENT           24 (bytes)
  VERDEF            0x0000003da70007c0
  VERDEFNUM         5
  BIND_NOW          
  FLAGS_1           NOW
  VERSYM            0x0000003da7000784
  RELACOUNT         16
  CHECKSUM          0x00000000e90e92bc
  GNU_PRELINKED     0x00000000616d5a26
  NULL              
  NULL              
  NULL
# 

As expected based on the previous discussion here, the kernel maps ld.so
at random addresses even though it has been prelinked.

This looks like another place where ASLR layout as to be tweaked
carefully to avoid obscure failure modes.

Thanks,
Florian



More information about the Libc-alpha mailing list