This defense technique is both simple (in terms of relative change from how things work today) and effective in that buffer overflows can’t ever call into the kernel but now instead have to go through libc which has had its location randomized on the application launch.

To provide this protection at the syscall layer would require some kind of randomization of how a syscall is performed which is something that has no prior art since that’s just pushing arguments into the stack and triggering an interrupt through a single instruction meaning complexity of the work is unknown in terms of how to secure a buffer overflow from being able to do that (ie harden an arbitrary process to not be able to directly jump into a syscall). Additionally because there’s no prior art the scope of that kind of change wouldn’t have the benefit of having well-understood behavior. Not impossible or prohibitive but raises the bar for the benefit you’d have to provide (& probably get a chip manufacturer and compiler vendors to go along with you). Also even if you could 3rd party binaries wouldn’t gain that protection magically. Putting this in libc is fantastic. Arguably Linux’s decision to treat libc as an external unrelated project and keep ABI comparability at the syscall layer prevents a protection mechanism like this.

That's how security theater for software works. Today's attackers are well-funded and technically competent. This is a a defense against script kiddies.

The way to get rid of buffer overflows is to get rid of C in trusted code, not requiring users to go through libc. It isn't hard any more. We have Go, Rust, C#, Java, and even node.js and Python for server side. If you're running C in a user-facing server application, you're doing it wrong.

The problem is buffer overflows. Fix that, and you don't need ASLR. ASLR is a form of security theater. It protects against dumb attackers.

[1] https://threatpost.com/bypassing-aslr-in-60-milliseconds/121...

On x86 clones Intel just dropped the buggy MPX, with no replacement in sight.

And by the way things are going, any form of Safe C variant, doesn't appear to ever be adopted by UNIX clones.

Let's ignore that only recently have languages become available that make it possible to do so for high-performance code. That's a straightforward problem to solve - we know how to rewrite code in other languages, we can build tools to help us do it effectively, etc.

Let's also ignore that the recency of the languages mean that few people know how to code that effectively. We can train armies of engineers.

Let's ignore that training engineers takes significant amounts of time & shifting massive industries is difficult. That will be solved over time.

Lets ignore that Rust is more difficult to write than C/C++ - after all we're just converting existing code so that could be easier & the more time spent during writing is paid off by less time debugging at runtime.

Let's also ignore that A LOT of money has been poured into existing software and a non-trivial amount would have to be donated/volunteered to migrate to languages where it's impossible. We have OSS volunteers and enthusiasts and corporate interests are aligned to sponsor conversions.

Let's ignore that it takes time to integrate new languages into large corporations with existing build systems, infrastructure, tooling, etc. They'll solve that - again, interests are aligned here.

Let's ignore ALL of those issues. XSS, Rowhammer, Meltdown, Specter, downgrade attacks, man-in-the-middle, spear phishing, bugs in cryptographic algorithm design, side-channel attacks, etc are all still security attacks that have very real, and perhaps sometimes more serious, consequences than buffer overflows and waving a magic wand and fixing all buffer overflows wouldn't really adjust the security landscape we deal with today (maybe exploits would get more expensive - maybe, but ASLR et all do that too).

Following the same logic you laid out, this focus on buffer overflows at all is just security theater: ASLR is to buffer overflows what buffer overflows is to all security bugs overall. Back in reality ASLR, syscall origin verification, etc are all tools to try to mitigate the impact of all the things we ignored above & we know they have an impact because exploits keep getting more expensive, the low-hanging fruit bugs always get patched quickly, etc.

So sure, once the world has switched to Rust and we can turn off all these other protections that make buffer overflows more difficult. Oh, except we can't because now we remember that Rust has "unsafe" & that's used A LOT for various reasons. So now you need those protections anyway in case there's a bug in the unsafe code. And I 100% promise you there will be exploits there or in the Rust compiler. We can have confidence this will be the case because it's already happened: https://medium.com/@shnatsel/how-rusts-standard-library-was-..., https://blog.rust-lang.org/2019/11/01/nll-hard-errors.html). So your claim that we know how to fix buffer overflows is just inane even on its face. Hell, this isn't even a Rust-specific thing. I would be very skeptical if you could find a single semi-popular language without a buffer overflow bug of some kind somewhere, even in managed languages. The Java VM is full of them. Go has them. etc.

TLDR: You may want to reexamine your arrogance. Security is an extremely hard topic that will never get solved. Are there shitty programmers? Sure. Are security problems exclusively written by them? No. Security issues are an emergent property of complex systems. Some are easy to solve once and for all once the root cause is known. Others are MUCH harder.

Just half trolling.

An OS that happens to expose some support for POSIX, yeah (e.g. Redox), but anything else wouldn't be an UNIX clone per se.

Modern software is sidestepping the UNIX way left and right. Rightly so, as anyone who's tried to write anything serious in shell would know. Or anyone who realizes that non-blocking I/O was an afterthought (look into the history of select(2) and why libraries like libev exist and what problems they run into on unix derivatives..) and that there's still nothing like a standard, robust, well designed async I/O API.

History would be quite different if AT&T was allowed to sell it from day one.

(Oh, double checked, and uh, maybe. ld.so does treat libc specially if it finds it in the library list, but at that point, you are linking with libc. But afaik there's no requirement you use the system ld.so either.)

They are designed as a protection against stuff like ROP and other memory based, zero information attacks that hit already running processes.

This doesn’t make sense, though. This would mean the OS would need to know the control flow of the program itself to figure out whether it “should” allow a system call to proceed.