zlacker

>>zxombi+(OP)
> The CHERI memory-protection features allow historically memory-unsafe programming languages such as C and C++ to be adapted to provide strong, compatible, and efficient protection against many currently widely exploited vulnerabilities.

https://www.cl.cam.ac.uk/research/security/ctsrd/cheri/

>>DrBazz+3c
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+pz
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+VB
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.)