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
(In reply to Mina Galić from comment #0) Sorry, dumb question, how do you enable W^X?
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
(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.
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?
(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.
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
(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.