17 ms·

https://marc.info/?l=openbsd-cvs&m=157500930922882&w=2 https://marc.info/?l=openbsd-cvs&m=157500930922882&w=2 For dynamic binaries, we continue to to permit th

https://marc.info/?l=openbsd-cvs&m=157500930922882&w=2 https://marc.info/?l=openbsd-cvs&m=157500930922882&w=2 For dynamic binaries, we continue to to permit the main program exec segment because "go" (and potentially a few other applications) have embedded system calls in the main program. Hopefully at least go gets fixed soon. We declare the concept of embedded syscalls a bad idea for numerous reasons, as we notice the ecosystem has many of static-syscall-in-base-binary which are dynamically linked against libraries which in turn use libc, which contains another set of syscall stubs. We've been concerned about adding even one additional syscall entry point... but go's approach tends to double the entry-point attack surface. https://marc.info/?l=openbsd-tech&m=157488907117170&w=2 https://marc.info/?l=openbsd-tech&m=157488907117170&w=2 [edit for convenience of readers - read the above linked thread - I just grabbed the go part] Unfortunately our current go build model hasn't followed solaris/macos approach yet of calling libc stubs, and uses the inappropriate "embed system calls directly" method, so for now we'll need to authorize the main program text as well. A comment in exec_elf.c explains this. If go is adapted to call library-based system call stubs on OpenBSD as well, this problem will go away. There may be other environments creating raw system calls. I guess we'll need to find them as time goes by, and hope in time we can repair those also. [/edit]

lonelappde 7y ago
Does this mean that they want to ban syscalls from everything but approved "fat client" libraries like libc? (And perhaps ban versions of libc that have bugs?) How is that implemented? I guess it's by only allowing syscalls if the calling code is in a special part of memory, and the OS can gatekeep access to that memory?
- Reelin 7y ago
  My understanding is that system calls can currently only be made from -w+x regions; attempting otherwise results in the process being killed. The idea is to extend this protection to only allow system calls from expected address ranges, so that a successful exploit can't simply make raw calls but instead has to track down an existing authorized one (and thus contend with ASLR). To that end, the new call-once syscall msyscall(2) is added. The linker uses it to register libc.so with the kernel after randomly mapping it into the current process.
- loeg 7y ago
  > Does this mean that they want to ban syscalls from everything but approved "fat client" libraries like libc? Yes. > (And perhaps ban versions of libc that have bugs?) There is only one OpenBSD libc.
Reelin 7y ago
Related (AFAIU): https://news.ycombinator.com/item?id=21653119 https://news.ycombinator.com/item?id=21653119 > We've been concerned about adding even one additional syscall entry point I don't understand the need for such a severe "only libc syscalls ever" approach. What would be the security concern with allowing syscalls only from preauthorized (ie msyscall(2)) regions, making initial region authorization opt-in (instead of opt-out), allowing the program to call msyscall(2) itself, and rejecting any statically linked (ie non-ASLR'd) regions for authorization?
- masklinn 7y ago
  > I don't understand the need for such a severe "only libc syscalls ever" approach. There's nothing severe about it. Most systems are exactly that: systems of which the kernel is only one part, syscalls are rarely if ever intended to be called directly nilly-willy. The issue is that unlike windows unices have never enforced this.
  - amscanne 7y ago
    Sorry, that generalization doesn’t hold water. It makes sense for systems where libc is tightly coupled and coversioned with the kernel, e.g. BSDs, but Linux always relied on third-party C libraries and supported static binaries, etc. You could argue that BSD made the mistake of intending to have a Windows-style C library compat guarantee but not enforcing it, but that was not in scope for Linux. The philosophy has always been syscall-level compat (and there are lots of famous threads with Linus re-enforcing this to others who would presume that things should be “fixed in user space”). So it’s hardly reasonable to generalize based on some BSD concerns; Linux is WAI and represents the most common Unix-like system people use today by far. There’s a pretty good argument that this level of compat, while the source of some problems, has also made other things much easier: consider container images that are bundled with their own system libraries. (You could certainly invent schemes to inject these libraries, but dealing with link and library level compatibility seems even more complex to deal with than system call-level compatibility.)
    - pcwalton 7y ago
komuW 7y ago
> Unfortunately our current go build model hasn't followed solaris/macos approach yet of calling libc stubs, and uses the inappropriate "embed system calls directly" method, Go, as of version 1.12,uses libSystem in Darwin to make syscalls. 1. https://golang.org/doc/go1.12#darwin https://golang.org/doc/go1.12#darwin
asveikau 7y ago
That recent change in OpenBSD is indeed interesting, however, this doesn't have much to do with how go handles scheduling of goroutines, other than the fact that the words "go" or "syscall" appear in both places.

lonelappde 7y ago

Does this mean that they want to ban syscalls from everything but approved "fat client" libraries like libc? (And perhaps ban versions of libc that have bugs?) How is that implemented? I guess it's by only allowing syscalls if the calling code is in a special part of memory, and the OS can gatekeep access to that memory?

Reelin 7y ago
My understanding is that system calls can currently only be made from -w+x regions; attempting otherwise results in the process being killed. The idea is to extend this protection to only allow system calls from expected address ranges, so that a successful exploit can't simply make raw calls but instead has to track down an existing authorized one (and thus contend with ASLR). To that end, the new call-once syscall msyscall(2) is added. The linker uses it to register libc.so with the kernel after randomly mapping it into the current process.
loeg 7y ago
> Does this mean that they want to ban syscalls from everything but approved "fat client" libraries like libc? Yes. > (And perhaps ban versions of libc that have bugs?) There is only one OpenBSD libc.

Reelin 7y ago

Related (AFAIU): https://news.ycombinator.com/item?id=21653119 https://news.ycombinator.com/item?id=21653119 > We've been concerned about adding even one additional syscall entry point I don't understand the need for such a severe "only libc syscalls ever" approach. What would be the security concern with allowing syscalls only from preauthorized (ie msyscall(2)) regions, making initial region authorization opt-in (instead of opt-out), allowing the program to call msyscall(2) itself, and rejecting any statically linked (ie non-ASLR'd) regions for authorization?

masklinn 7y ago
> I don't understand the need for such a severe "only libc syscalls ever" approach. There's nothing severe about it. Most systems are exactly that: systems of which the kernel is only one part, syscalls are rarely if ever intended to be called directly nilly-willy. The issue is that unlike windows unices have never enforced this.
- amscanne 7y ago
  Sorry, that generalization doesn’t hold water. It makes sense for systems where libc is tightly coupled and coversioned with the kernel, e.g. BSDs, but Linux always relied on third-party C libraries and supported static binaries, etc. You could argue that BSD made the mistake of intending to have a Windows-style C library compat guarantee but not enforcing it, but that was not in scope for Linux. The philosophy has always been syscall-level compat (and there are lots of famous threads with Linus re-enforcing this to others who would presume that things should be “fixed in user space”). So it’s hardly reasonable to generalize based on some BSD concerns; Linux is WAI and represents the most common Unix-like system people use today by far. There’s a pretty good argument that this level of compat, while the source of some problems, has also made other things much easier: consider container images that are bundled with their own system libraries. (You could certainly invent schemes to inject these libraries, but dealing with link and library level compatibility seems even more complex to deal with than system call-level compatibility.)
  - pcwalton 7y ago

komuW 7y ago

> Unfortunately our current go build model hasn't followed solaris/macos approach yet of calling libc stubs, and uses the inappropriate "embed system calls directly" method, Go, as of version 1.12,uses libSystem in Darwin to make syscalls. 1. https://golang.org/doc/go1.12#darwin https://golang.org/doc/go1.12#darwin

asveikau 7y ago

That recent change in OpenBSD is indeed interesting, however, this doesn't have much to do with how go handles scheduling of goroutines, other than the fact that the words "go" or "syscall" appear in both places.