Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
bcmills opened this issue Feb 23, 2023 · 3 comments
Closed

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

bcmills opened this issue Feb 23, 2023 · 3 comments
Labels
compiler/runtime Issues related to the Go compiler and/or runtime. FrozenDueToAge NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. OS-NetBSD
Milestone

Comments

@bcmills
Copy link
Contributor

bcmills commented Feb 23, 2023

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)

@gopherbot gopherbot added the compiler/runtime Issues related to the Go compiler and/or runtime. label Feb 23, 2023
@bcmills bcmills added OS-NetBSD NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. labels Feb 23, 2023
@bcmills bcmills added this to the Go1.21 milestone Feb 23, 2023
@bcmills
Copy link
Contributor Author

bcmills commented Feb 23, 2023

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
Copy link

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

@ianlancetaylor
Copy link
Contributor

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.

@golang golang locked and limited conversation to collaborators Feb 25, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
compiler/runtime Issues related to the Go compiler and/or runtime. FrozenDueToAge NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. OS-NetBSD
Projects
None yet
Development

No branches or pull requests

3 participants