RAM initialization code violates pointer provenance

[jonas-schievink]

https://github.com/rust-embedded/cortex-m-rt/blob/96525a64197049d11cfc8cb5cc2c4dc9b5240e42/src/lib.rs#L939-L959

This code uses a pointer to a single u32, but writes an arbitrary amount of data beyond the u32. This is UB, as it violates the contract of ptr::offset, which is called by r0. Namely:

Both the starting and resulting pointer must be either in bounds or one byte past the end of the same allocated object. Note that in Rust, every (stack-allocated) variable is considered a separate allocated object.

[jamesmunns]

Linking relevant issues so others can follow breadcrumbs:

• https://github.com/betrusted-io/betrusted-rt/issues/1
• https://github.com/iqlusioninc/usbarmory.rs/issues/74
• https://github.com/rust-embedded/riscv-rt/issues/69
• https://github.com/rust-embedded/msp430-rt/issues/13
• https://github.com/tock/tock/issues/2222

We also need to reach out to tock-os, I'll open an issue there shortly.

Edit: Added tock-os issue

[nagisa]

Note relevant discussion: https://rust-lang.zulipchat.com/#narrow/stream/136281-t-lang.2Fwg-unsafe-code-guidelines/topic/The.20least.20incorrect.20init.20code.20.3A)

[jonas-schievink]

Copying @RalfJung's comment from that Zulip thread:

This question is indeed well outside the usual abstract machine model, so I find it hard to say much. It quite clearly violates the aliasing rules, but also in some sense it happens before the abstract machine is even initialized and the aliasing rules start making sense. A compiler barrier is strongly advised, is unfortunately all I can say -- sorry.

I'd say the most practical way to continue is thus:

• Add compiler_fences to r0 (done in https://github.com/rust-embedded/r0/pull/25), publish that as 1.0.1. We might want to yank 1.0.0, but we won't yank/deprecate the whole r0 crate.
• Land #301 anyways, because it results in better assembly than what LLVM generates.
• Leave it to the maintainers of downstream -rt crates whether they think they need to do the initialization in assembly.

[RalfJung]

Note that I was talking about the "writing to statics without actually going through the static" part in what you quote above.

The issue about out-of-bounds accesses is a separate one, for which I created a new UCG issue as this has come up before: https://github.com/rust-lang/unsafe-code-guidelines/issues/259.