Minsoo Choo Oct 16

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

Show threadDavid Chisnall (*Now with 50% more sarcasm!*)Oct 16
@minsoochoo Note that, although FreeRTOs and Zephyr do run on CHERI systems, you lose a lot of the benefits of CHERI by using them. CHERIoT RTOS shows what you can do if you assume CHERI from the start, rather than trying to retrofit it to protection models designed around MPUs, which make sharing hard.
Show threadMinsoo Choo Oct 17

@david_chisnall Yup, I also support RTOS where CHERI support has been considered from the start. But FreeRTOS and Zephyr have huge market share right now, and I think it is a good idea to provide migration-layer for projects moving from non-CHERI to CHERI hardware, mostly for evaluation phase.

In my case, my university design team uses FreeRTOS on STM32. I’m planning to port our system to CHERI on RISC-V in a few years, and using FreeRTOS for proof of concept requires minimum code change compared to porting to new operating system.

Still, CHERIoT RTOS has a compatibility layer for FreeRTOS and its documentation on porting from FreeRTOS is super clear. For new projects, I would definitely stick with CHERIoT RTOS.

https://cheriot.org/porting/freertos/2024/01/12/freertos-porting.html
https://cheriot.org/book/porting_from_freertos.html

Porting from FreeRTOS

Before writing CHERIoT RTOS, we evaluated whether we could adapt an existing RTOS to a CHERI platform. Unfortunately, we found two things that made this hard. First, most existing RTOSs began life on platforms with no possible mechanism for isolation and where every byte mattered. This meant that they often lacked even software-engineering boundaries around components (for example, we found optional ThreadX components that directly manipulated internal data structures of the ThreadX scheduler), let alone security boundaries. This meant that it was often impossible to port without a complete rewrite.

CHERIoT Platform
Show threadDavid Chisnall (*Now with 50% more sarcasm!*)Oct 17

@minsoochoo We have a FreeRTOS compatibility layer in CHERIoT RTOS. It is sufficient, for example, to run the FreeRTOS TCP/IP stack. So we have that migration path. I’d love to hear more feedback from people trying it.

We are considering doing the same for Zephyr, but Zephyr is such a mess from a security standpoint that it’s not obvious what the right approach is.

Show threadMinsoo Choo Oct 17

@david_chisnall If migration from FreeRTOS to CHERIoT RTOS’s compatibility layer requires no code change, then using CHERIoT RTOS from the start should be sufficient for my use case.

I really want to experiment stuff on Sonata board. It’s bit pricy for a student (600 CAD), but it is definitely worth the price.

Show threadDavid Chisnall (*Now with 50% more sarcasm!*)Oct 17
@minsoochoo We should have chips out next year, which will be much cheaper than the FPGA on the Sonata board!
Show threadMinsoo Choo 
@david_chisnall 🚀🚀
Oct 17 at 3:32pmWeb