Re: Flurry of GMP check failures

[Torbjörn Granlund]

There are a few cycles lost for each call to PIC code and a few cycles
lost for each read/write of a PIC variable.

Currently, we pay these costs also for calls/variables *within* GMP.
The symbol hiding stuff will help, but only for calls, while variable
access still needs extra code (although not a memory reference through
the GOT) as these things are implemented (in Debian; I haven't checked
other environments yet).

Inconsequentially, symbol hiding does not let us use 32-bit offsets for
load-time patching, which would save some of the costs I don't see any
reason bahind that, except perhaps the people don't understand these
things properly.

It is not clear to me what to do here.  I dislike the heavy handed
approach taken by Debian and others; if people want PIE binaries,
compile with -fPIC/-fPIE and link them to shared libs!

One approach is to pass -static when compiling our test executables for
the problem systems.

As Niels said, we need a (robust) configure test for detecting the
Debian behaviour.

-- 
Torbjörn
Please encrypt, key id 0xC8601622
___
gmp-devel mailing list
gmp-devel@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-devel

Re: Flurry of GMP check failures

[Niels Möller]

t...@gmplib.org (Torbjörn Granlund) writes:

> But this is odd: At least Debian (didn't have a chance to check Gentoo
> yet) does not ban R_X86_64_64 which we use frequently from GMP's
> assembly for references to tables of constants.  It bans R_X86_64_32S
> which we use for tables of function pointer offsets.

Hmm, didn't openbsd pioneer this pie-by-default thing some year ago, and
there was a similar oddness with supported reloc types?

> To me, this discrepancy makes very little sense; either the resulting
> user binaries will not be PIE or they will require load-time reloc
> patching.

IIRC, the motivation was that a 64-bit reloc is large enough to *always*
be pathchable to point to the right place at load time, while a 32-bit
reloc might be too small, depending in the ultimate location of the
target. (If I haven't misunderstood what these relocs are; I have a very
fuzzy understanding of the details).

And if the code is expected to be pic and sharable at loadtime, neither
reloc type should be used in the text or rodata segment; while
R_X86_64_64 is perfectly fine for tables placed in the data segment.

Regards,
/Niels

-- 
Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677.
Internet email is subject to wholesale government surveillance.
___
gmp-devel mailing list
gmp-devel@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-devel

Re: Flurry of GMP check failures

[Torbjörn Granlund]

I have not read carefully follow-ups on this yet, but here are some
observations.

Gentoo "hardened" behaves similarly wrt my sym.c/m.c example.

Note that gcc's defaults for compiling and linking do not affect things
much here, except that PIC code adds overhead.  I am not suggesting that
we should pass -fno-pic (not am I suggesting that we should not pass
it); the sym.c/m.c example was intended to demonstrate the behaviour of
recent Debian 9.

But this is odd: At least Debian (didn't have a chance to check Gentoo
yet) does not ban R_X86_64_64 which we use frequently from GMP's
assembly for references to tables of constants.  It bans R_X86_64_32S
which we use for tables of function pointer offsets.  To me, this
discrepancy makes very little sense; either the resulting user binaries
will not be PIE or they will require load-time reloc patching.  (This
discrepancy between similar relocs is the reason why fat builds fail
while "thin" builds work fine.)

-- 
Torbjörn
Please encrypt, key id 0xC8601622
___
gmp-devel mailing list
gmp-devel@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-devel

Re: Flurry of GMP check failures

[Marc Glisse]

On Sat, 5 Nov 2016, Niels Möller wrote:


Marc Glisse  writes:


Uh? I have 2 very natural use cases for libgmp.a:

1) to build a static (or at least with few dependencies) executable
that I am going to send to someone else [...]



2) I am rebuilding GMP on my specific platform in order to get the
best possible performance. [...]


I see. In these cases, is it important whether or not libgmp.a uses pic
code?


In the first case, it doesn't matter. In the second case, we would have to 
run benchmarks where one build uses --with-pic and not the other. The PIC 
library is a tiny bit larger (1321280 vs 1319632). GMPbench doesn't really 
see the difference on x86_64 core2 (2117 vs 2124), but it may not be the 
best test for this.


--
Marc Glisse
___
gmp-devel mailing list
gmp-devel@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-devel

Re: Flurry of GMP check failures

[Niels Möller]

Marc Glisse  writes:

> Uh? I have 2 very natural use cases for libgmp.a:
>
> 1) to build a static (or at least with few dependencies) executable
> that I am going to send to someone else [...]

> 2) I am rebuilding GMP on my specific platform in order to get the
> best possible performance. [...]

I see. In these cases, is it important whether or not libgmp.a uses pic
code?

Regards,
/Niels



I might as well use a static libgmp to
> squeeze that extra bit of speed out of it (I might even want to use
> LTO in that case, although IIRC it currently causes some trouble in
> configure).
>
> Note that I do not care about security in either case.

-- 
Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677.
Internet email is subject to wholesale government surveillance.
___
gmp-devel mailing list
gmp-devel@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-devel

Re: Flurry of GMP check failures

[Marc Glisse]

On Sat, 5 Nov 2016, Niels Möller wrote:

At this point in time, I think use-cases involving static libgmp.a (or 
libnettle.a) are somewhat obscure.


Uh? I have 2 very natural use cases for libgmp.a:

1) to build a static (or at least with few dependencies) executable that I 
am going to send to someone else who doesn't have much control over the 
computer he uses (either lack of permission or lack of competence).


2) I am rebuilding GMP on my specific platform in order to get the best 
possible performance. I might as well use a static libgmp to squeeze that 
extra bit of speed out of it (I might even want to use LTO in that case, 
although IIRC it currently causes some trouble in configure).


Note that I do not care about security in either case.

--
Marc Glisse
___
gmp-devel mailing list
gmp-devel@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-devel

Re: Flurry of GMP check failures

[Niels Möller]

t...@gmplib.org (Torbjörn Granlund) writes:

> This fails:
>   $ gcc sym.c -c -fno-pic && gcc sym.o m.c

I guess we never need to pass -fno-pic to gcc, we should either pass
-fpic, when building shared library, or no pic-reaetd flags at all, when
building static libraries and executables. Right?

Problem is that when -fpic is on by default, assembly files need to use
pic conventions too. And to get this right automatically we'd need
configure to detect whether or not pic is on by default.

Or change the x86_64 assembly files to always use pic. Is there any
penalty to that? My understanding is that pic is somewhat of a pain with
32-bit x86, due to lack if addressing modes using pc + offset, but quite
nice and easy on x86_64.

> 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.

If debian is following ubuntu, I think we have to say there already is
some considerable momentum at work.

For reference, in Nettle, everything is built as pic by default since
the 1.11 release back in 2004. The motivation back then was the use case
that an interpreter, e.g., pike, loading it's crypto support code
dynamically using ldopen("Nettle.so"), and the corresponding .so file
then linked statically to libnettle.a. To get a non-pic static library,
one has to configure with --disable-shared --disable-pic, but I haven't
heard about anyone actually doing that.

At this point in time, I think use-cases involving static libgmp.a (or
libnettle.a) are somewhat obscure.

Regards,
/Niels

-- 
Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677.
Internet email is subject to wholesale government surveillance.
___
gmp-devel mailing list
gmp-devel@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-devel

Re: Flurry of GMP check failures

[Torbjörn Granlund]

ni...@lysator.liu.se (Niels Möller) writes:

  t...@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,22,33};
  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
___
gmp-devel mailing list
gmp-devel@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-devel

Re: Flurry of GMP check failures

[Niels Möller]

t...@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.

/Niels

-- 
Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677.
Internet email is subject to wholesale government surveillance.
___
gmp-devel mailing list
gmp-devel@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-devel