Off by default, build behaves normally.
WITH_META_MODE we get auto objdir creation, the ability to
start build from anywhere in the tree.
Still need to add real targets under targets/ to build packages.
Differential Revision: D2796
Reviewed by: brooks imp
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
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 <lattera@gmail.com>
Discussed between: des@ and Shawn Webb [2]
These tools declare global variables without using the static keyword,
even though their use is limited to a single C-file, or without placing
an extern declaration of them in the proper header file.
Declare perror(). We define and use a home made version of perror(3)
that can't simply be removed (although it has the same interface as
perror(3)) since it is very different (it prints on stdout, doesn't
always print the program name, and sometimes exits). Declare it to
get a reminder of this brokenness when WARNS is increased enough.
became garbage when block devices were axed and were removed a few
months later, but they came back (with hotroot renamed to hot + hotroot())
when the NetBSD fsck was mismerged.
- Don't use errexit() to (mis)implement usage(). Using errexit() just
gave the bogus exit code 8.
- Fixed 3 other style bugs in usage().
fsck/fsutil.[ch]:
- Garbage-collected errexit(). It is essentially just one of NetBSD's
fsck_ext2fs error printing functions, but we don't have fsck_ext2fs
and the function is unsuitable for use there too (since pfatal() is
also used and it printf to a different stream).
where we want to take the disklabel filesystem type of "4.2BSD" and use
fsck_4.2bsd on those filesystems.
Add a comment about why the code is there, now that we know:
* XXX This is a kludge to make automatic filesystem type guessing
* from the disklabel work for "4.2BSD" filesystems. It does a
* very limited subset of transliteration to a normalised form of
* filesystem name, and we do not seem to enforce a filesystem
* name character set.
upper-case alphabetical characters to lower-case ones, and spaces to dashes.
The person who added this when bringing the code from NetBSD has no idea why
he added it, and nobody on freebsd-fs came up with any cases where the icky
part (the conversion of spaces to underscores) was needed. The removal of
the upper-case conversion follows an even more obvious logic: it avoids any
sort of namespace issues. People using StUdLy caps for filesystem names
deserve everything they get. Otherwise, Efs and efs might be totally different
things, but would use the same fsck. And we don't want that, right? That
just provokes the sort of foot-shooting this would prevent.
If you have problems with this, I'll walk you through using sed on your fstab,
cause the only way you could have problems is if you spelled ufs as "UFS".
Most likely, you haven't done that.
MFC after: 1 month
