David Chisnall (*Now with 50% more sarcasm!*)<p><a href="https://cheriot.org/guide/book/2025/04/17/cheriot-book-published.html" rel="nofollow noopener noreferrer" target="_blank">The first edition of the #CHERIoT book has been published!</a></p><p>The eBook editions are available for purchase now from a few retailers, print editions will take a bit longer to appear (up to two weeks). And, of course, the <a href="https://cheriot.org/book/preface.html" rel="nofollow noopener noreferrer" target="_blank">drafts of the second edition remain free (HTML, ePub, PDF) from the CHERIoT site</a></p><p>Thanks to Discribe Hub for funding a lot of the work on this edition!</p>
Recent searches
No recent searches
Search options
Only available when logged in.
techhub.social is one of the many independent Mastodon servers you can use to participate in the fediverse.
A hub primarily for passionate technologists, but everyone is welcome
Administered by:
Server stats:
5.2Kactive users
techhub.social: About · Status · Profiles directory · Privacy policy
Mastodon: About · Get the app · Keyboard shortcuts · View source code · v4.3.7
#CHERIoT
2 posts · 1 participant · 0 posts today
David Chisnall (*Now with 50% more sarcasm!*)<p><span class="h-card" translate="no"><a href="https://sueden.social/@me_" class="u-url mention" rel="nofollow noopener noreferrer" target="_blank">@<span>me_</span></a></span> Welcome to the <a href="https://infosec.exchange/tags/CHERIoT" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>CHERIoT</span></a> world!</p>
David Chisnall (*Now with 50% more sarcasm!*)<p>We ported <a href="https://infosec.exchange/tags/Microvium" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>Microvium</span></a> to <a href="https://infosec.exchange/tags/CHERIoT" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>CHERIoT</span></a> several years ago, but never got around to writing up the details. For anyone <a href="https://cheriot.org/javascript/vm/2025/04/10/microvium-javascript.html" rel="nofollow noopener noreferrer" target="_blank">interested in how CHERIoT can help you extend safe-language guarantees across an FFI boundary</a>.</p>
David Chisnall (*Now with 50% more sarcasm!*)<p>One of the reasons I'm still using GitHub for a lot of stuff is the free CI, but I hadn't really realised how little that actually costs. For <a href="https://infosec.exchange/tags/CHERIoT" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>CHERIoT</span></a> <a href="https://infosec.exchange/tags/LLVM" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>LLVM</span></a>, we're using Cirrus-CI with a 'bring your own cloud subscription' thing. We set up ccache backed by a cloud storage thing, so incremental builds are fast. The bill for last month? £0.31.</p><p>We'll probably pay more as we hire more developers, but I doubt it will cost more than £10/month even with an active team and external contributors. Each CI run costs almost a rounding-error amount, and that's doing a clean (+ ccache) build of LLVM and running the test suite. We're using Google's Arm instances, which have amazingly good price:performance (much better than the x86 ones) for all CI, and just building the x86-64 releases on x86-64 hardware (we do x86-64 and AArch64 builds to pull into our dev container). </p><p>For personal stuff, I doubt the CI that I use costs more than £0.10/month at this kind of price. There's a real market for a cloud provider that focuses on scaling down more than on scaling up and made it easy to deploy this kind of thing (we spent <em>far</em> more money on the developer time to figure out the nightmare GCE web interface than we've spent on the compute. It's almost as bad as Azure and seems to be designed by the same set of creatures who have never actually met a human).</p>
David Chisnall (*Now with 50% more sarcasm!*)<p><span class="h-card" translate="no"><a href="https://sueden.social/@me_" class="u-url mention" rel="nofollow noopener noreferrer" target="_blank">@<span>me_</span></a></span> The <a href="https://infosec.exchange/tags/CHERIoT" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>CHERIoT</span></a> folks who are in town will be heading to the <a href="https://www.maypolefreehouse.co.uk" rel="nofollow noopener noreferrer" target="_blank">Maypole</a> at 6ish for beer and pizza before CHERI Blossoms. You're welcome to join us!</p>
David Chisnall (*Now with 50% more sarcasm!*)<p>Tor Jeremiassen (Google) has written up a post on <a href="https://cheriot.org/cheri/toolchain/2025/03/17/mpact_cheriot.html" rel="nofollow noopener noreferrer" target="_blank">how the MPACT simulator for #CHERIoT works</a>.</p><p>This is the fastest simulator that we currently ship, it manages around 20 MIPS on my laptop (compared to around 400 KIPS from the one generated from the formal model of the ISA). This model is designed to plug into larger system simulations, so expect to see full SoC emulators based on it!</p>
David Chisnall (*Now with 50% more sarcasm!*)<p><span class="h-card" translate="no"><a href="https://feedsin.space/feed/CHERIoT" class="u-url mention" rel="nofollow noopener noreferrer" target="_blank">@<span>CHERIoT</span></a></span> Great to see folks adopting <a href="https://infosec.exchange/tags/CHERIoT" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>CHERIoT</span></a> and learning to think about writing secure software as a side effect.</p>
David Chisnall (*Now with 50% more sarcasm!*)<p>I learned a new acronym this week: SOUP (software of unknown provenance). Unlike mushroom-identification AI, <a href="https://infosec.exchange/tags/CHERIoT" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>CHERIoT</span></a> makes your SOUP safe to consume.</p>
David Chisnall (*Now with 50% more sarcasm!*)<p>The recent news about an alleged backdoor in <a href="https://infosec.exchange/tags/ESP32" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>ESP32</span></a> chips is largely overhyped, but it’s a good opportunity to explain how we designed <a href="https://infosec.exchange/tags/CHERIoT" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>CHERIoT</span></a> <a href="https://cheriot.org/auditing/backdoor/2025/03/09/no-esp32-style-backdoor.html" rel="nofollow noopener noreferrer" target="_blank">to make this kind of attack almost impossible by construction</a>.</p><p>SCI and the CHERI Alliance will both be at Embedded World next week. Come and talk to us about CHERIoT and how you can adopt it with SCI’s ICENI chips in your next products.</p>
David Chisnall (*Now with 50% more sarcasm!*)<p><span class="h-card" translate="no"><a href="https://discuss.systems/@edwintorok" class="u-url mention" rel="nofollow noopener noreferrer" target="_blank">@<span>edwintorok</span></a></span> </p><blockquote><p>I assume that trap is a default fatal signal like SIGSEGV/SIGBUS</p></blockquote><p>On CheriBSD, it's SIGPROT, which is similar.</p><p>On <a href="https://infosec.exchange/tags/CHERIoT" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>CHERIoT</span></a> we have per-compartment error handlers, which are normally used to do a little bit of stack unwinding on fault. See: <a href="https://cheriot.org/book/compartments.html#_using_scoped_error_handling" rel="nofollow noopener noreferrer" translate="no" target="_blank"><span class="invisible">https://</span><span class="ellipsis">cheriot.org/book/compartments.</span><span class="invisible">html#_using_scoped_error_handling</span></a></p>
David Chisnall (*Now with 50% more sarcasm!*)<p><span class="h-card" translate="no"><a href="https://discuss.systems/@edwintorok" class="u-url mention" rel="nofollow noopener noreferrer" target="_blank">@<span>edwintorok</span></a></span> </p><p>My experience with embedded code on <a href="https://infosec.exchange/tags/CHERIoT" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>CHERIoT</span></a> is that memory-safety errors are pretty rare for mature codebases. </p><p>We found something similar with the original CheriBSD work: code that had run on a lot of different targets had often had memory-safety errors triggered deterministically on one of them. I found this 20 years ago with some of my own code, where some latent bugs were trivial to reproduce the first time someone tried running the code on and UltraSPARC. It's also why I still regard 'runs on a load of architectures and operating systems' as a quality badge and don't like to trust software that claims to be portable but supports on the 'big three'.</p><p>The variation in embedded targets is far greater than the variation in more mainstream software. AArch32, x86, and SPARC64 are basically identical on a spectrum that contains things like PIC24. If your code has run on a bunch of Harvard-architecture embedded devices, you've caught all of the memory-safety bugs that happen on the happy paths. The only ones left are the ones on error-handling paths.</p><p>If you're shipping safety-critical code, you <em>should</em> have test vectors that cover all of the error-handling conditions. Run that once on a CHERI system and you'll be told exactly where the memory-safety bugs are.</p>
David Chisnall (*Now with 50% more sarcasm!*)<p>Sealing remains one of my favourite features of <a href="https://infosec.exchange/tags/CHERI" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>CHERI</span></a>, and is a core part of any compartmentalisation model that's usable by programmers. In the <a href="https://infosec.exchange/tags/CHERIoT" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>CHERIoT</span></a> compiler, we've improved it by <a href="https://cheriot.org/sealing/compiler/2025/01/30/introducing-sealed-types.html" rel="nofollow noopener noreferrer" target="_blank">surfacing sealing in the C/C++ type system</a>.</p>
David Chisnall (*Now with 50% more sarcasm!*)<p>EDIT: After lots of helpful feedback in this thread, the article is now accepted. Thanks everyone who helped!</p><p>Any <a href="https://infosec.exchange/tags/Wikipedia" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>Wikipedia</span></a> editors around who can help? We are trying to get the <a href="https://en.wikipedia.org/wiki/Draft:Capability_Hardware_Enhanced_RISC_Instructions" rel="nofollow noopener noreferrer" target="_blank">article on #CHERI</a> added. It's so far been rejected three times:</p><p>First, it did not have enough independent citations. We added a lot to news articles about CHERI.</p><p>Second, it was insufficiently detailed and lacking context. We added a timeline of development, a load of cross references, and a simple introduction.</p><p>It was then rejected again because it lacks an explanation that a 15-year-old could understand. This is true of 90% of science-related articles on Wikipedia, so I'm not sure how we fix it. An explanation at that level is something I can write (I have done for the <a href="https://infosec.exchange/tags/CHERIoT" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>CHERIoT</span></a> book!) but it would then make the page 3-4 times as long and not suitable for an encyclopaedia (I've previously seen pages rejected because Wikipedia is not the right place for tutorials).</p><p>I don't understand the standards for Wikipedia and I really need some guidance for how to resolve and progress this.</p>
David Chisnall (*Now with 50% more sarcasm!*)<p>Some <a href="https://infosec.exchange/tags/CHERI" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>CHERI</span></a> philosophy for the weekend. Deconflating identifiers and capabilities has enormous security value in any setting and is an approach that <a href="https://infosec.exchange/tags/CHERIoT" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>CHERIoT</span></a> applies at all levels of the system, <a href="https://cheriot.org/cheri/philosophy/2025/01/19/capabilities-not-identifiers.html" rel="nofollow noopener noreferrer" target="_blank">from memory access up to network connections.</a></p>
David Chisnall (*Now with 50% more sarcasm!*)<p>EDIT: The <a href="https://cheriot.org/book/cheriot-programmers-guide.pdf" rel="nofollow noopener noreferrer" target="_blank">typeset draft is online</a> which has the acknowledgements in the Preface.</p><p>I've now got a hopefully-final version of the draft cover for the <a href="https://infosec.exchange/tags/CHERIoT" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>CHERIoT</span></a> Programmers' Guide. </p><p>Please can the folks who contributed cats check that I have the acknowledgement (and cat names) right? Here is the draft text:</p><p>The cats on the cover represent safe, secure, compartmentalisation (what is safer or more secure than a cat in a box?).<br>Each cat is in a separate, isolated, compartment, in the model for which<br>CHERIoT was designed.</p><p>The cat photos were contributed by some wonderful people from the Fediverse.<br>Starting at the top left, numbered left to right then top to bottom, the photo<br>credits are:</p><p>1, 3, 5, 10:<br>Photographer: James (<span class="h-card" translate="no"><a href="https://mastodon.ie/@chongliss" class="u-url mention" rel="nofollow noopener noreferrer" target="_blank">@<span>chongliss</span></a></span>), Cats: Jiji (1), Luna (3, 5), and<br>Felix (10).</p><p>2, 11:<br>Photographer: Cassian Lodge (<span class="h-card" translate="no"><a href="https://eldritch.cafe/@cassolotl" class="u-url mention" rel="nofollow noopener noreferrer" target="_blank">@<span>cassolotl</span></a></span>), Cat: Rosa</p><p>4:<br>Photographer: marinbenc (marinbenc@sigmoid.social)</p><p>6:<br>Photographer: Asta Halkjær From (<span class="h-card" translate="no"><a href="https://fedi.ahfrom.synology.me/users/ahfrom" class="u-url mention" rel="nofollow noopener noreferrer" target="_blank">@<span>ahfrom</span></a></span>), Cat: Betty Rambo.</p><p>7:<br>Photographer: vitaut (<span class="h-card" translate="no"><a href="https://mastodon.social/@vitaut" class="u-url mention" rel="nofollow noopener noreferrer" target="_blank">@<span>vitaut</span></a></span>)</p><p>8:<br>Photographer: Michael McWilliams (<span class="h-card" translate="no"><a href="https://mas.to/@MichaelMcWilliams" class="u-url mention" rel="nofollow noopener noreferrer" target="_blank">@<span>MichaelMcWilliams</span></a></span>)</p><p>9:<br>Photographer: jarkman (<span class="h-card" translate="no"><a href="https://chaos.social/@jarkman" class="u-url mention" rel="nofollow noopener noreferrer" target="_blank">@<span>jarkman</span></a></span>)</p><p>12:<br>Photographer: Isaac Freund (<span class="h-card" translate="no"><a href="https://hachyderm.io/@ifreund" class="u-url mention" rel="nofollow noopener noreferrer" target="_blank">@<span>ifreund</span></a></span>), Cat: Marzipan</p>
David Chisnall (*Now with 50% more sarcasm!*)<p>I wrote a little producer-consumer example for the <a href="https://infosec.exchange/tags/CHERIoT" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>CHERIoT</span></a> book. It's smaller and simpler than the one in the RTOS repo.</p><p>I ran it and the output was surprising. I realised that we're yielding in <code>futex_wake</code> more often than we strictly needed to.</p><p>One scheduler patch later, my example runs 35% faster and the test suite 2% faster. The network stack should also be faster, since the core structure for communication between its threads is not far off my toy example.</p><p>The things I do to avoid writing...</p>
David Chisnall (*Now with 50% more sarcasm!*)<p>There are a lot of recent improvements to the <a href="https://infosec.exchange/tags/CHERIoT" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>CHERIoT</span></a> compiler from folks at SCI Semiconductor and Google, along with community contributors. We are working towards tracking upstream LLVM and starting to upstream changes, as well as improving the developer experience. Owen Anderson has written <a href="https://cheriot.org/cheri/toolchain/2025/01/10/Clang-17-now-in-dev-container.html" rel="nofollow noopener noreferrer" target="_blank">a blog post describing some of the new improvements</a>.</p>
David Chisnall (*Now with 50% more sarcasm!*)<p>Starting the <a href="https://infosec.exchange/tags/CHERIoT" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>CHERIoT</span></a> new year with a post from Phil Day, in which he <a href="https://cheriot.org/rtos/cheri/2025/01/08/capabilities-not-trust-third-party.html" rel="nofollow noopener noreferrer" target="_blank">learns that respecting the principles of least privilege and intentional use don't just improve security, they also make it easier to understand what third-party code is doing</a>.</p>
David Chisnall (*Now with 50% more sarcasm!*)<p>I recently posted that we weren't currently hiring, but actually we are on the hardware side. We're still looking to hire some DV folks for our hardware team (full remote, UK easy, elsewhere a bit harder but may be possible).</p><p>Anyone interested in working on CHERI hardware, please ping me. Please boost if you have hardware folks in your network!</p><p><a href="https://infosec.exchange/tags/GetFediHired" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>GetFediHired</span></a> <a href="https://infosec.exchange/tags/hiring" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>hiring</span></a> <a href="https://infosec.exchange/tags/CHERIoT" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>CHERIoT</span></a></p>
David Chisnall (*Now with 50% more sarcasm!*)<p>Looks as if contracts are going to make it into <a href="https://infosec.exchange/tags/CPlusPlus" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>CPlusPlus</span></a>. The <a href="https://infosec.exchange/tags/CHERIoT" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>CHERIoT</span></a> programming guides will need updating to ensure that they are never used in our codebase, since (at least as currently specified) they are incompatible with modern software engineering practices.</p>
ExploreLive feeds
Mastodon is the best way to keep up with what's happening.
Follow anyone across the fediverse and see it all in chronological order. No algorithms, ads, or clickbait in sight.
Create accountLoginDrag & drop to upload