Hacker News Reader

Comment by rwmj | Hacker News Reader

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.

View on HN

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.

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

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.

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

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.

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.

Mid-level technical staff don't push hardware out the door for major OS vendors, unless it is something their management already cares about.

We're talking mostly about companies which push hardware in the door, here, such as the hyperscaler types which the CHERI people have been showing slide decks to.

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.

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

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.

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.

Right: unfortunately it really is a bit much to dismiss CHERI as a no-hope effort to boil the seas if the alternative plan is to rewrite everything in formally verified C (even if you'd also try to move some of it into GC languages instead).

The alternative is you use a compiler that adds bounds checking. It's possible to do this with C, with fine object granularity (even separate stack objects), and even preserve compatibility with existing non-bounds checked library code / system calls. When I did it back in 1996 there was a large overhead to doing that, but compilers can do much better these days. And anyway you have to compare the overhead to the cost of designing and building your own small run CPU and eshewing mainstream processors, which is also huge.

https://www.doc.ic.ac.uk/~phjk/BoundsChecking.html

Yet to this day no major OS vendor, selling C and C++ compilers, has ever bothered with.

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.

Major OS vendors have added loads of hardening to their C compilers. Not bounds checking specifically (because even if the overhead was only 20% that would be too high) but tons of other stuff such as: stack canaries, control flow integrity, hardened string functions, ASLR, zeroing uninitialized auto variables, forced warnings, linker hardening. These are added as standard in all decent Linux distros today. Probably Windows too, I've no idea. There's a good summary here: https://best.openssf.org/Compiler-Hardening-Guides/Compiler-...

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.

But no-one's claiming that the techniques which have been widely deployed already are bad or unworthy or haven't made a positive difference. (Certainly I'm not!) However it's evident that they haven't made a sufficient difference (and while they have an overall low cost compared to other approaches all that effort to patch and make do isn't free either).

Kind of, because to this day it has been a quixotic battle for devs to use them at scale.

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.

Those techniques are implemented by default in Fedora & Debian. You have to opt out if for some reason you don't want to use them. So almost all C software compiled in these two major distros are using all of them. (Likely in other distros too, but I'm less familiar with how they configure their compilers).

Fedora will soon implement shadow stacks across the entire C codebase: https://discussion.fedoraproject.org/t/f45-change-proposal-e...

I thought MISRA was fine, and I don’t really understand why people complain about it. At least as a Fortran programmer who had to dabble in some C, I found I could read and write MISRA C much more easily than the obfuscated nonsense that C programmers get up to without rules, haha. (Actually come to think of it, it could just be that the MISRA codebase was engineered from the beginning).

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

How many tokens do you think that would cost?

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

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.

> Why not just switch to a slightly different compiler and core, and then you make all your old code safe without verifying it

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.

Reply on news.ycombinator.com