#[link_section] is unsound on Harvard architectures

[H2CO3]

As pointed out in this thread on URLO, it is possible to read arbitrary memory without unsafe using the link_section attribute on architectures with separate address spaces for code and data.

To cite OP's code:

// Store PROG_BLOB in program space, ".text" would also work
#[link_section = ".progmem"]
static PROG_BLOB: [u8; 128] = [42; 128];

fn main() -> ! {
    let mut serial = /* initialize a serial output */;

    let mut idx = 0;
    loop {
        // This access is illegal, because Rust will emit a normal load
        // instruction, whereas the data is in the program space,
        // requiring a special load instruction.
        let b = PROG_BLOB[idx];

        // Dumping arbitrary RAM data!
        ufmt::uwrite!(&mut serial, "{:?} ", b).void_unwrap();

        idx += 1;
        if idx == BIG_BLOB.len() {
            break
        }
    }
    loop {
        // Just loop forever
    }
}

I expected to see this happen: the code should not compile, as it reads OOB memory.

Instead, this happened: The code compiles and outputs incorrect values, indicating UB.

[Nemo157]

See also #28179 and #72209, maybe this attribute could also be pulled under the unsafe_code lint (even on non-Harvard architectures it seems plausible that there's some way to cause unsoundness with it depending on the default linker scripts?).

[apiraino]

Assigning P-low as discussed as part of the Prioritization Working Group procedure and removing I-prioritize.

[DemiMarie]

I’m pretty sure #[link_section] is unsafe anyway. At a minimum I suspect you can segfault by putting a function in non-executable memory, or break assumptions by putting an (immutable) static with a nonzero value in a section that gets zeroed.

[geofft]

Now that we have #123757, the 2024 edition will require writing #[link_section] as #[unsafe(link_section)] and it is prohibited under #![forbid(unsafe_code)]. See this playground example. Does that resolve this issue? (There wasn't an expectation that we could get Rust to emit the right load operations, or something, right?)

[RalfJung]

Ideally this concern is documented somewhere with that attribute basically in the safety docs for the attribute.

[RalfJung]

Ah, but that's not an I-unsound issue, so maybe let's track adding documentation in #123757 instead.