I know a lot of folks have been going on about it, but Steam's latest hardware announcement has been utterly insane for the day and age in which we live.

Consider that they didn't hype it up with a launch event. They didn't sell a bunch of hype and buzzwords. All they did was release a ~6 minute video that effectively described the hardware and what it would provide, and had a webpage with *actual specs on it*.

They invited a bunch of tech reporters/YouTubers to their HQ, but they let them talk to *engineers*, not marketing people. The discussions focused on real capabilities of the hardware, and actual demonstrations. No vapor and promises. Not glitz and glam.

They made it clear this is all SteamOS driven, and that they have a focus of getting *existing x86 Windows software* running not only on Linux, but on ARM and in VR!!

They aren't pitching a closed ecosystem. They said, outright, "This is your hardware, you can do whatever you want with it".

THEY DIDN'T MENTION AI ONCE.

And they're _already_ making a bigger splash than any competitor ever did, even though those competitors have gobs more money they've thrown at this stuff, and tremendously more staff.

It's flabbergasting. I hope they make enough of an impact with all this that people sit up and take notice.

For folks who missed my #KISV keynote or #CHERITech talk, I wanted to pull out the two key points.

The first is that CHERI solves memory safety, but that’s almost incidental. I don’t want to downplay addressing the root cause of 70% of vulnerabilities but that’s not the goal. CHERI was originally designed to support scalable fine-grained compartmentalisation. To do that well, you need a programmer model. You need to be able to share things programmers understand (objects, in object graphs) not pages. And that means you need to be able to trivially map your protection up to language-level constructs like pointers / references and protect both them and the objects that they refer to. And so you need to build memory safety. And, it turns out, making an entire program memory safe is much easier than making just an exposed API memory safe. So we have memory-safe C/C++ and we can use those from languages like Java or Rust to ensure that the C/C++ doesn’t violate the guarantees that the safe language’s security depends on. And then we can use that for easy to use compartmentalisation, safe FFI, supply-chain security, and many more things.

The second is that CHERI is still quite young. I gave a talk about how CHERI impacted OS design. That’s like, in 1985, asking someone from IBM to give a talk about how MMUs impacted OS design. They would tell you you could create VMs to consolidate multiple minicomputers onto a single mainframe. They would tell you that you could enforce process isolation. And, just like the things we can do with CHERI today, these are hugely valuable. But they wouldn’t tell you about using Zygote models to speed up process creation. They wouldn’t tell you about how memory-mapped files could enable new I/O models. They wouldn’t tell you about how IOMMUs could enable kernel-bypass storage and networking. They wouldn’t tell you about how MMUs can introduce lightweight GC barriers. They wouldn’t tell you about how MMUs enable lightweight CoW snapshots for time-trace debugging. Because, although a lot of the hardware existed for these things (and the rest was a fairly small incremental tweak on existing ideas), most of these software uses hadn’t been invented.

CHERI is exactly the same. We have barely scratched the surface of what CHERI can let you build. The BLACKOUT work (presented at CCS and again at CHERITech) is another great example of this. I had never thought of using CHERI as a building block for providing a clean programmer model for avoiding side channels, but some other smart people did and proposed a really interesting model for doing so. I hope future CHERI systems will incorporate something based on this work.

As with MMUs in the early ‘80s, we have no idea what people will be building on top of CHERI in ten or twenty years. Many of these things will be possible on existing implementations, some will require hardware changes. This is why it’s very important for the RISC-V CHERI standard to be designed with agility in mind, so that future hardware can continue to add new and exciting features without breaking backwards compatibility for software. I think we’re on a good path to that.

#CHERI #RISCV