cmd/ld: add PAX header

[gopherbot]

by jameshubbard:

What steps will reproduce the problem?
1.Run all.bash on an SELinux enabled Fedora (using F12 Rawhide)
2. Fails during build process. 
3.

What is the expected output? What do you see instead?
hello, world

Error message received
/hello: error while loading shared libraries:
/home/jhubbard/go/pkg/linux_386/libcgo.so: cannot enable executable stack
as shared object requires: Permission denied

I changed the context for the hello world program and it ran. 

What is your $GOOS?  $GOARCH?
linux 
386

Which revision are you sync'ed to?  (hg log -l 1)

changeset:   3975:b51fd2d6c160

Please provide any additional information below.

[agl]

Comment 1:

Owner changed to a...@golang.org.

Status changed to Accepted.

[agl]

Comment 2:

See http://code.google.com/p/go/source/detail?r=6bfe1e03b36c8284bcf471f4b5ec3a4a33703e50
The magic command is # setsebool -P allow_execstack 1
make.bash: detect and warn about SELinux policy that crashes us.
The default SELinux policy on Fedora 12 (at least) disallows stack
pages to be +x. This causes all binaries written by 6g/6l to segfault
immedately. The 'true' way to fix this issue is to mark binaries with
the correct type. However, that assumes that 6l is going to detect
SELinux, figure out the correct type for the current distribution and
set the type (without libselinux).
For now we'll warn users and point them towards the way to enable
execstack for the whole system.
https://golang.org/issue/47
R=rsc
CC=golang-dev
http://codereview.prom.corp.google.com/1026041

[agl]

Comment 3:

Additional tasks for this bug:
  1) Maybe figure out if 6l can set the attributes needed to allow w+x for output
binaries.
  2) Detect the mmap failure in the generated code.

[gopherbot]

Comment 4 by jameshubbard:

Enabling an executable stack is the wrong way to fix the issue.  It's going to be a
problem for almost all selinux enabled distros.  I'm guessing that it will fail RHEL
5.x as well.
Here's a discussion of the general problem.
http://people.redhat.com/drepper/selinux-mem.html

[agl]

Comment 5:

Thanks for the pointer. I know it's not ideal.
Drepper is suggesting creating an anonymous file and mapping it twice: once W and once 
X. We're not going to do that.
The best answer may be a policy change to make it so that the output files of 6l are 
correctly typed so that they can execmem.

[agl]

Comment 6:

Status changed to Thinking.

[dhobsd]

Comment 7:

I think this may end up being an issue on OpenBSD as well.

[dhobsd]

Comment 8:

Actually, there, we can use mprotect

[rsc]

Comment 9:

The gc implementation is going to continue to depend on W+X memory.
Gccgo does too, though work on gcc may provide an
answer later.
The so-called security protections here are trying to
guard against badly written C programs.  There's no
good reason to force these restrictions onto a safe
language like Go.
If someone wants to do the work to make 6l generate
binaries that are blessed enough to do W+X mappings,
patches welcome.  But I think this is a bug in SELinux
and its ilk more than in Go.

Owner changed to r...@golang.org.

Status changed to WorkingAsIntended.

[adg]

Comment 10:

Issue #1669 has been merged into this issue.

[gopherbot]

Comment 11 by powerman.asdf:

This patch needed to compile and run go on amd64 Hardened Gentoo Linux. Probably it
should be modified to work both on amd64 and x86.

Attachments:

1. go-hardened.patch (777 bytes)

[gopherbot]

Comment 12 by powerman.asdf:

Updated patch to fix broken Go compile on Hardened Gentoo (actually, on kernel with PaX
patch) and force Go linker to generate paxmarked binaries. Support both x86 and amd64.

Attachments:

1. go-hardened.patch (1194 bytes)

[gopherbot]

Comment 13 by w.d.hubbs:

@RSC:
I am the developer for gentoo linux who is working to get the go language into our
distribution.
I could condissionally apply the patch in comment 12. But, I would like your opinion as
well. Is something like this a safe temporary fix until 6l/8l are fixed to write the
binaries correctly?
Thanks much,
William

[ianlancetaylor]

Comment 14:

That patch seems to be more or less what 8l and 6l would do anyhow.  It looks as safe as
anything.

[gopherbot]

Comment 15 by w.d.hubbs:

I am considering extending it so that it would be activated from the command line of
make.bash as follows:
make.bash --pax-kernel
or with a similar switch.
That way it could always be applied instead of being condissionally applied.
If we do that, is there a chance this would be accepted into the repository?