RAM init code violates pointer provenance and aliasing rules

[jonas-schievink]

RAM initialization currently passes pointers to these statics to r0:

usbarmory.rs/firmware/usbarmory-rt/src/lib.rs

Lines 57 to 66 in 692433d

	extern "C" {
	static mut _sbss: u32;
	static mut _ebss: u32;
	static mut _sdata: u32;
	static mut _edata: u32;
	static _sidata: u32;
	}
	r0::zero_bss(&mut _sbss, &mut _ebss);
	r0::init_data(&mut _sdata, &mut _edata, &_sidata);

But since r0 will fill the entire memory range between the pointers, it ends up calling offset with values that create pointers well beyond the u32 the static is declared to contain. According to the docs of offset, this is UB:

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.

(every static also counts as its own "allocated object", I believe)

Moreover, the ptr::write and ptr::write_volatile calls in r0 also cause UB, because this invariant is violated:

dst must be valid for writes.

Where the validity of a pointer requires this:

For a pointer to be valid, it is necessary, but not always sufficient, that the pointer be dereferenceable: the memory range of the given size starting at the pointer must all be within the bounds of a single allocated object. Note that in Rust, every (stack-allocated) variable is considered a separate allocated object.

...but again, we are crossing between potentially many allocated objects (every static in the .data/.bss section).

Furthermore, writing to a static through a pointer not derived from that static might violate aliasing rules, but it isn't yet clear if this is the case today (I've asked the folks working on the unsafe code guidelines for clarification / guidance).

The most robust solution for this issue is to write the RAM init code in assembly instead of Rust, and run no Rust code at all until RAM is initialized.

(this issue was recently discovered to affect most -rt crates in the ecosystem; we do not believe it to cause practical issues at the moment)

[tony-iqlusion]

@jonas-schievink thank you for bringing this to our attention. We will look into ASM solutions for RAM init code.