Best practices for sharing memory with untrusted parties

[RalfJung]

This was the starting point for #152. That got closed saying "volatile is for MMIO", which is further discussed in #321. However, since then we got "also volatile can access memory outside the AM" (rust-lang/rust#141260) which changes the picture again IMO. The question also recently came up in rust-lang/rust#154321.

I would say the safest (least AM/model-breaking) way to share memory with an untrusted party is to never make that memory part of the AM. This avoids any trouble related to memory models or compiler assumptions. If this isn't actual "memory" in the first place, there can't be any assumptions. And now that volatile accesses are allowed to access such "non-memory", this is actually a viable option. I think this also explains why people are naturally drawn towards using volatile for this kind of interaction. If LLVM changes volatile loads to no longer be willreturn (which @nikic says is on the table), this model even allows reads and writes on memory that might get unmapped at any time. (Alternatively, #606 discusses ways for such segfaults to be valid everywhere, that'd also implicitly cover volatile accesses.)

For a Rust program this means only using raw pointers, never creating a reference, and only using read_volatile and write_volatile. Those don't even have to be atomic; all concurrency behavior is hidden behind the opaqueness of volatile accesses. (Atomic volatile accesses are useful if the party those accesses are communicating with also has access to actual Rust memory. That's not the case for this discussion.) It currently also means never using offset or field projections but we could fix that (#350) -- the LLVM IR we generate is already okay here, we "just" have to update our Rust-level model.

---

The other model we have discussed in the past is to have that shared memory be actual Rust memory and model whatever the untrusted code does as atomic accesses. This means the Rust code must also use atomic accesses. This seems to work fine in practice but the model actually has a gaping hole -- mixed-size accesses are UB, so the untrusted code can still cause UB in the Rust code. The advantage of this model is that the Rust code is allowed to use shared references (as long as all bytes of the pointee type are inside an UnsafeCell).

[comex]

mixed-size accesses are UB, so the untrusted code can still cause UB in the Rust code.

But note that this UB could theoretically go away in the future. As one possibility, if Intel clarifies their documentation (#345), it might be possible to eventually update memory models so that mixed-size atomics just 'do the right thing'. That would be nice. Alternatively, we could continue to assume mixed-size atomics might tear, but make tearing well-defined, a concept which is desired anyway for atomic per-byte memcpy (as discussed in rust-lang/rfcs#3301).

Another note: the "untrusted code performs atomic accesses" model raises the question of whether those accesses are allowed to store uninit bytes, and if so, what programmers are supposed to do to guard against it. This is briefly discussed here.

[RalfJung]

Please let's not derail this issue with mixed-size atomics. That's already being discussed in #345, I replied there. The summary is that mixed-size accesses are not happening near-term and atomic bytewise memcpy does not make progress towards mixed-size accesses.

---

Another note: the "untrusted code performs atomic accesses" model raises the question of whether those accesses are allowed to store uninit bytes, and if so, what programmers are supposed to do to guard against it. This is briefly discussed rust-lang/rfcs#3301 (comment).

Given that the untrusted code is modeled as asm code, I think it is fair to say that it cannot store uninit bytes, as that concept does not exist in asm.

[Darksonn]

In that case, we should reconsider rust-lang/rust#58041 (comment)

[jethrogb]

In the “atomic” model, should it be allowed to create UnsafePinned mutable references to such memory?

[comex]

I do not think I was derailing the issue. I was merely summarizing the long-term prospects of mixed-size atomics, which are relevant to the question in this thread of which of the two models (volatile or atomic) should be used when sharing memory with untrusted parties.

On another note,

Atomic volatile accesses are useful if the party those accesses are communicating with also has access to actual Rust memory. That's not the case for this discussion.

In my experience, it's pretty common for shared-memory communication protocols to rely on atomic operations like compare-and-swap, swap, etc. For example, WebKit and Chromium both use atomic swaps in their IPC implementations.

Other shared-memory protocols use only loads and stores, but still rely on release/acquire ordering (to establish ordering between loads/stores to different parts of the shared memory buffer). These include Linux's io_uring and xnu's IOSharedDataQueue.

Whatever approach we recommend for sharing memory with untrusted parties, it needs to support these operations somehow.

[RalfJung]

@jethrogb

In the “atomic” model, should it be allowed to create UnsafePinned mutable references to such memory?

Opsem-wise, that would be pretty much equivalent to UnsafeCell shared references, yes. I would say that UnsafePinned is meant for pinning so this would be somewhat of a misuse of that mechanism, but that is an API design question, not an opsem question.

[RalfJung]

@comex

Other shared-memory protocols use only loads and stores, but still rely on release/acquire ordering (to establish ordering between loads/stores to different parts of the shared memory buffer). These include Linux's io_uring and xnu's IOSharedDataQueue.

FWIW volatile operations are totally ordered with each other so this should not be a problem. However you make a good point that volatile CAS is not a thing.

[bjorn3]

FWIW volatile operations are totally ordered with each other so this should not be a problem.

The compiler isn't inserting any fence instructions, right? So they would only be totally ordered when operating on strongly ordered memory like MMIO ranges mapped as uncached.

[RalfJung]

Oh right I forgot about hardware-level weak memory. 🙈