Bug 235735 - lang/go14 fails to build with ASLR
Summary: lang/go14 fails to build with ASLR
Status: New
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Only Me
Assignee: Julien Laffaye
URL:
Keywords:
: 239132 (view as bug list)
Depends on:
Blocks: 208580
  Show dependency treegraph
 
Reported: 2019-02-14 12:47 UTC by Antoine Brodin
Modified: 2019-09-26 20:22 UTC (History)
6 users (show)

See Also:
bugzilla: maintainer-feedback? (jlaffaye)


Attachments
ASLR buld fix (1.43 KB, patch)
2019-09-05 12:42 UTC, Dmitri Goutnik
no flags Details | Diff
patch file (4.46 KB, patch)
2019-09-05 15:47 UTC, Dmitri Goutnik
no flags Details | Diff
patch file (1.70 KB, patch)
2019-09-12 20:37 UTC, Dmitri Goutnik
dmgk: maintainer-approval? (jlaffaye)
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Antoine Brodin freebsd_committer 2019-02-14 12:47:00 UTC
Failure log:

http://package18.nyi.freebsd.org/data/112amd64-default-PR208580/2019-01-30_23h37m30s/logs/errors/go14-1.4.3_3.log

Peter reports that this patch fixes it:

+++ src/runtime/mem_freebsd.c   2019-02-14 01:27:32.087512000 -0800
-               p = runtime.mmap(v, n, PROT_READ|PROT_WRITE, MAP_ANON|MAP_PRIVATE, -1, 0);
+               p = runtime.mmap(v, n, PROT_READ|PROT_WRITE, MAP_ANON|MAP_FIXED|MAP_PRIVATE, -1, 0);
Comment 1 Konstantin Belousov freebsd_committer 2019-02-14 12:54:51 UTC
https://reviews.freebsd.org/D19194 is the supposed fix.  Or set vm.cluster_anon to 0.
Comment 2 Tobias Kortkamp freebsd_committer 2019-07-11 06:14:19 UTC
*** Bug 239132 has been marked as a duplicate of this bug. ***
Comment 3 Baptiste Daroussin freebsd_committer 2019-09-05 12:10:33 UTC
Anyone can confirm this fixed it? so we can close the PR?
Comment 4 Dmitri Goutnik freebsd_committer 2019-09-05 12:39:07 UTC
The build still fails for me on 12.0-STABLE r351809:

$ sysctl kern.elf64.aslr
kern.elf64.aslr.stack_gap: 3
kern.elf64.aslr.honor_sbrk: 1
kern.elf64.aslr.pie_enable: 1
kern.elf64.aslr.enable: 1

$ sysctl vm.cluster_anon
vm.cluster_anon: 0

...
go/build                                                                                                                                                                                
cmd/go
runtime: address space conflict: map(0xc208000000) = 0xc2086fc000
fatal error: runtime: address space conflict

runtime stack:
runtime.throw(0x7e5006)
        /usr/local/go14/src/runtime/panic.go:491 +0xad fp=0x7fffff8d81e8 sp=0x7fffff8d81b8
runtime.SysMap(0xc208000000, 0x100000, 0x0, 0x8027b8)
        /usr/local/go14/src/runtime/mem_freebsd.c:90 +0xd3 fp=0x7fffff8d8220 sp=0x7fffff8d81e8
runtime.MHeap_SysAlloc(0x807ea0, 0x100000, 0x4978d2)
        /usr/local/go14/src/runtime/malloc.c:284 +0x124 fp=0x7fffff8d8278 sp=0x7fffff8d8220
MHeap_Grow(0x807ea0, 0x8, 0x0)
        /usr/local/go14/src/runtime/mheap.c:398 +0x58 fp=0x7fffff8d82b8 sp=0x7fffff8d8278
MHeap_AllocSpanLocked(0x807ea0, 0x1, 0x0)
        /usr/local/go14/src/runtime/mheap.c:298 +0x365 fp=0x7fffff8d82f8 sp=0x7fffff8d82b8
mheap_alloc(0x807ea0, 0x1, 0x12, 0x0)
        /usr/local/go14/src/runtime/mheap.c:190 +0x121 fp=0x7fffff8d8320 sp=0x7fffff8d82f8
runtime.MHeap_Alloc(0x807ea0, 0x1, 0x10000000012, 0x476b4e)
        /usr/local/go14/src/runtime/mheap.c:240 +0x66 fp=0x7fffff8d8358 sp=0x7fffff8d8320
MCentral_Grow(0x80fc18, 0x0)
        /usr/local/go14/src/runtime/mcentral.c:197 +0x8b fp=0x7fffff8d83c0 sp=0x7fffff8d8358
runtime.MCentral_CacheSpan(0x80fc18, 0x0)
        /usr/local/go14/src/runtime/mcentral.c:85 +0x167 fp=0x7fffff8d83f8 sp=0x7fffff8d83c0
runtime.MCache_Refill(0x80175f000, 0x12, 0x0)
        /usr/local/go14/src/runtime/mcache.c:90 +0xa0 fp=0x7fffff8d8420 sp=0x7fffff8d83f8
runtime.mcacheRefill_m()
        /usr/local/go14/src/runtime/malloc.c:368 +0x57 fp=0x7fffff8d8440 sp=0x7fffff8d8420
runtime.onM(0x729f70)
        /usr/local/go14/src/runtime/asm_amd64.s:273 +0x9a fp=0x7fffff8d8448 sp=0x7fffff8d8440
runtime.mallocgc(0x120, 0x693c60, 0x0, 0x800000000)
        /usr/local/go14/src/runtime/malloc.go:178 +0x849 fp=0x7fffff8d84f8 sp=0x7fffff8d8448
runtime.newobject(0x693c60, 0x80175f000)
        /usr/local/go14/src/runtime/malloc.go:353 +0x49 fp=0x7fffff8d8520 sp=0x7fffff8d84f8
runtime.newG(0x4903ea)
        /usr/local/go14/src/runtime/proc.go:233 +0x2a fp=0x7fffff8d8538 sp=0x7fffff8d8520
allocg(0x7fa0e0)
        /usr/local/go14/src/runtime/proc.c:925 +0x1f fp=0x7fffff8d8548 sp=0x7fffff8d8538
runtime.malg(0x8000, 0x7fa340)
        /usr/local/go14/src/runtime/proc.c:2106 +0x1f fp=0x7fffff8d8578 sp=0x7fffff8d8548
runtime.mpreinit(0x7fa920)
        /usr/local/go14/src/runtime/os_freebsd.c:205 +0x27 fp=0x7fffff8d8590 sp=0x7fffff8d8578
mcommoninit(0x7fa920)
        /usr/local/go14/src/runtime/proc.c:201 +0xc9 fp=0x7fffff8d85b8 sp=0x7fffff8d8590
runtime.schedinit()
        /usr/local/go14/src/runtime/proc.c:138 +0x55 fp=0x7fffff8d85e0 sp=0x7fffff8d85b8
runtime.rt0_go(0x7fffff8d8618, 0x4, 0x7fffff8d8618, 0x0, 0x0, 0x4, 0x7fffffffe480, 0x7fffffffe4c5, 0x7fffffffe4cb, 0x7fffffffe4ce, ...)
        /usr/local/go14/src/runtime/asm_amd64.s:95 +0x116 fp=0x7fffff8d85e8 sp=0x7fffff8d85e0
*** Error code 2
Comment 5 Dmitri Goutnik freebsd_committer 2019-09-05 12:42:02 UTC
Created attachment 207211 [details]
ASLR buld fix

Patch to fix the build, based on Antoine comment above.
Comment 6 Konstantin Belousov freebsd_committer 2019-09-05 14:26:46 UTC
(In reply to Dmitri Goutnik from comment #5)
MAP_FIXED alone is quite unsafe, you might destroy existing mapping at the specified address.

I suggest you to add MAP_EXCL as well, see the mmap(2) man page for explanation.
Comment 7 Dmitri Goutnik freebsd_committer 2019-09-05 15:47:29 UTC
Created attachment 207218 [details]
patch file

Add MAP_EXCL, bump PORTREVISION while here.

Builds ok on 120a, 120i with ASRL on.
Comment 8 Dmitri Goutnik freebsd_committer 2019-09-12 20:37:13 UTC
Created attachment 207430 [details]
patch file

Make go14 actually able to bootstrap lang/go on i386.
Comment 9 dewayne 2019-09-14 18:13:05 UTC
(In reply to Baptiste Daroussin from comment #3)
On  FreeBSD 12.1-PRERELEASE #0 r352284M: Sat Sep 14 07:08:40 AEST 2019, with the patch applied.

I have built go14 (1.4.3_5) and used to build other applications in amd64 but not an i386 jail.

kern.elf64.aslr.stack_gap: 0   # this is required due to issues with ntpd in host
kern.elf64.aslr.pie_enable: 1
kern.elf64.aslr.enable: 1

kern.elf32.aslr.stack_gap=3
kern.elf32.aslr.pie_enable=1
kern.elf32.aslr.enable=1
kern.elf32.nxstack=1
vm.cluster_anon=1 # The default but others mentioned it

Go was built and used to build security/vuls (successfully on amd64 jail) with this outcome in the i386 jails...

/usr/local/go/pkg/tool/freebsd_386/link -o $WORK/b001/exe/a.out -importcfg $WORK/b001/importcfg.link -buildmode=exe -buildid=0tjvD8tux_zGvAh0x9fX/1j0VZJ1DOqHq_tWso3bW/cZbhax9_KEo4DJrh1SQi/0tjvD8tux_zGvAh0x9fX -X main.version=0.6.1 -extld=/usr/local/libexec/ccache/cc $WORK/b001/_pkg_.a
# _/var/ports/usr/ports/security/vuls/work/src/github.com/future-architect/vuls
/usr/local/go/pkg/tool/freebsd_386/link: running /usr/local/libexec/ccache/cc failed: exit status 1
cc: warning: argument unused during compilation: '-nopie' [-Wunused-command-line-argument]
ld: error: failed to open $WORK/b001/exe/a.out: Cannot allocate memory
cc: error: linker command failed with exit code 1 (use -v to see invocation)

This box has 24G and at the time 14G Free.

Over multiple runs, the cumulative changes were unsuccessful until aslr was disabled. Setting 
kern.elf32.aslr.stack_gap=0 did not change the result.
then 
kern.elf32.aslr.pie_enable=0
but 
kern.elf32.aslr.enable=0

Did result in a successful build of (the only thing I was after) security/vuls.  Please note that go14 did build, so in that sense, yes the PR could be closed but...

I think more data points are required.
Comment 10 Dmitri Goutnik freebsd_committer 2019-09-14 18:49:26 UTC
(In reply to dewayne from comment #9)
Hi,

Which go14 patch did you apply? The patch that I initially posted was not correct and was causing OOM issues similar to what you're seeing. With the currently attached patch I'm able to do a poudriere bulk of lang/go14, lang/go and security/vuls in i386 jail without errors, with ASLR both enabled and disabled.

$ sysctl -a | grep aslr
kern.elf32.aslr.stack_gap: 3
kern.elf32.aslr.honor_sbrk: 1
kern.elf32.aslr.pie_enable: 1
kern.elf32.aslr.enable: 1
kern.elf64.aslr.stack_gap: 0
kern.elf64.aslr.honor_sbrk: 1
kern.elf64.aslr.pie_enable: 1
kern.elf64.aslr.enable: 1

# poudriere bulk -j120i -C lang/go14 lang/go security/vuls
...
[00:05:12] Built ports: lang/go14 lang/go security/vuls
[120i-default] [2019-09-14_13h28m16s] [committing:] Queued: 3  Built: 3  Failed: 0  Skipped: 0  Ignored: 0  Tobuild: 0   Time: 00:05:11

This is on 12.1-PRERELEASE amd64 r352284
Comment 11 dewayne 2019-09-15 03:22:27 UTC
(In reply to Dmitri Goutnik from comment #10)
Hi Dmitri, I applied the patch-set from:
https://bugs.freebsd.org/bugzilla/attachment.cgi?id=207430
containing

+enum
+{
+       MAP_EXCL = 0x4000
+};
+

-               p = runtime·mmap(v, n, PROT_READ|PROT_WRITE, MAP_ANON|MAP_PRIVATE, -1, 0);
+               p = runtime·mmap(v, n, PROT_READ|PROT_WRITE, MAP_ANON|MAP_FIXED|MAP_EXCL|MAP_PRIVATE, -, 0);
Comment 12 Miyashita Touka 2019-09-26 20:22:22 UTC
Any progress on this?