x/sys/unix: OpenBSD mmap syscall number (unix.SYS_MMAP) obsolete

[dusaint]

On 2021-12-23, a new syscall for mmap was introduced:

49	STD NOLOCK	{ void *sys_mmap(void *addr, size_t len, int prot, \
			    int flags, int fd, off_t pos); }

At the same time, the existing mmap syscall was renamed from sys_mmap to sys_pad_mmap (since it contains a now-obsolete argument for padding).

See sys/kern/syscalls.master:

openbsd/src@1d60349#diff-e8c6a075c6e1240e27216779540b66f3db43b14a3b3615c2ecb7a111faa54504

On 2023-02-11, the original mmap syscall was retired entirely:

openbsd/src@8c7f5cc

With the release of OpenBSD 7.3 on 2023-04-10, any go program that uses mmap on OpenBSD will crash with SIGSYS.

For example, here's a snippet from kdump of a failing run of gotosocial:

 83839 gotosocial CALL  (via syscall) #197 (obsolete pad_mmap)()
 83839 gotosocial PSIG  SIGSYS caught handler=0x4682c0 mask=0<>
 83839 gotosocial RET   #197 (obsolete pad_mmap) -1 errno 78 Function not implemented

This is a bug both in this project and in modernc.org/libc. Here, the constant unix.SYS_MMAP needs to be changed from 197 to 49. I'll also file a bug in that project for them to switch both the number and how they're invoking syscall.

[ianlancetaylor]

CC @golang/openbsd

[landryb]

Fwiw, influxdb 1.8.10 on openbsd 7.3 had this issue (crashing with SIGSYS at startup, with a goroutine trace pointing at sys_mmap), and upgrading the x/sys module to 0.5.0 fixed it. cf https://marc.info/?l=openbsd-ports&m=168166545112152&w=2

so maybe it's already fixed 'somewhere' in the go ecosystem and projects need to update their dependencies ?

[sthen]

There are two related problems. One is that older versions of x/sys use syscall() itself, this has been replaced with calls to libc wrappers. The other is that the syscall tables are many (openbsd) releases out of date and in particular the old ones with "pad" arguments have recently been retired - golang/sys@3086868 synced some tables but not syscalls. Fixing that will partly involve syncing the table but will also involve fixing the call parameters.

There is an additional twist in that openbsd is considering blocking syscall() completely. It has not yet been done though the linker now prints a warning when it's used. If that's done then syscall access will become impossible except through libc.

[dusaint]

FWIW, just calling unix.mmap works as expected -- the SIGSYS I saw came from another package's use of the unix.SYS_MMAP constant. I haven't tested the other changed syscalls, but wouldn't be surprised if they follow the same pattern.

[palinon]

As a side effect bootstrapping go by building Go 1.4 from source is no longer possible on OpenBSD 7.3. During the build of cmd/go go_bootstrap is crashing with SIGSYS, due to a mmap call.

[4a6f656c]

As a side effect bootstrapping go by building Go 1.4 from source is no longer possible on OpenBSD 7.3. During the build of cmd/go go_bootstrap is crashing with SIGSYS, due to a mmap call.

The minimum bootstrap for Go 1.20 is Go 1.17.3:

https://go.dev/doc/go1.20#bootstrap

As such, there is no effort being made to keep Go 1.4 working on OpenBSD.