Page MenuHomeFreeBSD

Prototype WITH_PIE knob
Needs ReviewPublic

Authored by emaste on Mon, Dec 3, 6:04 PM.

Details

Reviewers
dim
kib
bdrewery
Summary

Add WITH_PIE knob to build position-independent binaries

  • kerberos5/tools/asn1_compile and kerberos5/tools/slc/Makefile link non-internal/private libroken.a explicitly; set MK_PIE=no for them
  • build private and internal libs as PIC when WITH_PIE is set
  • never build i386 boot components as PIE

Diff Detail

Lint
Lint Skipped
Unit
Unit Tests Skipped

Event Timeline

emaste created this revision.Mon, Dec 3, 6:04 PM
emaste added a comment.Mon, Dec 3, 6:06 PM

Presumably we should build INTERNALLIBs and PRIVATELIBs as both libfoo.a and libfoo_pic.a (or some similar scheme) and choose the appropriate one when linking the binary. I don't know how far down that path we want to go though.

kib added a comment.Mon, Dec 3, 6:24 PM

Presumably we should build INTERNALLIBs and PRIVATELIBs as both libfoo.a and libfoo_pic.a (or some similar scheme) and choose the appropriate one when linking the binary. I don't know how far down that path we want to go though.

Yes, I argued that this is the only correct way. We must not build normal libXXX.a with PIC, but we do need libXXX_pic.a. Also, formally architectures can have different -fPIC and -fPIE ABIs, so perhaps we really need libXXX_pie.a, and e.g. libc_pic.a and libc_pie.a simultaneously.

emaste added a comment.Mon, Dec 3, 7:01 PM

Also, formally architectures can have different -fPIC and -fPIE ABIs, so perhaps we really need libXXX_pie.a, and e.g. libc_pic.a and libc_pie.a simultaneously.

Do you have a reference for this? At least for any architecture relevant to us today I don't think this is a practical case, so perhaps we ought to build _pic.a for PIE use for now, with a comment in bsd.lib.mk?

For reference I see PRIVATELIB or INTERNALLIB under:

  • gnu/usr.bin/binutils
  • gnu/usr.bin/cc
  • gnu/usr.bin/gdb
  • kerberos5/lib
  • lib/atf
  • lib/clang
  • lib/libbsdstat
  • lib/libdevdctl
  • lib/libelftc
  • lib/libevent
  • lib/libifconfig
  • lib/libldns
  • lib/libnetbsd
  • lib/libopenbsd
  • lib/libpe
  • lib/libpmcstat
  • lib/libsm
  • lib/libsmdb
  • lib/libsmutil
  • lib/libsqlite3
  • lib/libtelnet
  • lib/libucl
  • lib/libunbound
  • lib/libzstd
  • rescue
  • sbin/ipf
  • secure/lib/libssh
  • stand/liblua
  • stand/usb
  • tools/tools/net80211
  • usr.sbin/svn/lib
  • usr.sbin/amd
  • usr.sbin/bsnmpd
  • usr.sbin/cron
  • usr.sbin/fifolog
  • usr.sbin/lpr
  • usr.sbin/ntp

Multiple subdirectories under some of these elided, there are a total of 69.

We could of course build _pie.a or _pic.a versions of these libs only if the WITH_PIE knob is set. We could even build only the _pie.a or _pic.a version when set.

kib added a comment.Mon, Dec 3, 7:47 PM

Also, formally architectures can have different -fPIC and -fPIE ABIs, so perhaps we really need libXXX_pie.a, and e.g. libc_pic.a and libc_pie.a simultaneously.

Do you have a reference for this? At least for any architecture relevant to us today I don't think this is a practical case, so perhaps we ought to build _pic.a for PIE use for now, with a comment in bsd.lib.mk?

-fPIE code does not need to redirect all its external symbol accesses through GOT/PLT. This does not matter for x86 at compile time, only at the link time, but it might give an opportunity to optimize for other arches. Also the default TLS model might be different.

emaste added a comment.Mon, Dec 3, 8:08 PM

This does not matter for x86 at compile time, only at the link time

Right, in particular I wonder if any architectures will do something different at compile time -- we need _pie.a vs _pic.a only if so.