It sped up, so I could do this before I left for the weekend #CheriBSD #cheri

It sped up, so I could do this before I left for the weekend #CheriBSD #cheri

It's here! #cheri #CheriBSD

It's here! #cheri #CheriBSD

#CHERI enabled hardware is cool. Every compiler engineer should be looking at the potential for using hardware-level pointer capabilities.

@cheri_alliance has posted about the Secure Horizons event in Duxford next week, which will be a great event for people who want to understand how CHERI (and, especially, CHERIoT) can make regulator compliance easier for secure IoT devices (as well as actually making them more secure).

Registration is still open and some SCI folks will be there!

#CHERI #CHERIoT #CRA #IoT

For anyone who missed CHERITech, there’s an online after party on the 4th! The talks will be online shortly and then CHERITech Reloaded will give you an opportunity to ask questions.

So you have two weeks to think of awkward questions for me about CHERIoT Audit! Good luck!

#CHERI #CHERIoT #CHERITech #CHERITech25

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

Yay, the embargo was finally lifted yesterday so we can talk about the UK Government funding for #CHERIoT!

They funded us (SCI) to do two projects, for a total of £7.7M:

• Bring #Rust on CHERIoT to production qualities.
• Build our second-generation chip with a dual-issue core, post-quantum crypto hardware, and an edge inference accelerator.

#CHERI

Yay, the embargo was finally lifted yesterday so we can talk about the UK Government funding for #CHERIoT!

They funded us (SCI) to do two projects, for a total of £7.7M:

• Bring #Rust on CHERIoT to production qualities.
• Build our second-generation chip with a dual-issue core, post-quantum crypto hardware, and an edge inference accelerator.

#CHERI

Sealing is one of the most powerful abstractions in #CHERI systems, because a tiny bit of hardware lets you turn a lot of software-engineering boundaries into security boundaries. In this post, I discuss how we make extensive use of this low-level feature throughout the #CHERIoT platform:

I'm joining @cheri_alliance@cheri_alliance@infosec.exchange as an ambassador, working to transform cybersecurity at its foundation.

Memory safety bugs cause 70% of cyber vulnerabilities, leading to disasters like OpenSSL Heartbleed and the 2024 CrowdStrike outage ($5.4 billion in losses). CHERI technology, developed over 15 years by Cambridge University and SRI International, prevents these attacks through hardware-enforced memory protection rather than endless software patches.

The momentum is extraordinary. The UK government invested £80 million alongside £200 million from industry, with backing from DSIT, NCSC/GCHQ, DSTL, and DARPA. Industry giants Google, Microsoft, and Arm have joined alongside BT Group and Siemens, recognizing that hardware-level security is no longer optional.

I'm particularly excited about our working groups porting critical operating systems to CHERI. FreeBSD, FreeRTOS, Zephyr, and seL4 have all been ported to run on CHERI hardware, with teams actively developing and maintaining these implementations. This ecosystem work ensures CHERI can protect everything from embedded IoT devices to enterprise servers, making memory safety accessible across the entire computing stack.

Microsoft found CHERI would have prevented two-thirds of their 2019 vulnerabilities. The technology is practical too – existing software often needs less than 0.03% code changes to become memory-safe. As we deploy AI and connect critical infrastructure, we can't afford to keep patching symptoms. CHERI addresses the root cause.

Join us in building secure-by-design systems. The Alliance welcomes all who share this vision. Let's stop playing defense and fundamentally solve memory safety.

#Cybersecurity #CHERI #MemorySafety #SecureByDesign

I'm joining @cheri_alliance@cheri_alliance@infosec.exchange as an ambassador, working to transform cybersecurity at its foundation.

Memory safety bugs cause 70% of cyber vulnerabilities, leading to disasters like OpenSSL Heartbleed and the 2024 CrowdStrike outage ($5.4 billion in losses). CHERI technology, developed over 15 years by Cambridge University and SRI International, prevents these attacks through hardware-enforced memory protection rather than endless software patches.

The momentum is extraordinary. The UK government invested £80 million alongside £200 million from industry, with backing from DSIT, NCSC/GCHQ, DSTL, and DARPA. Industry giants Google, Microsoft, and Arm have joined alongside BT Group and Siemens, recognizing that hardware-level security is no longer optional.

I'm particularly excited about our working groups porting critical operating systems to CHERI. FreeBSD, FreeRTOS, Zephyr, and seL4 have all been ported to run on CHERI hardware, with teams actively developing and maintaining these implementations. This ecosystem work ensures CHERI can protect everything from embedded IoT devices to enterprise servers, making memory safety accessible across the entire computing stack.

Microsoft found CHERI would have prevented two-thirds of their 2019 vulnerabilities. The technology is practical too – existing software often needs less than 0.03% code changes to become memory-safe. As we deploy AI and connect critical infrastructure, we can't afford to keep patching symptoms. CHERI addresses the root cause.

Join us in building secure-by-design systems. The Alliance welcomes all who share this vision. Let's stop playing defense and fundamentally solve memory safety.

#Cybersecurity #CHERI #MemorySafety #SecureByDesign

Honestly, #CHERI deserves more hype than LLMs.

Honestly, #CHERI deserves more hype than LLMs.

RE: https://infosec.exchange/@cheri_alliance/115304565481924558

Morello is a modified quad-core Neoverse N1 with CHERI support. The UK Government funded a lot of the development and there are a few tens of them left over that don't yet have homes.

They look like real computers (ATX case, HDMI out). The under my desk runs CheriBSD (FreeBSD fork), KDE with its Wayland compositor and a bunch of userspace apps, with everything including the GPU drivers memory safe. It can also run AArch64 binaries, but that's less fun.

If you're doing interesting research that would benefit from CHERI or if you are looking to evaluate building products on CHERI systems, reach out to the CHERI Alliance.

CHERI RISC-V (the 'Y' base) is near to standardisation, so there should be RISC-V CHERI application cores available fairly soon, but the Neoverse N1 is a fairly advanced microarchitecture (designed for server chips) and it will probably take a while for RISC-V chips to equal it in performance. It was a fairly rushed conversion to CHERI, so has a few significant performance artefacts that won't be there in a production chip, but this is still probably the best opportunity to get a desktop CHERI system for at least the next year or two.

#CHERI #Morello

🌟 BIG NEWS!! The CHERI Alliance now distributes Arm Morello boards 🌟
... the #CHERI development journey continues beyond DSbD

The CHERI Alliance is thrilled to announce that, following the end of the Digital Security by Design (DSbD) program, we have taken over distribution of the Arm Morello CHERI development boards. These boards, developed as part of the DSbD program and funded by the UK government, feature a chip developed by Arm with a powerful CHERI processor. We are excited to keep making a vital research and development platform available to the community — to discover and experiment with CHERI, but also to develop or port existing software and tools.

If you or your team are interested in obtaining a Morello board (research, teaching, prototyping, or evaluation), please contact the CHERI Alliance and tell us about your use case: https://cheri-alliance.org/contact/

Available boards are limited, so we will prioritise requests and loan the boards to the teams who will put them to the best use.

👉 We’ll be coordinating fulfillment and next steps soon. Please share this post and tag colleagues who should see it.

Excited to enable the community to use CHERI — let’s build the future of safer hardware and software together! 🙌

@david_chisnall