PIENotes

Differences between revisions 25 and 26
Revision 25 as of 2015-11-21 08:00:24
Size: 12999
Editor: sbeattie
Comment: report workaround results
Revision 26 as of 2015-11-21 08:22:22
Size: 13127
Editor: sbeattie
Comment: update corosync i386 build failure info
Deletions are marked like this. Additions are marked like this.
Line 92: Line 92:
   * {{{/usr/bin/ld.bfd.real: BFD (GNU Binutils for Ubuntu) 2.25.51.20151113 assertion fail ../../bfd/elf32-i386.c:5297}}} o.0

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.

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)

  • aalib
  • cdebconf-terminal
  • cloog-ppl
  • cpio
  • cwidget
  • dbus-c++
  • ecryptfs-utils
  • elfutils
  • evolution-data-server
  • firefox
  • git
  • glade
  • libmnl
  • p11-kit
  • shadow
  • util-linux

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

  • camlp5
  • findlib
  • netcfg

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.

  • grub2
  • lxd
  • qemu

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:

  • cmake (amd64)

    • lookslike a test case fails that tries to ensure that it bundled an executable properly
  • qtbase-opensource-src (amd64)

    • Fails in mimetype test because it's looking for an executable type, but the pie binaries look like shared libraries

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

  • hardening-wrapper (amd64)

    • fails in no-hardening testcase, needs to know about pie by default and no-pie

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

  • emacs24
  • linux
  • erlang (maybe? it's a documentation build failure, need to verify it succeeds with non-pie)

raw list of build failures (w/arches)

  • checkbox (both)
  • click (both)
  • cmake (amd64)

    • lookslike a test case fails that tries to ensure that it bundled an executable properly
  • corosync (i386)
    • /usr/bin/ld.bfd.real: BFD (GNU Binutils for Ubuntu) 2.25.51.20151113 assertion fail ../../bfd/elf32-i386.c:5297 o.0

  • emacs24 (amd64)

    • unknown problem with pie (fails with wily build host, too)
  • erlang (amd64)

    • unknown error occurs in documentation build
  • evolution (i386, dependency issue)
  • fcitx-qt5 (both)
  • gnome-control-center (i386, dependency issue on libgnome-desktop-3-dev)
  • gnome-settings-daemon (i386)
  • golang (both)
  • golang-race-detector-runtime (amd64)

    • ==5011==ERROR: ThreadSanitizer failed to allocate 0x4000 (16384) bytes at address 1fc448bf40000 (errno: 12)

  • gparted (both)
  • grantlee (both)
  • grep (i386)
  • grub2 (amd64)

    • /usr/bin/ld: -r and -pie may not be used together

  • hardening-wrapper (amd64)

    • fails in no-hardening testcase, needs to know about pie by default and no-pie
  • ibus (both)
  • keyutils (amd64)

    • unknown test failure (endianness test issue?)
  • libcmis (both)
  • libprelude (both)
  • libreoffice (both)
  • libxdmcp (both)
  • libxfont (both)
  • libxi (both)
  • lxd (amd64)

    • /usr/bin/ld: -r and -pie may not be used together during go module build

  • mir (i386)
  • nautilus (i386)
  • oxide-qt (i386)
  • phonon-backend-gstreamer (both)
  • procps (both)
  • qemu (amd64)

    • kernel aslr issue
    • with non-pie bash, build gets farther, but hits /usr/bin/ld: -r and -pie may not be used together issue

  • qtbase-opensource-src (amd64)

    • Fails in mimetype test because it's looking for an executable type, but the pie binaries look like shared libraries
  • qtsvg-opensource-src (both)
  • sendmail (both)
  • shim (amd64)

    • /usr/include/efi/x86_64/efibind.h:86:24: fatal error: stdint.h: No such file or directory ?

  • sosreport (both)
  • subversion (both)
  • syslinux (both)
  • telepathy-glib (i386)
  • totem (i386)
  • ubuntu-app-launch (both)
  • ubuntu-drivers-common (both)
  • unity (i386)
  • whois (both)

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

  • camlp5 (amd64)

    • /usr/bin/ld: /usr/lib/ocaml/libasmrun.a(roots.o): relocation R_X86_64_32 against `caml_frametable' can not be used when making a shared object; recompile with -fPIC

    • build succeeded after ocaml was rebuilt with -pie
  • findlib (amd64)

    • /usr/bin/ld: /usr/lib/ocaml/libcamlrun.a(stacks.o): relocation R_X86_64_32 against `.rodata.str1.8' can not be used when making a shared object; recompile with -fPIC

    • build succeeded after ocaml was rebuilt with -pie
  • netcfg (amd64)

    • /usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu/libcheck.a(check.o): relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a shared object; recompile with -fPIC

    • not sure what package build fixed this, truthfully

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

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