zlacker

[return to "Arm releases experimental CHERI-enabled Morello board"]
1. DrBazz+3c[view] [source] 2022-01-20 12:49:25
>>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/

◧◩
2. blueje+pz[view] [source] 2022-01-20 14:59:14
>>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.

◧◩◪
3. jrtc27+VB[view] [source] 2022-01-20 15:10:54
>>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).

◧◩◪◨
4. blueje+RE[view] [source] 2022-01-20 15:26:20
>>jrtc27+VB
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?

◧◩◪◨⬒
5. jrtc27+OK[view] [source] 2022-01-20 15:50:33
>>blueje+RE
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.
[go to top]