6 ms·

Nothing stops you from making your own libsystem. Or still just making syscalls. Nobody seems to understand how this feature works, even though it's quite simp

Nothing stops you from making your own libsystem. Or still just making syscalls. Nobody seems to understand how this feature works, even though it's quite simple. The process asks the kernel to only allow system calls from one segment. If you don't like that, don't ask for it.

newpavlov 3y ago
Lack of stable syscall ABI is what stops me. It can be only done by OS developers.
- nanolith 3y ago
  A "stable" syscall ABI means that the interface between kernel and userland is ossified, potentially forever. If OpenBSD did this, then many of the security improvements it has made over the years, which has required the deletion of old (bad) system calls and the modification of other system calls to make them safer, never could happen without fundamentally breaking userland. Calling into system calls in libc is not a hindrance at all for the use of other languages, any more than calling directly into a syscall would be. Cross-language function calls have been a time honored tradition since the first compilers were developed. Linux's ossified syscall ABI is a quirk of Linux, and not a feature found in most, let alone many, operating systems.
  - aforwardslash 3y ago
    Bullshit. A stable syscall api reflects a well designed kernel interface. You can obviously extend on it and deprecate at your will. Thing is, call gates are quite more common now (they even have shortcut instructions in modern cpus) vs software interrupts (int80h), and there is quite some effort into of runtime linking vs static linking - yes, static linking can be used in libc-based ABIs but just defeats the purpose. In my opinion, libc should not be a broker for privileged operations. There are a plethora of reasons for this, but the most obvious is that languages may not use libc in their linkage. And FFS, Ive been using OpenBSD for well over 2 decades now. I'd say any syscall changes done in the OS are minimal compared to eg. linux.
    - nanolith 3y ago
      > Bullshit. A stable syscall api reflects a well designed kernel interface. Says who? I certainly wouldn't consider Linux's syscall ABI to be well designed. You know what is well designed? A stable facade that provides minimal overhead between two components, which prevents tight coupling. Like libc. > You can obviously extend on it and deprecate at your will. Only by breaking userland, which grinds this process to a crawl, even when it can happen at all. libc provides a better interface here. > Thing is, call gates are quite more common now I fail to see the relevance here. The mechanism by which syscalls are made doesn't make it cheaper to ossify your syscall ABI, nor does it improve security. It can certainly reduce the performance hit of a context switch. But, even with call gates, the overhead of a context switch is so high that adding the overhead of calling a wrapped function in libc is hardly going to matter. > and there is quite some effort into of runtime linking vs static linking What effort? Yeah, you have ld.so doing the relocation for you at runtime, but this happens once at program load time. Compared to everything else that must occur to load a program, dynamic linking adds minimal overhead. > In my opinion, libc should not be a broker for privileged operations. That's an interesting opinion, but beyond an unlisted "plethora of reasons", I don't see any relevant reason for this blanket ban. Having a single path into and out of the system call interface provides a way in which userland protections -- such as syscall pinning, immutable pages, etc., can be added. For defense in depth, this is useful. > but the most obvious is that languages may not use libc in their linkage. How does language runtime library linkage matter? What is the real difference to a language whether it calls read() or the read syscall? Either way, it has to marshal arguments through a FFI. Either way, it has to do the same amount of work. Languages must be ported to each operating system they run on. On OpenBSD and MacOS in particular, this porting means calling libc. On most OSes, libc is considered the preferred interface. On Linux, it's not, and because of that, folks assume that Linux's relative uniqueness here is somehow the default. There is really no point to directly using syscalls. In nearly every case for unistd, socket, and fcntl, the libc wrapper is negligible. You can do all of the same things. There are few, if any, enforced C-isms. Even where they exist, they can be abstracted with a middling to average FFI library. Performance-wise, the significant overhead is making the syscall. Calling a library to do this has little measurable effect. This is much ado about nothing.
  - matheusmoreira 3y ago
    > Calling into system calls in libc is not a hindrance at all for the use of other languages, any more than calling directly into a syscall would be. I would say that it is a hindrance though. It's a hindrance even for relatively straight forward C code. You cannot for example use clone and expect the libc to continue working. https://sourceware.org/bugzilla/show_bug.cgi?id=10311 https://sourceware.org/bugzilla/show_bug.cgi?id=10311 > If you use clone() you're on your own. These libraries are the problem, not the solution. They're full of static global data which will get clobbered whenever you do anything more complicated than I/O. They use thread local variables for returning errors codes. It's bad legacy stuff.
    - nanolith 3y ago
      That's a Linux system call, on Linux. We're talking about OpenBSD. The OpenBSD developers aren't likely to design a system call like clone.

newpavlov 3y ago

Lack of stable syscall ABI is what stops me. It can be only done by OS developers.

nanolith 3y ago
A "stable" syscall ABI means that the interface between kernel and userland is ossified, potentially forever. If OpenBSD did this, then many of the security improvements it has made over the years, which has required the deletion of old (bad) system calls and the modification of other system calls to make them safer, never could happen without fundamentally breaking userland. Calling into system calls in libc is not a hindrance at all for the use of other languages, any more than calling directly into a syscall would be. Cross-language function calls have been a time honored tradition since the first compilers were developed. Linux's ossified syscall ABI is a quirk of Linux, and not a feature found in most, let alone many, operating systems.
- aforwardslash 3y ago
  Bullshit. A stable syscall api reflects a well designed kernel interface. You can obviously extend on it and deprecate at your will. Thing is, call gates are quite more common now (they even have shortcut instructions in modern cpus) vs software interrupts (int80h), and there is quite some effort into of runtime linking vs static linking - yes, static linking can be used in libc-based ABIs but just defeats the purpose. In my opinion, libc should not be a broker for privileged operations. There are a plethora of reasons for this, but the most obvious is that languages may not use libc in their linkage. And FFS, Ive been using OpenBSD for well over 2 decades now. I'd say any syscall changes done in the OS are minimal compared to eg. linux.
  - nanolith 3y ago
    > Bullshit. A stable syscall api reflects a well designed kernel interface. Says who? I certainly wouldn't consider Linux's syscall ABI to be well designed. You know what is well designed? A stable facade that provides minimal overhead between two components, which prevents tight coupling. Like libc. > You can obviously extend on it and deprecate at your will. Only by breaking userland, which grinds this process to a crawl, even when it can happen at all. libc provides a better interface here. > Thing is, call gates are quite more common now I fail to see the relevance here. The mechanism by which syscalls are made doesn't make it cheaper to ossify your syscall ABI, nor does it improve security. It can certainly reduce the performance hit of a context switch. But, even with call gates, the overhead of a context switch is so high that adding the overhead of calling a wrapped function in libc is hardly going to matter. > and there is quite some effort into of runtime linking vs static linking What effort? Yeah, you have ld.so doing the relocation for you at runtime, but this happens once at program load time. Compared to everything else that must occur to load a program, dynamic linking adds minimal overhead. > In my opinion, libc should not be a broker for privileged operations. That's an interesting opinion, but beyond an unlisted "plethora of reasons", I don't see any relevant reason for this blanket ban. Having a single path into and out of the system call interface provides a way in which userland protections -- such as syscall pinning, immutable pages, etc., can be added. For defense in depth, this is useful. > but the most obvious is that languages may not use libc in their linkage. How does language runtime library linkage matter? What is the real difference to a language whether it calls read() or the read syscall? Either way, it has to marshal arguments through a FFI. Either way, it has to do the same amount of work. Languages must be ported to each operating system they run on. On OpenBSD and MacOS in particular, this porting means calling libc. On most OSes, libc is considered the preferred interface. On Linux, it's not, and because of that, folks assume that Linux's relative uniqueness here is somehow the default. There is really no point to directly using syscalls. In nearly every case for unistd, socket, and fcntl, the libc wrapper is negligible. You can do all of the same things. There are few, if any, enforced C-isms. Even where they exist, they can be abstracted with a middling to average FFI library. Performance-wise, the significant overhead is making the syscall. Calling a library to do this has little measurable effect. This is much ado about nothing.
- matheusmoreira 3y ago
  > Calling into system calls in libc is not a hindrance at all for the use of other languages, any more than calling directly into a syscall would be. I would say that it is a hindrance though. It's a hindrance even for relatively straight forward C code. You cannot for example use clone and expect the libc to continue working. https://sourceware.org/bugzilla/show_bug.cgi?id=10311 https://sourceware.org/bugzilla/show_bug.cgi?id=10311 > If you use clone() you're on your own. These libraries are the problem, not the solution. They're full of static global data which will get clobbered whenever you do anything more complicated than I/O. They use thread local variables for returning errors codes. It's bad legacy stuff.
  - nanolith 3y ago
    That's a Linux system call, on Linux. We're talking about OpenBSD. The OpenBSD developers aren't likely to design a system call like clone.