#cheri — Public Fediverse posts

🚀 Call for Speakers: CHERITech'26 @ SEMICON Europa

This year, #CHERITech is going bigger than ever.

On 12-13 November 2026, CHERITech'26 will take place alongside SEMICON Europa in Munich, Europe's leading microelectronics and semiconductor event, organised by SEMI Europe.

This provides a unique opportunity to showcase #CHERI to an audience of more than 80,000 technology and semiconductor professionals from around the world.

Whether you're working on cutting-edge research, deploying CHERI in products, building tools, influencing standards, or helping drive adoption, we'd love to hear from you.

🎤 We're looking for:
✅ Technical talks and demonstrations
✅ Industry deployment experiences
✅ CHERI-enabled products and services
✅ Research breakthroughs and new innovations
✅ Posters and visual demonstrations
✅ Stories that show CHERI moving towards mainstream adoption

We are also particularly interested in submissions that showcase real-world impact and practical adoption.

📅 Key Dates
• Abstract submission deadline: 15 September 2026
• Acceptance notification: 30 September 2026
• Final slides due: 15 October 2026
• Conference: 12-13 November 2026

👉 Submit your proposal today: https://cheri-alliance.org/events/cheritech26/call-for-papers/

🔒 The EU Cyber Resilience Act is coming. Are you ready?

From December 2027, products sold in the EU with a digital element will face new cybersecurity requirements under the #CRA.

Join Tariq Kurd (Codasip) for an insightful discussion on why the CRA is expected to increase demand for #CHERI and what it means for industry, followed by live a Q&A session.

📅 9 September
🕑 2:00 PM UK Time
📍 Online via Zoom
🎟️ Free to attend

🎟️ Register here: https://cheri-alliance.org/events/webinar-cheri-cra-compliance/

From some folks at Ericsson who have done some interesting CHERI work:

Ericsson is currently hiring researchers with a PhD (or soon-to-graduate PhD candidates) with hardware security background for the R&D site in London, UK. Experience with HDL and CHERI hardware is considered a merit. For more information on how to apply, please see the full job description at:

https://jobs.ericsson.com/careers/job/563121776954881

#CHERI #GetFediHired

The recording (and transcript, for the sensible people who don't want to listen to me speaking) of my March QCon talk is online!

If you want to understand how CHERI works and the relationship between memory safety and compartmentalisation, and why starting from a programmer model is essential if you want to build useful hardware, here you go!

#CHERI #CHERIoT #QCon #Compartmentalisation #MemorySafety

CHERIoT: Wie Microsoft und Cambridge Embedded-Systeme endlich speichersicher machen wollen ― Martin Rings

https://martinrings.de/elektronik/cheriot-platform/

"Die Zahl vernetzter Embedded-Systeme wächst rasant. Vom Smart-Home-Gerät über industrielle Steuerungen bis hin zu autonomen Fahrzeugen laufen heute Milliarden Geräte dauerhaft mit dem Internet verbunden. Gleichzeitig basiert ein großer Teil dieser Systeme noch immer auf klassischem C- oder C++-Code – und damit auf einer Technologie, die seit Jahrzehnten für Sicherheitsprobleme wie Buffer Overflows, Use-after-Free-Fehler oder Speicherkorruption bekannt ist. …"

2026-05-14

#CHERI #CHERIoT #Microsoft #Cambridge

Debugging with CHERI | FreeBSD Foundation https://freebsdfoundation.org/our-work/journal/browser-based-edition/improving-software-quality/debugging-with-cheri-2/

#cheribsd #cheri #bsd

Je ne vais pas bien (Alaa al-Qatraoui)

https://arbrealettres.wordpress.com/2026/07/09/je-ne-vais-pas-bien-alaa-al-qatraoui/

I wrote this post over a year ago, but it probably needs repeating periodically. From my perspective, CHERI isn't really about security, it's about making it possible to solve a bunch of interesting language-interoperability and end-user-programming problems that happen to need a bunch of security fixed as building blocks. And so we get a load of security stuff for free. But that's not why I worked on it.

#CHERI #CHERIoT

One of the things that was drummed into my head repeatedly working with the late Ross Anderson was that most security problems are usability problems. It doesn't matter how secure your cryptosysetm is if people send unencrypted messages because they can't understand how to do key exchange. It doesn't matter how secure and fine-grained your sandboxing is if it has a user-prompted privilege elevation mechanism and users are trained to just hit 'approve' every time a dialog pops up.

This is why #CHERIoT focused so heavily on building a usable programmer model from the start. Compartments communicate with other compartments by calling functions. Compartments share objects by passing pointers to them. Compartments have a mechanism to expose type-safe opaque types and that's surfaced directly in the source languages. There is no look-aside policy that you have to read to know whether a compartment exercises some right: it's all explicit in the source code.

WebAssembly makes it easy to do the same kind of isolation, but not the sharing. A C pointer in WebAssembly is a 32-bit offset into a memory. If you want an object that's shared between two WebAssembly sandboxes, that's a totally different kind of pointer. Early CHERI work tried this and we gave up because the cognitive load and porting effort of having two kinds of pointer was too painful.

#cheri

RE: https://mastodon.bsd.cafe/@grahamperrin/116708332410403878

Preparing for a ‘vulnerability patch wave’ | National Cyber Security Centre

https://www.ncsc.gov.uk/blogs/prepare-for-vulnerability-patch-wave

＂Patching alone won’t address the systemic problems that my previous blogs have addressed. I’ve appealed to technology producers and vendors to ensure systemic technical security debt is minimised by including - where appropriate - memory safety and containment technologies such as CHERI and others. …＂

#CHERI #AI #cyberstrategy #CNI

cc @david_chisnall FYI I found this NCSC blog post indirectly via the closing line at <https://www.aisi.gov.uk/blog/our-evaluation-of-claude-mythos-previews-cyber-capabilities>.

Is this a reasonable definition of memory safety?

"Memory safety is a property, where all memory access is mediated by the platform to ensure that program memory can only be changed using the appropriate library functions."

(I feel ones at https://www.memorysafety.org/docs/memory-safety/ and https://en.wikipedia.org/wiki/Memory_safety start out too abstractly)

#security #cheri #memoryManagement

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

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.

#CHERI #RISCV

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/

#FreeBSD #CHERI #CheriBSD

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.

#Rust #CHERI #CHERIoT #CHERIBlossoms

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

#CHERI #CHERIoT #SeriouslyFolksItsBeen40Years

Yay, we won a Best in Show Award at #EmbeddedWorld ! In the Microcontrollers, Microprocessors, and IP category for our ICENI #CHERIoT chips!

#CHERI

The PQCA has published a blog by me about using their ML-KEM and ML-DSA libraries on CHERIoT

#PQC #CHERIoT #CHERI

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 #CHERIoT

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

🚨 Cybercrime is exploding — regulators aren’t waiting, you shouldn’t either! 🚨

The EU Cyber Resilience Act (CRA) is about to change everything: from 2027, products must be secure, maintained through their lifecycle, and ready for scrutiny… or they will not be sellable anymore!

Cybersecurity must be embedded as a core design principle from day one. If your organisation isn’t designing secure‑by‑design systems today… you’re already behind.

⭐️ Get ahead of the curve, #CHERI can help you. Read Tariq Kurd's blog: https://cheri-alliance.org/the-eu-cyber-resilience-act-what-it-means-for-secure-by-design-systems-and-cheri/