Hi everyone! Long ago Lobsters used to run interviews on active users. I thought that was a great idea but noticed it hadn’t happened for some time. I thought about which lobster I’d most like to see interviewed and immediately thought of David Chisnall. Enjoy!

Introduce yourself, describe what you do for work and how long you’ve been at it.

Professionally, I am currently the Director of System Architecture at SCI Semiconductor. I’ve been at that for a couple of months. About the time I was thinking about leaving Microsoft, I was introduced to someone who was putting together a startup aiming to commercialise the CHERIoT platform (which I’d open sourced at Microsoft, but which Microsoft didn’t want to sell, just to use in other products). We got on well and so I joined his team to lead the evolution of the CHERIoT ISA and software stack. We aim to ship CHERIoT chips some time this year, at which point I may finally be able to buy IoT devices that I trust to connect to my network and the Internet, for the first time. The company is still starting up, but I expect to be hiring very soon.

That covers the very recent bits, but my career has not gone in a straight line at all. I went to Swansea University because I did very badly in my A-level exams (the ones you take at 18 in the UK) and so didn’t get into any of the universities that I’d applied to. Swansea was most well known as the UK university closest to the sea. It was also home of the Swansea University Computer Society (yes, we know the acronym sucks) which popped up in the boot screen for Linux at the time because they’d written the original Linux TCP/IP stack. Folks like Alan Cox still hung around society events. I found the balance between a very theoretical course (Computer Science in Swansea acknowledged that there were machines that approximated universal models of computation, but wasn’t really in favour of touching them) and a very hands-on computer society gave a usefully broad education.

I ended up staying there for a PhD, where I met Nicolas Roard (funded on the same grant), who introduced me to Objective-C and OpenStep. I had a Mac, but hadn’t really planned on doing anything with Cocoa (which implements the OpenStep specification) because I wanted to write cross-platform things. Nicolas was a GNUstep contributor and persuaded me that it was worth writing Mac software and improving GNUstep so that it had the features to run it.

Around this time, Apple was rapidly adding Objective-C features and FSF GCC was not keeping up. I ended up being persuaded to write a new Objective-C runtime and add support for it to clang and discovered that I really enjoyed language implementation. The runtime I wrote was explicitly designed to support multiple languages and that led to a much deeper rabbit hole.

In parallel with this, I’d been actively involved in Jabber / XMPP and written a couple of clients. Peter Saint-Andre, who was driving the effort, posted to the mailing list that he had a contract for a book about the protocol but no time to write it and asked if anyone else was interested and, when I replied, he put me in touch with his editor. It turned out that another publisher had just released a Jabber book and it had not sold well, so the publisher was happy to let the project die, but they gave me some work-for-hire on a Linux book that was behind schedule. This went well and led to some regular writing for InformIT. They also asked me if I knew anyone who would be qualified to write a book on the Xen internals. I jokingly said ‘I could do it if you gave me six months to study the source code’. Six months later they came back with ‘so, that Xen book you’re going to write…’ and I ended up writing it. This was very much active procrastination: I wrote the book while avoiding working on my PhD thesis and the thesis while avoiding the book. I subsequently wrote three more books for them.

I spent the next five years working freelance, writing some code and some more books (and a lot of articles) before I came to Cambridge to work on CHERI.

What is your work/computing environment like?

I run macOS locally and use a mix of native, FreeBSD, and Linux VMs (some managed by Docker and Podman). Most of the remote machines I use are FreeBSD, with some Linux. On the floor next to me there’s a Morello desktop (CheriBSD), which I mostly use remotely. The M2 Max is fast enough that I don’t need to do much remote anymore.

What tools do you use to write software?

I keep finding myself going back to vim, not because it’s great, but because nothing else meets my requirements the same way. I want an editor that I can use with local and remote projects. VS Code has a remote extension but, because it works by running a headless instance of most of VS Code remotely, there’s a long tail of places where it doesn’t work, so I end up needing a local editor and a remote one and it’s easier if they’re the same.

Within vim, I use ALE for talking to clangd and other LSP servers (this lets me use a CHERI-aware clangd nice and easily, so all of the language extensions are supported) and I’m trying the Copilot plugin. I’m still unconvinced by Copilot but, at worst, it’s only a small net productivity drop to use it and it’s important to keep abreast of new developments in tooling.

I generally use clang for compiling, lldb for debugging. I test things with GCC if GCC supports the target and source language. Outside of Smalltalk, I’ve not found an IDE that I felt made me more productive.

How did you get started with CHERI?

I knew Robert Watson through FreeBSD. I’d ported libc++ to FreeBSD (which mostly involved implementing the POSIX 2008 xlocale APIs in libc) under contract with the FreeBSD Foundation and he’d been involved in organising that. At the time, I was still living in Swansea, which has a very low cost of living (it still does). This let me do a few days of paid work per month and spend the rest of the time on fun projects. His pitch was that, if I came to the University of Cambridge, I could work on the fun stuff full time and be paid for it.

I’d spent a lot of the previous years on Étoilé, which was a project to build a user-focused desktop environment that was built out of composable components with end-user programming as a key focus. We were inspired by the STEPS project at VPRI, which tried to build an entire system in under 20,000 lines of code. Our rule was simpler: we aimed to keep individual components to under 10 KLoC, which is small enough that a single person can understand it. This meant that we needed to be able to both use expressive languages and build expressive DSLs. We were starting from an Objective-C base, which gave us a nice model for late-bound components but brought along a lot of C baggage.

Unlike STEPs, I didn’t want to rewrite the world in high-level languages. I wanted to use things like libavcodec and libavformat as-is, but without bugs in them being able to destroy the invariants that higher-level software depended on. I’d tried building isolation mechanisms with the MMU and found it severely limiting. I’d also looked at Mondrian Memory Protection, but the table-based approach didn’t compose well with language-level abstractions. Early CHERI wasn’t the right thing either, but it was close enough that I felt I could evolve it into the right shape.

Most of my fingerprints in CHERI ISAs are with that goal in mind. I want to be able to compile existing C/C++ libraries for a CHERI compiler and use them safely from higher-level languages and use them directly. I’ve written a bit about this before:

https://www.linkedin.com/pulse/i-dont-care-memory-safety-david-chisnall

I want to be able to have documents embed scripting-language programs that can directly call large native libraries and still have strong guarantees that my system won’t be compromised. The key point is this observation:

Isolation is easy, (safe) sharing is hard.

It’s trivial to fully isolate two components. Separate cores, sandboxed processes, or WebAssembly sandboxes can give this kind of isolation, depending on the degree of isolation that you need. Most interesting things are built from communicating components and keeping things mostly isolated, but able to communicate safely, is much harder. For example, Rust says FFI is unsafe, but if you wanted it to be safe except that objects passed from Rust to C may contain arbitrary bit patterns after the call, that’s harder. You can do it with deep copies, but that’s a lot of overhead and very hard to do in the general case. You can do it with CHERI fairly easily, including richer things like deep immutability (in CHERIoT, we can also provide shallow and deep no-capture guarantees).

What was the hardest technical problem you’ve ever had to address?

That’s difficult to answer. Any problem seems easy when you know how to solve it and it’s easy to forget how much effort it took. Teaching a C/C++ toolchain that pointers and integers were, in fact, not interchangeable types might be in that space.

The one with the most evil solution is probably related to C++ exception interoperability with Objective-C. There are three C++ runtimes in wide use: libsupc++ (GNU), libc++abi (LLVM), and libcxxrt (which I wrote and is shipped by FreeBSD, Sony Playstations, OpenEnclave, and a bunch of other places). The story there is slightly annoying: I wrote libcxxrt for a company that agreed to open source it if other organisations would split the development cost. They approached the FreeBSD and NetBSD Foundations, who agreed to pay for some of it, along with Apple (who, at the time, were shipping libc++ but without a permissively licensed runtime). A few days before the public release, we sent Apple a polite heads up that we were going to be doing the release. They responded by creating the libc++abi project in LLVM, with a demangler that was much too large and generic for the runtime and none of the code that’s actually necessary.

History aside, all of these have very subtly different layouts of the structure that encapsulates an exception. This is not part of their public APIs (or ABIs) and has, in the past, changed between versions. We did have a load of compile-time detection for this in the GNUstep Objective-C runtime, but it proved somewhat fragile. Eventually, I rewrote it with some run-time detection that works by throwing a C++ exception though a stack frame with a custom personality function. The C++ exception is a custom type and contains a specific bit pattern as its value. We just poke at the memory for the object until we find the pointer to the typeid object for our type and until we find the bit pattern of the thrown object. This lets us find the two fields that we care about.

Do you have a long-term software pipe dream?

I still think of myself as working on Étoilé. I simply found that I can’t build it with existing software and programming languages and so took a little diversion to build the lower layers that I need. I need CHERI to be able to do fine-grained sharing with legacy libraries (i.e. the billions of lines of code that have been written already that I don’t want to rewrite). With Verona, we have a language that has sandboxing as a first-class abstraction so that we can reason about things like two independent instances of libavcodec for different movies in the same document, at the source level. We also have a deadlock-free and data-race-free concurrency model that we can use as a coordination language, which lets us build DSLs and end-user-programming systems that give strong local reasoning guarantees for individual components.

When those two things are mature, the things that we wanted to build in Étoilé are feasible and I can get back to building them.

Do you have any suggestions on how one may turn their open source interests into a fulfilling career?

Any form of success requires some luck. Remember that any time someone is telling you that an approach will lead to success, they’re working from a sample size of one and have no idea how many people tried the same thing and failed.

When I was a PhD student, someone pointed me at a study that showed that the main difference between people that self identified as lucky and those that didn’t was that the former were better at recognising and taking opportunities that were presented. Some people don’t have the opportunities at all, but a lot more do and miss them. A couple of examples:

When I saw Peter’s email about writing a book, I followed up and that led to an entire writing career for several years. I don’t write professionally anymore, but that experience has been useful in many of the things that I’ve done subsequently. I’d been pondering writing as a career option but really had no idea how to do it. I could easily have not had this opportunity (I was lucky to be working on XMPP at the time) and I could easily have not taken advantage of it.

When I started working with each of GNUstep, FreeBSD, and LLVM, I joined the mailing lists and IRC channels and helped people who had problems. There’s always a spectrum of people that want help. Some are individuals doing things for a hobby, some are working for companies and really need the help. Some of those companies have a decent contracting budget because they know that it’s much faster to pay someone who knows how to solve a problem now than it is to build that in-house expertise. Several conversations I had led to people offering to pay me to do the thing that they were trying to do, rather than finish explaining it to them (a few also led to requests to do training for their company).

A big part of the reason that this worked for me was that most of the things I worked on were used by companies that understood software development. It’s much easier to sell software development services to a company that employs software developers than it is to a company that doesn’t really know what that means. If you’re working on applications that target end users, I don’t think the same approach would work.

A lot of contracting work comes as a result of having a solid reputation. If people know that you know a codebase well, can be trusted to get work done, and aren’t a total pain to work with, they’re likely to consider hiring you. Open source lets you build this kind of reputation in public.

Permissive licenses also help a lot. We knew of a couple of companies shipping products using GNUstep, but violating the LGPL. The FSF didn’t want to take them to court and, because they were in violation of the license, they didn’t want to hire anyone who worked upstream and might report them. Unless you’re willing to pay lawyers to enforce license conditions, you won’t stop people infringing the license but you will put people off if they’re not 100% sure that they can comply. In contrast, I’ve worked with several companies that decided to do in-house forks of permissively licensed things and then changed their minds later and wanted to either upstream things or have things added upstream that let them ditch their fork. The permissive license lets them build a dependency on your project and then they grow a need for people with your expertise, with no effort on your part. Now you have a market for the exact skills that you have.

A lot of people slap restrictive copyleft licenses on things because they don’t want companies to benefit from their work, but that also means that those same companies have no incentive to contribute (code or money) to the project. If your project is valuable and people don’t like the license, they will either reimplement it or they will violate the license and hope that they don’t get caught. Neither of these benefits you. I think the GPL has led to fairly noticeable increase in the amount of proprietary software in the world as companies that would happily adopt a BSDL component decide to create an in-house proprietary version rather than adopt a GPL’d component. This benefits nobody but it especially won’t benefit you if you want someone to pay you to work on the GPL’d component.