CHERI plus/versus Rust

Posted Oct 6, 2025 11:06 UTC (Mon) by erithax (guest, #179705)
Parent article: CHERI with a Linux on top

Does CHERI provide additional memory safety even to Rust programs?

> ""what role do you see CHERI playing in an environment where a majority, even a vast majority, of all C code has been replaced with Rust?"" Shaw said that he wonders how successful TRACTOR will be, given that AI techniques may fall short of being able to reliably translate C for all of the different programs needed. Meanwhile, though, he does not see CHERI and Rust as being in conflict at all; the two can work together and it is something the project is putting effort into. ""There will be a CHERI Rust compiler.""

This answer does not clear up much. My guess is it would only improve the safety of `unsafe` Rust, like running in Miri does, but with much less performance degradation than Miri, enabling its use in production. While that is a nice safety improvement, we should then weigh whatever performance penalty CHERI has against the small amount of unsafe operations that it protects.

> While memory safety is definitely important, the compartmentalization afforded by CHERI is more interesting to him. ""Being able to get least privilege in software is a real big step forward, I think."" None of the current languages attack that problem, he said, so it would take ""a further evolution of language in order to support this whole concept nicely"".

I would agree that the non-memory-safety aspects of capability-based security are as important. However, although language support for capabilities should definitely improve, just about every language contains the groundworks of capabilities through encapsulated objects and parameter passing. Additionally, language support is not required for stronger use of capabilities in an OS: see Redox OS.

Also, unlike CHERI, Rust can afford memory safety on all existing hardware, awaiting rustc_codegen_gcc support for exotic platforms, which, mind you, probably won't support CHERI.
Lastly, I think there's a reason that patching fluid software to fix mistakes in fixed hardware is the norm, and not the other way around. What does CHERI address that could not be fixed in software?

CHERI plus/versus Rust

Posted Oct 6, 2025 19:28 UTC (Mon) by tialaramex (subscriber, #21167) [Link]

One nice property of Rust for CHERI is that Rust provides explicit provenance APIs. So you can see OK, what's going on (unsafely) here is legal and ought to still work under CHERI or, contrariwise, nope this is not even supposed to work so we need to expect that these parts must be rewritten or we can't target CHERI with this software.

All the safe Rust of course is in the first category, but also isn't reaping much benefit from CHERI.

core::ptr::without_provenance(addr) and core::ptr::with_exposed_provenance(addr) are largely text, one of them says we offer no justification for why this can be a pointer (maybe it isn't, if we never dereference it then it's fine even in CHERI AFAIU) the other offers the justification of exposure, a feature CHERI does not support, so it's effectively documenting why it won't work with CHERI.

On the other hand some_pointer.with_addr(addr) promises to work under CHERI because we're saying if we keep the CHERI capability bits from some_pointer, but use the address addr instead of the address from some_pointer that's also a valid pointer. On my x86-64 there are no capability bits, but on CHERI there are and on both this works _if_ it would be correct to do this, MIRI can check it, and CHERI can use it.