Open Kernel Products
Developer Resources
Platform Requirements
Minimized Privileged Context and Content
Both legacy RTOSes running complex application stacks and enterprise-style embedded OSes suffer from comparable ailments - running too much sensitive and critical code in a single execution context. RTOS kernels, drivers, libraries, middleware and application code all share a single namespace and physical address space. Errant routines or external exploits meet no barriers whatsoever to corrupting and/or commandeering the entire complement of resources in the device. Embedded Linux or even Windows at least separates system code from user applications but can present larger and more vulnerable execution contexts for exploitation - massive OS kernels (4-8 MLoC) that share address space with device drivers and shared user-space resources (application registries, file systems, network applications, etc.).
A secure embedded platform must give architects the means to segment systems and applications code into trusted and untrusted domains. It must offer the ability to minimize the scope of, access to, and resources needed by trusted or privileged program execution.
Encapsulation / Isolation
Building a secure system starts with restricting scope of privileged operations and access. POSIX-style process spaces in enterprise-class OSes offer a degree of needed isolation but fail to address exposure from commingling kernel and driver code and the need to isolate networking stacks, DRM implementations, and entire untrusted OSes.
A secure embedded platform is one that lets designers encapsulate and isolate critical resources with appropriate and scalable granularity and control.
Controlled System IPCs
Isolating critical resources can still prove insecure if untrusted programs can freely exploit system communications mechanisms (especially IPCs such as signals, pipes, semaphores, shared memory, etc.).
A secure embedded platform must provide a trusted and high-performance (sub)set of communications and synchronization mechanisms to facilitate communication among trusted and untrusted domains without compromising the security of either.
Manage Resources against DoS
Traditional embedded RTOS-type platforms were designed for lightweight task execution and rapid response to stimuli with mostly static compute loads. When systems based on legacy RTOS software must accommodate and balance new loads, post-deployment, and dynamically provide resources to accommodate out-of-spec inputs such as high network traffic, overall performance and throughput at best suffer, and at worst, the systems fail.As such, RTOS-based networking applications can easily fall prey to Denial of Service (DoS) attacks. Typically, a barrage of unexpected service requests can tie up CPU and memory resources, slowing or completely stopping application traffic and transactions. In extreme cases, network traffic causes broad thrashing, degrading other functions and depleting available memory, leaving watchdogs to clean up the mess.
A secure embedded platform must be able to control and allocate resources selectively to trusted and untrusted subsystems, from device drivers to network stacks to whole OSes.