Key Rust concepts for the kernel

The first day of the online Kangrejos conference was focused on introducing the effort to bring the Rust programming language into the Linux kernel. On the second day, conference organizer Miguel Ojeda shifted to presenting the Rust language itself with an emphasis on what Rust can provide for kernel development. The result was a useful resource for anybody who is curious about this project, but who has not yet had the time to become familiar with Rust.

Ojeda began by stressing that the talk was not meant to be a tutorial; to actually learn the language, one should get a good book and work from that. There is no way to cover everything needed in an hour of talk (a fact that became abundantly clear as time went on), but he hoped to be able to show some of the key ideas behind Rust. In the end, though, the only way to really understand the language is to sit down and write some code.

Reading material

There are a number of resources available for developers wanting to learn Rust, including several books. The definitive book appears to be The Rust Programming Language, which is available online for free. The book is a good introduction, he said, and is also an example of the documentation style that pervades the Rust project. Developers who are specifically interested in kernel development need not read the whole thing; much of the discussion on concurrency, for example, is not applicable to the kernel environment.

Programming Rust is also quite nice, he said. It is aimed at experienced programmers, and thus may be useful for kernel developers. This book is the only resource on his list that is not freely available, though. For readers who want to jump right in, Rust by Example presents a series of exercises, each of which introduces a new language feature.

Then, there is The Rustonomicon. This book, which is not complete, focuses on the challenges of writing unsafe Rust in particular. If the Rust-for-Linux project's goals are met, driver writers will not need to write unsafe Rust and, thus, may not need this book. There is a lot of gritty, low-level material in this book, but it also demonstrates a key point: most Rust developers should never have to deal with the language at this level.

Finally, The Rust Reference, which is also incomplete, is a good book for "people who like to read language standards". Most Rust developers will not need it. Ojeda summarized this section by suggesting either of the The Rust Programming Language or Programming Rust for most developers.

The Rust project offers a lot of other documentation too, of course. For the C language, Ojeda said, the standard is the documentation, but Rust is different. Documentation is everywhere, full of explanations and examples, and often generated directly from the code. A similar approach is being taken to the documentation generated by the kernel effort; it is being written using rustdoc rather than the kernel's Sphinx-based system. How to integrate those two bodies of documentation remains an open question.

Tools

Ojeda moved on to a couple of tools that are useful for looking at Rust code and the machine code that it is compiled to. One of those is the Rust playground, which can build code, run linters, examine assembly code, and more.

That said, he prefers Compiler Explorer; it offers a lot of the same features but is not limited to Rust. It can be used to compare assembly output produced by different languages, for example, and features a nice basic-block display for that purpose. Compiler Explorer can also run the code in question and display the results.

The language

While some people describe Rust as "a safer C", Ojeda doesn't like that term. It's more like a version of C with a safer type system, which is not the same as being safety-critical. Rust can also be described as a "cleaned-up C", he said. As an example, he presented a snippet of similar code in three languages:

    map(v, [](const auto & x) { return x.get(); });   // C++
    map(v, lambda x: x.get())    # Python
    map(v, |x| x.get());  // Rust

The Rust version is just cleaner and easier, he said. C++ may contain a lot of useful features, but developers often fear to use them; Rust makes it all easier.

He spent some time on the concept of "safety" in Rust, a discussion that repeated a fair amount from the first day. Rust is "safe" in that it has no undefined behavior; there are no situations where "the compiler has the freedom to do crazy things". Many undesirable behaviors, including kernel panics, memory leaks, and integer overflows, are well defined and, thus, Rust-safe (the compiler can be made to check for overflows though). And, of course, logic errors are "safe"; the language cannot guarantee that a program does what the developer intended.

But many other types of problems can be eliminated by coding in safe Rust. As an example of undefined behavior, Ojeda showed a simple C function:

    int f(int a, int b) {
        return a/b;
    }

There are two ways that this function can wander into undefined behavior. The obvious one is if the caller passes zero for b; if that happens, the compiler is allowed to produce any result it likes. The other undefined situation comes about if a is INT_MIN and b is -1. There is no positive equivalent of the largest negative integer in the two's complement representation, so the result of the division cannot be represented. Once again, the compiler is allowed to improvise when that happens.

One can write a similar function in Rust:

    pub fn f(a: i32, b: i32) -> i32 {
        a/b
    }

Using Compiler Explorer, Ojeda showed that this function, when compiled, contains tests for both of the above undefined-behavior cases. If either is encountered, the program will abort. That may not be what the programmer wanted, but neither is continuing to run in an undefined state.

There was some brief discussion of the performance cost for all of these checks. It certainly is not zero, but nobody seems to have measured what the impact really is in a performance-critical situation. Ojeda pointed out that, in the worst case, code can be put into an unsafe block, which will remove all of those checks. "Unsafe" was often described as an "escape hatch" during this conference — a way to remove many of the constraints placed by the language when they become too heavy.

There are also various tricks that can be applied to show the compiler that certain situations are impossible, at which point it will omit the checks automatically. If one defines a bounded-integer type, for example, the compiler knows that its value will be within its bounds and may not need to perform overflow checks. This technique often involves putting the necessary checks into a constructor, where they only need to be done once.

Ojeda provided one other example, being C code in a function that looks like this:

    int x;  /* not initialized */

    while (f())
        x = 42;
    return x;

Looking at the assembly output for this function, he pointed out that the compiled code just returns a constant 42. The loop body that assigns to x may never have executed, but to reference x in that case puts the program into undefined behavior. The compiler is allowed to assume that this will never happen; in that worldview, x must be assigned the value 42. Rust, instead, will throw a compile-time error in this case and force an explicit initialization of the variable.

Laurent Pinchart noted that developers must train their brains to avoid undefined behavior when working in either language. The difference is that the Rust compiler will catch mistakes, while a C compiler will often remain silent. After training your brain with a language like Rust, he said, the result will often be writing better C code as well.

The time for the session had long since run out by this point, but Ojeda pressed through a series of additional slides describing other Rust language features that are relevant to kernel developers. These include union types that don't allow access to the wrong member, implicit freeing of dynamically allocated objects, handling signed integer overflow, mechanisms for avoiding data races, and more. There is, in short, a lot in Rust for systems developers — much more than can be covered in a brief conference session.

Index entries for this article
Kernel	Development tools/Rust
Conference	Kangrejos/2021

---

to post comments

warning: use of uninitialized value 'x' [CWE-457] [-Wanalyzer-use-of-uninitialized-value]
    9 |   return x;
      |          ^
  'test': events 1-3
    |
    |    7 |   while (f())
    |      |          ^
    |      |          |
    |      |          (1) following 'false' branch...
    |    8 |     x = 42;
    |    9 |   return x;
    |      |          ~
    |      |          |
    |      |          (2) ...to here
    |      |          (3) use of uninitialized value 'x' here
    |

      DO 10 I=1,10
        …
10    CONTINUE

      DO 10 I=1.10
        …
10    CONTINUE

      DO 10, I=1,10

#include <limits.h>
#include <stdio.h>
#include <stdlib.h>
int im = INT_MIN;

int divide(int a, int b)
{
    return a/b;
}

int main(int argc, char **argv)
{
    int b = atoi(argv[1]);
    printf("%d\n", divide(im, b));
}

$ ./test -1
Floating point exception

$ ./test 
-2147483648