zlacker

[return to "OpenBSD: Removing syscall(2) from libc and kernel"]
1. __turb+3l[view] [source] 2023-10-27 17:00:14
>>eclipt+(OP)
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?

◧◩
2. matheu+lp[view] [source] 2023-10-27 17:21:34
>>__turb+3l
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

◧◩◪
3. KRAKRI+U21[view] [source] 2023-10-27 20:47:50
>>matheu+lp
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.
◧◩◪◨
4. samus+C52[view] [source] 2023-10-28 06:48:29
>>KRAKRI+U21
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.

◧◩◪◨⬒
5. IshKeb+Ta2[view] [source] 2023-10-28 07:58:42
>>samus+C52
It does matter. You don't have to link with the kernel, or support the C ABI. You're still tied to C with libc. It's especially bad on Linux because glibc is so awful.

Forcing libc has absolutely nothing to do with type safety. How do you think they invoke syscalls in libc? There's no more type checking of syscalls there than there is in Go's standard library. From a user's point of view it's identical, except you don't have to worry about endless glibc version errors with Go.

◧◩◪◨⬒⬓
6. samus+EL3[view] [source] 2023-10-28 22:51:31
>>IshKeb+Ta2
Glibc and the situation on Linux is not involved at all here; we're talking about OpenBSD that takes invoking system calls via libc very seriously.

The libc can enforce some minimal sanity checks on the syscall arguments. For example the number of arguments and some early validation to avoid entering the kernel if failure can be foreseen. But the main utility is to make it more difficult to use Return Oriented Programming to build exploits.

[go to top]