Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Soundly initializing custom memory sections #771

Open
ryan-summers opened this issue Jun 28, 2024 · 2 comments
Open

Soundly initializing custom memory sections #771

ryan-summers opened this issue Jun 28, 2024 · 2 comments

Comments

@ryan-summers
Copy link

ryan-summers commented Jun 28, 2024

Currently, pointer provenance appears to make it entirely impossible to correctly initialize a memory section within rust code because linkers communicate with the application by setting the address of variables. These passed-back variables then have a provenance that does not cover the entire memory region that needs to be defined. For example:

// Linker-provided symbols for a custom memory segment called `itcm`, which contain the start, end, 
// and initialization data pointers for the section, passed via variable address.
extern "C" {
    static mut __sitcm: u32;
    static mut __eitcm: u32;
    static mut __siitcm: u32;
}

unsafe {
    let sitcm = core::ptr::addr_of_mut!(__sitcm); // Provnenance of 4 bytes
    let eitcm = core::ptr::addr_of_mut!(__eitcm); // Provenance of 4 bytes
    let siitcm = core::ptr::addr_of_mut!(__siitcm); // Provenance of 4 bytes
    let len = eitcm.offset_from(sitcm) as usize;

    // This is UB because `sitcm` and `siitcm` only have provenance of 4 bytes from their respective 
    // addresses, when `len` > 4.
    core::ptr::copy_nonoverlapping(siitcm, sitcm, len);
}

Right now, it doesn't appear possible to soundly perform section initialization using data provided by the linker due to these provenance issues. I'm opening this issue to track the topic, as we were discussing this extensively in the Matrix channel earlier.

@jamesmunns
Copy link
Member

rust-embedded/cortex-m-rt#300 is the discussion where we removed this pattern from cortex-m-rt

@jamesmunns
Copy link
Member

rust-lang/unsafe-code-guidelines#259

I hadn't seen this update, it may be that statics are now more magical than I was arguing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants