Are these lines of code written _just_ for Google Chromium, or does this include all dependencies that you would normally not touch the source code of?
Really impressive to see this on a practical codebase.
> 56% of total vulnerabilities (113 of 200) are memory-safety; of these:
> • 54% mitigated through referential and spatial safety (implemented); of these, 8% of memory safety w/sub-object
> 72% mitigated if including heap temporal memory safety (white-board design)
> • 26% unmitigated are uninitialized values; at least 5% of memory safety would likely be mitigated by LLVM stack initialization
> • Handful of unmitigated vulnerabilities: stack temporal safety, VM vulnerabilities, …
Could someone explain this?
I believe this is saying that 54% of the 113 vulnerabilities were mitigated with what the implementation can do today, 72% would have been mitigated using the heap temporal stuff, which this seemingly implies is future work.
From what I have heard from various talks on Cheri that I attended, it only targets about 72% of memory safety issues. Handling the remaining 28% is not mentioned, but I suspect it would be future work.
The 26% that aren't covered makes sense to me. It's the gap between the 54% and 72% that I'm trying to understand.
My recollection is that by default CHERI provides strong spatial safety but it requires work (and possibly primitives that do not fully exist yet) to get the temporal safety. I'm wondering if that's what this is/ if my recollection is correct.
Yes. CHERI handily solves the spatial issue but does not really have a good solution for temporal safety as every solution eventually ends up requiring sweeping memory and revoking capabilities. Temporal safety really is a beast of an issue and it's still unclear whether there is a palatable solution using CHERI.
Cool, when can I buy a Morello board for myself? I don't really care until this product actually exists. I'm not a large research institution looking to participate in their program, I just want something interesting to play with.
Can anyone in the know share details on when arm servers with CHERI extensions can become generally available to developers and for deploying to production?
What’s the current consensus on how this rollout and transition is expected to happen?
As I understand it Morello was a research prototype and dead end.
I'd like to see something similar standardized for ARM and available in off-the-shelf ARM CPUs and SoCs; I'd also like to see it supported in Apple's ARM SoCs and OSes, and in Android and Windows on ARM.
What are the real-life (i.e. measured) performance impacts across different applications? "0-5%" sounds like it was pulled out of thin air--an unbelievably small variance for such a big change.
https://discourse.llvm.org/t/rfc-enforcing-bounds-safety-in-...
In particular, it will allow safety issues from type casting, which do not happen under Cheri C/C++:
https://www.cl.cam.ac.uk/techreports/UCAM-CL-TR-947.pdf
I hope that the two efforts could be combined. Having a software version of Cheri for "legacy hardware" would give us the best of both worlds.