cmd/ld: support grsec kernels

[bradfitz]

From danderson@, regarding weekly.2012-03-13 (Go 1 RC1):

"""
This version of Go does not work on a subset of Linux kernels. Right off the bat I'd
like to say that I don't think this should hold up Go 1.0 . I would like to see a fix in
Go 1.0.1 or Go 1.1.0, and I have a patch to offer. But for the initial release, it's
most definitely inconsequential.

Linux kernels with the grsecurity.net hardening patch enforce write-xor-execute on
memory pages. Specifically, mmap() and mprotect() calls that attempt to make pages
write+execute will fail unless the binary is marked as needing the W^X defense disabled.
This of course makes the runtime crash on startup, as it is dependent on W+X.

It's still possible to run Go binaries compiled on a different machine, by using the
`paxctl` tool to tag the binary as needing W+X memory. However, unless the Go toolchain
can produce binaries tagged in this way by itself, the vanilla source tarball cannot be
built/used on machines with this kernel patch.

I have a patch for Go's linkers that adds the appropriate ELF program header to Go
binaries. The header maps no additional memory into the runtime, it's used only for its
flags (similar to PT_GNU_STACK). The patch is around 5 lines (times five to put it in
[568]l). Once Go 1.0 gets out there, I'll send a code review with the change needed to
get the toolchain working on grsec machines. Obviously I'll leave it to you folks to
decide whether it's worth supporting or not, as grsecurity users are a minority, and a
workaround exists for deploying on such machines, even if you can't compile on them
directly.

Thanks for what's shaping up to be a great Go 1.0!
- Dave
"""

Keywords: grsec grsecurity

[rsc]

Comment 1:

Thanks for the detailed report.

Status changed to Accepted.

[minux]

Comment 2:

FYI: http://code.google.com/p/go/source/detail?r=5099eaeb3086 fixed issue #47 and this
issue.

Status changed to Duplicate.

Merged into issue #47.