#cheri — Public Fediverse posts
Live and recent posts from across the Fediverse tagged #cheri, aggregated by home.social.
-
BSDCan https://www.bsdcan.org/2026/ Talk Saturday 2026-06-20: 14:30 - 15:20 DMS 1130
Bringing memory safety to BSD with CHERI
Brooks Davis
https://www.bsdcan.org/2026/timetable/timetable-Bringing-memory-safety.html
To register https://www.bsdcan.org/2026/registration.html @bsdcan #openbsd #freebsd #netbsd #cheri -
CW: computer stuff
TIL about the #CHERI technology. If you are into anything from programming languages to computer architecture and haven't encountered it yet, I suggest you have a look:
https://en.wikipedia.org/wiki/Capability_Hardware_Enhanced_RISC_Instructions
https://cheri.cst.cam.ac.uk/
https://cheri-alliance.org/ -
When we originally created #CHERIoT, we added an instruction to make accessing globals uniform with respect to the rest of RISC-V. We fairly quickly realised it wasn’t a great design, but the toolchain changes required to eliminate it took a while.
We’ve finally done it and I spent a bit of time this week writing up our journey. Removing this instruction is something we always planned to do before rebasing on the upcoming RV32YE base.
-
When we originally created #CHERIoT, we added an instruction to make accessing globals uniform with respect to the rest of RISC-V. We fairly quickly realised it wasn’t a great design, but the toolchain changes required to eliminate it took a while.
We’ve finally done it and I spent a bit of time this week writing up our journey. Removing this instruction is something we always planned to do before rebasing on the upcoming RV32YE base.
-
When we originally created #CHERIoT, we added an instruction to make accessing globals uniform with respect to the rest of RISC-V. We fairly quickly realised it wasn’t a great design, but the toolchain changes required to eliminate it took a while.
We’ve finally done it and I spent a bit of time this week writing up our journey. Removing this instruction is something we always planned to do before rebasing on the upcoming RV32YE base.
-
When we originally created #CHERIoT, we added an instruction to make accessing globals uniform with respect to the rest of RISC-V. We fairly quickly realised it wasn’t a great design, but the toolchain changes required to eliminate it took a while.
We’ve finally done it and I spent a bit of time this week writing up our journey. Removing this instruction is something we always planned to do before rebasing on the upcoming RV32YE base.
-
When we originally created #CHERIoT, we added an instruction to make accessing globals uniform with respect to the rest of RISC-V. We fairly quickly realised it wasn’t a great design, but the toolchain changes required to eliminate it took a while.
We’ve finally done it and I spent a bit of time this week writing up our journey. Removing this instruction is something we always planned to do before rebasing on the upcoming RV32YE base.
-
A couple of talks I've given recently about #CHERI have had people ask about performance overheads. That's a difficult question to answer, so probably benefits from a longer answer:
First, measuring performance overhead of hardware features is hard. A small tweak to a prefetcher, for example, may cause a 15% speedup on some workloads, but a 10% slowdown on others. I saw this with some Arm performance data on MTE, where one benchmark got measurably faster with MTE enabled. It turned out that enabling MTE disabled a specific prefetcher and this prefetcher made the benchmark performance worse (but made performance of others better and was typically a net win).
This is especially complicated for hardware because building an SoC is complicated. There are a lot of design decisions that trade performance, area, and power in different ways. Designers will optimise performance within the other constraints for workloads that they expect customers to care about. If you want to have a completely fair measure of how much feature X costs or helps performance, you need to have two equally competent teams build implementations, with the same budget.
If you do that (which, to be clear, is infeasible), you still have the problem of measurement. For example, AVX probably makes things faster (wider vectors, yay!), but moving between SSE and AVX vectors can make things slower. Turning on AVX can cause thermal throttling to kick in earlier and so make things slower. Even with a feature designed solely for performance, determining the degree to which is makes things faster (or if it does) is hard.
So, where does this leave us? We can talk about the unavoidable costs of CHERI. Capability checks must happen on every load, store, or jump, but that's a handful of fairly simple ALU operations in the load-store units. Those are very simple in comparison to memory-access logic. Pointers get bigger, and that's a real concern for performance, but you typically don't see a gradual decline from this, you see a cliff when workloads suddenly stop fitting in each layer in the cache hierarchy or in the TLB. An SoC design can size some of these structures differently to mitigate this, and you may be able to use larger cache lines rather than more associativity sets. There's a lot of performance tuning to be done here in a production SoC and it's not clear what the real impact would be. Beyond that, you have a bit of area overhead at the bottom of the memory hierarchy for storing tags. But that's basically everything.
What about the flip side? How much does CHERI improve performance? If you're doing mitigations against transient execution vulnerabilities, such as speculative taint tracking, CHERI can improve things. In a conventional STT implementation, an instruction that adds two integers to compute an address and then does a load can't retire until after both are untainted. On a CHERI system, only the capability operand needs to be untainted, the offset can be an arbitrary speculated value. Similarly, knowing that something is a pointer and what its bounds are enables better prefetching. There are even some fun things like connecting register writeback to the branch predictor (for shorter pipelines), because you know which things in the register are executable pointers and so can make a very good guess about which address is going to be a jump target. And that's ignoring the performance gains from simply disabling a load of weaker mitigations that people are shipping today.
That's all at the small scale though. Being able to share object graphs between mutually distrusting components can eliminate some large defensive copies. Last time I did a detailed look, Apple's XPC framework for process-base compartmentalisation did seven copies of objects sent between processes. In a CHERI system, that would be either zero or one, depending on your threat model, and would involve a lot less TLB pressure.
The kinds of overheads we see are hard to measure because they're well into the noise. The performance improvements we see from being able to actually build the systems programmers want to construct, without fighting hardware designed with totally different goals in mind, are much easier to measure. They tend to be complexity-class improvements: turning O(n) things into O(1) things. Or, sometimes, just a factor of 2-3 speedup.
-
I commend this #podcast episode to the house: https://softwareengineeringdaily.com/2026/03/31/freebsd-with-john-baldwin/
-
I commend this #podcast episode to the house: https://softwareengineeringdaily.com/2026/03/31/freebsd-with-john-baldwin/
-
I commend this #podcast episode to the house: https://softwareengineeringdaily.com/2026/03/31/freebsd-with-john-baldwin/
-
I commend this #podcast episode to the house: https://softwareengineeringdaily.com/2026/03/31/freebsd-with-john-baldwin/
-
I commend this #podcast episode to the house: https://softwareengineeringdaily.com/2026/03/31/freebsd-with-john-baldwin/
-
To those who miss (part of) #CHERI Blossoms, good news, from the organizers:
> the presentations and recordings will be available on the cheri-alliance.org website a week or so after the event.
🥳
-
We’ll be talking more about the progress on the CHERIoT port of Rust at CHERI Blossoms next week, but here’s a teaser:
The embedded graphics crate rendering an image on Sonata. This currently using a (memory-safe) C function to draw pixels (that can go away with a little bit more work) but the current compiler is able to build this crate and run it in a CHERIoT compartment.
-
We’ll be talking more about the progress on the CHERIoT port of Rust at CHERI Blossoms next week, but here’s a teaser:
The embedded graphics crate rendering an image on Sonata. This currently using a (memory-safe) C function to draw pixels (that can go away with a little bit more work) but the current compiler is able to build this crate and run it in a CHERIoT compartment.
-
We’ll be talking more about the progress on the CHERIoT port of Rust at CHERI Blossoms next week, but here’s a teaser:
The embedded graphics crate rendering an image on Sonata. This currently using a (memory-safe) C function to draw pixels (that can go away with a little bit more work) but the current compiler is able to build this crate and run it in a CHERIoT compartment.
-
We’ll be talking more about the progress on the CHERIoT port of Rust at CHERI Blossoms next week, but here’s a teaser:
The embedded graphics crate rendering an image on Sonata. This currently using a (memory-safe) C function to draw pixels (that can go away with a little bit more work) but the current compiler is able to build this crate and run it in a CHERIoT compartment.
-
We’ll be talking more about the progress on the CHERIoT port of Rust at CHERI Blossoms next week, but here’s a teaser:
The embedded graphics crate rendering an image on Sonata. This currently using a (memory-safe) C function to draw pixels (that can go away with a little bit more work) but the current compiler is able to build this crate and run it in a CHERIoT compartment.
-
Me? Trolling the other microcontroller vendors? Surely not! Maybe if they had bothered to do something about the most common source of vulnerabilities at some point in the last few decades, the could have been on the other side of the sign...
-
Me? Trolling the other microcontroller vendors? Surely not! Maybe if they had bothered to do something about the most common source of vulnerabilities at some point in the last few decades, the could have been on the other side of the sign...
-
Me? Trolling the other microcontroller vendors? Surely not! Maybe if they had bothered to do something about the most common source of vulnerabilities at some point in the last few decades, the could have been on the other side of the sign...
-
Me? Trolling the other microcontroller vendors? Surely not! Maybe if they had bothered to do something about the most common source of vulnerabilities at some point in the last few decades, the could have been on the other side of the sign...
-
Me? Trolling the other microcontroller vendors? Surely not! Maybe if they had bothered to do something about the most common source of vulnerabilities at some point in the last few decades, the could have been on the other side of the sign...
-
Yay, we won a Best in Show Award at #EmbeddedWorld ! In the Microcontrollers, Microprocessors, and IP category for our ICENI #CHERIoT chips!
-
Yay, we won a Best in Show Award at #EmbeddedWorld ! In the Microcontrollers, Microprocessors, and IP category for our ICENI #CHERIoT chips!
-
Yay, we won a Best in Show Award at #EmbeddedWorld ! In the Microcontrollers, Microprocessors, and IP category for our ICENI #CHERIoT chips!
-
Yay, we won a Best in Show Award at #EmbeddedWorld ! In the Microcontrollers, Microprocessors, and IP category for our ICENI #CHERIoT chips!
-
Yay, we won a Best in Show Award at #EmbeddedWorld ! In the Microcontrollers, Microprocessors, and IP category for our ICENI #CHERIoT chips!
-
🚀🤖 "CHERI with a #Linux hat" is the latest #geekfest where nerds dream of rearchitecting the universe with "capabilities" that sound like #access #control for your #toaster. 🍞🔐 Meanwhile, #Carl #Shaw showcases yet another attempt to make #Linux run on something other than your grandfather's calculator. 😂
https://lwn.net/Articles/1037974/ #CHERI #capabilities #innovation #HackerNews #ngated -
It was a great evening.
Both talks were great. Christian Farrow (@zedstarr) did an entertaining talk about about time synchronisation and atomic clocks, which was really good. Sadly it was so interesting I forgot to take any pictures.That is the second talk about time I heard at #NetMCR, but both were great and there was no overlap in information, surprisingly!
Apparently around #Nicosia is where the most spoofed GPS signals in the world happen.
Sam Cater (https://uk.linkedin.com/in/samalexcater) also gave a very interesting talk about #CHERI (https://www.cl.cam.ac.uk/research/security/ctsrd/cheri/) and what it does.
This was also great as I'd heard of the term, but that was about it. -
#FreeBSD30 timeline - a few things that happened during these 30 #FreeBSD years:
#UNIX #BSD #MULTICS #1BSD #2BSD #42BSD #43BSD #386BSD #ipfw #FreeBSDCon #BSDCON #ports #jails #FreeBSDFoundation #kqueue #EuroBSDCon #CoreTeam #AsiaBSDCon #BSDCAN #pf #OpenBSD #ZFS #DTrace #VNET #Capsicum #Cheri #Poudriere #clang #llvm #subversion #OpenZFS #git
-
One of our founding directors, Mike Eftimakis, sat down with Akshaya Asokan from Information Security Media Group (ISMG) to explore how CHERI is helping tackle one of cybersecurity’s biggest challenges: memory safety.
CHERI (Capability Hardware Enhanced RISC Instructions) is a hardware-based approach to security, designed to prevent around 70% of today’s common vulnerabilities. Backed by industry leaders and the UK government, we're working to ensure global adoption across the electronics supply chain.
Watch the interview to learn more about:
💠 How CHERI addresses memory safety issues
💠 Common hardware supply chain vulnerabilities
💠 Progress on adoption by chipmakers
💠 Scalability challenges associated with CHERI🎥 Watch the full interview: https://www.bankinfosecurity.com/uks-cheri-alliance-expands-to-global-hardware-supply-chain-a-28942
#CHERI #CyberSecurity #HardwareSecurity #MemorySafety #SecurityByDesign #InfoSec
-
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.
-
Colin Percival's AWS re:Invent asks
https://www.daemonology.net/blog/2024-12-04-My-reinvent-asks.html
-
Do you want to see #CHERIoT talking to #Morello, showing big server and tiny IoT-class #CHERI systems from the #DSbD ecosystem? Come to the UKRI stand at CyberUK this week!
-
@bugaevc I'll mention, but not advocate, CheriBSD <https://www.cheribsd.org/> …
-
Ed Maste, Senior Director of Technology at The FreeBSD Foundation, discusses the rapidly-evolving interplay between hardware, cybersecurity, open source, and instruction set architectures.
<https://hackernoon.com/the-cybersecurity-battle-has-come-to-hardware>
#RISCV #Arm #Morello #CHERI #CheriBSD #hardware #ISA #security #cybersecurity #University #Cambridge #SRI #FreeBSD
-
Some more relevant links:
https://freebsdfoundation.org/wp-content/uploads/2023/06/20230207-freebsd-use-cases.pdf
-
I'm joining @cheri_alliance@[email protected] 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.
-
“Fil-C: A Memory-Safe C Implementation”, LWN (https://lwn.net/SubscriberLink/1042938/658ade3768dd4758/).
On HN: https://news.ycombinator.com/item?id=45735877
On Lobsters: https://lobste.rs/s/mg0aur/fil_c_memory_safe_c_implementation
-
First Post! Uh, I mean, First CHERIoT Silicon!
We have our first chips back! It is very exciting! Spatial and temporal memory safety, fine-grained compartmentalisation, and also a load of other big chips on a board, so you can play 'Where's ICENI?' on the board picture!
-
@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!
-
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!