[NOTES] Sandbox concept

[steved]

I am going for a subset of Posix API too

Posix APIs are, in general, a good idea IMO. It's becoming increasingly possible to use 3rd party libraries which expect a Posix API, and having a proper implementation would be useful. (This includes a Posix wrapper for many RTOS functions)

[Giovanni]

I think stdin, stdout and stderr would be an important link between the sandbox and the main system. The stderr route might benefit from being treated as a higher priority, perhaps options to have errors treated as either fatal (perhaps chSysHalt) or recoverable, where the sandbox might be terminated, but the main system handle the reported error.

Mike

Now stdin/stdout/stderr can be associated to any stream in the SB configuration, look at the demo, it is very easy. I also added a syscalls.c so the SB can use the full C library, I just tried printf() and it appears to work.

Next, I wish to add a virtualized HAL in order to access drivers "on the other side" but callback-based drivers are not possible, events-based ones should be fine. This one will probably take more time, the SVC interfaces are entirely to be designed.

The whole thing will allow to implement more robust embedded systems, code running in sandboxes cannot cause harm and can be restarted in case of problems.

Giovanni

[Giovanni]

Posix APIs are, in general, a good idea IMO. It's becoming increasingly possible to use 3rd party libraries which expect a Posix API, and having a proper implementation would be useful. (This includes a Posix wrapper for many RTOS functions)

Posix is huge, the implementation it is limited to file handle functions on standard descriptors so far. Pthreads would be difficult unless a sub-scheduler is placed directly into the sandbox.

Giovanni

[steved]

Posix is huge, the implementation it is limited to file handle functions on standard descriptors so far. Pthreads would be difficult unless a sub-scheduler is placed directly into the sandbox.

That's a pity; PThreads is probably the second most useful part of Posix to implement, IMO.

[mikeprotts]

I'd prefer sandboxes to be single threads. Keep them simple and if you need more, run a second sandbox.

Mike

[Giovanni]

Right now it is able to run multiple sandboxes already, creating multiple threads inside would be possible but there would be several problems to consider:

- Sandboxed threads need 2 stacks: User-PSP and Supervisor-PSP. Creating a thread would require allocating a S-PSP on the RTOS side, that would mean a pre-allocated pool of buffers for sandbox threads, you would need to define a maximum number of threads among all sandboxes OR use dynamic allocation.
- If you allow multiple threads then you will also need allocation of semaphores, mutexes and other objects.

The alternative would be to have a sub-scheduler able to implement threading entirely on the sandbox side. It could be also something very simple like this: http://dunkels.com/adam/pt/ (I like this solution, it would be optional and lightweight, NIL could be used too).

Giovanni

[Giovanni]

Hi,

It is mostly complete, needs test and feedback mainly.

About the watchdog concept. My idea is, why limit it to the sandbox? wouldn't be better to introduce a generic thread watchdog mechanism in RT (and perhaps also in NIL)?

Threads would call:

Code: Select all

chThdSetWatchdog(sysinterval_t timeout, watchdog_action_t action);

Each thread could establish its own maximum running time and an action (pointer to a function) to be performed if the timeout is triggered. Of course this would work also for sandboxed threads that would first set the timeout then enter the sandbox.

Without calling the function there would be no watchdog and the behavior will be the current one: no timeouts for threads.

I will add a "multiple channels" capability into the HAL ST driver, this will allow to use the same timer already allocated to tick-less mode also for the watchdog.

Giovanni