FreeBSD 13 memory mapping policy allow_wx=0 causes crash

[richnetdesign]

I'm using FreeBSD 13 on a network appliance, with dnscrypt-proxy installed. A new security feature in FreeBSD 13 is "W^X memory mapping policy for user processes". In other words "disallow pages to be executable and writable".

To enable the mitigation
sysctl kern.elf64.allow_wx=0

So I wanted to try it out, and most of my programs worked. However, the app crashes
exec_new_vmspace: mapping stack size 0x20000000 prot 0x7 failed mach error 2 errno 13 Abort trap

Output of the following commands:

./dnscrypt-proxy -version
2.0.45

./dnscrypt-proxy -check

What is affected by this bug?

Crashes on start

When does this occur?

When starting dnscrypt-proxy it crashes with
exec_new_vmspace: mapping stack size 0x20000000 prot 0x7 failed mach error 2 errno 13 Abort trap

Changing the sysctl back restores functionality.

Where does it happen?

FreeBSD 13

Expected behavior (i.e. solution)

Normal functionality

Other Comments

I can help investigate this. Wanted to put it out there and get feedback first. While this is a new feature in FreeBSD, I believe OpenBSD has had it for awhile so perhaps something to reference.

References

https://ximalas.info/2021/04/15/freebsd-13-and-wx-memory-mapping-policy-for-user-processes/

[jedisct1]

Looks like +wxneeded needs to be set on programs written in Go: https://forums.freebsd.org/threads/rclone-not-working-with-w-x.80279/

[jedisct1]

I don't think there's much that can be done by applications themselves. This needs to be fixed in Go.

[richnetdesign]

That rclone thread is very helpful. I'll be sure to search freebsd forums in the future.
Now to track down if Go has this on there roadmap.

Seems like there might be 2 seperate issues.

1. Go / compile toolchain issue is causing elf to be missing header. This prevents elfctl from configure binary to deviate from global W^X config.
2. Executables compiled with Go crash immediately if W^X enabled.

[igalic]

given that this is a Go runtime issue, I've opened a ticket in Go: golang/go#48112

[jedisct1]

Awesome, thank you!

[richnetdesign]

I forgot about this. Thanks everybody it seems to be getting fixed upstream in Go, so perhaps I can set allow_wx=0 on my network appliance again soon.