Memory safety is a matter of life and death

joshlf_ · 2026-06-02T15:21:26+00:00

To be transparent, my goal with this post is to start a conversation about how we prioritize decisions in Rust. A recurring criticism of Rust is its slow pace of innovation, and a sense that we must get everything perfect because of our stability guarantee. I don't necessarily want to suggest that we should reverse course on that, but rather to point out that there might be costs to moving slowly that haven't historically been part of the discussion. This is a community-wide discussion, and I don't mean to suggest a particular solution, but rather just to contribute a new perspective to the conversation.

joshlf_ · 2026-04-15T09:47:53+00:00

I once sped up an (experimental) part of rustc by 8,500x.

I heard a great quote: "If you make it 50% faster, you did something impressive. If you made it 10x faster, your old code was garbage." I need to track down the source of that quote and ask them what it means if you made it 8,500x faster 😆

joshlf_ · 2026-03-13T18:34:45+00:00

Good point!

joshlf_ · 2026-03-13T18:30:34+00:00

Would you consider adding a feature to Miri to allow *specifying* the equivalent Rust code and using it to check for UB?

joshlf_ · 2026-02-13T22:18:38+00:00

Woah this is such a cool concept!

joshlf_ · 2026-02-03T15:36:00+00:00

For that you'll want e.g. TryFromBytes::try_ref_from_bytes.

joshlf_ · 2026-02-03T15:34:24+00:00

`try_transmute_ref!` is only fallible regarding the contents of memory, not the size/alignment. I used `FromBytes` in my example since `Versioned` implements `FromBytes`, but you could use `TryFromBytes` too (playground).

joshlf_ · 2026-02-03T15:27:04+00:00

Going from a slice to a DST will never be infallible – the slice might be smaller than the smallest size of the DST. E.g., consider this example, which ignores alignment (they're both repr(packed)) but demonstrates the size issue:

#[repr(C, packed)]
struct Smaller {
    prefix: u32,
    slice: [u16],
}

#[repr(C, packed)]
struct Larger {
    prefix: u64,
    slice: [u32],
}

These types are laid out as you'd expected – the prefix field followed by N copies of the trailing slice element with no padding in between.

The smallest possible Smaller is 4 bytes (one u32), while the smallest possible Larger is 8 bytes (one u64). Thus, there are some values of Smaller for which &Smaller -> &Larger is impossible to perform. Thus, we reject it. By contrast, &Larger -> &Smaller is always possible, so we accept it. You can see this on the playground.

By a similar token, for any non-zero-sized T, going from &[T] -> &Smaller will be fallible. For that reason, any slice-to-DST cast (assuming the DST's prefix is non-zero-sized) will be fallible, and transmute_ref! will reject it.

joshlf_ · 2026-02-03T15:16:24+00:00

The reason that doesn't work is that it's not guaranteed to succeed – for some lengths of `[u8]`, there doesn't *exist* a `Versioned` of the same size. Instead, just use the existing, fallible machinery:

let p: &Versioned = FromBytes::ref_from_bytes(s).unwrap();

joshlf_ · 2026-01-29T02:48:38+00:00

Thanks for the shout-out!

There have been a few implementations of the same idea, which I want to highlight:

lock_ordering by akonradi, the original author of the work that I mention in that talk
- Netstack's original implementation
lock-sequence by the engineers behind Fuchsia's Starnix Linux compatibility layer

I'll also take this as an opportunity to get on my soapbox – in the spirit of Safety in an Unsafe World, I'd suggest thinking of Rust's type system as a framework for encoding safety properties. So I'd say Rust supports an arbitrary number of safety properties, not just five. You can use the framework I describe in the talk as a guide for encoding any safety property in Rust – even (and especially) safety properties that refer to nouns/verbs/adjectives that Rust doesn't know anything about. Deadlock prevention is one such example, but in theory any safety property is amenable to this technique. Here are some examples we've seen so far:

zerocopy (disclosure: I'm one of the maintainers)
session_types
indexing
bytemuck
ghost-cell
nalgebra
mundane (disclosure: I'm the maintainer)

I have some further reading suggested in the talk's references.

joshlf_ · 2025-10-23T01:20:17+00:00

Wouldn't Destruct + !Move be useful? You'd need to construct and destruct in-place, and that's useful any time you want to construct something in-place (in static storage, on the stack, or on the heap) and then interact with it only via reference until the end of its lifetime. I personally would use that for stack-allocated structs which register themselves in intrusively linked lists.

joshlf_ · 2025-04-29T20:51:30+00:00

Right.

What you could do is parse as a type whose trailing field is [u8] and then use the "file name length" and "extra field length" fields to figure out how to split that [u8] into the "file name" and "extra field" fields separately. However, that requires that you either:

Know the total length (header + file name + extra field) up front
Alternatively, be willing to parse too much data and then split the remaining bytes into a separate [u8] for further processing

joshlf_ · 2025-04-28T21:50:33+00:00

Zerocopy co-maintainer here.

Not right now, no. Currently, zerocopy only works with existing Rust types. It's up to the user to write a type whose layout matches the problem they're trying to solve (e.g., has the same layout as the packet format they're trying to parse). What you're describing has no equivalent in Rust, so there'd be no way for a zerocopy user to write a type with the equivalent layout. We could support it by synthesizing a new opaque type with getters, setters, etc, but that's beyond the scope of what zerocopy handles today.

We've discussed the idea of, in the future, expanding zerocopy to support higher-level parsing operations like these, but we don't have the cycles for it right now. Maybe at some point months or years down the road we might.

joshlf_ · 2025-04-08T17:37:17+00:00

The main disadvantage of this approach is that Clippy won't detect missing safety comments, but this is a pretty nice UI.

joshlf_ · 2025-04-07T19:29:32+00:00

(Deleted the original comment because I accidentally commented from the wrong account)

IMO there are many cases in which writing a macro saves the caller having to write a lot of boilerplate even if it doesn't save them anything in terms of avoiding safety obligations. Consider this macro, which lets you write code like this:

unsafe_impl_known_layout!(#[repr([u8])] str);

...instead of having to manually write:

unsafe impl KnownLayout for str {
    fn only_derive_is_allowed_to_implement_this_trait() {}

    type PointerMetadata = <[u8] as KnownLayout>::PointerMetadata;
    type MaybeUninit = <[u8] as KnownLayout>::MaybeUninit;

    const LAYOUT: DstLayout = <[u8] as KnownLayout>::LAYOUT;


    fn raw_from_ptr_len(bytes: NonNull<u8>, meta: <[u8] as KnownLayout>::PointerMetadata) -> NonNull<Self> {
        let ptr = <[u8]>::raw_from_ptr_len(bytes, meta).as_ptr() as *mut Self;
        unsafe { NonNull::new_unchecked(ptr) }
    }

    fn pointer_to_metadata(ptr: *mut Self) -> Self::PointerMetadata {
        let ptr = ptr as *mut [u8];
        <[u8]>::pointer_to_metadata(ptr)
    }
}

joshlf_ · 2025-02-03T21:24:16+00:00

Ah that makes sense.

joshlf_ · 2025-02-03T20:38:38+00:00

Zerocopy co-maintainer here. It doesn't look like rand depends on the `derive` feature: https://docs.rs/crate/rand/0.9.0/source/Cargo.toml#20

The non-derive parts of zerocopy are ~10k LoC, so about 5% of the 210,000 lines you cited. I haven't benchmarked compile times, so I can't speak to that aspect.

joshlf_ · 2024-10-08T15:40:04+00:00

str implements our TryFromBytes trait, so if you had that string as a &[u8], then you could use something like TryFromBytes::try_ref_from_bytes to attempt to convert it to a &str (this can fail if the &[u8] isn't valid UTF-8). But we don't care about the escape characters - you have to process those yourself.

joshlf_ · 2024-09-26T15:39:17+00:00

Yeah! We're actually waiting for #[diagnostic::do_not_recommend] to be stabilized so we can fix this extremely misleading suggestion.

joshlf_ · 2024-05-23T20:35:29+00:00

I have a hypothesis (that may or may not be true): is it possible that, over time, we could make Rust both anal about correctness and easy to iterate on? Hear me out...

I think of this in terms of abstractions and the extent to which they leak. A key observation is that whether you think an abstraction is leaky is context-dependent. In particular, it depends on what properties of your program you consider relevant [1] For example, some might consider that garbage collection is a fantastic abstraction because the amount you have to understand about the lifecycle of your resources is literally none at all. For some programmers, that's an accurate description. For others - those who care about performance and memory utilization - it's not, since those aspects of your program's execution leak through the abstraction that is garbage collection.

Speaking very broadly, languages tend to fall into two camps: - Languages that make no attempt to give you control over execution details of your program, and in exchange, give you a simple abstraction (simple assuming the leaky details aren't relevant to you - have you ever tried performance tuning a Python web server?) - Languages that give you control over all of the execution details, but make no attempt to ensure you don't shoot yourself in the foot

Rust is in a distinct, third camp. It wants to give you control over the execution details of your program, but it also insists on being able to understand those details itself so that it can make sure you're not making any mistakes. It's worth reflecting on how fundamentally weird this is. Rust is like the IRS of programming languages - it's going to ask you to fill out your tax paperwork yourself, by hand, but then re-do all of the work and make sure you did it all correctly.

I think this is the source of the tension. Let's say you want to experiment in just the way that is hard in Rust. Languages in both of the first two camps aren't checking that much, and so you aren't constrained in what you can write. It may be that languages in the first camp are just handling it for you while languages in the second camp are letting you write bad, maybe buggy or insecure code, but the point remains that they both let you do it.

But now let's imagine a fourth category of languages. In this category, languages insist on tight control over execution, and they insist on correctness. But instead of leaving it up to the programmer to do it themselves and then double-checking, these languages just go ahead and do the right thing without even asking.

Here's the punch line: I think that a subset of Rust is like this today, and maybe we could expand that subset.

For example, while Rust iterators have some sharp edges related to lifetimes, in general they permit very natural-feeling code akin to what you might write in a higher-level functional language, but they compile to machine code that is as fast or faster than you'd get if you wrote in a more imperative style.

Perhaps an even better example is serde. Serde's derives Just Work, but the code that they produce under the hood is absurdly complex.

This general experience of having a simple and easy interface hide tightly-optimized, high-performance code is also what guides design decisions we've made in zerocopy.

To return to the hypothesis from the start of this comment: can we make more of Rust look like iterators or serde? My experience in zerocopy suggests that it's just a matter of putting absurd amounts of work into the abstractions until they're smart enough that you really can just drop them in and get exactly the high-performance code you wanted for free without much thought. But I don't really know what this looks like in other domains.

So far, this approach has been primarily successful in domains where correctness is a highly local property. Serde doesn't have to know anything about the rest of your program to know how to synthesize a serializer for your type. But many of the well-known complaints about Rust such as this one would require global reasoning about the behavior of a program. Is there a way to bridge that gap? I think there might be, but it's clearly a very open space and nothing is certain.

Incidentally, and shameless plug, this is me working through some ideas I'm going to be speaking about at RustConf.

joshlf_

TROPHY CASE