Repository navigation
#[link_section] is unsound on Harvard architectures #76507
Description
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.
Activity
Nemo157 commentedon Sep 9, 2020
See also #28179 and #72209, maybe this attribute could also be pulled under the
unsafe_codelint (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 commentedon Sep 16, 2020
Assigning
P-lowas discussed as part of the Prioritization Working Group procedure and removingI-prioritize.DemiMarie commentedon Apr 14, 2022
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 commentedon Aug 28, 2024
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 commentedon Aug 28, 2024
RalfJung commentedon Aug 28, 2024
Ah, but that's not an I-unsound issue, so maybe let's track adding documentation in #123757 instead.