[HN Gopher] Creating a Memory-Safe Workstation with CheriBSD [pdf]
___________________________________________________________________
Creating a Memory-Safe Workstation with CheriBSD [pdf]
Author : ksec
Score : 58 points
Date : 2023-05-30 17:52 UTC (5 hours ago)
(HTM) web link (www.bsdcan.org)
(TXT) w3m dump (www.bsdcan.org)
| dilippkumar wrote:
| 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?
| pjmlp wrote:
| 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.
| hello_computer wrote:
| 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.
| insanitybit wrote:
| 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?
| ryao wrote:
| 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.
| insanitybit wrote:
| 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.
| lucgagan wrote:
| 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?
| ryao wrote:
| 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.
| JdeBP wrote:
| 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
| anotherhue wrote:
| Here's an older video from Robert Watson detailing the goals.
|
| https://www.youtube.com/watch?v=yrk5FfjHDCo
___________________________________________________________________
(page generated 2023-05-30 23:01 UTC)