Security & Functional Safety

A major threat for embedded systems are network interfaces, because they can put an unanticipated load on the system. For example, a faulty device could increase traffic on the network or send wrongly packed data. IoT devices are especially vulnerable to this threat as they are accessible through the internet. But with increased network connectivity this concern also applies to industrial systems, wireless sensor networks or building automation. An RTOS should therefore prevent overload or errors from one task to spread to the whole system.

Most of the general purpose RTOS we have seen in the survey offer a SIL-3 certified variant. The certification proves functional safety for automotive and railway applications. Although Rust is stricter at compile time than C, the language is not certified for functional safety applications and no guidelines like MISRA C/C++ are in place. Still, functional safety is a concern and the implementation of the Bern RTOS should rely on the stable Rust compiler version (not beta or nightly). Moreover, the RTOS must be usable without dynamic memory allocation.

The Bern RTOS strives to isolate bugs that can arise from external factors such as network interfaces and software bugs that the compiler cannot detect. As a consequence tasks on ARM architectures should be run in thread (unprivileged) mode and access to the hardware should only be possible through the kernel. Any attempt to access a resource a task has no privileges can be caught by the memory protection unit (MPU) [10]. As a trade-off this solution will introduce some latency in reaction time because the MPU configuration has to be changed on a context switch and to access hardware the CPU must switch to kernel mode.

Internet of things raised concerns about the security of embedded systems that are connected to internet. This means above all that systems and network stacks must be updated to close security loopholes. A bootloader, encryption and key management is needed for a secure update process. These are features that can added in modules at a later stage, but I will neglect them for the kernel development.

The main objective of the Bern RTOS is a system that does not crash. Strong typing and Rusts ownership will help to reduce the number of bugs at compile-time. The architecture design and memory protection hardware should isolate bugs at runtime. This will help to make the RTOS stable, safe and secure.