I have a question about the reaction of uVisor after detecting a tried access to a restricted area or a missing ACL. Right now, during my first tests, I only saw a complete stopped OS on my target after an unallowed access. The reason for my question is that I want to build applications which at an unallowed access of a box only stopp this box while all other boxes keep running.
This reaction would be nessesary in an application which handles a sensor and an actuator in one box and a website in another box for visualizing the value of the sensor. If somebody injects code to the box of the website to overwrite the values of the sensor, the box with the website should be stopped and the box with the sensor and the actuator should keep running.
Is it possible to stop only the box with the unallowed access? Where can I configure this reaction?
Current uVisor reboots the device after catching a security problem. The solution for just rebooting a single box would be implemented using the planned debug box feature. The debug box would be able to catch a box faulting and resetting just that box.
Architecturally its better to move the logic for handling a box-specific reset into the application debug box, as it can notify depending boxes of the reset, as they would need to re-establish potential session.
In case you’re interested in that feature, please comment on the topic mentioned above or feel free to open a new issue in the uVisor github repository.
Thank you for the answer. Yes, I’m interested in that feature you described.
So rebooting a single box isn’t implemented yet, am I right? The next days I’m gonna make some experiments with the debug box.
Sorry for the long time till I’m answering your post, but my bachelor thesis leads me to some big issues with uVisor and lwip (see https://github.com/ARMmbed/uvisor/issues/315#issuecomment-263006097)