I think the memory safety aspects of capabilities kind of missed the boat (often intrusive and breaking for memory unsafe languages whilst superfluous in practice for memory safe languages). The memory safety stuff is better dealt with by lots of small programs that don't share memory.
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.
> often intrusive and breaking for memory unsafe languages whilst superfluous in practice for memory safe languages
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.
For capabilities, a special instruction only makes sense in the context of CPU memory access and this is all about out of bounds C bugs. OS capabilities do not need new instructions.
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.
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.
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.
I think that any design firm that works on a RISC-V server CPU should seriously consider integrating CHERI support.
If only because it could be a selling point, potentially making RISC-V more competitive in the server market place.
Curious if this is similar to capabilities FreeBSD has had for ages ?
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.
I think the memory safety aspects of capabilities kind of missed the boat (often intrusive and breaking for memory unsafe languages whilst superfluous in practice for memory safe languages). The memory safety stuff is better dealt with by lots of small programs that don't share memory.
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.
> often intrusive and breaking for memory unsafe languages whilst superfluous in practice for memory safe languages
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...
For capabilities, a special instruction only makes sense in the context of CPU memory access and this is all about out of bounds C bugs. OS capabilities do not need new instructions.
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.
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.
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-...
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.
I think that any design firm that works on a RISC-V server CPU should seriously consider integrating CHERI support. If only because it could be a selling point, potentially making RISC-V more competitive in the server market place.
Curious if this is similar to capabilities FreeBSD has had for ages ?
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.
“The Capability Hardware Enhanced RISC Instructions (CHERI) project is a rethinking of computer architecture in order to improve system security.”