Age | Commit message (Collapse) | Author |
|
matches the behaviour of the other Makefile.bsd-wrapper files
ok miod@
|
|
leave gopher, news, and dired in place for now. but we will soon catch up
to the security level of internet explorer 7 by removing these too.
ok's for the version of this diff that removes even more protocols from
deraadt@, tedu@. general support from other devs.
|
|
From dt71 at gmx.com via FreeBSD
Required to build with recent versions of clang.
|
|
This is the flag name that modern GCC and Clang have de facto
standardized on for the functionality that we locally named
-Wstack-larger-than-N.
ok brad, miod
|
|
changes from 2.8.8dev.16:
* fix most issues found by clang 3.2 analyze
* fix most issues found by Coverity scan
tested on i386, sparc64, and macppc by myself.
tested on vax by miod@ (including https)
helpful discussion with avsm@, sthen@
ok deraadt@
|
|
ok deraadt@, sthen@
|
|
Currently, GCC 4.2 silently ignores the "aligned" attribute for
objects allocated on the stack if the specified minimum alignment
exceeds the platform's natural stack alignment. This has bitten us in
the past, so we shouldn't allow this to continue.
Fixing the "ignores" problem seems hard, so this commit settles for
tackling the "silently" problem instead.
ok miod, and possibly guenther and deraadt
|
|
From FreeBSD SA-14:11
ok millert@
|
|
OK sthen@ miod@
|
|
Sure miod@
|
|
ok sthen@
|
|
ok afresh@
|
|
word from the (deprecated) /dev/arandom. This also makes it work
in chroot environments.
ok deraadt@ afresh@
|
|
ok deraadt@ millert@
|
|
Miod says all architectures work with it now (thanks to his fix for
the pf.c bug).
|
|
|
|
commit.
|
|
a little pointer-sized gap before the return value. This protects
from common off-by-one type of bugs and costs nothing: the attacker
won't be able to overwrite return pointer. Developed at m2k14,
thanks for the hackathon!
|
|
This will make the environment more hostile and help detect bugs
that depend on overrunning one variable into another, with almost
no performance cost.
Discussed with Theo at m2k14 hackathon. "oh god yes" tedu@, "oh nice" djm@
|
|
a bad idea, for it causes false positives, which then can cause ICE trying
to protect narrower-than-int incoming arguments, if building with
-fstack-protector-all.
From etoh@'s gcc 3.4 tree, unbreaks -fstack-protector-all on m88k (well, maybe
not completely, but it makes it compile more files, such as pf.c which contains
functions receiving uint16_t arguments pushed on the stack due to the
exhaustion of caller-saved registers).
|
|
|
|
16byte boundary. However, GCC 16-byte aligns arrays of >=16 BITS,
not BYTES.
This diff improves bug detectability for code which has local arrays
of [16 .. 127] bits: in those cases SSP will now detect even 1-byte
overflows.
OK kettenis@. Tested in snaps for a week.
|
|
already manually disabled).
ok deraadt@
|
|
more comfortable.
Reminded by brad@
|
|
ok miod@
|
|
was present, but commented.
This fixes code generation of usr.sbin/dhcpd/memory.c!new_address_range()
on vax.
|
|
mod_perl).
ok sthen@ millert@
|
|
_moddi3.o gets protected and landisk bootblocks got broken.
Fundamentally this causes a link dependency on libc that we'll not
always be able to satisfy. Spotted by deraadt@.
OK matthew@, kettenis@, guenther@.
|
|
fucompi was correct.
Unbreaks www/webkit on i386.
ok sthen@
|
|
ok deraadt@
|
|
additional functions --- those that have local array definitions,
or have references to local frame addresses.
Note that upstream uses -fstack-protector-strong and misleads people:
-fstack-protector, -fstack-protector-all, -fstack-protector-strong
can you tell which one is safe?
Luckily, OpenBSD has its own compiler and is able to do the right
thing for security: this is enabled by default, and called
-fstack-protector.
OK deraadt@, miod@. Tested for 3 months.
|
|
|
|
OK millert@ deraadt@
|
|
OK espie@ sthen@ deraadt@
|
|
OK espie@ sthen@ deraadt@
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
config.sh.OpenBSD are the only local changes.
|
|
sendmail.8 note by jmc
|
|
Taken from binutils 2.17.
ok guenther@
|
|
|
|
Makes it possible to build an i386 kernel with binutils-2.17 again.
ok miod@
|