For years, academic hiring and promotions (in computer science, at least) have focused on precisely one thing: number of first-author papers in top-tier venues.

Focusing on the number of papers encourages people to publish the so-called minimum publishable unit: The smallest thing that stands a chance of being accepted. This discourages large research projects where you may take multiple years to reach something worthy of a top-tier venue. It also discourages high-risk projects (or, as they are more commonly called: research projects) because there’s a chance of not reaching a publishable unit at all.

Focusing on first author publications discourages collaborations. If two people work on a project that leads to a paper, only one will get the first-author credit. If a large project needs ten people on it, you need to do ten publications per year for it to have the same return on investment as everyone doing small incremental projects.

The net result of this is that even top-tier venues are saturated with small incremental projects. Academics bemoan this fact, but continue to provide the same incentives.

In the #CHERIoT project, we have tried, in a small way, to push back on this. We list authors in alphabetical order and we add an asterisk for people who deserve the conventional idea of ‘first author’ credit. Alphabetical order makes it clear that the author list is not sorted by contribution size (and such a total ordering does not exist when multiple authors made indispensable contributions in wildly different areas).

I was incredibly disappointed with the PC Chairs at the #ACM conference for a recent accepted submission deciding to push back on this (in particular, on including the exact same words that we used in our MICRO paper). ACM should be actively trying to address these problems, not enabling editorial policies that perpetuate them. If I had understood that the venue had such a strong objection to crediting key contributors, I would not have submitted a paper there nor agreed to give a keynote at one of the associated workshops.

I am in the fortunate position that paper credit no longer matters in my career. But that doesn’t mean that I am happy to perpetuate structural problems and it is very sad to see that so little thought is given to them by the organisations with the power to affect change.

The one exception that I have seen, which deserves some recognition is the Research Excellence Framework (REF) which is used to rank UK universities and departments. This requires a small number of ‘outputs’ (not necessarily papers) by each department, scaled by the number of research staff but not directly coupled to the individuals. These outputs are ranked in a number of criteria, of which publication venue is only one. It is not perfect (you will hear UK academics complaining about the REF with increasing frequency over the next couple of years as we get closer to the deadline for submission in the next round), but at least it’s trying.

Simply not actively trying to make the problem worse is a low bar that I would previously have expected any conference to clear.

I just tried cloc on the #CHERIoT RTOS repo. Over 1/3 of the non-blank lines in the RTOS are comments. On top of that, the book describing how to use it is aroudn 62,000 words (so around six words per line of code in the RTOS), not including example code.

We’re starting to upstream CHERI support to LLVM!

#CHERI #CHERIoT @cheri_alliance

Since I'm looking for new opportunities, are there any companies hiring for #CHERIoT right now? If so, I'd love to have a chat and see if there is a match.

Ooo, fun. All of the Linux tools that we ship in the #CHERIoT dev container work in the Linuxulator on #FreeBSD with #Podman

There appears to be a bug in the Podman with image tags that are multi-arch manifests if you specify --os Linux: it downloads the image and then fails to run it. If you specify the tag for the x86-64 version, it works fine.

Compiled and tested cheriot-clang21 preview against Sail tonight.

Very nice.

Put a smile on my face.
Owen is a legend.

#CHERI #CHERIoT
@cheri_alliance

Excellent news yesterday, the #CHERIoT RTOS paper was accepted at SOSP!

Huge thanks to @hle, who led on rewriting the rejected submission and made numerous improvements to the implementation.

We now have CHERIoT papers in top architecture and OS venues, I guess security and networking are the next places to aim for!

Since working on #CHERIoT, I've been surprised at how many other potential security problems I can just ignore if I have temporal memory safety that works in the presence of malicious compartments.

If I free an object, I guarantee that nothing else I care about will alias it. Another compartment may have kept a reference, but they either claimed it (and so it counts against their quota) or didn't (in which case its pointer stops working right now).

A whole chunk of the TLS stack can be riddled with TOCTOU bugs and I don't care because the scoped delegation mechanism means that, once a receive call has returned from the TCP/IP stack, I know that the TCP/IP stack can't hold a pointer to it, so the only thing that can mutate the object is the TLS compartment (and it's not actively trying to attack itself), so as long as it doesn't check something in the packet and then mutate it, it's fine: nothing else can, not even untrusted assembly code in the TCP/IP stack.

I guess it's not surprising that it's easier to build secure systems if the hardware and core platform give you a sensible set of core guarantees.

Exciting to see the first #Rust code running on #CHERIoT! Edoardo has rebased the Kent work on a newer rustc and added the CHERIoT bits so we can now add two integers together in Rust!

Probably other things work too. The core library compiles, but not much of it is tested. Cross-compartment calls aren’t possible yet and the alloc crate needs implementing wrapping our shared heap (there’s also a fun project at UBC to replace our allocator with a formally verified one in Rust, but it’s not there yet and, of course, depends on Rust working).

I realised my previous post about why we wrote a new RTOS for #CHERIoT was light on details. The core reason is at the end of the new post: We don't want to build a system that is secure, where people can then layer insecure things on top, we want to build the core that enables you to build secure systems. And that requires rethinking a lot of core OS abstractions with usability and security as core requirements. We can't do that by retrofitting CHERI to an existing system.

Does anyone know if GitHub Code Spaces work in China (specifically, Shanghai)? We are hoping to use them for a #CHERIoT tutorial at the RISC-V event in a few weeks.

A few people have asked me recently questions along the lines of ‘how mature is #CHERI as a technology?’ The analogy that I usually use is the 386’s memory management unit (MMU). This shipped 40 years ago, at a time when most desktops did not do memory protection, though larger systems usually did. Similarly, most systems today do not do object-granularity memory safety.

The 386 shipped after the 286 had tried a very different model for the same goal and had failed to provide abstractions that were usable and performant. Similarly, things like Intel MPX have failed to provide the memory safety guarantees of CHERI and thins like Arm’s POE2 have failed to provide the kind of useable programmer model for fine-grained compartmentalisation model that CHERI enables, yet both technologies have shown that these are important problems to solve.

The 386’s MMU had a bunch of features that you’d recognise today. Page tables were radix trees, for example, just as they are on a modern system. It wasn’t perfect, but it was enough for Linux and Windows NT to reach Bill Gates’ goal of ‘a computer on every desk’, at least in wealthy countries (and the cost of the MMU was not the blocker elsewhere). For over 20 years, operating systems were able to use it to provide useful abstractions with strong security properties.

It was not perfect. Few people thought, in 1985, that PCs would run VMs because they barely had enough memory to run two programs, let alone two operating systems. But the design was able to evolve. It grew to support more than 4 GiB of physical memory with PAE, to support nested paging for virtualisation with VT-x, and so on. It made some mistakes (read permission implied execute, for example) but these were fixed in later systems that were able to provide programmers with the same abstractions.

And this is why I’m excited about the progress towards the Y (CHERI) base architecture in RISC-V, and why I believe now is the right time for it. There’s a lot of CHERI that’s very stable. Most of the things from our 2015 paper are still there. A few newer things are also now well tested and useful. These are an excellent foundation for a base architecture that I’m confident we can standardise and that software and hardware vendors can support for at least the next 20 years.

At the same time, in #CHERIoT (and some other projects) we have a few extensions that we know are validated in software and very useful in some domains (in our case, for microcontrollers) but not as useful elsewhere. Some of the things we’ve done in CHERIoT would be terrible ideas in large out-of-order machines, but would be great to standardise as extensions because they are useful on microcontrollers, and some might be useful on some accelerators. It would be great if these could share toolchain bits.

There are also some exciting research ideas. I’d be much less excited by CHERI if I thought we were finished. 40 years after MMUs became mainstream, people are still finding exciting new use cases for them and new ways to extend them to enable more software models and that’s what a new foundational piece of architecture should provide. I firmly believe CHERI has the same headroom. After Y is standardised, I expect to see decades more vendor and standard extensions that are doing things no one has thought of yet, but which would be impossible without CHERI as a foundation.

Receiving the IEEE Symposium on Security and Privacy's Test of Time Award for our 2015 CHERI paper seemed like a good time to reflect on how #CHERI has evolved (and how it has remained the same) over the past decade

This mostly focuses on the road to #CHERIoT, there's a lot more going on in the wider ecosystem.

If anyone is going to be at #CyberUK this week, drop by the SCI Semiconductor stand and say hi! We will he showing what you can do with the #CHERIoT platform.

First copies of the first print edition of the #CHERIoT Programmers' Guide are here!

SCI Semiconductor will have some to hand out at #CyberUK next month in the DSIT SME Innovation Zone.

The first retailers are now advertising available copies of the #CHERIoT Programmers' Guide print edition!

The first edition of the #CHERIoT book has been published!

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 drafts of the second edition remain free (HTML, ePub, PDF) from the CHERIoT site

Thanks to Discribe Hub for funding a lot of the work on this edition!

We ported #Microvium to #CHERIoT several years ago, but never got around to writing up the details. For anyone interested in how CHERIoT can help you extend safe-language guarantees across an FFI boundary.