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

sim: Test interruptions in the middle of write or erase operations #2108

Open
taltenbach opened this issue Nov 2, 2024 · 0 comments
Open

Comments

@taltenbach
Copy link
Contributor

Currently, the simulator is used to ensure an interruption of an upgrade or revert process occurring between any flash_area_write or flash_area_erase operation would properly be handled by MCUboot. There is no test checking the behavior of MCUboot in case the interruption occurs in the middle of such an operation.

However, flash_area_write and flash_area_erase operations are not guaranteed to be atomic and a power failure happening in the middle of a such an operation might therefore lead to a state where the data has been partially written or erased. Write operations are made word by word, the size of the word depending on the hardware capabilities and the flash driver implementation. Erase operations are made sector by sector, the size of the sectors depends on the hardware and is not necessarily equal to the sector size used by MCUboot. Any write operation longer than a word and any erase operation performed on multiple sectors is not atomic.

Therefore, the current tests would not reveal issues related to power failures happening in the middle of a write or erase operation, which is the reason why #1966 passed unnoticed until recently.

Simulating an interruption between every word writing would be extremely time consuming. Doing it randomly could work but lead to a non-deterministic test. However, it should be noted that, in practice, a power failure occurring in the middle of a write or erase operation is not likely to cause any issue unless the operation is modifying data that is read by MCUboot at boot and interpreted to determine where the upgrade or revert process has to be resumed. Therefore, it should not be necessary to simulate interruptions in the middle of operations that are not altering a trailer. This could be extended to the image header and TLV areas if considered useful.

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

1 participant