ralf-jung

<p>The Rust Abstract Machine is full of <a href="/blog/2020/12/14/provenance.html">wonderful oddities</a> that do not exist on the <a href="/blog/2019/07/14/uninit.html">actual hardware</a>. Inevitably, every time this is discussed, someone asks: “But, what if I use inline assembly? What happens with provenance and uninitialized memory and Tree Borrows and all these other fun things you made up that don’t actually exist?” This is a great question, but answering it properly requires some effort. In this post, I will lay down my current thinking on how inline assembly fits into the Rust Abstract Machine by giving a <em>general principle</em> that explains how anything we decide about the semantics of pure Rust impacts what inline assembly may or may not do.</p> <!-- MORE --> <p>Note that everything I discuss here applies to FFI calls just as much as it applies to inline assembly. Those mechanisms are fundamentally very similar: they allow Rust code to invoke code not written in Rust.<s…

<p>It is time for another “what is happening in Miri” post. In fact this is <em>way</em> overdue, with the <a href="/blog/2022/07/02/miri.html">previous update</a> being from more than 3 years ago (what even is time?!?), but it is also increasingly hard to find the time to blog, so… here we are. Better late than never. :)</p> <p>For the uninitiated, <a href="https://github.com/rust-lang/miri/">Miri</a> is an <a href="https://doc.rust-lang.org/reference/behavior-considered-undefined.html">Undefined Behavior</a> testing tool for Rust. This means it can find bugs in your unsafe code where you failed to uphold requirements like “all accesses must be aligned” or “mutable references must never alias” or “there must not be any data races”. Miri’s claim to fame is that it is a practical tool that can find <em>all de-facto Undefined Behavior in deterministic Rust programs</em>. To my knowledge, no other freely available tool can claim this—for any language.<!-- MORE --><sup id="fnref:relwork">…

<p>Memory safety is all the rage these days. But what does the term even mean? That turns out to be harder to nail down than you may think. Typically, people use this term to refer to languages that make sure that there are no use-after-free or out-of-bounds memory accesses in the program. This is then often seen as distinct from other notions of safety such as thread safety, which refers to programs that do not have certain kinds of concurrency bugs. However, in this post I will argue that this distinction isn’t all that useful, and that the actual property we want our programs to have is <em>absence of Undefined Behavior</em>.</p> <!-- MORE --> <h2 id="breaking-memory-safety-with-a-data-race">Breaking memory safety with a data race</h2> <p>My main issue with the division of safety into fine-grained classes such as memory safety and thread safety is that there’s no meaningful sense in which a thread-unsafe language provides memory safety. To see what I mean by this, consider this p…

<p>After several years of work, our Tree Borrows paper has finally been presented recently at PLDI 2025 in Seoul. Tree Borrows has not changed much compared to what has previously been mentioned in this blog and on <a href="https://perso.crans.org/vanille/treebor/">Neven’s website</a>. We used all that extra time for <em>formal proofs</em> that Tree Borrows indeed allows at least some of the optimizations that we hope to gain from it, and to carry out an extensive evaluation of Tree Borrows on the 30 000 most-downloaded crates on crates.io. This overall package of implementation, proof, and evaluation impressed the PLDI program committee enough that we got a <em>distinguished paper award</em>. :-) Thanks a lot to Neven and Johannes for all the hard work and congratulations on an amazing paper!</p> <p>If you want to check out the paper yourself, everything is <a href="https://plf.inf.ethz.ch/research/pldi25-tree-borrows.html">available under open access</a>. Neven’s amazing talk presen…

<p>A few weeks ago, many Rust folks met in Utrecht for RustWeek and we all had a great time. As part of that, I also gave a talk titled “MiniRust: A core language for specifying Rust” about the current state of MiniRust. This was my first time giving a talk in a (fully packed) movie theater; unfortunately, my special effects budget cannot keep up with the shows that would usually be presented there. But nevertheless, if you would like to learn more about my vision for how we should specify the gnarly details of unsafe Rust, <a href="https://www.youtube.com/watch?v=yoeuW_dSe0o">please go watch my talk</a>. :)</p> <p>Thanks to everyone who was there for being a great audience, and thanks to the organizers for an amazing week and high-quality recordings!</p>

<p>The first paper produced entirely by my group has recently been published at OOPSLA. :) The paper is about fuzzing the optimizations and code generation of the Rust compiler by randomly generating MIR programs and ensuring they behave the same across different backends, different optimization levels, and in Miri. The core part of this work was done by Andy (Qian Wang) for his <a href="https://ethz.ch/content/dam/ethz/special-interest/infk/inst-pls/plf-dam/documents/StudentProjects/MasterTheses/2023-Andy-Thesis.pdf">master thesis</a>. This was already a strong thesis, but Andy kept working on this even after he started having a regular dayjob, and we ended up with a very nice paper. In total, he found 22 new bugs in the Rust compiler, 12 of them in the LLVM backend that has already been extensively fuzzed by prior work.</p> <p>To learn more, <a href="https://plf.inf.ethz.ch/research/oopsla24-rustlantis.html">check out the paper</a> or <a href="https://www.youtube.com/watch?v=kHYEHSH…

<p>One of the more subtle aspects of the Rust language is the fact that there are actually two kinds of expressions: <em>value expressions</em> and <em>place expressions</em>. Most of the time, programmers do not have to think much about that distinction, as Rust will helpfully insert automatic conversions when one kind of expression is encountered but the other was expected. However, when it comes to unsafe code, a proper understanding of this dichotomy of expressions can be required. Consider the following <a href="https://play.rust-lang.org/?version=nightly&amp;mode=debug&amp;edition=2021&amp;gist=9a8802d20da16d6569510124c5827794">example</a>:</p> <div class="language-rust highlighter-rouge"><div class="highlight"><pre class="highlight"><code><span class="c1">// As a "packed" struct, this type has alignment 1.</span> <span class="nd">#[repr(packed)]</span> <span class="k">struct</span> <span class="n">MyStruct</span> <span class="p">{</span> <span class="n">field</span><span clas…

<p>We are all used to spam emails, supposedly from Google, that say “You won” and I just need to send all my data to somewhere to receive my lottery payout. When I recently received an email about Google’s “Open Source Peer Bonus” program, I almost discarded it as yet another version of that kind of spam. But it turns out sometimes these emails are real! Meanwhile the <a href="https://opensource.googleblog.com/2023/12/google-open-source-peer-bonus-program-announces-second-group-of-2023-winners.html">official announcement</a> has been released which lists me as a recipient of this bonus as a thank you for my work on Rust. So this one time, it wasn’t spam after all!</p> <!-- MORE --> <p>Thanks a lot to Google for this program at the $250 reward; it is great to see open source work honored this way. I have donated the amount in full to <a href="https://noyb.eu/en">noyb</a>, who I’m sure will be using it <a href="https://noyb.eu/en/noyb-win-first-major-fine-eu-1-million-using-google-anal…

<p>I recently gave a talk at a local Rust meetup in Zürich about Undefined Behavior, unsafe Rust, and Miri. The recording is available <a href="https://www.youtube.com/watch?v=svR0p6fSUYY">here</a>. It targets an audience that is familiar with Rust but not with the nasty details of unsafe code, so I hope many of you will enjoy it! Have fun. :)</p>

<p>Since last fall, <a href="https://perso.crans.org/vanille/">Neven</a> has been doing an internship to develop a new aliasing model for Rust: Tree Borrows. Hang on a second, I hear you say – doesn’t Rust already have an aliasing model? Isn’t there this “Stacked Borrows” that Ralf keeps talking about? Indeed there is, but Stacked Borrows is just one proposal for a possible aliasing model – and it <a href="https://github.com/rust-lang/unsafe-code-guidelines/issues/133">has</a> <a href="https://github.com/rust-lang/unsafe-code-guidelines/issues/134">its</a> <a href="https://github.com/rust-lang/unsafe-code-guidelines/issues/256">fair</a> <a href="https://github.com/rust-lang/unsafe-code-guidelines/issues/274">share</a> <a href="https://github.com/rust-lang/unsafe-code-guidelines/issues/276">of</a> <a href="https://github.com/rust-lang/unsafe-code-guidelines/issues/303">problems</a>. The purpose of Tree Borrows is to take the lessons learned from Stacked Borrows to build a new model with…

<p>Did you know that the standard library is full of useful checks that users never get to see? There are plenty of debug assertions in the standard library that will do things like check that <code class="language-plaintext highlighter-rouge">char::from_u32_unchecked</code> is called on a valid <code class="language-plaintext highlighter-rouge">char</code>, that <code class="language-plaintext highlighter-rouge">CStr::from_bytes_with_nul_unchecked</code> does not have internal nul bytes, or that pointer functions such as <code class="language-plaintext highlighter-rouge">copy</code> or <code class="language-plaintext highlighter-rouge">copy_nonoverlapping</code> are called on suitably aligned non-null (and non-overlapping) pointers. However, the regular standard library that is distributed by rustup is compiled without debug assertions, so there is no easy way for users to benefit from all this extra checking.</p> <!-- MORE --> <p><a href="https://github.com/RalfJung/cargo-careful">…

<p>I have some very exciting news to share: starting November 1st, I will work at ETH Zürich as an assistant professor! Becoming a professor in the first place is a dream come true, and becoming a professor at a place like ETH Zürich is not something I even dared to dream of. I still cannot quite believe that this is actually happening (I will be <em>professor</em>?!??), but <a href="https://twitter.com/CSatETH/status/1548944615285350400">the news is out</a> so I guess this is real. :D</p> <!-- MORE --> <p>I feel excited and terrified in about equal parts. Excited by all the new possibilities, by the prospect of working with students and inspiring the next generation of researchers; terrified by all the responsibility and the prospect of having to stand in a classroom and give a lecture in only a few months’ time. But somehow everyone else seems confident that I can do this, so I guess I’ll just play along and hope that I will not prove them wrong…</p> <p>I am also humbled and etern…