search

rust-embedded / cortex-m

Low level access to Cortex-M processors
Apache License 2.0
791 stars 142 forks source link

`static mut` transform is unsound on multi-core systems #411

Open Disasm opened 3 years ago

Disasm commented 3 years ago

RP2040 starts execution on both cores. If entry function contains a "special" definition of static mut variable, each core takes a mutable reference to it, which is illegal from the Rust point of view.

Here is the relevant piece of #[entry] code: https://github.com/rust-embedded/cortex-m-rt/blob/ca4790f40738bcc770285c8080955a2077682078/macros/src/lib.rs#L87-L88

jonas-schievink commented 3 years ago

cortex-m-rt only supports single-core systems

Disasm commented 3 years ago

Is it stated anywhere apart from this comment?

adamgreig commented 3 years ago

Do the static mut transforms in the macros provide much value? I can't remember but I think we discussed removing them at some point, maybe involving rust-embedded/cortex-m#407/#250. Cortex-m's Mutex is definitely only single-core aware too, though, and I'm not sure what else would need changing in c-m-rt to make it safe on multi-core systems (at least, when they both execute the same code).

Doesn't the RP2040 ROM send the second core to sleep, so it only starts execution after being signalled once user code is running?

jamesmunns commented 5 months ago

Chiming in that this also applies to #[interrupt] macro, if the two cores share the same vector table/ISR functions.

thejpster commented 5 months ago

It's unsound where the interrupt function can be re-entered. The NVIC usually prohibits this but on a multi-core system you need something at the HAL level to ensure this. You can imagine a mechanism that moves ownership of system interrupts from one core to another, hiding the regular NVIC API from the user. Then it would still be sound.