MFS r352754: Add WITH_PIE knob to build Position Independent Executables

MFC r344179: Add WITH_PIE knob to build Position Independent Executables

Building binaries as PIE allows the executable itse

MFS r352754: Add WITH_PIE knob to build Position Independent Executables

MFC r344179: Add WITH_PIE knob to build Position Independent Executables

Building binaries as PIE allows the executable itself to be loaded at a
random address when ASLR is enabled (not just its shared libraries).

With this change 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.

Currently only dynamically linked binaries will be built as PIE.

MFC r344181: Fix Makefile conditional after r344179

MFC r344182: Use make's :tl instead of checking "no" and "NO"

MFC r344189: Fixup bsd.prog.mk after r344182

MFC r344211: wlandebug: disable PIE to fix build failure

libifconfig is built as a static-only PRIVATELIB (and there is no _pie.a
version) so disable PIE in libifconfig's consumer.

r345489: Fix GNU objdump build under WITH_PIE

Explicitly specified bare .a libraries need ${PIE_SUFFIX}.

r345490: Apply WITH_PIE changes to other binutils components

Followon to r345489, explicitly specified bare .a libraries need
${PIE_SUFFIX} (although these still built).

r345778: Fix gdb/kgdb build under WITH_PIE

Explicitly specified bare .a libraries need ${PIE_SUFFIX}.

Approved by: re (gjb)
Sponsored by: The FreeBSD Foundation

show more ...

Rename RELTOP since it will mean something else globally.

Sponsored by: Dell EMC Isilon

Revert r267233 for now. PIE support needs to be reworked.

1. 50+% of NO_PIE use is fixed by adding -fPIC to INTERNALLIB and other
build-only utility libraries.
2. Another 40% is fixed by generati

Revert r267233 for now. PIE support needs to be reworked.

1. 50+% of NO_PIE use is fixed by adding -fPIC to INTERNALLIB and other
build-only utility libraries.
2. Another 40% is fixed by generating _pic.a variants of various libraries.
3. Some of the NO_PIE use is a bit absurd as it is disabling PIE (and ASLR)
where it never would work anyhow, such as csu or loader. This suggests
there may be better ways of adding support to the tree. Many of these
cases can be fixed such that -fPIE will work but there is really no
reason to have it in those cases.
4. Some of the uses are working around hacks done to some Makefiles that are
really building libraries but have been using bsd.prog.mk because the code
is cleaner. Had they been using bsd.lib.mk then NO_PIE would not have
been needed.

We likely do want to enable PIE by default (opt-out) for non-tree consumers
(such as ports). For in-tree though we probably want to only enable PIE
(opt-in) for common attack targets such as remote service daemons and setuid
utilities. This is also a great performance compromise since ASLR is expected
to reduce performance. As such it does not make sense to enable it in all
utilities such as ls(1) that have little benefit to having it enabled.

Reported by: kib

show more ...

In preparation for ASLR [1] support add WITH_PIE to support building with -fPIE.

This is currently an opt-in build flag. Once ASLR support is ready and stable
it should changed to opt-out and be ena

In preparation for ASLR [1] support add WITH_PIE to support building with -fPIE.

This is currently an opt-in build flag. Once ASLR support is ready and stable
it should changed to opt-out and be enabled by default along with ASLR.

Each application Makefile uses opt-out to ensure that ASLR will be enabled by
default in new directories when the system is compiled with PIE/ASLR. [2]

Mark known build failures as NO_PIE for now.

The only known runtime failure was rtld.

[1] http://www.bsdcan.org/2014/schedule/events/452.en.html
Submitted by: Shawn Webb <[email protected]>
Discussed between: des@ and Shawn Webb [2]

show more ...

Most of binutils now compiles at WARNS=3, except for libiberty and
libbfd, which still need WARNS=2.

Lower WARNS to avoid warning about type-punned casting.

Updated Bmake framework for Binutils 2.15.

style.Makefile(5):
Use WARNS?= instead of WARNS=

For this to work properly for all part is the subdirectories
the WARNS assignments in Makefile.inc0 are moved to the correspondning
Makefile.inc.

A

style.Makefile(5):
Use WARNS?= instead of WARNS=

For this to work properly for all part is the subdirectories
the WARNS assignments in Makefile.inc0 are moved to the correspondning
Makefile.inc.

Approved by: obrien (binutils maintainer)
Tested by: make universe

show more ...

Removed invasion into these makefiles by the "legacy" stuff;
I have a better fix in the works.

libbinutils.a needs basename(3); when the latter is provided
by -legacy, liblegacy.a should come last in the LDADD list.

Update to Binutils 2.12.0 release.

Turn up WARNS as high as possible.

Tested by: gcc31, gcc32, /usr/bin/cc

Change the way the version strings are handled.

Clean up the formatting.

Pull the switch and activate our Binutils to a snapshot of the up and
comming 2.10 release.

Use `${dir}/libfoo.a' instead of `-L${dir} -lfoo' for local static
libraries in LDADD so that `make checkdpadd' doesn't report non-errors.

Fixed some style bugs (the usual ones for DPADD and LDADD,

Use `${dir}/libfoo.a' instead of `-L${dir} -lfoo' for local static
libraries in LDADD so that `make checkdpadd' doesn't report non-errors.

Fixed some style bugs (the usual ones for DPADD and LDADD, and misformatting
of $FreeBSD$).

show more ...

$Id$ -> $FreeBSD$

Add missing DPADD's.

Restructure the binutils hierarchy somewhat in order to better
support building it for variant architectures. It was already
becoming clear that the former structure was too rigid and didn't
scale w

Restructure the binutils hierarchy somewhat in order to better
support building it for variant architectures. It was already
becoming clear that the former structure was too rigid and didn't
scale well.

The usual sort of makefile magic arranges to .include an architecture
specific makefile "Makefile.${MACHINE_ARCH}" in each directory
where it exists. Also, sources will be found in each subdirectory
"${MACHINE_ARCH}" that exists. This is all taken care of automatically
by the top level "Makefile.inc0".

This all seems to work right for the i386 now. I have also converted
those alpha pieces already present to the new schema as best I
could.

Also: change the BINDIR on the i386 to /usr/libexec/elf for "ar"
and "ranlib". They are not object format independent enough to
put into /usr/bin.

show more ...

Add bmakefiles for building binutils from the contrib tree.

This finishes up the binutils import. But I am leaving it disabled
in "src/gnu/usr.bin/Makefile" for now. It is not used by anything
yet

Add bmakefiles for building binutils from the contrib tree.

This finishes up the binutils import. But I am leaving it disabled
in "src/gnu/usr.bin/Makefile" for now. It is not used by anything
yet, so I'll take this opportunity to run one more round of tests
before enabling it.

show more ...