> “CHERI is not an extension; CHERI is a new base,” Asanović clarified to the keynote audience.

> 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.

▲

embedding-shape 4 hours ago | parent | next [-]

What a circular argument that avoids answering the question. How does "it needs a new base ISA" address the concern about "might fracture the open-source community" even one bit? Why does the "journalist"/writer call that reply "a devoted defense", in what world is that any sort of defense?

▲

unprovable 3 hours ago | parent | prev | next [-]

I've been trying to get access to CHERI for quite a while - I have a background in hardware security so was very curious to have a play. But only 'approved partners' are allowed to have access... guessing even in projects like this, Security through Obscurity still reigns.

	▲	timhh an hour ago \| parent [-]
		> Security through Obscurity still reigns. 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.

▲

rwmj 4 hours ago | parent | prev [-]

There's zero chance CHERI will go anywhere, I wouldn't worry about it.

▲

pjmlp 4 hours ago | parent | next [-]

ARM and Microsoft care about CHERI, that is enough to eventually make it happen, even if only on high integrity computing, like folks that still care about paying for Unisys ClearPath MCP.

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.

▲

rwmj 4 hours ago | parent [-]

ARM and Microsoft don't "care" enough to do anything beyond a bit of token research. Maybe there will be some extremely niche chips one day, or maybe not because the problem can be solved 90% as well in software on ordinary hardware.

▲

an hour ago | parent | next [-]

[deleted]

▲

imtringued 3 hours ago | parent | prev [-]

Microsoft and Apple will probably switch to CHERI RISC-V for their Secure Enclave/TPMs once it has proven itself in the field. That means there will be hundreds of millions of CHERI RISC-V processors in the world.

Not to mention the smartcard market which would mean billions of processors around the world.

▲

crote 2 hours ago | parent [-]

The Intel Management Engine famously runs MINIX. Tanenbaum has called it "the most widely used computer operating system in the world" - but it hasn't exactly led to mainstream MINIX adoption.

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.

	▲	pjmlp an hour ago \| parent [-]
		More important to remember is that not everything needs to be Web scale to be a success. 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.

▲

rando1234 4 hours ago | parent | prev [-]

Yeah, I feel like Rust has killed Cheri.

▲

Timshel 4 hours ago | parent | next [-]

Do you have more details on why ? I just found stuff like: https://cheri-alliance.org/discover-cheri/rust-and-cheri/ Or https://rust.cheriot.org/2026/02/15/status-update.html

▲

pjmlp 4 hours ago | parent | prev [-]

CHERI is valuable even for unsafe Rust code.

▲

timhh an hour ago | parent | next [-]

Is it valuable enough though. Looking at Google's stats Rust has several orders of magnitude fewer memory vulnerabilities even with `unsafe` (kind of the point). If C was at that level there's no way CHERI would have ever been proposed.

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.

▲

rwmj 4 hours ago | parent | prev [-]

The problems with CHERI are not whether it's technically good or not, it's organizational. It's an academic project that requires everyone to boil the ocean. They tried to get ARM interested and that didn't go anywhere and now they're trying to get RISC-V interested. But they haven't addressed any of the problems of why manufacturers would ever make a complex and completely incompatible chip for a problem that they (the manufacturers) don't have and don't care about, that can probably be solved 90% as well in software.

▲

panick21_ 3 hours ago | parent [-]

The manufactures will do what costumers demand and if they demand safty then cheri will make a lot of sense to many costumers.

And you cant rewritte 50 years of C in Rust. And even in Rust you can still run into various issues.

▲

crote 2 hours ago | parent | next [-]

> And you cant rewritte 50 years of C in Rust

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.

	▲	panick21_ an hour ago \| parent [-]
		Can you show me that research? 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.

▲

rwmj 3 hours ago | parent | prev | next [-]

However you can do what Airbus do and formally prove your C code and use a formally proven toolchain like compcert to compile it. Or you can take a performance hit and add bounds checking to the C code[1]. Aircraft systems are probably the best chance that CHERI has, and that's pretty niche, small runs and very expensive, and still better solved in software.

[1] I literally wrote the paper on this back in 1996: https://www.doc.ic.ac.uk/~phjk/BoundsChecking.html

▲

pjmlp an hour ago | parent [-]

Most people on HN would run screaming away if they had to follow high integrity computing processes on their daily C programming.

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.

	▲	ykonstant 33 minutes ago \| parent [-]
		For the record, I found programming in MISRA C guidelines really fun; but then again, I did it out of personal interest. If I had to do it professionally, I guess the pressure would be less pleasant.

▲

mort96 3 hours ago | parent | prev | next [-]

I haven't exactly seen an outpouring of consumer demand for CHERI.

▲

sph 3 hours ago | parent | next [-]

Is there an outpouring of hardware offer for CHERI? I'm a random nobody, but I'm sitting on this design for a message-passing platform that can only truly perform in a world where processes live in a single address space, which requires CHERI hardware to be feasible (or secure) at all.

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.

▲

leoc 24 minutes ago | parent | next [-]

Right: it's not clear whether the availability of some $300 US CHERI SBCs would be enough to carry CHERI to glory, but it would obviously generate a significant pop of awareness, support and grassroots activity. For their part the antis could then transition seamlessly from "nobody wants it lol" to "all these enthusiasts are so annoying and out of touch with reality lol" as is traditional. Instead, AFAICT, the CHERI leadership seems to be convinced that the next step is to present the business case for CHERI to people at or just below CxO level https://www.youtube.com/watch?v=FJhS2i7KVtI . Imagine how far Rust (or, earlier and further afield, Linux) adoption would have got if it had relied solely on having an academic-led consortium present a business case to CxOs, instead of being pushed along by internal pressure from mid-level technical staff who had used it themselves and were crazy about it.

▲

pjmlp an hour ago | parent | prev [-]

Tell ARM about it, https://cheri-alliance.org/discover-cheri/cheri-products/mor...

	▲	leoc 3 minutes ago \| parent [-]
		It's a lot better than things apparently used to be, but what CHERI really needs to develop a grassroots is a board that runs CheriBSD ( https://www.cheribsd.org/ ) and is actually available for a few hundred US dollars cash down, not a board of which you can apply to, maybe, have a single unit eventually allocated to you if you are deemed worthy. Even taking for granted that they only have a small supply which has to be allocated on a non-commercial basis for now, they should be beating down the doors of guys like Jeff Geerling and Wendell Wilson from Level1Techs and thrusting eval boards in their hands, not sitting on their throne waiting to hear entreaties.

▲

panick21_ an hour ago | parent | prev [-]

I'm not saying end consumer, I mean companies who have to insure safety and reliability. That is also behind adoption of things like Rust and many other trends.

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.

▲

fragmede 3 hours ago | parent | prev [-]

> And you cant rewritte 50 years of C in Rust.

How many tokens do you think that would cost?