|Summary:||[patch] ASLR feature request|
|Product:||Base System||Reporter:||Rodney W. Grimes <rgrimes>|
|Component:||kern||Assignee:||Konstantin Belousov <kib>|
|Severity:||Affects Many People||CC:||cem, emaste, rgrimes|
|Bug Depends on:|
Description Rodney W. Grimes 2018-06-12 16:50:01 UTC
Comment 1 Conrad Meyer 2018-08-02 01:49:19 UTC
Kib, any objection to committing your existing work off-by-default and following up with exp-runs of it enabled to chase out remaining ports bugs? Is there another specific concern about committing the change, other than it being fairly large and invasive? Thanks.
Comment 2 Ed Maste 2018-08-03 17:14:50 UTC
(In reply to Conrad Meyer from comment #1) Note that there is an outstanding issue with i386 in the current patch set.
Comment 3 Conrad Meyer 2018-08-03 18:42:36 UTC
(In reply to Ed Maste from comment #2) What's the specific issue? I don't see anything called out i386-specific in the phabricator review, and the problems you pointed out earlier seem to have been addressed. If you referring to the Go issue, that appears to be a bug in the Go runtime that they have been addressed in their master branch (also present in 1.11beta1+): https://github.com/golang/go/commit/51ae88ee2f9a1063c272a497527751d786291c89 (They previously assumed that mmap() without MAP_FIXED would honor their requested address, which has definitely never been guaranteed. And the bug was only present on 64-bit platforms, not i386.) ASLR has limited utility on i386 — IMO it would be perfectly acceptable to merge with support for 32-bit architectures fully disabled. This gets us 99% of the benefit and any bugfixes for 32-bit architecture support can be applied on CURRENT and potentially MFC'd to a later 12.x.
Comment 4 Conrad Meyer 2018-08-03 18:55:21 UTC
(Further on Go: the authors explicitly reject the idea of ASLR and claim it is only useful for C programs. Those mmap assumptions probably ignored ASLR entirely. It is unclear how they reconcile that with, say, cgo or other interaction with C libraries. https://groups.google.com/forum/#!topic/golang-nuts/Jd9tlNc6jUE )
Comment 5 Konstantin Belousov 2018-08-03 19:03:24 UTC
(In reply to Conrad Meyer from comment #3) No, there seems to be an overflow in calculating the interpreter base address. It is hidden by the fact that 64bit AS has more space and I only randomize that many bits, I need to fix this.
Comment 6 Ed Maste 2018-08-03 19:05:22 UTC
(In reply to Conrad Meyer from comment #3) On i386 we trip one of these assertions: KASSERT(res >= base, ("res %#lx < base %#lx, minv %#lx maxv %#lx rbase %#lx", res, base, minv, maxv, rbase)); KASSERT(res < maxv, ("res %#lx > maxv %#lx, minv %#lx base %#lx rbase %#lx", res, maxv, minv, base, rbase));
Comment 7 Conrad Meyer 2018-08-03 19:30:36 UTC
(In reply to Konstantin Belousov from comment #5) (In reply to Ed Maste from comment #6) Thanks!
Comment 8 Ed Maste 2018-11-05 01:43:53 UTC
(In reply to Ed Maste from comment #6) i386 assertions fixed as of diff 49195 https://reviews.freebsd.org/differential/diff/49195/
Comment 9 Ed Maste 2019-12-07 03:58:42 UTC