6 comments

[ 2.6 ms ] story [ 20.2 ms ] thread
“The Capability Hardware Enhanced RISC Instructions (CHERI) project is a rethinking of computer architecture in order to improve system security.”
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.

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.
Are the specs finalized? Otherwise it will be difficult; heck, we don't even have RVA23 CPUs yet!

But I agree with you. A modern, open hardware platform with built-in hardware security would be a dream come true.

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.

No, CHERI is about not being able to forge pointers with e.g. C buffer overflows.