Initialize data and bss sections in assmebly#101
Initialize data and bss sections in assmebly#101BartMassey merged 3 commits intorust-embedded:masterfrom
Conversation
The embedonomicon currently suggests to initialize the bss and data sections in Rust code. However, since this was written, there has been extensive discussion about the soundness of the runtime initialization code. In particular, the following questions have been raised: - Whether it is sound to write outside the bounds of the data pointed by pointers whose provenance come from a static variable. - Whether it is sound to mutably alias all static memory and write to it during initialization. - Whether it is unsound to enter the Rust abstract machine without the static variables being initialized. - Whether pointers obtained from different static allocations (such as `_sbss` and `_ebss`) can be compared. Note that the code in embedonomicon does not suffer from this issue, since pointers are converted to `usize` values such that provenance does no longer apply by the time they are subtracted to determine the region size. This was not the case in multiple runtime crates. The general consensus in the ecosystem has been to move away from performing the initialization of the static memory regions in Rust. In order to avoid creating a false sense of security while reading the embedonomicon, these issues should be mentioned in the book, and the code written in assembly to reflect the current best-practice approach to platform initialization code. References: - rust-embedded/cortex-m-rt#300 - rust-embedded#69 - https://rust-lang.zulipchat.com/#narrow/stream/136281-t-lang.2Fwg-unsafe-code-guidelines/topic/The.20least.20incorrect.20init.20code.20.3A) - rust-lang/unsafe-code-guidelines#259 - rust-embedded/cortex-m-rt#301
And why we do not do it in Rust
|
I've added this as an agenda item for the Embedded WG meeting this coming Tuesday rust-embedded/wg#875. I really appreciate the thought and effort you've put into this; please feel free to come help us figure out the right things at the meeting. |
Thank you! I should have brought it up myself for discussion in the first place, but I thought I'd go ahead and show my proposal! I will be glad to attend the meeting on Tuesday and help if I can 👍🏻 |
jonathanpallant
left a comment
jonathanpallant
left a comment
There was a problem hiding this comment.
Looks good to me, but let's not merge until the discussion at the meeting.
BartMassey
left a comment
BartMassey
left a comment
There was a problem hiding this comment.
The REWG looked these over and approved them. Thanks much for this.
3 participants
The embedonomicon currently suggests to initialize the bss and data sections in Rust code. However, since this was written, there has been extensive discussion about the soundness of the runtime initialization code.
In particular, the following questions have been raised:
_sbssand_ebss) can be compared. Note that the code in embedonomicon does not suffer from this issue, since pointers are converted tousizevalues such that provenance does no longer apply by the time they are subtracted to determine the region size. This was not the case in multiple runtime crates.The general consensus in the ecosystem has been to move away from performing the initialization of the static memory regions in Rust. In order to avoid creating a false sense of security while reading the embedonomicon, these issues should be mentioned in the book, and the code written in assembly to reflect the current best-practice approach to platform initialization code.
References: