Build with binary hardening flags when available #108

wants to merge 9 commits into


None yet
2 participants

kmcallister commented Apr 10, 2012

Detect and use available binary hardening flags for the compiler and linker. Closes #79.

Since we have the infrastructure for it, we also detect -fno-default-inline and -pipe. The former had been causing clang warning spew.

An open question is whether we're okay with a 30% performance hit on the slowest netbooks. (By contrast, a much more capable machine sees only a 2% slowdown.) See benchmark results on #79; we can gather more data if necessary.


keithw commented Apr 11, 2012

This all looks pretty nice (rebased and pushed to harden-workinprogress), except the linking step fails on Debian/Ubuntu (with system skalibs) with:

/usr/bin/ld: /usr/lib/skalibs/lib/libstddjb.a(selfpipe.o): relocation R_X86_64_32S against `.text' can not be used when making a shared object; recompile with -fPIC
/usr/lib/skalibs/lib/libstddjb.a: could not read symbols: Bad value
collect2: ld returned 1 exit status


kmcallister commented Apr 12, 2012

Good catch! The bug is simple enough: skalibs is built without -fPIC and we're linking it statically (in fact, there are no dynamic libraries in Debian's package).

It seems that Debian and Ubuntu really don't want us bundling libstddjb. I don't think we should push the skalibs-dev maintainer to recompile with -fPIC either, since it can have a serious performance penalty. Maybe the right answer is a new package skalibs-pic-dev but it's questionable if that's worth anyone's time...

So instead I added a thin layer which lets Mosh bypass selfpipe on platforms with signalfd (i.e., Linux). I've tested it on Linux, with and without USE_LIBSTDDJB.

I pushed this commit on my harden branch, which is now based on your harden-workinprogress rebase.

kmcallister added some commits Mar 25, 2012

@kmcallister kmcallister Add ax_check_{compile,link}_flag.m4 14054ee
@kmcallister kmcallister Detect binary hardening flags supported by the compiler and linker 12fab4d
@kmcallister kmcallister Use the hardening flags
Closes #79.
@kmcallister kmcallister Document the binary hardening measures 7c301b3
@kmcallister kmcallister Grep for clang warnings when testing compiler flag support
There is no way to make clang's "argument unused" warning fatal.

Ideally the search string would also include 'clang: ' but this output might
depend on clang's argv[0].
@kmcallister kmcallister Check compiler support for -fno-default-inline and -pipe
clang was spewing warnings about the unrecognized -fno-default-inline.  (Oddly,
it warns only with -c, not when compiling directly to an executable.)  For
completeness we also check -pipe, even though clang is OK with that one.

It should be fine to omit either flag.  gcc -fno-default-inline drops the
implicit 'inline' annotation on functions defined inside a class scope, but
'inline' is only a hint anyway.  -fno-default-inline does not change linkage.
-pipe is merely a compile speed optimization.
@kmcallister kmcallister Try $LD -Wl,-pie if $LD -pie fails
clang on OS X wants the former.

@kmcallister kmcallister Include -fPIE when we check for $LD -pie
configure's linker flag check also compiles a C++ program.  g++ -pie informs
both the compiler and linker, but clang++ -Wl,-pie is only a linker flag, and
the linker will complain that the code hasn't been compiled as
@kmcallister kmcallister Linux: Use our own signalfd wrapper, rather than libstddjb
selfpipe already does a fine job of interfacing to signalfd.  But Debian and
Ubuntu want us to depend on the skalibs-dev package rather than build libstddjb
ourselves.  That would be fine except that skalibs-dev has static libraries
only, and they aren't built with -fPIC.  This interferes with building
mosh-{client,server} as position-independent executables, which is a desirable
security measure.

So we have our own wrapper, which invokes either signalfd or selfpipe.  And we
build it ourselves with our own flags, because it's part of the Mosh project

keithw closed this in 0eec0b6 Apr 13, 2012

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment