Re: The Case for Rust (in the base system)

On 31 Jan 2024, at 10:15, Wojciech Puchar <wojtek@puchar.net> wrote:
> 
> The is no such thing as secure system programming language.

While true in the absolute, that’s an unhelpful framing.  Different languages can eliminate different bug classes by construction. The same is true of different APIs.  For example, SQL injection attacks are completely eliminated by APIs that present format strings, whereas they are easy to introduce in ones that require you to construct an SQL expression by string concatenation.

For the languages under discussion, the key properties are memory safety.  Rust and modern C++ prevent a lot of bounds errors by carrying bounds either in the type or as properties of a value and performing explicit checks.  More importantly, they provide abstractions such as iterators, ranges, and views, which make bounds errors impossible by construction because they use subset-like operators on valid ranges derived from a collection and so ensure that every range that you iterate over *must* be a valid subrange of the underlying collection.  They provide ownership semantics for pointers (in the language for Rust, in the library via RIAA and smart pointers) than ensure that owning a pointer prolongs its lifetime and so avoid temporal safety errors.

Can a programmer get these things right without language support?  Absolutely, but each programmer has a finite budget for cognitive load.  In addition to thinking about memory management, they need to think about good data structure design, efficient algorithms, and higher-level security properties.  The more attention that they have for these things, the better their code is.  We’ve seen this in some of the Apple Silicon drivers for Linux, where writing them in Rust with strong ownership types made it easy to implement some concurrent algorithms that would be hard to get right in C and led to fast and correct code.

In terms of safe *systems* programming, I would regard the definition of *systems* programming as programming that needs to step outside of a language’s abstract machine.  Memory allocators and schedulers, for example, are in this category.  These still benefit from richer type systems (in snmalloc, as I mentioned previously in the thread, we model the allocation state machine in C++ templates to ensure that memory state transitions are all valid as memory moves between allocated and the various states of deallocation), but the language cannot enforce strong properties, it can at best provide the programmer with tools to ensure that certain properties are always true in code that compiles.

It’s up to you where you want to invest your cognitive budget, but for code that runs in the TCB I’d rather we have as many properties correct by construction as possible.

David