ralf/_posts/2019-01-12-rust-2019.md

   1 ---
   2 title: "Rust 2019: Solid Foundations for Unsafe Code"
   3 categories: rust
   4 ---
   5
   6 It is that time of the year again where our feedreaders are filled with people's visions for what Rust should become in the next year.
   7 Coming up with a vision is not exactly my strong suit, but it is probably something I should learn, so here's my episode of the "Rust 2019" blog post series.
   8
   9 I think in 2019, we should make a coordinated effort to improving the *foundations for writing unsafe code*.
  10 Of course my particular Rust bubble is mostly about unsafe code, as you will know if you have read some of my previous posts -- but safety is a core value proposition of Rust, and the entire ecosystem rests on a foundation of crates that make heavy use of unsafe code, so I believe that caring about unsafe code is an important piece to Rust's overall success.
  11
  12 <!-- MORE -->
  13
  14 ## Foundations for unsafe code
  15
  16 What do I mean by "improving the foundations" of unsafe code?
  17 There are many questions that frequently come up when writing unsafe code, like:
  18
  19 * What are the rules around handling uninitialized or otherwise invalid data?
  20 * How can I create pointers to fields of packed structs?
  21 * When can I turn raw pointers into references, and what can I do with these references?
  22 * When do I need `UnsafeCell`?
  23 * What can I do with a `union`?
  24
  25 I am sure there are more, these are just some questions that regularly show up in my inbox because someone @mentions me.
  26 What all of these questions have in common is that *we don't know the full answer*, and even the parts of the answer that we do know are hard to figure out for someone who's new to this.
  27
  28 So a key ingredient to providing better foundations for writing unsafe code is to start answering some of these questions, and to figure out which other questions need answering.
  29 One issue that any attempt to answer any one of these questions precisely will run into is that we do not have a proper specification for what a Rust program *does* when it is executed -- the semantics of Rust are basically defined by "whatever the generated LLVM IR does", and that's not a very solid foundation at all.
  30 As a consequence, we often even lack the terminology to make precise statements about what unsafe code can and cannot do.
  31 What we need is a specification of at least a large enough fragment of Rust to serve as the framework in which these other discussions can take place.
  32
  33 But that's just the beginning: we can't just dump a bunch of rules onto programmers and let them deal with the rest.
  34 We need to help them write code that follows the rules.
  35 To this end, we need more documentation and teaching material -- things like the [Rustonomicon](https://doc.rust-lang.org/nightly/nomicon/).
  36
  37 But I strongly believe that we can't leave it at that.
  38 We should also provide *tooling* that helps programmers check their code for rule violations.
  39 I believe that this is extremely important: it does not just help programmers increase confidence in their unsafe code, it also helps them learn what the rules even are.
  40 We all learn by making mistakes, but that only works if you *know* that you made a mistake -- and with unsafe code, that's very hard to figure out.
  41 And, last but not least, creating such tooling will uncover ambiguities in the rules and raise new questions about corner cases that we forgot to consider, and thus help flesh out the rules themselves.
  42
  43 ## Where are we at?
  44
  45 Some of the things I described above are already happening, but things are moving slowly and more hands are always needed!
  46
  47 The [unsafe code guidelines effort](https://github.com/rust-rfcs/unsafe-code-guidelines/) (UCG) is slowly but steadily chipping away at the kind of questions I raised, determining whether we can have a consensus among the small group of people that is actively participating in these discussions.
  48 This is an interesting mix of descriptive and normative work: we are trying to cater patterns that already existing unsafe code follows and cast them into rules that future code will have to follow.
  49 Of course, anything we do still has to go through the RFC process before it becomes normative, and I am sure new interesting questions will come up then.
  50 Right now, we are discussing ["validity invariants"](https://github.com/rust-rfcs/unsafe-code-guidelines/blob/master/active_discussion/validity.md), which describe the assumptions the compiler is allowed to make about the contents of a variable based on its type.
  51 This just started, so now is a perfect time to join the effort!
  52
  53 A [new approach for handling uninitialized data](https://github.com/rust-lang/rust/issues/53491) is available in nightly, replacing the old `mem::uninitialized` that turned out to be impossible to design reasonable rules for.
  54 At this point, this is mostly blocked on [bikeshedding the API](https://github.com/rust-lang/rust/pull/56138) and figuring out whether we want to allow or forbid unsafe code to create references to uninitialized data (without reading from them) -- the latter being one of the most interesting open questions around "validity invariants" that the UCG is discussing.
  55
  56 There is an [accepted RFC](https://github.com/rust-lang/rfcs/blob/master/text/2514-union-initialization-and-drop.md) for resolving the open questions around the interaction of `union` and `Drop`, and a [work-in-progress partial implementation](https://github.com/rust-lang/rust/pull/56440) of that RFC.
  57
  58 There is an [RFC under discussion](https://github.com/rust-lang/rfcs/pull/2582) for resolving the situation around references to fields of packed structs, that also helps with other questions around references in unsafe code.
  59 This RFC could need some pushing over the finish line, and then it needs implementing.
  60
  61 In terms of tooling, there is [Miri](https://github.com/solson/miri/) (also available on the [Rust Playground](https://play.rust-lang.org/)), which could need quite some love to improve the error messages, to track more information during execution for better diagnostics, to make it run faster and to support more things that test suites often do (like panics, or seeding RNGs from the OS).
  62
  63 Rust also, in principle, supports some of the LLVM sanitizers, namely asan, tsan, msan and lsan.
  64 However, using them [still seems to run into some issues](https://github.com/google/mundane/issues/15), and the [rust-san project](https://github.com/japaric/rust-san) seems to lay dormant.
  65 We should aim at making it standard practice for crates to run these sanitizers as part of their CI.
  66 Even if the crate doesn't use unsafe code itself, it might have a dependency that does, so using the sanitizer here helps improve the test coverage of that dependency.
  67 This won't catch violations of Rust-specific rules, and to my knowledge these sanitizers all have false negatives (meaning they miss bugs in their domain), but they *do* find many issues and that goes a long way.
  68
  69 Of course, it would be awesome to have a Rust-specific sanitizer as well.
  70 There is some low-hanging fruit here, like having a way to compile your program with assertions guarding unchecked slice accesses, or verifying that pointers are sufficiently aligned -- and then there is a long list of interesting checks that are increasingly hard to implement.
  71
  72 And then there are all the things I did not think of that could help unsafe code authors do their work with confidence, and reduce the number of mistakes that people inevitably make when writing unsafe code.
  73 I am sure there is a lot of possibility here for API design to improve the overall reliability of unsafe code.
  74
  75 So, as you can see, many things are happening, so I think there is some real chance that we can make serious progress on this topic in 2019.
  76 Let's make it happen, together!