Arm releases experimental CHERI-enabled Morello board(lightbluetouchpaper.org) |
Arm releases experimental CHERI-enabled Morello board(lightbluetouchpaper.org) |
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.
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).
> Any piece of code running in a process can construct an integer value and, if this integer corresponds to a valid location in the process’ address space, then it can access memory at that location.
What this adds:
> CHERI changes this. Every load or store instruction and every instruction fetch must be authorized by an architectural capability.
So it should be possibly to call into any function (e.g. from an untrusted blob, and given the capabilities are set up) and on return have the guarantee that none of the callers memory has been touched and all the side effects are contained in the return value, and maybe selected whitelisted addresses?
I remember the mill architecture[1] also claims to have that capability, I think they called these calls "Portals". Btw the talks by Ivan Godard are a must watch if you have any interest in hardware architecture.
But how can existing code be just a recompile away from benefiting from these features, don't the capabilities have to be set up somehow (unless it is purely functional language)?
Edit: To answer the first question, yes, that is the primitive which enables CHERI to be used for in-address-space compartmentalisation rather than relying on an MMU for process-based separation and all the overheads that come from context switching address spaces.
So these bounds are set by the software (and are guarded against manipulation). Then each read or write to memory is checked against these bounds by the "fine grained MMU" hardware.
The Mill's "Portals" are more intended for inter-process calls than for compartmentalisation within a process. The Mill can have fine-grained protection of memory temporarily given to a callee because protection ranges are separate from paging. I believe there have been several research OS:es that did pass full pages back and forth over IPC, but at the cost of setting these up and restricting them to that purpose.
Because Portals are so cheap they could probably be useful for compartmentalising larger complex applications such as a modern-day web browser into smaller chunks than today.
BTW, Goddard has told that the Mill team once considered a capability-oriented architecture but they chose not to because the model they had in mind broke C's pointer semantics in some way. They have chosen to prioritise compliance with the C spec, so as to be able to market the architecture.
This sounds great. But on the other hand ... Yikes! What if this tech falls into the hands of a big corporation and some manager needs a raise?
(2020) CheriBSD port to Morello, https://www.youtube.com/watch?v=7aVygpgkm1
(2021) GCC support for Morello, https://gcc.gnu.org/pipermail/gcc/2021-July/236868.html
(2021) OSS desktop software stack, https://www.capabilitieslimited.co.uk/pdfs/20210917-capltd-c...
> We measure a 0.026% Lines-of-Code (LoC) change rate in approximately 6 million lines of C and C++ code to introduce CHERI memory safety. In our review of past vulnerabilities, we see likely mitigation rates of 91% for X11, 82% for Qt, 43% for KDE, and 100% for other supporting libraries (typically image processing).
(2022) Microsoft Research, https://msrc-blog.microsoft.com/2022/01/20/an_armful_of_cher...
> We can implement this model on a variety of mechanisms, such as MMU-based isolation or software fault isolation, but expect that CHERI will provide better performance and scalability than anything on current commodity hardware ... If the Morello program can demonstrate that CHERI meets the performance goals for real-world use then it is a game changer for security, deterministically preventing spatial safety vulnerabilities and (with software support) heap temporal safety bugs, dramatically reducing the set of bugs that become exploitable as for anything other than denial of service.
I try to choose my words carefully (these kinds of conversations can get pretty toxic pretty quick). But honestly I think in the long arc of history, C will be regarded like asbestos: very obviously dangerous in retrospect. I respect the designers of C immensely and the amount of work many thousands of people the world over have put into that entire toolchain and ecosystem, but we can't blamelessly have that conversation yet, so I guess I'll stop here.
Unfortunely x86/x64 don't have any, and MPX was broken from the get go.
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.
See the following for theoretical foundations for the work:
Linux 60th Anniversary Keynote
Did I miss anything?
Fuzzing helps but it's a probabilistic method with fallible search mechanisms, there's going to be cases left that an intelligent adversary can find by reasoning, a different/better fuzzer, better instrumentation, or alt techniques like symbolic execution etc.
In a sense the entire aim of this is for it to be 'hacked' to further improve the security architecture.
1. Memory safety issues not found in testing do not lurk as exploitable vulnerabilities; testing is never perfect, often far from it when it comes to edge/unexpected cases where vulnerabilities lurk (though fuzzing can help somewhat)
2. Sandboxing still needs some kind of isolation primitive, which CHERI can provide in place of the heavyweight MMU-based techniques that exist today
Plus let's not kid ourselves that all software is being tested with sanitisers. The vast majority of software running on your system probably is not.
One more question: does the CHERI add on introduce new 'uLimit' like limitations, for instance the number of allocatable blocks or will it scale seamlessly with whatever the various memory management functions and system calls provide?
Everything else is the same, just "as much as your system can fit (and system policies will let you)". Which will be slightly less, because pointers are bigger, but we don't have any additional tables that impose arbitrary restrictions on what you can do.
Have you found that the relative difficulty of bootstrapping Rust on a new architecture, as mentioned in [1], has hindered your team's ability to research this? Or is it not as bad with CHERI on ARM, because aarch64 is already a Rust tier 1 platform?
[1]: https://drewdevault.com/2022/01/15/2022-01-15-The-RISC-V-exp...
Are there estimates on the performance improvement people can expect with the bounds checks elided and the capability bounds used instead?
Either they aren't interesting for hackers, or they actually did a good job with hardware memory tagging.