zlacker

My reading of that linked article on CHERI is two things. First that software needs to adopt the instructions in order to use it. It then raises a question of what is the benefit. What is the experience compared to today, and it should be that embedded software can gain some of the features that are generally reserved for user space. That’s virtual memory protection.

The experience then I would guess is that software will crash rather than, for example, read bad data from the wrong address space. A feature user space apps get from virtual memory (if it’s outside their processes memory space that is).

Did I get this right? Also, it should help Rust just as much, especially in unsafe code regions.

>>blueje+(OP)
Software doesn't need to "adopt the instructions", it just needs to be recompiled in the same way as you compile it for a new architecture (CHERI is effectively like the 32-to-64-bit transition in that sense). Yes, having capabilities allows you to bring memory protection to the MMU-less embedded space (see for example the now somewhat old paper https://www.cl.cam.ac.uk/research/security/ctsrd/pdfs/201810...).

Yes, if you attempt to access outside the bounds of a capability you will deterministically crash. This is true even if you do have virtual memory and there is memory there.

Yes, the use of CHERI to protect unsafe code in memory-safe languages like Rust is of interest to us. There is also the possibility of being able to remove some of the compiler-generated bounds checks by using the capability bounds instead, though some care is needed to preserve the precise semantics (but some may also be happy to slightly change the semantics if it means they can all be removed and potentially improve performance).

>>jrtc27+w2
Thank you for clarifying that.

Are there estimates on the performance improvement people can expect with the bounds checks elided and the capability bounds used instead?

>>blueje+s5
Not really, because it gets traded off with the increased memory pressure due to the larger pointer size, and it'd likely be workload dependent. It's not something we've explored to date beyond hypothesising that it could be a good thing.

>>blueje+(OP)
With a program split into multiple small compartments one does not need to crash the whole application on out-of-bound access. It will be enough to signal the parent compartment that one of its children performed an illegal operation.

>>jrtc27+w2
> Yes, the use of CHERI to protect unsafe code in memory-safe languages like Rust is of interest to us.

Have you found that the relative difficulty of bootstrapping Rust on a new architecture, as mentioned in [1], has hindered your team's ability to research this? Or is it not as bad with CHERI on ARM, because aarch64 is already a Rust tier 1 platform?

[1]: https://drewdevault.com/2022/01/15/2022-01-15-The-RISC-V-exp...

>>mwcamp+Qm
I've bootstrapped Rust for RISC-V on FreeBSD, it's not that bad, the issues I faced were solely porting issues, not bootstrapping issues. I've certainly not had cross-compiling issues like Drew. The awful part about porting Rust is that you need Rust bindings for every type and function in your system's libc, which is fine if your OS+libc combination is already supported (though even then 32-bit and 64-bit need some separate implementation bits), but a real pain if your OS isn't yet supported. Rust on CHERI has the additional complexity of a poor design decision in the language that defines usize as a pointer-sized integer, conflating integers and pointers, rather than providing both size_t and uintptr_t equivalents like C has; see https://internals.rust-lang.org/t/pre-rfc-usize-is-not-size-... for a discussion of this and ways to resolve it without breaking existing software on non-CHERI which, as you might expect, is to introduce a new uptr type for the rare cases when a usize holds a pointer not an offset/length/machine word-sized integer, allowing a usize to be used in its place on non-CHERI architectures (at least for existing editions) but not for CHERI architectures. Someone needs to do that engineering though and it's not a priority for us.

>>jrtc27+w2
It's important to note that this is "just" a recompile, but it's the kind of recompile that you need to port 32-bit software to 64-bit. Pointers on CHERI are 128+1 bits, and software that treats long longs as a good place to put pointers are common. There's a lot of code that is going to need some sort of rewrite to be able to take advantage of CHERI capabilities. (But the problem is not insurmountable: WebKit already runs to some capacity, so it's reasonable to take even very low-level bit twiddling code and make it work on this platform.)

>>saagar+3h1
Yes it's non-zero, though https://www.capabilitieslimited.co.uk/pdfs/20210917-capltd-c... is a recent exploration of what it takes to port X11 and KDE to CHERI. Of the around 6 million lines of C and C++ code involved, only about 0.026% needed to be touched, or just under 1.6k. That number will of course vary significantly between the type of code; boring applications code generally doesn't need changes (e.g. htop and sudo built and ran out of the box for me recently, as examples), but language runtimes will need significant changes. Pages 21, 22, 26 and 27 of that report have the per-component breakdown of that number.