Why does const-prop refuse to read from statics that contain pointers?

[RalfJung]

const-prop checks statics for whether they contain relocations, and if they do, it refuses to read from them. It is not clear why that happens.

As discussed in #70241 (comment), it turns out that const-prop will sometimes permit reading from mutable global allocations. That could be a soundness issue in case those allocations are actually mutated at run-time; const-prop would then be propagating non-constant data.

Currently it is not entirely clear what those mutable allocations are that const-prop is reading from, all we have is an ICE because an unexpected error ("const-prop does not support reading from mutable global allocation") arose during validation. It is also unclear (to me, at least) why const-prop is doing validation at all.

Cc @oli-obk @wesleywiser

[RalfJung]

I just realized the condition is allocation.mutability == Mutability::Mut || allocation.relocations().len() > 0, so maybe the allocation in question was not even mutable but had relocations in it. I am testing that now.

I do not understand the argument given in the code for why relocations are a problem:

        // If the static allocation is mutable or if it has relocations (it may be legal to mutate
        // the memory behind that in the future), then we can't const prop it.

If the memory behind that pointer is mutable, we will notice that when that allocation is being accessed. Why do we have to bail out so early? Is it because the hook used to only be called for statics, not all global allocations?

[RalfJung]

Also the mystery about why validation is even happening is answered here:

rust/src/librustc_mir/transform/const_prop.rs

Line 643 in 1add455

if let Err(e) = self.ecx.const_validate_operand(

I think I understand why, conservatively, this does validation... can this ever fail? Validation is quite picky about the kinds of errors in expects can happen, and with const-prop having a machine that bails out early on many operations, that could be a problem. The reason validation is so picky is to make sure we get good errors, which const-prop does not care about (the errors are not shown to the user), but it re-uses the same machinery.

[RalfJung]

Okay so the actual problem turned out to be relocations. There is no bug here, we can reject all reads from mutable globals (phew).

What remains open is why we check for the presence of relocations at all. @wesleywiser you added that comment that I mentioned above, would be great if you could explain it a bit more. :)

[wesleywiser]

@oli-obk wanted it:

for now also bail out if the allocation has relocations. If a static contains a *mut i32 it may be legal to mutate the memory behind that (if not now, maybe in the future).

But I'm not quite sure why...

[oli-obk]

Basically I want to avoid the following (assume it compiles with more boilerplate) from optimizing foo to unsafe fn foo() -> u32 { 42 }

static A: UnsafeCell<u32> = UnsafeCell::new(42);
static B: &'static UnsafeCell<u32> = &A;
unsafe fn foo() -> u32 {
	*B.get()
}

Since we can't ever know what users are up to with their code, the presence of relocations was the easiest way to avoid any kind of troubles there.

Furthermore, assuming we just forbid raw pointers from being derefed in const prop, we'd still have problems with the following getting const propped::

let x = Cell::new(42);
let y = &x;

I want to prevent const prop from creating any kind of mutable global memory that we may end up pointing to. While we can probably devise a smart scheme, right now it seems better to just forbid any relocations.

[RalfJung]

@oli-obk that sounds to me like an indirect way to do the check that we can now do much more reliably and directly:

rust/src/librustc_mir/transform/const_prop.rs

Lines 285 to 287 in cdb50c6

	if allocation.mutability == Mutability::Mut {
	throw_machine_stop_str!("can't eval mutable globals in ConstProp");
	}

This is done for all accesses to globals (things stored in tcx). So if a constant global points to a mutable one, the check will fire when the mutable global actually gets accessed.

[oli-obk]

that's true. Makes more sense to handle the first case like that.