zlacker

OpenBSD: Removing syscall(2) from libc and kernel

submitted by eclipt+(OP) on 2023-10-27 15:23:10 | 144 points 118 comments
[view article] [source] [go to bottom]

NOTE: showing posts with links only show all posts
1. brynet+r6[view] [source] 2023-10-27 15:48:51
>>eclipt+(OP)
Follow-up mail from Theo showing what the full removal looks like.

https://marc.info/?l=openbsd-tech&m=169842095809570&w=2

◧◩
6. matheu+lp[view] [source] [discussion] 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

◧◩◪◨
19. kstrau+Js[view] [source] [discussion] 2023-10-27 17:36:47
>>PrimeM+nr
It's a play on a quote often attributed to Winston Churchill: https://quoteinvestigator.com/2012/11/11/exhaust-alternative...
◧◩◪◨⬒
45. aseipp+8B[view] [source] [discussion] 2023-10-27 18:18:30
>>MarekK+Oy
Windows does actually have a universal C runtime library now, but it's pretty recent; only Windows 10+ https://learn.microsoft.com/en-us/cpp/porting/upgrade-your-c...

A big motivation for it was security posture; it means that Microsoft can now ship security updates to UCRT that everyone can rely on rather than a ton of extra surface area through various multiple versions of runtime libraries.

◧◩◪
49. dpasse+ZM[view] [source] [discussion] 2023-10-27 19:21:53
>>marcos+CL
Only on systems where the syscall ABI is stable, like on Linux. Others, like macOS and Windows[0], can and will change theirs between releases. OpenBSD even goes one step further and actively prevents code other than libc from performing syscalls[1]

[0] I seem to remember that this changed in a recent Windows version, but I couldn't immediately find a source.

[1] msyscall(2) or, if you don't have an OpenBSD system at hand, https://man.openbsd.org/msyscall

◧◩◪
52. Legion+KT[view] [source] [discussion] 2023-10-27 19:55:47
>>matheu+lp
> 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...

◧◩◪◨⬒
53. Legion+pV[view] [source] [discussion] 2023-10-27 20:05:00
>>maskli+It
> It is different, uniquely so, on linux: on most unices the kernel and libc are developed as two sides of an entire system, both being updated in lockstep when the system is updated.

Do FreeBSD [0] and NetBSD [1] not fall under "most unices"? They similarly retain backward compatibility in their syscall interface, so that old binaries with old libcs can run on newer kernels. Linux does not stand alone here.

[0] https://wiki.freebsd.org/AddingSyscalls#Backward_compatibily

[1] https://www.netbsd.org/docs/internals/en/chap-processes.html...

56. notapl+dY[view] [source] 2023-10-27 20:21:21
>>eclipt+(OP)
OpenBSD developers are making a serious effort to kill off indirect syscalls, the base system is completely clean, take a look at the work Andrew Fresh did to adapt Perl. He wrote a complete syscall "dispatcher" or emulator for the Perl syscall function so that it calls the libc stubs.

https://github.com/openbsd/src/commit/312e26c80be876012ae979...

The ports tree is being cleansed of syscall(2) usage, until they're all gone.

msyscall, pinsyscall, recent mandatory IBT/BTI, xonly. OpenBSD is making some waves, but people aren't really seeing them yet.

◧◩◪◨
68. treali+0j1[view] [source] [discussion] 2023-10-27 22:16:06
>>KRAKRI+U21
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

◧◩◪◨
81. monoca+6r1[view] [source] [discussion] 2023-10-27 23:19:36
>>saagar+7e1
Every time I've seen a dev team go down that road, it's come with rather unfortunate unintended side effects.

https://devblogs.microsoft.com/oldnewthing/20041215-00/?p=37...

◧◩◪◨
82. matheu+ns1[view] [source] [discussion] 2023-10-27 23:29:15
>>Legion+KT
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.

◧◩◪◨⬒⬓
106. marcus+Fz2[view] [source] [discussion] 2023-10-28 13:22:54
>>MrJohz+ju2
> Wow, that discussion does not warm me at all to OpenBSD. A lot of those responses seemed way more abrasive than they needed to be.

It's pretty much on-brand for them. The OpenBSD project started when the founder was kicked off of the NetBSD core team, allegedly for being rude and abrasive to users. At one point, both the FreeBSD[0] and NetBSD[1] mailing lists blocked traffic from this individual because they claimed he threatened to aggressively spam their mailing lists.

0 - https://mail-archive.freebsd.org/cgi/getmsg.cgi?fetch=56044+... 1 - http://mail-index.netbsd.org/current-users/1996/10/20/0004.h...

◧◩◪◨⬒⬓⬔⧯
116. marcus+iv5[view] [source] [discussion] 2023-10-29 17:39:49
>>Louisv+O94
From three years ago, when Theo would have been in his early fifties: https://marc.info/?l=openbsd-misc&m=157819616927844&w=2
[go to top]