> Addressing concerns that creating a new base ISA might fracture the open-source community, Asanović offered a devoted defense to EE Times. “CHERI is too invasive to be a simple extension on regular RISC-V, and so needs a new base ISA for that reason,”
To me it sounds like they're creating RISC-VI before RISC-V even winning the market.
That's not the case at all. The spec is developed in the open: https://riscv.github.io/riscv-cheri/
If you want to run CHERI code, it's true that silicon isn't easily available, but that's simply because it takes time. Various companies are working on it (Codasip, SCI, Secqai, lowRISC, etc.).
But you don't need silicon to run CHERI code. There are various emulators available that support it. There's QEMU: https://github.com/CHERI-Alliance/qemu There's also the RISC-V Sail model, this is the latest CHERI branch: https://github.com/CHERI-Alliance/sail-riscv (unfortunately it is a bit behind upstream master, and also a bit behind the latest CHERI spec which is still evolving).
There are also a few open source chips available that implement CHERI which you can run in Verilator or an FPGA. For example cheriot-ibex https://github.com/microsoft/cheriot-ibex . This is actually a variant of CHERI for microcontrollers called CHERIoT. Long story but the plan is to merge CHERIoT back into CHERI so it is just a "profile" of CHERI.
https://cheri-alliance.org/discover-cheri/cheri-products/mor...
Also, you can buy a Sonata board with CHERIoT from Mouser:
https://www.mouser.co.uk/en/ProductDetail/NewAE/NAE-SONATA-O...
And you cant rewritte 50 years of C in Rust. And even in Rust you can still run into various issues.
CHERI would open many doors in operating system design and security, and it's stagnant because it's not a real thing yet, there's no CPU one can buy that supports it in any way outside of research. Without CHERI, we're stuck with security models from the 1970s. Most people are fine with 1970s design, but the OS research world has been itching for something like this for decades.
CHERI gives you that and more. But its still very new and radical, and a lot of work needs to happen all over the place to make it practical.
Once you have micro-controllers and software it makes sense in lots of niches, and then it can expand.
For example, Google OpenTitan project. There is no reason not to use Cheri if the open source core supports it.
[1] I literally wrote the paper on this back in 1996: https://www.doc.ic.ac.uk/~phjk/BoundsChecking.html
If they think programming with Modula-2 and Object Pascal is programming with a straightjacket, good luck with MISRA, Frama-C, DOD and ISO certifications for reliable C code.
Hardware memory tagging, via SPARC ADI, ARM MTE, CHERI has become a thing, before software based processes so far have failed adoption, and the OS vendors like Google, Microsoft, Apple, Oracle, rather go with hardware approach.
There are also bounds checking options for major C compilers so if you want to use it, you can, eg. -fbounds-safety or the various sanitize options in Clang.
Those OS vendors rather push for Swift, Java/Kotlin, C#, and Rust instead.
Alongside ARM MTE, Pluton, SPARC ADI.
Also, all those hardening measures and lack of bounds checking could have been solved with WG14 papers, nowhere to be found. C isn't set in stone.
Fedora will soon implement shadow stacks across the entire C codebase: https://discussion.fedoraproject.org/t/f45-change-proposal-e...
How many tokens do you think that would cost?
You don't have to. Google already showed that the vast majority of memory safety bugs are in newly-written C code. Stop writing new C code (which the industry already seems to be moving towards) and the problem will eventually solve itself - even with plenty of C code still around.
Besides, very few (if any) pieces of code have been around for anywhere close to 50 years. Over time components naturally get refactored or rewritten for all sorts of reasons. And if you're rewriting anyways, why not switch to a more secure language? Don't allow C for rewrites and over the years every C component will eventually be replaced by a non-C one without forcing a big C-to-Rust rewrite.
Also, nothing new in C is just not happening, there is massive amounts of things that will not switch for decades.
Why not just switch to a slightly different compiler and core, and then you make all your old code safe without verifying it. And your new code in whatever language is also safe.
Also it helps with debugging. Also it helps you enforce security constraints on higher level.
CHERI also gives you features you can build more on-top off.
The silicon area and the performance hit are pretty minor, if it 'just' works for most code and most open source code just works, many people will want to use it.
Yes most bugs are new code, but plenty of bugs aren't and with CHERI I can be much more confident in running all that stuff. Specially older code that isn't as well used and tested as say Linux kernel.
You don't even need a new core. Fil-C makes regular old (and new) C code memory-safe. You can use it for individual apps on your existing OS, or Filip Pizło has been making an entire distro work with it ... libc, bash, ssh ... everything. He's got web browsing working and at the moment is working on LibreOffice. Many things work as-is, most things require very minor patches (which he's upstreaming).
Unlike Rust, there is no "unsafe" escape hatch (and it's not needed).
Follow https://x.com/filpizlo for progress.
There are two counter-arguments:
1. There's a lot of C/C++ code still out there. You can't rewrite it all. I'm not totally convinced by that though because, a) do you need to? Google has shown that just writing new code in Rust is very effective, and b) AI is actually pretty decent at porting from C/C++ to Rust so maybe you can?
2. CHERI also allows really strong and fine grained compartmentalisation. This is absolutely fantastic for robustness, supply chain security and so on. If you want the absolute 100% most secure code possible, then Rust + CHERI with compartmentalisation is basically the best thing you can do. (Though Rust compartmentalisation is still not actually ready yet; it's in progress though.) That's really great but I'm not sure that level of security is needed by most projects, and also I think you can get pretty good compartmentalisation (though definitely not CHERI level) by doing something like what Xous does (basically isolation with processes/virtual memory, combined with the ability to call functions in other processes; IIRC Hubris OS does something similar).
CHERI is clever tech though and it would definitely be a boon for RISC-V if it succeeds.
Even on OpenJDK and CLR side, as new language features allow to rewrite even more runtime code from C++ into Java and C#, there is still new runtime code getting written in C++.
There is already clever tech for hardware memory tagging (SPARC ADI, and ARM MTE), CHERI is yet another way to tame unsafety on our computing stacks.
V8 is actually a nice case for CHERI since you can easily sandbox the JIT'd code. If you were to just rewrite V8 in Rust then you wouldn't get that benefit (you can't run the borrow checker on generated assembly). I assume they have some other sandboxing methods instead though.
But in general if you think about things like V8, that's used on high performance application class consumer CPUs. It's going to be at least 10 years before anyone has one of those with CHERI (unless ARM changes its mind about Morello). I would not bet against V8 being ported to Rust before that.
As I said I think CHERI is great technology and I hope it does succeed, but it does seem like the business case for it is not as strong as it was just a few years ago.
Or eventually have its ideas come into the evolution of ARM MTE, Pluton, and Silicon, which increasingly becoming adopted, alongside the oldie SPARC ADI.
It is the x86 linage that keeps getting it wrong on hardware memory tagging solutions.
Not to mention the smartcard market which would mean billions of processors around the world.
Smartcards often run Java Card, which solves the whole memory safety problem the other way around. You don't need CHERI for this kind of limited platforms: want to run memory-safe C today? Just ban all dynamic memory allocations. Throw in the usual UB restrictions and stick to a single thread and very little can go wrong.
What's important to remember is that, despite its large deployment figures, those are still niche applications. The number of people developing for them is a rounding error. There is no clear path from there to mainstream adoption.
We don't need to measure technology adoption by the late stage capitalism of Silicon Valley VCs.
Many technologies do leave an impact in the industry even when adopted in niche domains.
Last I looked you need a garbage collector to deallocate at which point you might as well use Java which is actually designed for that use case.
https://lowrisc.org/news/opentitan-earl-grey-2-to-support-ch...
Last year, Google announced that their Coral NPU will include CHERI:
https://developers.googleblog.com/en/introducing-coral-npu-a...
There are more cores that companies are actively working on:
X730 from Codasip https://codasip.com/solutions/riscv-processor-safety-securit...
ICENI from SCI Semiconductor: https://www.scisemi.com/products/iceni-device-family/