With funding of DARPA how sure can we be that it will not have a backdoor? Is there a way to proof that there is no backdoor to the security features?
Arm releases experimental CHERI-enabled Morello board
31–40 of 84 posts
Re: Arm releases experimental CHERI-enabled Morello board
#32How does this compare to testing with address sanitizers?
Apart from some more interesting scenarios enabled by CHERI: you probably don’t want to run all your production software with address sanitizers, because it would be unacceptably slow. Here the performance overhead is negligible.
Re: Arm releases experimental CHERI-enabled Morello board
#33With funding of DARPA how sure can we be that it will not have a backdoor? Is there a way to proof that there is no backdoor to the security features?
The MIPS and RISC-V CHERI implementations are open, you can audit the BlueSpec. The entire software stack is open too.
Note however that CHERI is not just an implementation; it’s a design, an idea. You can’t backdoor that.
Re: Arm releases experimental CHERI-enabled Morello board
#34I wonder how hard it will be to retrofit CHERI support into Windows, macOS, and Chromium, so we can have a new defense against browser sandbox escapes, making remote browser isolation products irrelevant.
Windows is likely a big task for the same reasons as SMAP (https://github.com/microsoft/MSRC-Security-Research/blob/mas...). XNU should be comparable to FreeBSD, which CheriBSD is a fork of, as both use Mach's VM for memory management and have a bunch of shared code in various places, but userspace is more of an unknown quite how much effort it'd be (you'll need to port Objective-C and, now, Swift, for example). For Chromium we have ported WebKit, so I'd imagine Blink isn't too dissimilar. V8 is likely interesting, though we have a version of WebKit's JSC JIT for Morello, which gives confidence in V8 being doable.
Re: Arm releases experimental CHERI-enabled Morello board
#35Earlier quoted context omitted.
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…
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,…
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?
Re: Arm releases experimental CHERI-enabled Morello board
#36Earlier quoted context omitted.
Are you saying Arm haven't released a CHERI enabled Morello board?
It's technically true, but it makes it look like CHERI is only for ARM.
I don't see why it implies that. "Arm releases experimental DDR5-enabled $NAME board" wouldn't make it sound like DDR5 is only for Arm, so why would "Arm releases experimental CHERI-enabled Morello board"?
Re: Arm releases experimental CHERI-enabled Morello board
#37Earlier quoted context omitted.
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,…
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?
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.
Re: Arm releases experimental CHERI-enabled Morello board
#38I wonder how hard it will be to retrofit CHERI support into Windows, macOS, and Chromium, so we can have a new defense against browser sandbox escapes, making remote browser isolation products irrelevant.
That is already slowly happening on the versions that have access to ARM hardware memory tagging and pointher authentication, specially on iOS and Android.
Solaris on SPARC has about one decade of experience via Application Data Integrity.
And Unisys ClearPath MCP memory tagging architecture goes back to its Burroughs B5500 roots.
Also in case you missed it, Microsoft is one of the CHERI sponsors.
Re: Arm releases experimental CHERI-enabled Morello board
#39How does it compare to previous proposed hw assisted ways to bolt memory safety onto C? Like Hardbound, In-Fat, MPX for example.
I'll leave it to others to go into technical details, but the most obvious answer is that this effort has major industry players behind it, meaning it might actually make it into production.
As mentioned in another reply, there are already a couple of tagging approaches in production.
Unfortunely x86/x64 don't have any, and MPX was broken from the get go.
Re: Arm releases experimental CHERI-enabled Morello board
#40How does it compare to previous proposed hw assisted ways to bolt memory safety onto C? Like Hardbound, In-Fat, MPX for example.
The simple answer is that it actually works for real-world software, is microarchitecturally feasible and flexible, and architecturally enforces non-forgeability (which is crucial allowing in-address-space compartmentalisation of distrusting software). Most schemes that take the metadata-table-on-the-side approach fall down on those last two points. MPX is particularly notorious for tanking performance, having race conditions (because loading the bounds is not atomic with loading the address) and having an extremely limited number of bounds registers (I think 4? which is even worse than the highly constrained register set of 32-bit x86) so you're constantly spilling/reloading bounds data from memory. I don't think any of them have been shown to work across the entire software stack from the kernel to core userspace runtime parts to graphical desktops like KDE.