SPI service sometimes fails to start when run in sandbox mode

mangOH Red
1

Hello all,

This is an issue I’ve already briefly discussed with @dfrey. In essence, the app supervisor fails to grant the spiService access to the required /dev/spidev0.0 path. I believe this occurs when the supervisor starts before the required spidev kernel module is loaded (we load this module at boot by appending spidev to /etc/modules). I’ll post some logs that show this behaviour a little later today when I’m at the office.

Oddly enough, this only seems to occur on one of our 5 units. Additionally, this issue can be “solved” by running the spiService outside of a sandbox by modifying spiService.adef in the Legato source and then re-compiling. Obviously this is not ideal as it requires forking from the main Legato releases and compromises some security on the target device.

I’ve seen lots of discussion on here about the spiService failing to start on boot despite the app definition specifying start: auto without a conclusive root cause or solution. I believe this is the root cause based on what I’ve seen. In terms of solving this, would it be plausible to ensure all kernel modules are loaded before the supervisor is allowed to start?

If any additional information would be helpful for debugging, please let me know and I’ll provide it.

Any help is greatly appreciated.

2

Gist of the logs

3

Thanks @nick. I have routed this feedback to the appropriate people within Sierra Wireless.

4

Thanks @dfrey.

How severe of a security risk is it to run apps outside of a sandbox? If an attacker manages to run malicious code on the device, could they theoretically call IPC sub-routines from the un-sandboxed app?

Either way, I may try and fix this by forking the supervisor to wait for /dev/spidev0.0. I’ll definitely prioritize it much more if the security risk is severe. The sandbox feature of Legato adds a nice layer of security (to my understanding) so it would be nice to use it.