summaryrefslogtreecommitdiffstats
path: root/lib/libc/stdio/fmemopen.c
diff options
context:
space:
mode:
authorpfg <pfg@FreeBSD.org>2015-10-04 18:54:02 +0000
committerpfg <pfg@FreeBSD.org>2015-10-04 18:54:02 +0000
commitcdfe89c7e1dd3aa6deac41e0f3317b19d51030ec (patch)
tree84fc0a28ae24e36319e8b5c9b84e1238f96b8460 /lib/libc/stdio/fmemopen.c
parent503489ef47b166c4b54b769afb4138194cc85d71 (diff)
downloadFreeBSD-src-cdfe89c7e1dd3aa6deac41e0f3317b19d51030ec.zip
FreeBSD-src-cdfe89c7e1dd3aa6deac41e0f3317b19d51030ec.tar.gz
Bump the stack protector to level "strong".
The general stack protector is known to be weak and has pretty small coverage. While setting stack-protector-all would give better protection it would come with a performance cost: for this reason Google's Chrome OS team developed a new stack-protector-strong variant. In addition to the protections offered by -fstack-protector, the new option will guard any function that declares any type or length of local array, even those in structs or unions. It will also protect functions that use a local variable's address in a function argument or on the right-hand side of an assignment. The option was introduced in GCC-4.9, but support for it has been back-ported to our base GCC (r286074) and is also available in clang. The change was tested with dbench and doesn't introduce performance regressions. An exp-run over the ports tree revealed no failures when using the stricter stack-protector-all. Thanks to all testers involved. Reference: https://outflux.net/blog/archives/2014/01/27/fstack-protector-strong/ Tested by: pho, portmgr (antoine) Discussed with: secteam (delphij) Differential Revision: https://reviews.freebsd.org/D3463 PR: 203394 (exp-run) Relnotes: yes MFC: no (not supported in older clang)
Diffstat (limited to 'lib/libc/stdio/fmemopen.c')
0 files changed, 0 insertions, 0 deletions
OpenPOWER on IntegriCloud