Description
Hello!
@tyler-potyondy, @Samir-Rashid and I are porting OpenThread to Tock.
Goals
We are looking to utilize Tock's flash features so that OpenThread can save some state persistently.
We have the following two constraints:
- We want full isolation between flash storage of user applications. Ex: another application should not be able to read/write to OpenThread's flash storage region.
- We want to store up to around 4KB of flash data.
Issues
We have looked into Tock's flash offerings and have come across two potential options:
According to our current understanding of these features, they are insufficient for our needs. Can anyone confirm if the following is an accurate understanding and that there is no way to do this flash isolation without keeping the flash region in memory?
app_flash_driver
-
Here is how we understand the app_flash_driver to work:
- The user application reserves region of flash at app-compile time. See this example in libtock-c
- Tock maps flash region to user program memory (similar to mmap) See this libtock-c comment
- Need to manually sync entire mapped memory region to flash device. See here
-
Pros:
- Isolation is given.
tock/capsules/extra/src/app_flash_driver.rs
Lines 101 to 111 in 01918fa
- Cons:
- We must write entire flash region at once. This is problematic since we might need up to 4KB in flash and only need to make updates to a few bytes at a time.
- Entire flash region must be mapped into memory. We are potentially memory constrained and storing 4KB in memory is not ideal.
nonvolatile_storage_driver
- How we think it works:
- Can read/write anywhere on flash device. Only protection provided is between user and kernel flash.
tock/capsules/extra/src/nonvolatile_storage_driver.rs
Lines 218 to 229 in 01918fa
- Pros:
- Allows us to write a few bytes at a time (unlike our entire flash region in app_flash_driver)
- Don't need to keep our flash region mapped to memory (unlike app_flash_driver).
- Cons:
- Provides no isolation of flash storage between user applications.
Question
With these two existing offerings, it seems that it is not possible for us to have flash isolation while avoiding mapping our entire persistent state to memory. One potential solution is to add application-level isolation to the existing non-volatile driver. This can re-use the mechanisms that app_state uses for reserving space at app-compile time. Otherwise, we are open to suggestions on how to proceed.