In regards to bounds checking, that has been solved in Solaris since ADI was introduced in 2015.

https://docs.oracle.com/en/operating-systems/solaris/oracle-...

I think what the parent means is we should be able to create syscall sandboxes within the same process (like a library not being able to do IO). Maybe I'm wrong but I think this could sort of be implemented with CHERI, by restricting syscalls to the official libc entry points (like OpenBSD) and requiring a capability pointer to access the functions.

.NET Framework tried that with their whole "security" system, but it was a massive failure.

The only fool-proof solution is separate address spaces and OS cooperation.

Are you referring to Midori?

I've only ever seen three reasons for Midori to shutdown:

1) they were hitting C# limitations (and started working on custom compilers etc) (and people involved in Midori say Rust has already shipped things they failed to do)

2) there was a bit too much academic overeagerness, e.g. software transactional memory will kill any project that attempts it

3) basically getting their budget taken away

https://www.zdnet.com/article/whatever-happened-to-microsoft...

https://joeduffyblog.com/2015/11/03/blogging-about-midori/

Midori is certainly an interesting project, but no; I meant the old "code access security" model that .NET Framework had.[0][1] Administrators (and other code) could restrict you from doing certain operations, and the runtime would enforce it. It was removed in .NET Core.[2]

[0]: https://learn.microsoft.com/en-us/previous-versions/dotnet/f...

[1]: https://learn.microsoft.com/en-us/dotnet/api/system.security...

[2]: https://learn.microsoft.com/en-us/dotnet/core/compatibility/...

Okay, that looks really funky. Like, libraries explicitly state what access they have ambient authority to use, and then callers can be constrained by an access control list, or something like that. Really weird design.

I'd love to see someone put genuine thought into what it would take to say that e.g. a Rust crate has no ambient authority. No unsafe, applied transitively. For example, no calling std::fs::open, must pass in a "filesystem abstraction" for that to work.

I think the end of that road could be a way to have libraries that can only affect the outside world by values you pass in (=capabilities), busy looping, deadlocking, or running out of memory (and no_std might be a mechanism to force explicit use of an allocator, too).

(Whether that work is worth doing in a world with WASM+WASI is a different question.)

Language safety helps get you 80% of the way there, but you are still working from software on top of fundametally unsafe hardware. Companies and agencies are and, increasingly, will pour money into hardware that give certain safety and security guarantees.