cmd/link,x/sys/unix: unix.TestMmap failing on netbsd as of CL 470298

[bcmills]

CL 470298 defaulted to external linking for Go programs that import the standard-library packages net, os/user, and crypto/x509 when cgo is used to build those packages.

The tests for golang.org/x/sys/unix happen to import the net package:
https://cs.opensource.google/search?q=%5C%22net%5C%22&ss=go%2Fx%2Fsys:unix%2F

Somehow, the change in linking seems to have caused all of the netbsd builders to start failing unix.TestMmap (https://build.golang.org/log/1335867d48cb1aa20e21d276efe7e282e1f4938e):

--- FAIL: TestMmap (0.00s)
    mmap_unix_test.go:23: Mprotect: permission denied
FAIL
FAIL	golang.org/x/sys/unix	0.476s

It isn't clear to me why changing the linker behavior would have that effect, but there is a clear inflection point in the dashboard logs at that CL (https://build.golang.org/?repo=golang.org%2fx%2fsys).

(attn @golang/compiler @golang/netbsd)

[bcmills]

I suspect that this may have something to do with the NetBSD “PaX MPROTECT” extension (https://man.netbsd.org/security.7).

Probably on NetBSD the initial Mmap call needs to pass PROT_MPROTECT(PROT_READ|PROT_WRITE) instead of PROT_NONE.

It looks like PROT_MPROTECT is defined here:
https://github.com/NetBSD/src/blob/aba449a55bf91b44bc68f542edd9afa341962b89/sys/sys/mman.h#L68-L75

[gopherbot]

Change https://go.dev/cl/470775 mentions this issue: unix: pass PROT_MPROTECT(PROT_READ|PROT_WRITE) to initial Mmap on netbsd

[ianlancetaylor]

For the record, this happens with external linking mode because in that mode we link in a startup file that includes a .note.netbsd.pax section. That section includes some PaX flags, defined at https://www.netbsd.org/docs/kernel/elf-notes.html. When this note is present, the PaX protections are set to the system default. (The note can be adjusted by the paxctl command to change the protections for that particular program.) When the note is not present, it appears that no PaX protections are applied. When using internal linking, the note is not present.

In this context it's worth noting that on Linux we add the Linux version of this note, a PT_PAX_FLAGS segment, and set it to disable PaX mprotect, randexec, and emutramp protections. We did that back in 2012 for #47. It's quite possible that we no longer need that.