Bug 208580 - [EXP-RUN] ASLR check
Summary: [EXP-RUN] ASLR check
Status: Closed Overcome By Events
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Ports Framework (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Only Me
Assignee: Port Management Team
URL:
Keywords:
Depends on: 235735
Blocks:
  Show dependency treegraph
 
Reported: 2016-04-06 14:31 UTC by Konstantin Belousov
Modified: 2020-07-21 20:10 UTC (History)
7 users (show)

See Also:
lwhsu: exp-run?


Attachments
aslr.8.patch (against HEAD r297617) (20.75 KB, patch)
2016-04-06 14:31 UTC, Konstantin Belousov
no flags Details | Diff
aslr.9.patch (22.87 KB, patch)
2016-04-07 10:43 UTC, Konstantin Belousov
no flags Details | Diff
sbcl memory mappings (23.73 KB, text/plain)
2016-06-22 20:25 UTC, Shawn Webb
no flags Details
aslr.10.patch (27.08 KB, patch)
2019-01-30 19:44 UTC, Konstantin Belousov
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Konstantin Belousov freebsd_committer freebsd_triage 2016-04-06 14:31:54 UTC
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.
Comment 1 Antoine Brodin freebsd_committer freebsd_triage 2016-04-06 18:06:42 UTC
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.
Comment 2 Konstantin Belousov freebsd_committer freebsd_triage 2016-04-07 10:43:55 UTC
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.
Comment 3 Antoine Brodin freebsd_committer freebsd_triage 2016-04-09 18:22:38 UTC
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
Comment 4 Antoine Brodin freebsd_committer freebsd_triage 2016-04-09 18:25:26 UTC
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
Comment 5 Antoine Brodin freebsd_committer freebsd_triage 2016-04-09 18:29:34 UTC
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
Comment 6 Antoine Brodin freebsd_committer freebsd_triage 2016-04-09 18:32:20 UTC
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
Comment 8 Shawn Webb 2016-04-12 19:19:01 UTC
sbcl compiles fine with HardenedBSD's ASLR, which is based off of PaX ASLR.
Comment 9 Antoine Brodin freebsd_committer freebsd_triage 2016-04-23 09:17:44 UTC
Reassign the PR to portmgr@ when you need a 2nd run.
Comment 10 Ed Maste freebsd_committer freebsd_triage 2016-06-21 15:56:03 UTC
> 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).
Comment 11 Shawn Webb 2016-06-21 16:08:34 UTC
(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.
Comment 12 Ed Maste freebsd_committer freebsd_triage 2016-06-21 16:17:55 UTC
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.
Comment 13 Shawn Webb 2016-06-21 16:20:02 UTC
(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.
Comment 14 Shawn Webb 2016-06-22 20:25:55 UTC
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.
Comment 15 op 2016-06-22 23:27:23 UTC
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.
Comment 16 vali gholami 2017-12-17 07:12:26 UTC
MARKED AS SPAM
Comment 17 Konstantin Belousov freebsd_committer freebsd_triage 2019-01-30 19:44:49 UTC
Created attachment 201539 [details]
aslr.10.patch
Comment 18 Konstantin Belousov freebsd_committer freebsd_triage 2019-01-30 19:50:00 UTC
Hello portmgr, I am asking for the exp-run for the ASLR patch again.  Please see the original description which is still relevant.
Comment 19 Antoine Brodin freebsd_committer freebsd_triage 2019-02-01 19:56:43 UTC
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.
Comment 20 Konstantin Belousov freebsd_committer freebsd_triage 2019-02-02 02:53:04 UTC
(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.
Comment 21 Antoine Brodin freebsd_committer freebsd_triage 2019-02-04 18:26:18 UTC
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
Comment 22 Antoine Brodin freebsd_committer freebsd_triage 2019-02-06 17:12:50 UTC
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
Comment 23 Antoine Brodin freebsd_committer freebsd_triage 2019-02-09 06:37:51 UTC
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
Comment 24 commit-hook freebsd_committer freebsd_triage 2019-02-10 17:20:19 UTC
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