Notes about enabling PIE by default in gcc for amd64

The following is my notes about landing PIE in 16.04.

In the gcc-5, there are two additional patches added to enable this, the first is applying the patch H.J. Lu landed in gcc trunk (https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=223796), which allows gcc to be configured with -pie on by default (and adds the disabling option -no-pie). The second patch changes the arguments passed to the linker (ld) to enable -z now (aka Immediate Binding) when -pie is enabled on amd64.

Patches are available in https://code.launchpad.net/~sbeattie/+junk/pie-amd64-patches .

Build Testing

A first round of building testing was done in the gcc-pie-amd64 PPA, attempting to build most of main that has architecture specific components (i.e. build architecture 'all' or 'amd64'). The vast majority of packages succeeded to build.

(I also enabled the ppa in a xenial desktop VM and basic testing showed no problems.)

I'll capture the failures I see and the solutions to them

PIE+ASLR issue for kernels in vivid (3.19) and older

In build testing, one of the issues discovered is an (as yet unknown) issue with the kernel's handling of PIE+aslr binaries for kernels older than 4.2 (i.e. vivid and older). This manifests when bash is built with pie enabled and then is used to build some other packages; frequently an error like: 

   bash: xmalloc: .././locale.c:81: cannot allocate 2 bytes (0 bytes allocated)

is seen in the build logs. Unfortuantely, the buildds are running a mix of 3.13 and 3.19 kernels. Building with bash reverted to non-pie works around the issue. I verified that it's a kernel issue by reproducing the issue locally in an sbuild with bash+pie on a host running trusty, reproducing the build failure and then rebooting into the linux-lts-wily kernel, redoing the build, and seeing it succeed.

This issue affects the following package build failures (from below)

This has been filed as LP: #1518483

A workaround that I'm testing that at least succeeded for cpio is rebuild bash with pie disabled, and then rebuild the failing package. But it leaves the possibility that other build programs may trip over it in perhaps less obvious ways.

Incompatible relocation R_X86_64_32

These are due to the static libraries they're linking against (/usr/lib/ocaml/libcamlrun.a for campl5 and findlib, /usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu/libcheck.a for netcfg) not being built in PIC mode. To resolve, build the package that provides the static library with -pie first, then rebuild the failing package.

incremental linking via ld -r (incompatible with -pie)

Often shows up with go modules and for other oddballs.

miscellaneous test case failures and other oddities

A few packages have tests that check that they either identify a binary executable properly, or verify that the did some operation on an executable that does not mess it up. These will need to be patched:

Hardening-wrapper needs to be taught about -pie and -no-pie

Others have random failures due to -pie and likely need a patch to disable it.

raw list of build failures (w/arches)

build successful after static lib dependency was rebuilt with -pie (to get -fPIC)

kernel aslr failures, worked around by building with non-pie bash

i386 failures due to amd64 FTBFS

Some i386 builds failed because they had a dependency on an arch all package built from a source that had FTBFS on amd64; after fixing the amd64 failure, rebuilding the i386 package succeeded.

cmake

gnome-desktop3

SteveBeattie/PIENotes (last edited 2015-12-03 09:15:31 by sbeattie)