Flurry of GMP check failures

[Torbjörn Granlund]

nisse at lysator.liu.se (Niels Möller) writes:

  tg at gmplib.org (Torbjörn Granlund) writes:
  
  > 2. Something is broken wrt Debian sid from the past few weeks.
  >    It seems they want static lib code to be PIC.
  
  Or rather, PIC code for all executables, to enable randomization of the
  mapping of the text segment into the process address space. I think the
  rationale is documented here: https://wiki.debian.org/Hardening.
  
  Changes to default gcc seem to be described at 
  https://wiki.debian.org/Hardening/PIEByDefaultTransition
  
  It's not entirely clear if and how it's intended to affect builds which
  don't involve debian-specific tools, maybe something is broken.
  
Thanks, this is probably the explanation.  Indeed, Debian seems to have
decided to no longer support the x86-64 ABI without extra options:

sym.c:
  int blah[] = {17,4711,222222,333333};
  int foo(int i) { return blah[i]; }

m.c:
  int foo(int i);
  int main()
  {
    foo (0);
  }

This fails:
  $ gcc sym.c -c -fno-pic && gcc sym.o m.c
  /usr/bin/ld: sym.o: relocation R_X86_64_32S against symbol `blah' can not be
  used when making a shared object; recompile with -fPIC
  /usr/bin/ld: final link failed: Nonrepresentable section on output
  collect2: error: ld returned 1 exit status

This works:
  $ gcc sym.c -c -fno-pic && gcc -static sym.o m.c

This seems like a very heavy-handed way of pushing for ASLR.

Should we be bothered?  Adapting seems quite messy.  I'm migrating from
Debian to Gentoo for GMP's testing, so unless Debian's approach is
gaining momentum in the GNU/Linux world, we could just ignore this.

It would be useful if list readers with other "hardened" systems could
test the example above and report the results here.

-- 
Torbjörn
Please encrypt, key id 0xC8601622