Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

all: stop using direct syscalls on OpenBSD #36435

Open
4a6f656c opened this issue Jan 7, 2020 · 5 comments
Open

all: stop using direct syscalls on OpenBSD #36435

4a6f656c opened this issue Jan 7, 2020 · 5 comments
Assignees
Labels
Milestone

Comments

@4a6f656c
Copy link
Contributor

@4a6f656c 4a6f656c commented Jan 7, 2020

Upcoming changes to the OpenBSD kernel will prevent system calls from being made unless they are coming from libc.so (with some exceptions, for example, a static binary). There are also likely to be changes to the APIs used for system calls. As such, the Go runtime (and other packages) need to stop using direct syscalls, rather calling into libc functions instead (as has always been done for Solaris and now also for macOS). This will avoid these issues and allow Go to continue to function correctly on OpenBSD.

A version of Go with openbsd/amd64 being modified to perform all calls via libc is available at:

https://github.com/4a6f656c/go/tree/openbsd-syscall

Further work is still required to convert openbsd/386, openbsd/arm and openbsd/arm64.

@randall77

This comment has been minimized.

Copy link
Contributor

@randall77 randall77 commented Jan 7, 2020

with some exceptions, for example, a static binary

But Go fits squarely within that exception. Or are you worried about nonstandard build modes?

@bradfitz bradfitz added the OS-OpenBSD label Jan 7, 2020
@bradfitz bradfitz added this to the Go1.15 milestone Jan 7, 2020
@FiloSottile

This comment has been minimized.

Copy link
Member

@FiloSottile FiloSottile commented Jan 7, 2020

That exception exists specifically for Go. https://lwn.net/Articles/806863/

@beoran

This comment has been minimized.

Copy link

@beoran beoran commented Jan 8, 2020

I think this move to make kernels callable only though a blessed C library is a bad idea, in particular for all users of programming languages that are not C-like. It introduces a performance overhead for every kernel call that could be avoided by direct kernel calls. The security benefits are debatable, fix the kernel, not hide the flaws and incompatibilities behind a C library.

Kernels should do like Linux does, and provide a safe, stable, kernel API, and not try to shift the interface to C libraries. And even then, graphic on Linux is a disaster because they exactly did that, provide most functionality in a C library, not in the kernel itself. We should protest at least once to mr. De Raadt. against this debatable decision.

@4a6f656c

This comment has been minimized.

Copy link
Contributor Author

@4a6f656c 4a6f656c commented Jan 8, 2020

@randall77 - in many cases Go on OpenBSD will generate a dynamically linked executable, unless cgo is disabled:

$ cat n.go
package main

import (
        "fmt"
        "net"
)

func main() {
        fmt.Println(net.IPv4len)
}
$ go build -o n n.go 
$ ldd n              
n:
        Start            End              Type  Open Ref GrpRef Name
        0000000000010000 00000000001d3000 exe   2    0   0      n
        0000000453cfd000 0000000453d3e000 rlib  0    1   0      /usr/lib/libpthread.so.26.1
        000000048614c000 000000048624c000 rlib  0    1   0      /usr/lib/libc.so.95.1
        0000000497c90000 0000000497c90000 ld.so 0    1   0      /usr/libexec/ld.so
$ CGO_ENABLED=0 go build -o n n.go
ldd n
$ ldd n
n:
not a dynamic executable

This would mean that we'd have to drop cgo support and only support statically compiled Go executables.

@FiloSottile you're correct in that there is currently an exception for dynamically linked executables to allow syscalls from both libc.so and the main text segment, so that Go continues to work. However, in addition to this there will always likely be an exception for static binaries, since in that case there is no libc.so and parts of libc.a have likely been linked into the main text segment (otherwise a static binary could not make syscalls).

@goleo108

This comment has been minimized.

Copy link

@goleo108 goleo108 commented Jan 12, 2020

@4a6f656c why does it generate dynamically linked executable in the first place?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
6 participants
You can’t perform that action at this time.