Comment by monocasa
2 years ago
OpenBSD has been putting in a lot of work lately to harden the syscall ABI; a large component of that work has been constricting how a syscall is invoked from user space as a defense in depth technique to make shell code style exploits more difficult. That's previously taken the form of techniques like only allowing syscalls to be invoked from the libc .text section.
This work is removing a very indirect morph of syscall where the arguments/sysnum are in a struct in memory, making it harder for exploits to invoke weird versions of syscalls on their own terms.
But aren't shellcode style exploits already fairly rare with W^X, so most end up using return-to-libc style attacks? Wouldn't CFI be a much better solution?
It's defense in depth. Removing a function like syscall(2) that's a "whatever syscall you want" function that is ostensibly white listed works very well when combined with CFI, and strengthens security of systems without hardware support for CFI.
OpenBSD users mostly don’t use systems with strong hardware CFI, so they make do with stuff like this.
Why aren't these changes made in kernel to keep the syscall ABI standardized and safe instead of requiring the use of an unsafe language wrapper? We should be discouraging more use of unsafe languages, not forcing it.
Then don't run a OS with a kernel written in C. That would rule out Windows, Mac, Linux and *BSD.
Using syscalls means you can replace the kernel. Using libc means you are locked into and FFI/C calling convention for anything other than C. Apples/Oranges.
1 reply →
The C ABI doesn't necessarily force you to use C. Maybe to turn some pesky macros into proper functions. Bury the bindings deep in the language's stdlib. Done.
Under the hood, it's all assembly language instructions invoking an operating system written in C. Operating systems care very much about types, but can't offer type safety. Programming languages can.