Differential D18423
Prototype WITH_PIE knob Authored by emaste on Dec 3 2018, 6:04 PM. Tags None Referenced Files
Subscribers
Details Add WITH_PIE knob to build position-independent binaries
Diff Detail
Event TimelineComment Actions 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. Comment Actions 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. Comment Actions
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:
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. Comment Actions -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. Comment Actions
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. Comment Actions Share the INSTALL_PIC_ARCHIVE logic to install libXXX_pic.a versions of INTERNALLIBs and PRIVATELIBs.
Comment Actions What architectures would require having both a _pic.a and _pie.a? In a userland address space that addresses less than 48 bits (32-bit archs, fbsd/riscv), address space randomization is effectively useless. So, really, amd64, arm64, and mips64 are currently the only relevant architectures with respect to address space randomization and position-independent executables. If FreeBSD were to use SV64 instead of SV39 for riscv, then riscv would be in the picture, too. Comment Actions This is suboptimal - consider this test code: int global_variable;
int
lib_function1(int a)
{
return (a + global_variable);
}
int
lib_function2(int a)
{
return (lib_function1(a));
}-fPIC causes Clang to emit a GOT access to global_variable and a PLT call to lib_function1 while -fPIE omits GOT and PLT use. (By comparison GCC emits GOT and PLT use in both cases.) Demo: https://github.com/emaste/pic-pie So we'll want to build a separate _pie.a lib. Comment Actions Compile objs with -fpie or -fPIE and use _pie suffix instead of reusing _pic build infrastructure as generated code may be different. (PIE objects do not need to support symbol interposition and thus avoid GOT/PLT use.)
Comment Actions Just turn off PIE for clang and svn (their Makefiles explicitly reference .a archives and need invasive changes to add ${PIE_SUFFIX} - that may come in a later commit but this smaller change is easier to review. Comment Actions I believe this is ready to commit now (disabled by default); commit message: Add WITH_PIE knob to build base system as Position Independent Executables Building binaries as PIE allows the executable itself to be loaded at a random address with ASLR enabled, not just its shared libraries. PIE objects have a .pieo extension and INTERNALLIB libraries libXXX_pie.a. MK_PIE is disabled for some kerberos5 tools, Clang, and Subversion, as they explicitly reference .a libraries in their Makefiles. These can be addressed on an individual basis later. MK_PIE is also disabled for rtld-elf because it is already position-independent using bespoke Makefile rules. Comment Actions Do static binaries work ? I suspect they do not, or they work by a chance. Most scary is init(8) of course, but other static binaries esp. rescue(8) are also questionable. Comment Actions Untested, the intent is that the knob applies only to dynamically linked binaries in this iteration. There was indeed a bug in bsd.prog.mk though, will be updated shortly. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||