“We've also seen projects where rewrites in Rust have introduced new logical flaws because, okay, you get memory safety, but it doesn't mean that everything's invulnerable. ... Getting memory safety from the hardware is ultimately going to be a lot cheaper than redoing all of the software.”
The InfoQ Podcast · Hands-On Engineering Podcasts · October 2026
Swan is explaining a research project that puts memory safety into the chip, so existing C code can be recompiled instead of rewritten. He puts open source C at billions of lines against tens of millions of lines of Rust, and says rewriting it all would take almost impossibly long even with AI help.
Transcript
So part of putting Cherry onto the track, which was David's talk, focusing on how we can make security better in the hardware, was I think we're still at a point where there's an opportunity to make safety better in hardware, which will benefit the entire software ecosystem. And that opportunity comes about because the profile for RISC-V on Android hasn't yet been fully baked. And so it's still possible that Cherry could become part of that. And if we then had hardware memory safety baked into the system on chips that were in popular handsets and the stacks using that, I think that would be a massive boon for our security. Now, we've already seen a glimpse of that. If you look at the latest iPhone system on chip and the latest kind of flagship Android system on chip for the Google Pixel and some of the Samsung Galaxy devices, they've been what I could kind of call cherry picking from Cherry. So they've got some hardware memory safety features in them, which are sort of activated with their particular versions of iOS and Android. And it would just be great for that to become a more ubiquitous thing. And so part of my reasoning behind picking David. David's talk was to raise awareness of the possibility that's offered by Cherry and things like that. And so, in terms of looking back and how we could have been looking forward at the time, getting better hardware protection in place seemed like something worth advocating for. It kind of runs through Alex's talk about the layers that we stand on. Alex didn't talk a great deal about their day job at Adira in terms of what they're doing there to protect containers. But I think being able to anchor what we're doing in software down to the hardware, which is what they do at Adira, is going to become all the more important. And what we've seen since with Mythos and Glass Wing and now kind of what we could almost refer to as the AI lab leaks, these supposedly ancients run amok starting to break into services like Hugging Face, is really an escalation in the exploitation landscape. But I think there's also potentially a very helpful side of that, because there's ultimately a finite number of vulnerabilities. And so we have the opportunity now to use these things to help us find them all and rid ourselves of them all. So if I look back 20 years, there was a brilliant paper presented by Microsoft Research, UseMix Security, about does software age like milk or wine? And it was building statistical models of the latent vulnerabilities in software and how these got discovered and potentially exploited. And from that, you could actually build a model of how many vulnerabilities do I think would be in a large code base that I've probably not found yet. And I think we're actually potentially on the cusp of being able to take that kind of knowledge and say, okay, let's grind my way through. And if I look at real world projects like Curl, it feels like they've been on this journey for a while. And we've seen that journey accelerate for a bit in terms of the AI tools have helped them find a lot more vulnerabilities a lot faster than they might have otherwise done. But this can't keep going forever. And so at some point, we'll find ourselves in a situation where there'll just be fewer vulnerabilities left to discover. And that should be a happier place for all of us to exist in because we won't be worrying as much about zero days and their exploitation.
Okay. Well, you mentioned Sherry and the fact that both Android and iPhones are looking into adopting this model. Maybe we can allocate a couple of minutes to get more details to our listeners and understand what Sherry actually is. Maybe we inspire other folks to adopt it.
So Cherry's a project that's kind of emerged out of research at Cambridge on providing hardware memory safety. And so if we look at a whole kind of class of memory safety bugs, there's been a big push over recent years to start using more memory safe languages. And so, you know, one thing we hear is, oh, just rewrite it all in Rust. But if you look at the size of the problem, there's something like five and a half billion lines of open source C C and something like 70 million lines of Rust at the moment. And so if we were to plot our course of how long it would take humanity to rewrite all of that C and C into Rust, even with AI assistance, it's almost an impossibly long duration. And we've also seen projects where rewrites in Rust have introduced new logical flaws because, okay, you get memory safety, but it doesn't mean that everything's invulnerable. You still have to think through the other ways that systems can be attacked. The rewrite of some of the core utils into Rust has unfortunately thrown away decades of hardware experience about what can go wrong with applications. You end up with functionally equivalent replacements, but that have some new bugs in them. They might be not memory safety bugs, but they're still potentially security problems. What Cherry does is say, what if I could catch out-of-bounds errors, the kind of things that kind of cause buffer overflows, et cetera, in my hardware and raise an exception out of the hardware. And then I can take all of my existing C and C, do a recompile to make it Cherry aware. And that should be pretty much all I need to do. Some cases, there's a small amount of rework involved. But the research so far suggests that that's a fairly light load. And so we can now have applications that are unsafe in terms of the language that they're using, but the hardware is ensuring. That the safety is there. So we don't have to do this potentially huge scale rewrite into Rust. And so getting memory safety from the hardware is ultimately going to be a lot cheaper than redoing all of the software.
Given the points that you had, having it in Android and iOS will have a very wide span, given the OUB-COTUS nature of the mobile phone. It would be to have a magic wand and you should pick another platform that would have it tomorrow. Which one would that be?
So it would be RISC-V. And I say that because RISC-V is still nascent as an instruction set architecture in terms of its adoption. It's still standards-wise, a little bit more malleable than the x86 and the ARM stuff that we've all become accustomed to. And I think having the Cherry instructions in the Android profile for RISC-V would be something where we would see the emergence of an entire new class of devices. And it wouldn't be the high-end ones like the flagships that presently have these memory safety features. It would be entry-level and mid-level phones and tablets and stuff like that that would come with memory safety. And I think that would then drive memory safety ubiquity. Cherry kind of just missed the boat to be able to do that with ARM on Android first time around. And there was potentially an opportunity in the past to push it in, but that opportunity wasn't taken. And we've kind of got another swing at it now with RISC-V. But I think if we did that with RISC-V, that approach would very quickly find its way into the mainstream for everything.
Yeah, probably given the open source nature of RISC-V, we'll have maybe hopefully a better blast radius. But fingers crossed that we get closer to having a more memory-safe ecosystem.
More from The InfoQ Podcast
