interpret/allocation: expose init + write_wildcards on a range

[nia-e]

Part of rust-lang/miri#4456, so that we can mark down when a foreign access to our memory happened. Should this also move prepare_for_native_access() itself into Miri, given that everything there can be implemented on Miri's side?

r? @RalfJung

[rustbot]

Some changes occurred to the CTFE / Miri interpreter

cc @rust-lang/miri, @RalfJung, @oli-obk, @lcnr

[RalfJung]

@rustbot author

There's also something missing: either you need an operation that fills uninit bytes with 0 without doing the mark_foreign_write steps, or you need to patch write_uninit to enforce the general invariant that uninit bytes are 0. I think we should do the latter.

[rustbot]

Reminder, once the PR becomes ready for a review, use @rustbot ready.

[nia-e]

either you need an operation that fills uninit bytes with 0 without doing the mark_foreign_write steps

I think I implemented that in rust-lang/miri#4456 directly in Miri; under call_native_fn():

// Prepare for possible write from native code if mutable.
if info.mutbl.is_mut() {
    let alloc = this.get_alloc_raw_mut(alloc_id)?.0;
    if tracing {
        let full_range =
            AllocRange { start: Size::ZERO, size: Size::from_bytes(alloc.len()) };
        // Overwrite uninitialized bytes with 0, to ensure we don't leak whatever their value happens to be.
        for chunk in alloc.init_mask().clone().range_as_init_chunks(full_range) {
            if !chunk.is_init() {
                let uninit_bytes = unsafe {
                    let start = chunk.range().start.bytes_usize();
                    let len = chunk.range().end.bytes_usize().strict_sub(start);
                    let ptr = alloc.get_bytes_unchecked_raw_mut().add(start);
                    std::slice::from_raw_parts_mut(ptr, len)
                };
                uninit_bytes.fill(0);
            }
        }
    } else {
        // FIXME: Make this take an arg to determine whether it actually
        // writes wildcard prov & marks init, so we don't duplicate code above.
        alloc.prepare_for_native_access();
    }
    // Also expose *mutable* provenance for the interpreter-level allocation.
    std::hint::black_box(alloc.get_bytes_unchecked_raw_mut().expose_provenance());
}

Though there is a FIXME about this, I considered moving prepare_for_native_access() as a whole into Miri and avoiding code duplication that way. Making all uninit bytes be 0 feels like a notable perf hit, no?

[RalfJung]

I think I implemented that in rust-lang/miri#4456 directly in Miri; under call_native_fn():

Please don't. That's just unnecessary code duplication. Also, just because you now can access all these private parts of the allocation from Miri doesn't mean you should.

Making all uninit bytes be 0 feels like a notable perf hit, no?

Indeed, which is why I suggested a way that it can be avoided. :)

[rustbot]

The Miri subtree was changed

cc @rust-lang/miri

[nia-e]

Can't test locally but seems to build

@rustbot ready

[RalfJung]

I thought we had agreed that this function should just disappear entirely? I guess I was not clear enough, so here we go:

• please adjust write_uninit to fill the range with 0s
• then remove prepare_for_native_access, it is not not needed any more.

[nia-e]

Oh! Sorry, I thought you meant the opposite - I was concerned that having write_uninit() write zeroes by default would be a perf hit. But sure, I'll do that if you think it's an okay tradeoff

[RalfJung]

Ah, that was the misunderstanding then. :)

write_uninit already does some things that are probably more expensive than writing a few 0s, so I think it's fine.

[nia-e]

Should mark_init(false) also inherit this behaviour?

[RalfJung]

That's a private function... no, it doesn't need to.

[RalfJung]

@rustbot author

[nia-e]

@rustbot ready

[RalfJung]

(ignore CI, there was an oopsie and everything is broken)

[RalfJung]

Thanks!
I did some minor changes, mostly just comment tweaks.

@bors r+ rollup

[bors]

📌 Commit de15924 has been approved by RalfJung

It is now in the queue for this repository.

[nia-e]

...well I can't say I expected that but I'm not complaining!

[RalfJung]

I don't see a decent way to do this directly; best I can think of is extending Machine with fn uninit_is_zero(&self) -> bool and then using that since every callsite for Allocation::write_uninit() seems to be very close to having / already has an &impl Machine? Not the prettiest solution but I imagine the perf impact might be noticeable in cases relying on large lazily-initialised allocations. Though, I doubt many of those are const...

The Machine trait is not in scope in the file where Allocation is defined so this will not work in a clean way.

---

I will take this mostly as a null result, this is not that much above the usual noise level.

@oli-obk what do you think? Is it worth preserving the optimization where if you copy a large amount of uninitialized memory somewhere, we avoid actually touching the target memory and filling it with 0s? This was apparently added in #67658. I guess it was added for a reason but we don't have a benchmark for a large uninit array being copied around. Seems like a shame to regress this.

Maybe we should just say that it's entirely fine for native code to see non-0 leftover values in uninit memory. It's uninit after all...

[oli-obk]

Maybe we should just say that it's entirely fine for native code to see non-0 leftover values in uninit memory. It's uninit after all...

yes, I think that is the right behaviour. I haven't read the rest of the PR yet, will do so now

[oli-obk]

Yea we should just keep the bytes at whatever they were, even if that exposes some non-zero bytes.

[RalfJung]

@nia-e okay, so can you remove the filling-with-0s, and the comment stating that as an invariant, and add a comment in Miri in the native-lib code saying that yes this exposes whatever bytes happen to be in the "uninitialized" part to the C code but, well, it's uninitialized so it's arbitrary garbage anyway.

(The invariant about there being no provenance on uninit bytes is still true AFAIK. I don't think we need it but it's probably a good invariant to have and it doesn't hurt documenting it.)

[RalfJung]

@rustbot author

[nia-e]

Force-pushed, hope that's ok given it's tiny?

[nia-e]

@rustbot ready

[RalfJung]

Looks good, thanks. :)

@bors r+ rollup

[bors]

📌 Commit 8d0e0c6 has been approved by RalfJung

It is now in the queue for this repository.