Cheri with a Linux on Top
Posted3 months agoActive3 months ago
lwn.netTechstory
calmmixed
Debate
40/100
CheriLinuxSecurityComputer Architecture
Key topics
Cheri
Linux
Security
Computer Architecture
The article discusses CHERI, a capability-based security system integrated with Linux, sparking a discussion on its effectiveness and comparison to other security mechanisms.
Snapshot generated from the HN discussion
Discussion Activity
Moderate engagementFirst comment
32m
Peak period
9
0-12h
Avg / period
3.2
Comment distribution16 data points
Loading chart...
Based on 16 loaded comments
Key moments
- 01Story posted
Oct 6, 2025 at 12:25 AM EDT
3 months ago
Step 01 - 02First comment
Oct 6, 2025 at 12:57 AM EDT
32m after posting
Step 02 - 03Peak activity
9 comments in 0-12h
Hottest window of the conversation
Step 03 - 04Latest activity
Oct 13, 2025 at 4:52 PM EDT
3 months ago
Step 04
Generating AI Summary...
Analyzing up to 500 comments to identify key contributors and discussion patterns
ID: 45487629Type: storyLast synced: 11/20/2025, 1:35:57 PM
Want the full context?
Jump to the original sources
Read the primary article or dive into the live Hacker News thread when you're ready.
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...
https://joeduffyblog.com/2015/11/03/blogging-about-midori/
[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.