Addendum: With go build -buildmode=pie the resulting binary works!

meena@bsdix ~/s/wxorx> go build -buildmode=pie hello.go
meena@bsdix ~/s/wxorx> ./hello
Hello, World!
meena@bsdix ~/s/wxorx> sudo -H sysctl kern.elf64.allow_wx=0
Password:
kern.elf64.allow_wx: 1 -> 0
meena@bsdix ~/s/wxorx> ./hello
Hello, World!
meena@bsdix ~/s/wxorx> go version
exec_new_vmspace: mapping stack size 0x20000000 prot 0x7 failed mach error 2 errno 13
fish: Job 1, 'go version' terminated by signal SIGABRT (Abort)
meena@bsdix ~/s/wxorx [SIGABRT]>

not only that, elfctl is happy with the binary:

meena@bsdix ~/s/wxorx> elfctl hello
File 'hello' features:
noaslr          'Disable ASLR' is unset.
noprotmax       'Disable implicit PROT_MAX' is unset.
nostackgap      'Disable stack gap' is unset.
wxneeded        'Requires W+X mappings' is unset.
la48            'amd64: Limit user VA to 48bit' is unset.
noaslrstkgap    'Disable ASLR stack gap' is unset.
meena@bsdix ~/s/wxorx>

kib@ explained at least part of the issue: -buildmode=exe results in a binary with no PT_GNU_STACK, so defaults to rwx stack and thus fails with allow_wx=0

It seems -buildmode=pie causes go to use (parts of) the standard host tool chain, and so gets both a PT_GNU_STACK for rw stack, and the NT_FREEBSD_FEATURE_CTL note that elfctl manipulates.

We can modify our ports system to set -buildmode=pie for ports depending on go.
That means, we can produce packages, built with go, that will be compiled as PIEs.

However, we cannot seem to be able to produce a go compiler that is PIE.

Put differently: we can build packages with go on a system with WX disabled, that will work on a system with WX enabled, but we cannot produce a go compiler that will work on such a system.

We already set PT_GNU_STACK for Linux, we just need to do so for freebsd also (and all the other bsds?). That would solve the problem for internal linking, and I think that's the situation when it is happening?

Yes, we need PT_GNU_STACK on FreeBSD. I believe both OpenBSD and NetBSD provide a no-X stack in any case and would be fine without PT_GNU_STACK (although it might not cause any trouble to have it).

That would solve the problem for internal linking

I believe so, yes. I'm not completely familiar with go's linking/tool chain use, but I assume that -buildmode=pie ends up relying on the standard host linker as a side effect? (And, this may be an implementation detail that could change in the future?)

Change https://golang.org/cl/346872 mentions this issue: cmd/link: mark stacks as non-executable on freebsd

@igalic @emaste Try the above linked CL and tell me if that works for you.

CC @dmgk, FreeBSD's lang/go port maintainer

with that patch it now works with w^x enabled:

meena@bsdix /u/p/l/go (main)> file /usr/local/go/bin/go*
/usr/local/go/bin/go:    ELF 64-bit LSB executable, x86-64, version 1 (FreeBSD), dynamically linked, interpreter /libexec/ld-elf.so.1, Go BuildID=XLIT5y7zsZF5lR-GsGHn/5sUPdtoWTSvCjrig1rac/oUGhGkYcwZr5aypGE13h/PyCGVZmPPahQmZyis-c2, not stripped
/usr/local/go/bin/gofmt: ELF 64-bit LSB executable, x86-64, version 1 (FreeBSD), statically linked, Go BuildID=23dNAVgDQa9cM8y7STWR/ZMhOBGxd00N-4hKWF1zI/-MZO7QHiu4q61cHkSr4w/107R6PUcs881Y9-en7pT, not stripped
meena@bsdix /u/p/l/go (main)> elfctl /usr/local/go/bin/go*
elfctl: NT_FREEBSD_FEATURE_CTL note not found
elfctl: NT_FREEBSD_FEATURE_CTL note not found
meena@bsdix /u/p/l/go (main) [1]> sudo -H sysctl kern.elf64.allow_wx=0
kern.elf64.allow_wx: 1 -> 0
meena@bsdix /u/p/l/go (main)> go version
go version go1.17 freebsd/amd64
meena@bsdix /u/p/l/go (main)>

(this means that whenever the bootstrap compiler switches to Go1.18, we could start building lang/go on w^x enabled systems)

Do we want to backport this, so Go 1.16 and 1.17 will work on newer FreeBSD? Thanks.

I guess that depends on how often people enable W^X mode. My intuition is not very often, or we'd have seen this before.
Is there a plan to make W^X the default?

My intuition is not very often, or we'd have seen this before. Is there a plan to make W^X the default?

You're right that it's not enabled often at present. Right now it's really "adventurous" users trying it out; I expect we will make a more comprehensive effort within the FreeBSD developer community to find showstoppers (e.g. major runtimes that fail with it enabled, as here), before a broader call for testing and any discussion of defaults.

That said, independent of W^X with no PT_GNU_STACK we get a RWX stack, and IMO it's worth backporting this just to avoid that.

@ cherrymui Our "quarterly" branch currently has 1.16 and our "latest" branch has 1.17, so i think it would make sense to backport it to both of those.

I'll also open an issue to have NT_FREEBSD_FEATURE_CTL note added, as @emaste mentioned in the review for https://golang.org/cl/346872
I see that NetBSD and OpenBSD already have a .note section, so there's precedent.

I don't think this qualifies for backporting. https://github.com/golang/go/wiki/MinorReleases
It's always been this way, so it isn't a regression. A workaround is to just turn W^X mode off.
It's not really a security issue either - at least not something exploitable (and not new). In fact, I think this would only affect the single stack the program starts with - for freebsd all the other stacks (both G and M stacks) are allocated by the Go runtime and are already not marked executable.

Aye.
I've submitted this as patch to our lang/go port then: https://bugs.freebsd.org/258241 /cc @dmgk

We can modify our ports system to set -buildmode=pie for ports depending on go. That means, we can produce packages, built with go, that will be compiled as PIEs.

However, we cannot seem to be able to produce a go compiler that is PIE.

Any specific blockers on why we cannot have a go compiler that is PIE? Currently, go itself builds fail if set kern.elf64.allow_wx=0.

I don't know why the Go tools would fail with allow_wx=0. Can you provide more details?

You should be able to build the Go tools with pie by running something like go install -buildmode=pie cmd.

Oh, I see, the problem is the missing PT_GNU_STACK. But that problem should be fixed for 1.18.

If you still have problems on tip, please open a new bug. Thanks.