Bug 258169 - net/syncthing fails to start with W^X protections enabled
Summary: net/syncthing fails to start with W^X protections enabled
Status: Closed Not Accepted
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Only Me
Assignee: Steve Wills
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2021-08-30 15:49 UTC by Mina Galić
Modified: 2021-08-31 12:57 UTC (History)
0 users

See Also:
bugzilla: maintainer-feedback? (swills)


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Mina Galić 2021-08-30 15:49:45 UTC
On a FreeBSD 13.0 system, syncthing fails to start, throwing the following error:

exec_new_vmspace: mapping stack size 0x20000000 prot 0x7 failed mach error 2 errno 13


a quick search seems to indicate that this is related to W^X, which i, indeed, have enabled on my systems.

I created an issue with upstream to see if this can be fixed, on their end, or if we "just" need to recompile with -Wl,-z,wxneeded: https://github.com/syncthing/syncthing/issues/7915
Comment 1 Steve Wills freebsd_committer 2021-08-30 16:06:18 UTC
(In reply to Mina Galić from comment #0)
Sorry, dumb question, how do you enable W^X?
Comment 2 Mina Galić 2021-08-30 16:14:06 UTC
here's my sysctl.conf, or parts thereof 

##security(7)
#
### PIE & ASLR & WX & NX for 64
kern.elf64.allow_wx=0
kern.elf64.aslr.honor_sbrk=1
kern.elf64.aslr.pie_enable=1
kern.elf64.aslr.enable=1
kern.elf64.nxstack=1

## PIE & ASLR & WX & NX for 32
kern.elf32.allow_wx=0
kern.elf32.aslr.honor_sbrk=0
kern.elf32.aslr.pie_enable=1
kern.elf32.aslr.enable=1
kern.elf32.nxstack=1
# i don't understand this one
#kern.elf32.read_exec=0

disallowing wx should be enough, tho
Comment 3 Steve Wills freebsd_committer 2021-08-30 16:31:06 UTC
(In reply to Mina Galić from comment #2)
Gotcha, ok. Well, let's see what upstream says, and if you want to provide a patch for building with "-Wl,-z,wxneeded", I'm happy to do that too.
Comment 4 Mina Galić 2021-08-30 16:59:47 UTC
Upstream's response:

> You can try that. Report back if it works. There may be some aspects to the Go runtime as well possibly.

Do you know anyone who knows anything about go?
Comment 5 Steve Wills freebsd_committer 2021-08-30 18:02:19 UTC
(In reply to Mina Galić from comment #4)
Sorry, not sure what you're asking. I know a bit about writing and building Go things, but about the runtime, not so much. And I don't know anyone who does.

Let's test building with -Wl,-z,wxneeded and see what happens. Failing that, telling people to use elfctl -e +wxneeded on it seems reasonable.
Comment 6 Mina Galić 2021-08-31 09:32:16 UTC
elfctl doesn't seem to work:

root@backup:~ # elfctl -e +wxneeded /usr/local/bin/syncthing
elfctl: NT_FREEBSD_FEATURE_CTL note not found
elfctl: NT_FREEBSD_FEATURE_CTL note not found
root@backup:~ #

somebody is suggesting this may indeed be a Go runtime issue:
https://github.com/DNSCrypt/dnscrypt-proxy/issues/1730
Comment 7 Steve Wills freebsd_committer 2021-08-31 12:57:43 UTC
(In reply to Mina Galić from comment #6)
Sounds like it's not particular to this port, so we should close this and see what happens upstream. Closing for now, feel free to re-open if you have suggestions on how to work around it in syncthing.