Comment by __turbobrew__
2 years ago
It looks like golang is going to have to deal with — again — OpenBSD treating libc as the interface with the kernel instead of syscalls being the interface with the kernel.
I wonder if there could be some way to sign a dynamic library to allow it to create direct system calls and then pass that as a kernel command line argument at boot?
OpenBSD is certainly taking it quite far. They want to disallow system calls from all non-libc code segments so that only whitelisted code can interface with it.
It is not the only operating system in the "unstable kernel interface" group though. Linux is actually the only one with a stable system call interface.
I've written somewhat at length about this:
https://www.matheusmoreira.com/articles/linux-system-calls
> It is not the only operating system in the "unstable kernel interface" group though. Linux is actually the only one with a stable system call interface.
It's wrong to say that Linux stands alone in having a stable syscall interface. FreeBSD [0] and NetBSD [1] both retain syscall compatibility for old binaries (the former apparently with some exceptions permitted); DragonFly BSD also appears to keep old syscalls in place. In fact, I only know of Windows, OpenBSD, and presumably macOS as mainstream desktop OSes without mostly-stable syscalls.
[0] https://wiki.freebsd.org/AddingSyscalls#Backward_compatibily
[1] https://www.netbsd.org/docs/internals/en/chap-processes.html...
When I wrote the article I searched the web for the kernel-userspace ABI situation in the BSDs. I found posts that contradict that.
https://forums.freebsd.org/threads/what-is-meant-by-abi.8622...
> I keep reading that the ABI of FreeBSD is constantly changing.
> Someone's system has random crashes and someone else says it's that pesky ABI changing again.
It seems FreeBSD has a reputation of changing binary interfaces. Even when they clarified that they meant the kernel-userspace interface, it was pointed out they're only stable for current releases. There seems to be some emulation but I can't figure out how hard of a guarantee that is.
https://docs.freebsd.org/en/books/handbook/kernelconfig/#ker...
> If the kernel version differs from the one that the system utilities have been built with
> for example, a kernel built from -CURRENT sources is installed on a -RELEASE system
> many system status commands like ps(1) and vmstat(8) will not work.
> To fix this, recompile and install a world built with the same version of the source tree as the kernel.
> It is never a good idea to use a different version of the kernel than the rest of the operating system.
How could the ABI be stable if you have to recompile user space when you update the kernel? Linux is said to be able to run binaries from the 90s.
https://old.reddit.com/r/BSD/comments/8vysxg/a_question_abou...
> FreeBSD breaks syscall ABI compatibility with some regularity.
> Like Windows and unlike Linux, the compatibility layer is considered to be libc, rather than the syscall interface.
FWIW your website is unusable on desktop: the font is unreadably huge. And while Firefox's reader mode does seem to mitigate the issue correctly, Safari's cuts off at the second paragraph.
Thank you. I'll try to fix it. I gotta get better at this.
I reduced the font size to 24px. Does it read better despite the margins?
I appreciate the feedback. My intention was to maximize the use of space with big fonts even on the desktop but there's no point if the resulting text is unreadable.
1 reply →
We need more fat kernels and less libcs, libc ties us forcibly to the C legacy. Time for more type safe and richer interfaces with the kernel.
What do you mean when you say "fat kernel"?
Also, FYI, OpenBSD is never going to stop being written in C, and is never going to introduce a language like Rust into the kernel [1], so there's little point in wishing for this.
If you wish to rid yourself of legacy of C (and therefore that of Unix), then OpenBSD, which is Unix (or derived from it) and will always be written in C, is not a good operating system for you.
Edit: Changed to be less rude; it wasn't my intention to be rude.
[1]: https://marc.info/?t=151233221700001&r=1&w=2
10 replies →
A kernel is not a programming languages. Type safety is something enforced by a compiler or interpreter, while accessing a system call interface is always something that can be expressed in terms of a sequence of assembly language instructions. Doesn't matter whether you're accessing a C API or a syscall mechanism.
Forcing usage of libc is actually an effort towards type safety. `syscall` just takes a syscall number and an unspecified amount of arguments of unconstrained type. It's the opposite of being type safe.
2 replies →
[dead]
> It looks like golang is going to have to deal with — again — OpenBSD treating libc as the interface with the kernel instead of syscalls being the interface with the kernel.
Something they wouldn't have to do if they'd heeded the warnings they got since they first started going raw syscalls on non linux systems.
But as usual, go is uniquely american, only doing the right thing after it has tried everything else.
You could also describe it as doing the sane thing (avoiding hardcoding against the libc ABI through FFI) until the only sane option is removed. Did you know many libc APIs are preprocessor macros?
> You could also describe it as doing the sane thing (avoiding hardcoding against the libc ABI through FFI)
No, you could not.
On pretty much every system but linux the libc (or equivalent) is the officially supported API to the kernel. Bypassing it is not supported and thus definitionally can not be sane, that's like declaring that doing the sane thing is avoiding hardcoding against the front door and entering your home through the roof instead. The front door is what you're supposed to use, do hardcode against it. Same with libc.
And Go has been going "ouch" then putting its fingers straight back in the socket from the start, as it keeps trying to work around libcs on all the platform where it is not supported.
5 replies →
> go is uniquely american, doing the right thing after it has tried everything else.
That doesn't seem like anything common to an American way of doing things. What an odd statement.
It's a play on a quote often attributed to Winston Churchill: https://quoteinvestigator.com/2012/11/11/exhaust-alternative...
2 replies →
I don't use Go, but I had the exact same reaction; C is the source of most of the problems and this is just codifies the use of C. The whole thing has a security by obscurity smell.
Your comment seems to conflate a language with an ABI. To what end? What is inherently insecure about the C ABI? Why is using a syscall interface any more secure?
3 replies →
> go is uniquely american, only doing the right thing after it has tried everything else.
Perhaps this is why most innovations are American. We don't automatically fall for the bully pulpit of the gnostic class.
> Something they wouldn't have to do
Yea, but they'll get it done anyways, and the language will continue to be excellent. I'm sure Google can absorb the engineering challenge without subtracting anything from us or other languages.
> OpenBSD treating libc as the interface with the kernel instead of syscalls being the interface with the kernel
Which is a reasonable thing, given that the libc interface is defined by a widely used IEEE standard while the kernel interface is not.
libC is an extremely leaky abstraction. Programming to it assumes you have a runtime that supports constructor functions, POSIX errno and locale, a global heap allocator singleton, and more. The design space of _Hello World_ is massively constrained by libC.
OpenBSD’s position is far from unique. It’s shared with MacOS (and iOS).
And windows.
And that's just the platforms which technically enforce it. Linux is essentially the only platform which actually supports raw syscalls, in the sense that it's considered a normal system API.
And Windows, in a sense: not that libc is the interface, but that the assembly-level API is not the interface.
And almost every other OS still in use today, what Linux does is reminiscent from OSes like CP/M and MS-DOS.
1 reply →
> I wonder if there could be some way to sign a dynamic library to allow it to create direct system calls and then pass that as a kernel command line argument at boot?
That sounds like an additional knob to tweak. The OpenBSD project is famously opposed to such knobs.
I am sure Cosmopolitan is going to love this change.
I would assume they already have ways to bounce through a dynamically linked system library since cosmopolitan works on macos, and even more so windows.
That's true, but it's a point of pride in Cosmo's marketing that it produces statically linked binaries acroscreate, least several operating systems.
It can dynamically link the system32 DLLs in Windows and probably could OpenBSD's crt, but dynamic linking in general doesn't work. `dlopen` is no-op, and this has made Cosmo graphics extremely difficult so far.
2 replies →
What about OSes that are not built around monolithic kernels and the syscall() paradigm?
[dead]