Creating a Memory-Safe Workstation with CheriBSD [pdf] | Hacker News Reader

Creating a Memory-Safe Workstation with CheriBSD [pdf]

bsdcan.org

83 pointsksec17 comments

There is currently a LLVM proposal for -fbounds-safety that seems like a software version of this, although not quite as good:

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.

This effort is basically clang's version of what MSVC already does since the Windows XP SP2 days,

https://learn.microsoft.com/en-us/cpp/code-quality/understan...

TIL that Google Chromium has more than 35M LoC

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.

Correct?

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.

Makes sense, thanks. TBH guaranteed spatial safety is such a nice win I'd take that and still be happy.

So, someone's doing AS/400-style pointers for various smaller platforms.

The mentioned Morello boards appear to be these:

* https://www.arm.com/architecture/cpu/morello

Or Solaris SPARC, Burroughs B5000, Lisp Machines, ...

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?

No idea, maybe one day it can come to Windows,

https://msrc.microsoft.com/blog/2022/01/an_armful_of_cheris/

Although not CHERI, Solaris SPARC, iOS PAC and Android MTE (on ARMv9) are already doing memory tagging.

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.

Here's an older video from Robert Watson detailing the goals.

https://www.youtube.com/watch?v=yrk5FfjHDCo

The slides say they're expecting to have the Chromium port complete in May 2023 (checks calendar) ... any news on this front?

Reply on news.ycombinator.com