LWN: Comments on "CHERI with a Linux on top"

Capability-Based Computer Systems

chmaynard — Thu, 25 Sep 2025 06:30:37 +0000

During the mid-1980s, I was looking for technical information about the IBM System/38 and ran across the book "Capability-Based Computer Systems" by Henry M. Levy, published by Digital Press.

From the Amazon.com summary:

"The book describes early descriptor architectures and explains the Burroughs B5000, Rice University Computer, and Basic Language Machine. The text also focuses on early capability architectures. Dennis and Van Horn's Supervisor; CAL-TSS System; MIT PDP-1 Timesharing System; and Chicago Magic Number Machine are discussed. The book then describes Plessey System 250, Cambridge CAP Computer, and Hydra System. The selection also discusses STAROS System and IBM System/38 ... The book highlights Intel iAPX 432, and then considers segment and objects, program execution, storage resources, and abstraction support."

Spectre mitigation overhead

wahern — Wed, 24 Sep 2025 23:02:38 +0000

> Are CHERI capabilities able to provide SPECTRE-resistant isolation between mutually distrustful privilege domains within a single address space?

Intrinsically, AFAIU, no. But hardware CHERI support, by requiring both bounds and (to varying extents) provenance information to accompany addresses, potentially makes it easier and more natural to avoid side-channels. And maybe more importantly, CHERI provides an opportunity to nail down ISA guarantees before widespread deployment. See Safe Speculation for CHERI, https://www.cl.cam.ac.uk/research/security/ctsrd/pdfs/202...

Capability Revocation and Indirection

wahern — Wed, 24 Sep 2025 22:49:16 +0000

While CHERI avoids indirection when using a capability/pointer, a consequence is that capability revocation (e.g. free(3)) requires sweeping the process address space to invalidate capabilities. In the simplest implementation it's stop-the-world during a linear word-by-word sweep of the address space. There have been several optimizations explored, including schemes to avoid reading memory unnecessarily by skipping words without the out-of-band capability tag bit, concurrent sweeping by leveraging page tables or memory coloring, etc. I think the latest upstreamed to CheriBSD is Cornucopia Reloaded[1]--during the pendency of a concurrent background sweep, a CoW-like scheme temporarily traps all reads to sweep specific pages on demand, permitting forward progress before the concurrent sweep completes.

CHERI is great for spatial safety, but the cost of avoiding indirection means temporal safety requires more work. Perhaps the next evolution will be exploring how linear or affine typing in application languages such as Rust could be leveraged to minimize the sweeping work, e.g. by automatically clearing capabilities as they're copied through the application from malloc through free. Or evolving allocation APIs and page table permission schemes so memory that doesn't need to store a capability/pointer can be skipped from sweeping entirely.

[1] https://www.cl.cam.ac.uk/research/security/ctsrd/pdfs/202...

Spectre mitigation overhead

notriddle — Wed, 24 Sep 2025 22:32:42 +0000

> the compartmentalization afforded by CHERI is more interesting to him

Rust treats speculative execution as completely out of scope. That, as far as I'm concerned, is its biggest weakness and the main reason you still need hardware isolation.

A quick Google drops me onto at least one paper <https://www.cl.cam.ac.uk/research/security/ctsrd/pdfs/202...> that claims to address speculative execution in CHERI, but I don't know if that's been incorporated into real cores, if it's long obsoleted by more recent innovation, or if I'm completely barking up the wrong tree.

Are CHERI capabilities able to provide SPECTRE-resistant isolation between mutually distrustful privilege domains within a single address space?