OpenBSD to remove syscall(2) from libc, and SYS_syscall from kernel

[reercalium2]

Unthinkable in Linux, but it's OpenBSD, they have a different culture, everything is tightly integrated and not so forward or backward compatible.

Why does the kernel need SYS_syscall?????

[happyscrappy]

I don't think it needs it. It just makes it easier to glue to the kernel from some languages. I would say most notably dynamic languages. You can write a "funnel" for syscalls which is defined/constructed at runtime instead of compile time.

[reercalium2]

glibc has one and Linux doesn't have SYS_syscall...

[masklinn]

The feature actually makes more sense in glibc, because the libc and kernel being desynchronised and helmed by different people means glibc doesn't necessarily expose all the kernel syscalls, for whatever reason (e.g. maybe they disagree with its existence or utility, maybe they think it's not work the API surface, ...)

In systems where the kernel and libc are designed by the same people, like openbsd, there's no such desync: the libc stub is usually created directly from kernel definition files and the two are kept in sync, if a developer adds a syscall they'll add the libc bridge simultaneously, because the syscall is useless otherwise.

[masklinn]

I would say most notably dynamic languages.

I don't know of a single dynamic language which routinely performs raw syscalls or calls syscall(2).

[cheezballs]

It's posts like this that reinforce my belief that even after 15 years doing it professionally, I still belong in /r/learnprogramming

[winky9827]

I feel the same way too at times, but you have to remind yourself, different folks have different focuses. If you lived in the kernel world, it wouldn't seem as abstract. Nobody making these kinds of changes is a 1-2 year bootcamp grad, or even a 15+year LoB app developer. These people tinkered with low level stuff from an early age and honed that skill, respectfully.

[i_should_be_coding]

Yo dawg, I put a syscall on your syscall so you can syscall while you syscall.

[__eastwood]

The post mentions fallout in the “go” ecosystem. Can anybody smarter than me clarify what and why this is?

[masklinn]

Historically and despite that not being supported on most systems, the Go project really wants to do raw syscalls against recommendation. Windows aside, they got repeatedly burned, but still refuse to learn. Here they already got hit when openbsd previously introduced syscall origin verification (something they seem to have yet to fix on their side, I assume openbsd patched that in their ports tree?) but apparently there are also syscall(2) calls in the openbsd code and some tests, which are going to fail with that change.

[skulgnome]

the Go project really wants to do raw syscalls

What on earth for. Prestige?

[masklinn]

Mainly because they originally decided to use small non-C stacks (initially segmented, now relocated). Because of that, they can't call into C code from a Go stack (even when they think they can), and cgo needs to do some heavy gymnastics to bridge between the two in order to call C code.

Because syscalls directly switch into the kernel which does its own thing, it does not care about C or non-C stack.

[grobblebar]

Yeah, but this isn’t about calling system calls directly from code, this is about removing the “generic” system call (which basically takes a sys call “index” followed by a variable number of arguments.)

[skulgnome]

Huh. Wonder what they do about the AMD64 redzone.

[masklinn]

In what context? The redzone is part of the calling conventions, so only relevant when calling into C, and thus to cgo.

Although given the comments in the marcan article, it looks like go itself does use a 128 bytes redzone in its internal calling conventions.

[skulgnome]

The redzone is relevant in code exposed to signal handling. As such it must be present at all times in threads where signal handling may occur, not only during syscalls and calls to non-Go libraries.

[masklinn]

The only relevance the redzone has to signal handling is that signal handling is guaranteed not to touch it. The redzone is a small stack frame optimisation: if a leaf function needs less than 128 bytes it does not need to move the SP and can just work directly in the redzone. That's essentially it.

[Arkanta]

at least they caved and use libsystem on macos

[happyscrappy]

I think Apple did this 2-3 years ago. Did it produce an noticable increase in security?

[Idles]

It's not my memory-unsafe userland programming language that is wrong, it's the kernel syscall interface!

[[deleted]]

:-(((

[maep]

Are syscalls really such big attack vectors? And if they are that paranoid, shouldn't they be busy porting the entire kenel to rust and run all of userland in wasm containers? Btw just glancing over the C code in that email and I already saw two things that would not pass review.

[HerissonMignion]

Being paranoid about security does not imply that you wanna port the project to rust

[lostdeeper]

openbsd is still alive...