Created attachment 169039 [details] aslr.8.patch (against HEAD r297617) This is a request to perform exp-run for the ASLR patch. As I understand, all ports build nodes run amd64 kernel. The run is requested both for amd64 and i386 builds (on amd64 host). No sysctl or tunables frobbing is required, the patch has everything set up for max aggressive level.
There are lots of those errors, before actual package building starts: ELF interpreter /libexec/ld-elf.so.1 not found, error 22 Abort trap ELF interpreter /libexec/ld-elf.so.1 not found, error 22 Abort trap And I believe package23 just crashed, need to check with clusteradm.
Created attachment 169071 [details] aslr.9.patch The original issue was manifested by the 'interpreter' messages. The recursion on the vnode lock is the bug in existing code of ELF image activator when broken interpeter is on tmpfs. I fixed that as well, but hopefully neither of these two problems would reappear. Some ports building and 32bit pypy build were successfull.
Exp-run results for 10.1 amd64 jail: http://package22.nyi.freebsd.org/build.html?mastername=101amd64-default-PR208580&build=2016-04-08_13h44m49s New failures: + {"origin"=>"editors/emacs", "pkgname"=>"emacs24-24.5_3,3", "phase"=>"build", "errortype"=>"coredump"} + {"origin"=>"editors/emacs-devel", "pkgname"=>"emacs-devel-25.0.92_1,2", "phase"=>"build", "errortype"=>"coredump"} + {"origin"=>"editors/emacs-nox11", "pkgname"=>"emacs-nox11-24.5_3,3", "phase"=>"build", "errortype"=>"coredump"} + {"origin"=>"java/classpath", "pkgname"=>"classpath-0.99_1", "phase"=>"configure", "errortype"=>"configure_error"} + {"origin"=>"java/openjdk6", "pkgname"=>"openjdk6-b38,1", "phase"=>"build", "errortype"=>"coredump"} + {"origin"=>"java/openjdk6-jre", "pkgname"=>"openjdk6-jre-b38,1", "phase"=>"build", "errortype"=>"coredump"} + {"origin"=>"java/openjdk7", "pkgname"=>"openjdk-7.95.00,1", "phase"=>"build", "errortype"=>"coredump"} + {"origin"=>"java/openjdk7-jre", "pkgname"=>"openjdk-jre-7.95.00,1", "phase"=>"build", "errortype"=>"coredump"} + {"origin"=>"lang/ecl", "pkgname"=>"ecl-15.3.7_1", "phase"=>"build", "errortype"=>"coredump"} + {"origin"=>"lang/go14", "pkgname"=>"go14-1.4.3", "phase"=>"build", "errortype"=>"???"} + {"origin"=>"lang/rust", "pkgname"=>"rust-1.7.0", "phase"=>"build", "errortype"=>"coredump"} + {"origin"=>"lang/rust-nightly", "pkgname"=>"rust-nightly-1.9.0.20160318", "phase"=>"build", "errortype"=>"coredump"} + {"origin"=>"lang/sbcl", "pkgname"=>"sbcl-1.3.1,1", "phase"=>"build", "errortype"=>"termios"} + {"origin"=>"print/pdftk", "pkgname"=>"pdftk-2.02_3", "phase"=>"build", "errortype"=>"missing_header"} Failure logs: http://package22.nyi.freebsd.org/data/101amd64-default-PR208580/2016-04-08_13h44m49s/logs/errors/emacs24-24.5_3,3.log http://package22.nyi.freebsd.org/data/101amd64-default-PR208580/2016-04-08_13h44m49s/logs/errors/emacs-devel-25.0.92_1,2.log http://package22.nyi.freebsd.org/data/101amd64-default-PR208580/2016-04-08_13h44m49s/logs/errors/emacs-nox11-24.5_3,3.log http://package22.nyi.freebsd.org/data/101amd64-default-PR208580/2016-04-08_13h44m49s/logs/errors/classpath-0.99_1.log http://package22.nyi.freebsd.org/data/101amd64-default-PR208580/2016-04-08_13h44m49s/logs/errors/openjdk6-b38,1.log http://package22.nyi.freebsd.org/data/101amd64-default-PR208580/2016-04-08_13h44m49s/logs/errors/openjdk6-jre-b38,1.log http://package22.nyi.freebsd.org/data/101amd64-default-PR208580/2016-04-08_13h44m49s/logs/errors/openjdk-7.95.00,1.log http://package22.nyi.freebsd.org/data/101amd64-default-PR208580/2016-04-08_13h44m49s/logs/errors/openjdk-jre-7.95.00,1.log http://package22.nyi.freebsd.org/data/101amd64-default-PR208580/2016-04-08_13h44m49s/logs/errors/ecl-15.3.7_1.log http://package22.nyi.freebsd.org/data/101amd64-default-PR208580/2016-04-08_13h44m49s/logs/errors/go14-1.4.3.log http://package22.nyi.freebsd.org/data/101amd64-default-PR208580/2016-04-08_13h44m49s/logs/errors/rust-1.7.0.log http://package22.nyi.freebsd.org/data/101amd64-default-PR208580/2016-04-08_13h44m49s/logs/errors/rust-nightly-1.9.0.20160318.log http://package22.nyi.freebsd.org/data/101amd64-default-PR208580/2016-04-08_13h44m49s/logs/errors/sbcl-1.3.1,1.log http://package22.nyi.freebsd.org/data/101amd64-default-PR208580/2016-04-08_13h44m49s/logs/errors/pdftk-2.02_3.log
Exp-run results for 10.1 i386 jail: http://package23.nyi.freebsd.org/build.html?mastername=101i386-default-PR208580&build=2016-04-08_13h04m47s New failures: + {"origin"=>"editors/emacs", "pkgname"=>"emacs24-24.5_3,3", "phase"=>"build", "errortype"=>"clang"} + {"origin"=>"editors/emacs-nox11", "pkgname"=>"emacs-nox11-24.5_3,3", "phase"=>"build", "errortype"=>"clang"} + {"origin"=>"java/classpath", "pkgname"=>"classpath-0.99_1", "phase"=>"configure/runaway", "errortype"=>"runaway_process"} + {"origin"=>"java/openjdk6", "pkgname"=>"openjdk6-b38,1", "phase"=>"build/runaway", "errortype"=>"runaway_process"} + {"origin"=>"java/openjdk6-jre", "pkgname"=>"openjdk6-jre-b38,1", "phase"=>"build/runaway", "errortype"=>"runaway_process"} + {"origin"=>"java/openjdk7", "pkgname"=>"openjdk-7.95.00,1", "phase"=>"build/runaway", "errortype"=>"runaway_process"} + {"origin"=>"java/openjdk7-jre", "pkgname"=>"openjdk-jre-7.95.00,1", "phase"=>"build/runaway", "errortype"=>"runaway_process"} + {"origin"=>"lang/gprolog", "pkgname"=>"gprolog-1.4.4", "phase"=>"build", "errortype"=>"???"} + {"origin"=>"lang/nhc98", "pkgname"=>"nhc98-1.22_1", "phase"=>"build", "errortype"=>"makefile"} + {"origin"=>"lang/rust", "pkgname"=>"rust-1.7.0", "phase"=>"build", "errortype"=>"coredump"} + {"origin"=>"lang/sbcl", "pkgname"=>"sbcl-1.3.1,1", "phase"=>"build", "errortype"=>"coredump"} + {"origin"=>"print/pdftk", "pkgname"=>"pdftk-2.02_3", "phase"=>"build", "errortype"=>"missing_header"} + {"origin"=>"sysutils/terraform", "pkgname"=>"hashicorp-terraform-0.6.3", "phase"=>"build", "errortype"=>"???"} Failure logs: http://package23.nyi.freebsd.org/data/101i386-default-PR208580/2016-04-08_13h04m47s/logs/errors/emacs24-24.5_3,3.log http://package23.nyi.freebsd.org/data/101i386-default-PR208580/2016-04-08_13h04m47s/logs/errors/emacs-nox11-24.5_3,3.log http://package23.nyi.freebsd.org/data/101i386-default-PR208580/2016-04-08_13h04m47s/logs/errors/classpath-0.99_1.log http://package23.nyi.freebsd.org/data/101i386-default-PR208580/2016-04-08_13h04m47s/logs/errors/openjdk6-b38,1.log http://package23.nyi.freebsd.org/data/101i386-default-PR208580/2016-04-08_13h04m47s/logs/errors/openjdk6-jre-b38,1.log http://package23.nyi.freebsd.org/data/101i386-default-PR208580/2016-04-08_13h04m47s/logs/errors/openjdk-7.95.00,1.log http://package23.nyi.freebsd.org/data/101i386-default-PR208580/2016-04-08_13h04m47s/logs/errors/openjdk-jre-7.95.00,1.log http://package23.nyi.freebsd.org/data/101i386-default-PR208580/2016-04-08_13h04m47s/logs/errors/gprolog-1.4.4.log http://package23.nyi.freebsd.org/data/101i386-default-PR208580/2016-04-08_13h04m47s/logs/errors/nhc98-1.22_1.log http://package23.nyi.freebsd.org/data/101i386-default-PR208580/2016-04-08_13h04m47s/logs/errors/rust-1.7.0.log http://package23.nyi.freebsd.org/data/101i386-default-PR208580/2016-04-08_13h04m47s/logs/errors/sbcl-1.3.1,1.log http://package23.nyi.freebsd.org/data/101i386-default-PR208580/2016-04-08_13h04m47s/logs/errors/pdftk-2.02_3.log http://package23.nyi.freebsd.org/data/101i386-default-PR208580/2016-04-08_13h04m47s/logs/errors/hashicorp-terraform-0.6.3.log
Exp-run results in 9.3 amd64 jail: http://package22.nyi.freebsd.org/build.html?mastername=93amd64-default-PR208580&build=2016-04-07_12h44m09s Extra failures (compared to 10.1 amd64): + {"origin"=>"benchmarks/wrk", "pkgname"=>"wrk-4.0.1_3", "phase"=>"build", "errortype"=>"???"} + {"origin"=>"devel/efl", "pkgname"=>"efl-1.16.1_1", "phase"=>"build", "errortype"=>"???"} + {"origin"=>"lang/racket", "pkgname"=>"racket-6.2", "phase"=>"build", "errortype"=>"process_failed"} + {"origin"=>"lang/racket-minimal", "pkgname"=>"racket-minimal-6.2", "phase"=>"build", "errortype"=>"process_failed"} + {"origin"=>"lang/yap", "pkgname"=>"yap-6.2.2_1", "phase"=>"stage", "errortype"=>"install_error"} + {"origin"=>"print/tex-luatex", "pkgname"=>"tex-luatex-0.80.0_4", "phase"=>"package", "errortype"=>"PLIST"} Failure logs: http://package22.nyi.freebsd.org/data/93amd64-default-PR208580/2016-04-07_12h44m09s/logs/errors/wrk-4.0.1_3.log http://package22.nyi.freebsd.org/data/93amd64-default-PR208580/2016-04-07_12h44m09s/logs/errors/efl-1.16.1_1.log http://package22.nyi.freebsd.org/data/93amd64-default-PR208580/2016-04-07_12h44m09s/logs/errors/racket-6.2.log http://package22.nyi.freebsd.org/data/93amd64-default-PR208580/2016-04-07_12h44m09s/logs/errors/racket-minimal-6.2.log http://package22.nyi.freebsd.org/data/93amd64-default-PR208580/2016-04-07_12h44m09s/logs/errors/yap-6.2.2_1.log http://package22.nyi.freebsd.org/data/93amd64-default-PR208580/2016-04-07_12h44m09s/logs/errors/tex-luatex-0.80.0_4.log
Exp-run results in 9.3 i386 jail: http://package23.nyi.freebsd.org/build.html?mastername=93i386-default-PR208580&build=2016-04-07_11h57m22s Extra failures (compared to 10.1 i386 jail): + {"origin"=>"lang/ecl", "pkgname"=>"ecl-15.3.7_1", "phase"=>"build", "errortype"=>"coredump"} + {"origin"=>"lang/fsharp", "pkgname"=>"fsharp-3.1.2.5", "phase"=>"build", "errortype"=>"???"} Failure logs: http://package23.nyi.freebsd.org/data/93i386-default-PR208580/2016-04-07_11h57m22s/logs/errors/ecl-15.3.7_1.log http://package23.nyi.freebsd.org/data/93i386-default-PR208580/2016-04-07_11h57m22s/logs/errors/fsharp-3.1.2.5.log
Bug report for SBCL failure with pax aslr on Linux: https://bugs.launchpad.net/sbcl/+bug/1523213 They added MAP_FIXED here: https://sourceforge.net/p/sbcl/sbcl/ci/55abdffb4b920e5e1bf370062eb695e2c17aacd1/ Then discussed here: https://sourceforge.net/p/sbcl/mailman/message/34981259/ And reverted: https://sourceforge.net/p/sbcl/sbcl/ci/a10fd4e2674f0bc1bf8be0848d54f53bfa12680e
sbcl compiles fine with HardenedBSD's ASLR, which is based off of PaX ASLR.
Reassign the PR to portmgr@ when you need a 2nd run.
> sbcl compiles fine with HardenedBSD's ASLR, which is based off of PaX ASLR. Note that bugs have been filed against sbcl with PaX ASLR on Linux (possibly with more aggressive randomization?) so it appears there is a legitimate problem here. It may well fail intermittently (to build or pass tests).
(In reply to Ed Maste from comment #10) It's important to keep in mind that HardenedBSD's ASLR implementation is based off of PaX's documentation, not PaX's implementation. So HardenedBSD's ASLR implementation may not have the same issues as PaX's, especially given the differences in the virtual memory manager between the two operating systems.
The point is that having it build successfully is not sufficient to claim that there are no possible issues. There is ample evidence that at least some versions of sbcl have trouble on at least some ASR and ASLR implementations.
(In reply to Ed Maste from comment #12) That could very well be true. sbcl might have runtime issues regardless of ASR or ASLR implementation.
Created attachment 171693 [details] sbcl memory mappings The attached sbcl.txt shows sbcl working with HardenedBSD ASLR. I've verified that a simple "Hello World" lisp application runs. I ran sbcl without any arguments, then typed this into the interpreter: (print "hello world") I have no real-world lisp applications to test sbcl with. But hello world is running perfectly wth HardenedBSD's ASLR implementation.
Correction: I can reproduce one build time error on our implementation too: ; SYS:SRC;CODE;RUN-PROGRAM.FASL.NEWEST written ; compilation finished in 0:00:00.374 T * //doing warm init - load and dump phase load: 2.51 cmd: sbcl 52277 [running] 52.18r 0.34u 1.92s 2% 694812k make: Working in: /usr/ports/lang/sbcl make[1]: Working in: /usr/ports/lang/sbcl 67.30 real 0.00 user 0.00 sys load: 2.48 cmd: sbcl 52277 [biowr] 83.36r 0.34u 3.13s 2% 995236k make[1]: Working in: /usr/ports/lang/sbcl make: Working in: /usr/ports/lang/sbcl 98.49 real 0.00 user 0.00 sys load: 2.48 cmd: sbcl 52277 [running] 84.90r 0.34u 3.18s 2% 1009024k make: Working in: /usr/ports/lang/sbcl 100.02 real 0.00 user 0.00 sys make[1]: Working in: /usr/ports/lang/sbcl load: 2.48 cmd: sbcl 52277 [biowr] 86.07r 0.34u 3.21s 2% 1018128k make[1]: Working in: /usr/ports/lang/sbcl make: Working in: /usr/ports/lang/sbcl 101.19 real 0.00 user 0.00 sys Segmentation fault (core dumped) 107.96 real 14.86 user 4.08 sys *** Error code 139 Stop. make[1]: stopped in /usr/ports/lang/sbcl *** Error code 1 Stop. make: stopped in /usr/ports/lang/sbcl op has logged on pts/4 from :0. op@opn sbcl# make clean ===> Cleaning for sbcl-1.3.1,1 op@opn sbcl# sysctl hardening. hardening.procfs_harden: 1 hardening.log.ulog: 0 hardening.log.log: 1 hardening.version: 46 hardening.pax.hbsdcontrol.status: 1 hardening.pax.segvguard.max_crashes: 5 hardening.pax.segvguard.suspend_timeout: 600 hardening.pax.segvguard.expiry_timeout: 120 hardening.pax.segvguard.status: 1 hardening.pax.mprotect.status: 1 hardening.pax.pageexec.status: 1 hardening.pax.disallow_map32bit.status: 2 hardening.pax.aslr.status: 2 Here the last line means a fully enabled ASLR and enabled MAP_32BIT restriction. Other mitigations are opt-in, and not enabled by default. And this is on: op@opn sbcl# uname -a FreeBSD opn 11.0-CURRENT-HBSD FreeBSD 11.0-CURRENT-HBSD #2 c1cada9(op/hardenedbsd/current/master): Wed May 18 17:11:47 CEST 2016 root@opn:/usr/obj/usr/src/sys/OP-HBSD amd64 Which contains the same ASLR implementation, what the recent HardenedBSD HEAD has.
MARKED AS SPAM
Created attachment 201539 [details] aslr.10.patch
Hello portmgr, I am asking for the exp-run for the ASLR patch again. Please see the original description which is still relevant.
Exp-run results in 11.2 amd64 jail: http://package18.nyi.freebsd.org/build.html?mastername=112amd64-default-PR208580&build=2019-01-30_23h37m30s New failures in 11.2 amd64 jail: + {"origin"=>"lang/go14", "phase"=>"build", "errortype"=>"???"} + {"origin"=>"lang/sbcl", "phase"=>"build", "errortype"=>"???"} + {"origin"=>"print/pdftk", "phase"=>"build/runaway", "errortype"=>"runaway_process"} New failure logs in 11.2 amd64 jail: http://package18.nyi.freebsd.org/data/112amd64-default-PR208580/2019-01-30_23h37m30s/logs/errors/go14-1.4.3_3.log http://package18.nyi.freebsd.org/data/112amd64-default-PR208580/2019-01-30_23h37m30s/logs/errors/sbcl-1.4.16,1.log http://package18.nyi.freebsd.org/data/112amd64-default-PR208580/2019-01-30_23h37m30s/logs/errors/pdftk-2.02_8.log Around 300 ports were newly skipped due to those failures.
(In reply to Antoine Brodin from comment #19) sbcl is known to be not compatible with ASLR, even on Linux. I would be not surprised about go as well. For print/pdftk, the problem is that it uses gcj from gcc 6 for build, and gcj uses sbrk. For me, the port builds if I set sysctl kern.elf64.aslr.honor_sbrk=1.
Exp-run results in 11.2 i386 jail: http://package18.nyi.freebsd.org/build.html?mastername=112i386-default-PR208580&build=2019-02-03_17h52m03s New failures in 11.2 i386 jail: + {"origin"=>"biology/cytoscape", "phase"=>"build", "errortype"=>"???"} + {"origin"=>"devel/aws-sdk-cpp", "phase"=>"build", "errortype"=>"coredump"} + {"origin"=>"lang/ecl", "phase"=>"build", "errortype"=>"coredump"} + {"origin"=>"lang/sbcl", "phase"=>"build", "errortype"=>"coredump"} + {"origin"=>"www/chromium", "phase"=>"build", "errortype"=>"linker_error"} + {"origin"=>"www/iridium", "phase"=>"build", "errortype"=>"linker_error"} New failure logs in 11.2 i386 jail: http://package18.nyi.freebsd.org/data/112i386-default-PR208580/2019-02-03_17h52m03s/logs/errors/cytoscape-3.6.1.log http://package18.nyi.freebsd.org/data/112i386-default-PR208580/2019-02-03_17h52m03s/logs/errors/aws-sdk-cpp-1.7.37.log http://package18.nyi.freebsd.org/data/112i386-default-PR208580/2019-02-03_17h52m03s/logs/errors/ecl-15.3.7_5.log http://package18.nyi.freebsd.org/data/112i386-default-PR208580/2019-02-03_17h52m03s/logs/errors/sbcl-1.4.16,1.log http://package18.nyi.freebsd.org/data/112i386-default-PR208580/2019-02-03_17h52m03s/logs/errors/iridium-browser-2018.5.67_7.log http://package18.nyi.freebsd.org/data/112i386-default-PR208580/2019-02-03_17h52m03s/logs/errors/chromium-71.0.3578.98_2.log
New failures in 12.0 amd64 jail: + {"origin"=>"lang/ecl", "pkgname"=>"ecl-15.3.7_5", "phase"=>"build", "errortype"=>"coredump"} + {"origin"=>"lang/go14", "pkgname"=>"go14-1.4.3_3", "phase"=>"build", "errortype"=>"???"} + {"origin"=>"lang/sbcl", "pkgname"=>"sbcl-1.4.16,1", "phase"=>"build", "errortype"=>"???"} + {"origin"=>"print/pdftk", "pkgname"=>"pdftk-2.02_8", "phase"=>"build/runaway", "errortype"=>"runaway_process"} Additional failure log in 12.0 amd64 jail (compared to 11.2 amd64 jail): http://package18.nyi.freebsd.org/data/120amd64-default-PR208580/2019-02-04_21h08m20s/logs/errors/ecl-15.3.7_5.log
New failures in 12.0 i386 jail: + {"origin"=>"devel/aws-sdk-cpp", "phase"=>"build", "errortype"=>"coredump"} + {"origin"=>"lang/ecl", "phase"=>"build", "errortype"=>"coredump"} + {"origin"=>"lang/pypy", "phase"=>"build", "errortype"=>"???"} + {"origin"=>"lang/sbcl", "phase"=>"build", "errortype"=>"coredump"} + {"origin"=>"lang/smalltalk", "phase"=>"build", "errortype"=>"coredump"} + {"origin"=>"math/asymptote", "phase"=>"build", "errortype"=>"???"} + {"origin"=>"www/chromium", "phase"=>"build", "errortype"=>"coredump"} + {"origin"=>"www/iridium", "phase"=>"build", "errortype"=>"coredump"} Additional failure log in 12.0 i386 jail (compared to 11.2 i386 jail): http://package18.nyi.freebsd.org/data/120i386-default-PR208580/2019-02-08_12h02m59s/logs/errors/pypy-6.0.0_1.log http://package18.nyi.freebsd.org/data/120i386-default-PR208580/2019-02-08_12h02m59s/logs/errors/smalltalk-3.2.5_13.log http://package18.nyi.freebsd.org/data/120i386-default-PR208580/2019-02-08_12h02m59s/logs/errors/asymptote-2.44_6.log
A commit references this bug: Author: kib Date: Sun Feb 10 17:19:49 UTC 2019 New revision: 343964 URL: https://svnweb.freebsd.org/changeset/base/343964 Log: Implement Address Space Layout Randomization (ASLR) With this change, randomization can be enabled for all non-fixed mappings. It means that the base address for the mapping is selected with a guaranteed amount of entropy (bits). If the mapping was requested to be superpage aligned, the randomization honours the superpage attributes. Although the value of ASLR is diminshing over time as exploit authors work out simple ASLR bypass techniques, it elimintates the trivial exploitation of certain vulnerabilities, at least in theory. This implementation is relatively small and happens at the correct architectural level. Also, it is not expected to introduce regressions in existing cases when turned off (default for now), or cause any significant maintaince burden. The randomization is done on a best-effort basis - that is, the allocator falls back to a first fit strategy if fragmentation prevents entropy injection. It is trivial to implement a strong mode where failure to guarantee the requested amount of entropy results in mapping request failure, but I do not consider that to be usable. I have not fine-tuned the amount of entropy injected right now. It is only a quantitive change that will not change the implementation. The current amount is controlled by aslr_pages_rnd. To not spoil coalescing optimizations, to reduce the page table fragmentation inherent to ASLR, and to keep the transient superpage promotion for the malloced memory, locality clustering is implemented for anonymous private mappings, which are automatically grouped until fragmentation kicks in. The initial location for the anon group range is, of course, randomized. This is controlled by vm.cluster_anon, enabled by default. The default mode keeps the sbrk area unpopulated by other mappings, but this can be turned off, which gives much more breathing bits on architectures with small address space, such as i386. This is tied with the question of following an application's hint about the mmap(2) base address. Testing shows that ignoring the hint does not affect the function of common applications, but I would expect more demanding code could break. By default sbrk is preserved and mmap hints are satisfied, which can be changed by using the kern.elf{32,64}.aslr.honor_sbrk sysctl. ASLR is enabled on per-ABI basis, and currently it is only allowed on FreeBSD native i386 and amd64 (including compat 32bit) ABIs. Support for additional architectures will be added after further testing. Both per-process and per-image controls are implemented: - procctl(2) adds PROC_ASLR_CTL/PROC_ASLR_STATUS; - NT_FREEBSD_FCTL_ASLR_DISABLE feature control note bit makes it possible to force ASLR off for the given binary. (A tool to edit the feature control note is in development.) Global controls are: - kern.elf{32,64}.aslr.enable - for non-fixed mappings done by mmap(2); - kern.elf{32,64}.aslr.pie_enable - for PIE image activation mappings; - kern.elf{32,64}.aslr.honor_sbrk - allow to use sbrk area for mmap(2); - vm.cluster_anon - enables anon mapping clustering. PR: 208580 (exp runs) Exp-runs done by: antoine Reviewed by: markj (previous version) Discussed with: emaste Tested by: pho MFC after: 1 month Sponsored by: The FreeBSD Foundation Differential revision: https://reviews.freebsd.org/D5603 Changes: head/sys/amd64/amd64/elf_machdep.c head/sys/arm/arm/elf_machdep.c head/sys/compat/freebsd32/freebsd32_misc.c head/sys/compat/ia32/ia32_sysvec.c head/sys/i386/i386/elf_machdep.c head/sys/kern/imgact_elf.c head/sys/kern/kern_exec.c head/sys/kern/kern_fork.c head/sys/kern/kern_procctl.c head/sys/sys/imgact.h head/sys/sys/proc.h head/sys/sys/procctl.h head/sys/sys/sysent.h head/sys/vm/vm_map.c head/sys/vm/vm_map.h head/usr.bin/proccontrol/proccontrol.c