knurling-rs / flip-link

Adds zero-cost stack overflow protection to your embedded programs
Apache License 2.0
266 stars 6 forks source link

Handle multiple RAM regions #3

Open MathiasKoch opened 3 years ago

MathiasKoch commented 3 years ago

Currently this only checks for overflows in single-ram region called RAM.

Eventually it would be awesome to support multi region layouts like:

MEMORY
{
    RAM             : org = 0x20000000, len = 96k      /* SRAM1 */
    RAM2            : org = 0x10000000, len = 32K      /* SRAM2 */
}

The "line-by-line" parser only looks for RAM: org = ..., but I am not sure if this is the actual blocker?

Also minor side issue; This line: https://github.com/knurling-rs/flip-link/blob/e123f17ba307832d8287ceb708099f2be8100a83/src/main.rs#L61 Should probably read MEMORY.RAM not found after scanning linker scripts ? Missing the not

japaric commented 3 years ago

Eventually it would be awesome to support multi region layouts like:

What kind of layout do you have in mind? For instance, if you place the stack in RAM2 and the rest of sections in RAM then already have stack overflow protection and flip-link should be a no-op.

This definitively seems doable but we need to list the potential arrangements of stack, static variables and heap. Also more than 2 RAM regions seems possible though I'm not sure cortex-m-rt supports that particularly well.

japaric commented 3 years ago

if you place the stack in RAM2 and the rest of sections in RAM then already have stack overflow protection and flip-link should be a no-op.

if we rely solely on standard sections like .bss and .data we may miss the cases where the user puts a custom section (.my_section) in RAM2 -- that could result in a collision. Perhaps we should look at the addresses of symbols instead of at the sections in that (2 RAM regions) case?

MathiasKoch commented 3 years ago

Ohh

You are totally right! I was waaay to fast on an early monday morning! Totally forgot we are only talking about stack. Please disregard this issue! Feel free to close.

japaric commented 3 years ago

I'm going to leave this open because I think we want to "support" at least the 2 RAM region configuration. By support I mean flip-link should not error and panic and it should produce a binary that won't result in memory corruption due to stack overflow (even if that means doing nothing = linking normally). Also, I'm not sure what the behavior is in the 2 RAM regions case; that's an scenario I haven't really tested.

MathiasKoch commented 3 years ago

In my case i am using both ram regions, but only for static queues and buffers:

#[init(None)]
#[link_section = ".ram2"]
res_queue: Option<ResQueue<AtatRxBufLen, consts::U5>>,
#[init(None)]
#[link_section = ".ram2"]
urc_queue: Option<UrcQueue<AtatRxBufLen, consts::U10>>,
#[init(None)]
#[link_section = ".ram2"]
com_queue: Option<ComQueue<consts::U3>>,

// Cellular Socket Buffer
#[init(None)]
#[link_section = ".ram2"]
socket_set: Option<SocketSet<consts::U2, consts::U2048>>,