Embedded Systems -> RTOSes shield from net-centric bugs

Popular embedded platforms such as the PowerPC and MIPS processors automatically include memory management capabilities in the memory management unit. However, to take advantage of the hardware memory protection, the system designer must use a memory-protected real-time operating system (RTOS) to access and utilize the processor's capabilities.

Before delving into the protection opportunities available in a memory-protected RTOS, let's compare a memory protected real-time operating system against the more common flat-memory operating system. In the flat-memory model, all applications and the operating system run in the same address space. Any application can directly access the operating system kernel code and data. The implications for system reli ability are obvious: A malicious piece of code or a careless stray pointer can take down any application in the system or the kernel itself. Thus, the first and foremost requirement for a reliable system is a memory-protected RTOS.

How else can a virus affect an application written in a flat-memory RTOS? Let's suppose the system consists of two applications, each with one task and each with the same priority for the CPU. The RTOS kernel includes a scheduler that automatically prioritizes tasks for the CPU. Under ideal conditions, the two tasks share 50 percent of the CPU's capacity and time. However, suppose one of the applications is erroneous, either by malicious intent or bad design, and spawns 100 additional "confederate" tasks. Now there are 101 bad tasks instead of one task sharing time with the good application. In effect, by spawning many confederate tasks, the virus starves the good application of CPU access. Now, instead of having 50 percent access to the CPU's resources, the good task has less than 1 percent. Most kernel schedulers cannot prevent starvation due to spawned confederate tasks. When a virus appears, it will cause the good tasks to starve for CPU time. A typical flat-memory RTOS will have a small footprint of approximately 10 kbytes for a small kernel.

By comparison, a memory-protected operating system such as the Integrity RTOS can achieve a memory footprint as small as 70 kbytes. Since a wireless handheld device requires IP stacks and other middleware software that consume much greater space, this is a modest size increase over the footprint of a flat-memory operating system to gain the advantages of memory protection and guaranteed resource availability. In addition to the security and reliability provided by the kernel, an advanced RTOS also supports cache initialization, board memory initialization and device drivers, referred to as a BSP, or board support package. Many flat-memory model kernels do not come with this initialization code. The RTOS provides se veral flavors of resource protection called "time and space domain protection."

The first time-domain-protection mechanism provides a minimum guaranteed percentage of the CPU's execution time for the priority level of the task or thread. The system developer assigns a "weight" or percentage to each task. Compared to the flat-memory operating system example described earlier, the system developer now assigns a weight of 50 percent to each of the two tasks, both with the same priority. Again, if one of the tasks is malicious and spawns 100 confederate tasks, the good one still retains 50 percent of the execution time. The malicious task also gets 50 percent of the execution time, but now that execution time is divided among 101 tasks (the original plus the 100 confederate tasks). By compartmentalizing access to the CPU in this way, the RTOS preserves and protects the integrity of the good tasks. However, it also isolates the malicious bug or virus, making it much easier to identify and correct the problem.

The second protection in the time domain is called a "partition scheduler." The concept of partitioning originated in avionics applications. For safety's sake and to conform with aircraft design standards in Arinc 653, tasks run by the CPUs on an aircraft must be partitioned, which prevents a bug in one aircraft system from compromising another one-for example, this would prevent a bug in the aircraft's in-flight entertainment system from disrupting the navigational system.

The partition scheduler partitions by address space. Each partition equals one address space. When one address space is running, all threads of the address space are available to run. By system developer selection, each address space is assigned one or more windows of execution time during a complete period. When the address space window begins, the kernel runs only the tasks within that address space. Thus, the CPU resource is guaranteed for the address space during its execution window. Any bug or virus that occurs in one application is contained by its partition, again making it easy to identify a problem and guaranteeing that the other partitions are not starved of their CPU time.

Most operating systems dole out memory from a central store. When a task creates new tasks, it asks for memory. In this approach any application can create message queues, tasks, semaphores or make other memory requests. All of these requests for memory must be filled from the central store, which typically equals the available RAM after booting the system. If a bug or virus begins proliferating and starts asking for more and more memory, these demands soon exhaust the central store and the entire system crashes.

If the task or tasks in a particular address space are badly written and exce ed the quota established by the system designer, then they cannot execute. Further, if a bug or virus begins to proliferate in a particular address space, the memory quota prevents the bug or virus from infecting other address spaces.

This space domain protection can also be applied to dynamic product designs. The system designer leaves sufficient memory for additional upgrades or applications, when the new application or upgrade receives its quota of memory.

The number of address spaces is limited only by either the processor capacity or the available memory. An advanced RTOS can handle an unlimited number of address spaces, applications or tasks.

In an unpartitioned system, there's no limitation or control on what application can access the various system devices. With a partitioned RTOS, only the system designer can define those address spaces that have access to a device such as a file system. If the end user of a handheld device downloads data, an application or an upgrade that c ontains a bug or virus, the system designer can ensure that the application does not gain access to the file system and its important data and that only trusted apps are granted access.

An upcoming release of the Integrity RTOS will enable designers to set up the initial state of their address spaces, tasks, semaphores, etc., in a graphical environment using a GUI and drag-and-drop icons.