Its the higher-level, logical capabilities like 'can perform this kind of access to this specific file for the duration of this call' that are much more interesting.
Lots of modern operating systems do have some kind of capability system - even the intents in modern mobile phones are a capability system - but it's something you could imagine benefitting from machine support e.g. passing securely capabilities in syscalls in a microkernal and to peers in IPC.
And then, out of bound memory access may be better solved with better programming languages, thought of course we need to live with the legacy code.
The only fool-proof solution is separate address spaces and OS cooperation.
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...
[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/...
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.)
https://docs.oracle.com/en/operating-systems/solaris/oracle-...
The Fil-C project (discussed in [0],[1]) has ported many programs to an emulated CHERI-like capability runtime, and shown that capabilities aren't actually that breaking in practice [0].
Another way of using CHERI would be in "Hybrid mode" with most of a program under a single capability, and using other capabilities for compartmentalisation. In a system where you have only memory-safe languages, you'd still sometimes need to run older code from other languages, or code from external sources: and you can't always validate them 100%. A couple operating system projects based on Rust (such as Theseus [1]) solve this by running them in WASM instances. A CHERI capability would be fast hardware-support for bounds-checking access to such a compartment.
Also, there is the problem of fast inter-process communication: Copying bytes vs. modifying PTEs — each method with different trade-offs. With CHERI, you could potentially instead pass capabilities, and even share them by writing them in shared memory without involving the kernel.
0: https://fil-c.org/programs_that_work
1: https://www.theseus-os.com/2021/11/01/October-Update-WASM.ht...
One interesting angle for legacy code is used in Firefox. An image decoding library written in C couldn't be trusted, so it was built for WASM and then AoT translated to machine code. It's effectively in a WASM sandbox, without a full WASM runtime.
But, frankly, I'm on team full speed ahead with memory safe languages. It's not just "safer", the developer experience with Rust is so much better than C/C++.
But I agree with you. A modern, open hardware platform with built-in hardware security would be a dream come true.
But I wish they would have chosen pledge(2)/unveil(2) from OpenBSD instead. Added that to your programs is so easy even I can do it.
I know that someone in Linux tried to add that to Linux. But IIRC it was in user space and harder to use. I think pledge/unveil really should be in the Linux kernel.
learningmore•4mo ago