5 ms·

Honestly, I think that making libc THE system interface is a mistake. Ok, I understand issues with the Linux approach of exposing raw syscalls (though it works

Honestly, I think that making libc THE system interface is a mistake. Ok, I understand issues with the Linux approach of exposing raw syscalls (though it works well enough in practice and ossification could be amended by some kind of syscall versioning scheme), but why in the world can't you introduce libsystem/libsyscall/libopenbsd which would contain only "syscall" functions? Why do you need all the C junk in a library for talking with OS?

resuresu 3y ago
[dead]
tedunangst 3y ago
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.
pjmlp 3y ago
UNIX is the C language runtime, so to speak, so naturally libc is THE system interface. It only became something else, when C got standardised, a tiny subset of it landed into ISO C, grew beyond UNIX, and the rest of the UNIX API surface landed at Open Group's POSIX. Obviously on the UNIX world nothing changed, until GNU/Linux came into scene and decided to act in another way, due to being GNU ecosystem + Linux kernel combo.
- newpavlov 3y ago
  I do not dispute that it made sense during early days of UNIX. But today we write system software for these operating systems in many languages other than C. Maybe it's time to reconsider the dominant libc position instead of reinforcing it further? Linux has successfully paved the way and demonstrated its practicality. Yes, it made certain unfortunate mistakes along the way, but OpenBSD (or any other OS) can learn from those and provide a better solution.
  - pjmlp 3y ago
    Every other operating system does exactly the same in regardless to abstracting syscalls, regardless of being UNIX clone or not, GNU/Linux is the exception, not the rule. If you mean a C based OS ABI, there are many other alternatives, like on managed OSes, IBM and Unisys surviving mainframe and micro computers, OS IPC like COM/XPC/AIDL/FIDL/D-BUS.
- lproven 3y ago
  > UNIX is the C language runtime, so to speak That is one _heck_ of a TL;DR executive summary! I am quietly awed. I doff my hat to you for this.
ByQuyzzy 3y ago
Do you know what Unix is or the C programming language? Your bafflement is entirely baffling. OpenBSD is never switching to Rust or Go or any of the new fad languages, so why not use libc? It’s the Unix way after all.

resuresu 3y ago

[dead]

tedunangst 3y ago

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.

pjmlp 3y ago

UNIX is the C language runtime, so to speak, so naturally libc is THE system interface. It only became something else, when C got standardised, a tiny subset of it landed into ISO C, grew beyond UNIX, and the rest of the UNIX API surface landed at Open Group's POSIX. Obviously on the UNIX world nothing changed, until GNU/Linux came into scene and decided to act in another way, due to being GNU ecosystem + Linux kernel combo.

newpavlov 3y ago
I do not dispute that it made sense during early days of UNIX. But today we write system software for these operating systems in many languages other than C. Maybe it's time to reconsider the dominant libc position instead of reinforcing it further? Linux has successfully paved the way and demonstrated its practicality. Yes, it made certain unfortunate mistakes along the way, but OpenBSD (or any other OS) can learn from those and provide a better solution.
- pjmlp 3y ago
  Every other operating system does exactly the same in regardless to abstracting syscalls, regardless of being UNIX clone or not, GNU/Linux is the exception, not the rule. If you mean a C based OS ABI, there are many other alternatives, like on managed OSes, IBM and Unisys surviving mainframe and micro computers, OS IPC like COM/XPC/AIDL/FIDL/D-BUS.
lproven 3y ago
> UNIX is the C language runtime, so to speak That is one _heck_ of a TL;DR executive summary! I am quietly awed. I doff my hat to you for this.

ByQuyzzy 3y ago

Do you know what Unix is or the C programming language? Your bafflement is entirely baffling. OpenBSD is never switching to Rust or Go or any of the new fad languages, so why not use libc? It’s the Unix way after all.