Meeting Security Requirements in Software Defined Radios

By using secure partitioning, an operating system can take advantage of a processor’s MMU to act like multiple processors—alleviating the need for redundant hardware and excessive power consumption and cost in portable software defined radios.

By Brian Doherty, Green Hills Software

With traditional, non-reprogrammable radios, providing data security classifications—say, between red and black communications —requires segregation through discrete comms sub-systems. Typically, these radios are closed systems that offer protection to the waveforms and cryptographic algorithms they contain. Devices operating at different security levels are often physically separated from each other and use different processor systems to achieve security partitions.

Using multiple processors is expensive in terms of cost, physical space and weight, heat dissipation and power consumption. Using separate hardware for each security level also introduces inflexibility (Figure 1). The security architecture is fixed at manufacturing time, as determined by the configuration of processors and buses in the system. Such inflexibility partially defeats the goal of deploying a radio that is adaptable to current and future needs.

On the other hand, software radios are open, reprogrammable systems designed to support multiple waveforms and cryptography schemes—possibly concurrently. The challenge here is that the software radio infrastructure must still ensure that users and applications cannot access nor interfere with the flow of information at a higher security classification.

In some software defined radios (SDRs), a typical approach to security is to segregate secure data by delegating each security level to a dedicated processor with its own data bus and memory. With this architecture, software radios internally resemble a microcosm of traditional, fixed radios. The radio is reprogrammable, but still uses redundant hardware sub-systems.

However, a significantly better approach in SDRs is to use a single processor with the security architecture implemented in software. This saves space, weight, power and cost.

Secure Partitioning and Multiple Independent Levels of Security (MILS)

To support Multiple Independent Levels of Security (MILS) on a single processor, the hardware and software must work together to provide the same, absolute protection provided by a multiprocessor, multi-bus solution.

This can be accomplished by using an operating system and processor capable of secure partitioning. A secure partition is effectively a virtual computer that shares a processor but has its own tasks, dedicated resources and view of memory. Multiple secure partitions can exist concurrently on a single processor if they are completely isolated from each other by the operating system by utilizing hardware protection capabilities provided by the processor. Software and hardware protections are applied to ensure that a task can never have visibility—of any type—into data or processing occurring in a higher security partition.

With secure partitioning, MILS can be supported without the need for dedicated hardware for each security level. This approach maximizes flexibility while minimizing the use of hardware and its incumbent costs. It also allows standard, off-the-shelf hardware to be used for software radio design in lieu of proprietary hardware with dedicated processors and buses for each distinct security level to be supported.

In order to use a single processor solution, the operating system and hardware must guarantee the same degree of data protection and isolation as in a system in which discrete hardware and physical separation are used (Figure 2). In particular, to support MILS, the system must:

• Ensure that data in one partition can never be accessed, compromised or otherwise deduced or detected by a task in a less secure one.
• Ensure that an error or deliberately malicious behavior in one partition cannot compromise processing in other partitions or the system as a whole.
• Guarantee that each partition has the resources it needs to execute successfully. This encompasses processor bandwidth, physical resources such as memory and kernel objects such as semaphores. For example, there must be protection from denial-of-service attacks: a task in one partition cannot be allowed to consume so much processor bandwidth or other resource that a necessary service would be denied to a higher priority partition.

Memory Protection

The basis for ensuring data isolation in different partitions is by using hardware- enforced memory protection within the underlying processor.

To support MILS, the processor must contain a Memory Management Unit (MMU). An MMU allows the operating system to control and regulate access to all memory.When an MMU is used, software applications do not have direct access to physical memory. Instead, application software operates in a virtual address space. The MMU translates the virtual addresses that are visible to an application into physical addresses that correlate to real memory and device registers.

An MMU translates virtual addresses to physical ones using a lookup table (Figure 3). The granularity of the table is one page of memory; hence, the lookup table is called a page table. (The size of a memory page is processor-dependent— four or eight kilobytes are common.)

By configuring the MMU page table associated with a partition, the operating system can control the physical memory that the partition is able to access. If a given physical page of memory is not present in a partition’s memory map, then a task in that partition cannot access it. Thus, by leveraging the MMU, the operating system can prevent a task in one partition from accessing data in another.

To ensure the integrity of memory protection, the processor must prevent application code from surreptitiously reconfiguring the MMU in order to circumvent the protections put in place by the operating system. Consequently, processors with MMUs support at least two privilege levels: supervisor and user. The MMU can only be configured by software running at the supervisory level, which is generally limited to the operating system itself (or, more likely, just a subset of the operating system, for additional protection). The operating system switches to user mode when scheduling an application task, thus preventing application tasks from being able to manipulate the MMU.

One additional level of protection is still needed. It must be impossible for an application task to switch into supervisory mode. To guarantee this, the processor always notifies the operating system when an application task attempts to change modes. Unless the task was in a partition operating at the highest possible security level, the operating system must deny the request.

Fault Isolation

A securely partitioned operating system must ensure that a fault caused by a task in one partition—whether accidental or deliberate—cannot affect another partition. For example, if a task attempts to access memory not allocated to it, a corruption cannot occur to memory allocated to a different partition. Or, if a task makes a system call to the operating system with an illegal parameter, that cannot result in a corruption to the kernel that will bring down the whole system.

In software defined radios using a COTS processor, the requirement to provide memory protection in a MILS-capable operating system goes a long way toward isolating faults. The MMU will catch any attempt by a task to access memory not allocated to its partition. The MMU will notify the operating system of the attempt by calling a fault handler. The operating system can then take remedial action without having any impact on any other partition.

Other processing faults, such as attempts to divide by zero or execute an illegal instruction, also result in the processor delivering a fault notification to the operating system. As with memory access violations, the operating system can handle the error in a manner that is completely transparent to any partition other than the one in which the fault occurred.

Since the SDR is using a single CPU instead of several, the other type of fault that must be protected against is an erroneous parameter being passed to the operating system as part of a system call. For example, a task in an unclassified partition could pass an invalid pointer as an argument to an I/O read() call.

If this went unchecked, it could cause corruption within another, more important partition or to the operating system itself, since the operating system runs in the processor’s supervisory mode so it does not have the same level of memory protection as an application task. A MILS-capable operating system must protect against this type of error by completely validating all parameters passed as arguments to system calls. This ensures that errors occurring within one partition will not compromise a software defined radio as a whole.

Guaranteed Resource Availability

In order to support MILS, the operating system must ensure that each partition has sufficient resources to execute successfully. These resources include

• Processor bandwidth,
• Memory, and
• Operating system objects.

The operating system must also insulate partitions from errors or malicious behavior originating in other partitions. For example, it cannot allow a task in one partition to carry out a denial-ofservice attack against another by consuming all of a resource that a higher security partition may need.

To ensure that each partition has sufficient processor bandwidth, a secure partitioning operating system used for software defined radios must utilize a different task-scheduling algorithm than traditional operating systems.

Real-time operating systems typically use a fixed priority scheduler. The processor is granted to the highest priority executable task (that is not blocked waiting for an event or resource to become available). If multiple tasks of the highest priority are executable, then a real-time operating system uses a round robin scheme to grant each an equal share of available processing time.

A securely partitioned operating system cannot use a standard fixed priority scheduler.With a fixed priority scheduler, a high-priority task can consume all of the available processor time. If this were to occur in a software defined radio, it would allow a high-priority task in a partition processing unclassified data to prevent a task in a partition handling classified data from being able to run. Nor can a partitioned operating system used for software defined radios employ a straight round robin scheduler, since that would preclude supporting real-time capabilities that are essential for reliable data communication.

In order to both provide real-time performance and guarantee that each partition has its necessary allocation of processor time, a securely partitioned operating system must use a hybrid approach. One example of this is found in Green Hills Software’s INTEGRITY operating system, which uses an implementation based on the ARINC 653 specification. Each partition is assigned a specific execution interval and period. A thread in one partition cannot affect how much time is allocated to threads in another. During a partition’s time slot, a standard fixed priority scheduler is used to schedule the tasks within it. A system designer can ensure that all real-time requirements are met by assigning a time allotment and period sufficient to accommodate the frequency of real-time events and processing time required.

In addition to guaranteeing that each partition has an adequate amount of processor bandwidth, a securely partitioned operating system must also ensure that a task in one partition cannot affect the resource allocation within another partition or the operating system itself. A task in one partition cannot be allowed to exhaust a resource needed by another. For example, if a partition handling critical, classified information depended on dynamic memory allocation, a task in an unclassified partition cannot be allowed to allocate all of the available memory, thus starving the more important partition.

One way to guarantee resource availability is the approach implemented in INTEGRITY. Instead of using a global pool of memory shared between the kernel and each partition, each partition has its own dedicated memory. A task in one partition cannot use memory reserved for another. In addition, the operating system itself does not dynamically allocate any memory. In this way secure data cannot be inadvertently passed from one partition to a lower security partition through distribution of memory pages from a global pool (Figure 4).

Operating system objects that can be dynamically created, such as semaphores, clocks and I/O devices, use memory provided by the partition that created and owns the object. This prevents a task in one partition from exhausting operating system resources that may be needed by another. Each partition is accountable for its own objects.

Improving the Flexibility and Economics of Software Defined Radios

A secure partitioning operating system that allows MILS to be supported on a single processor must be implemented differently than traditional real-time operating systems. It must strictly utilize a processor’s MMU in order to isolate each partition. A task-scheduling algorithm must be employed that guarantees each partition will have adequate overall bandwidth and be able meet its real-time deadlines. And resources must be guaranteed in order to prevent tasks from inadvertently starving another partition or from carrying out deliberate denialof- service attacks.

By taking advantage of a MILS-capable operating system, the design of a software defined radio can be greatly simplified. In place of a separate dedicated processor, and data bus to each security level, each security level can be delegated to a unique partition on a single processor (Figure 5). This is a superior approach to a software defined radio implementation because it maximizes flexibility while minimizing the number of processors, buses and dedicated memory pools that must be used. Fewer hardware components also reduces cost, minimizes heat dissipation requirements, radio size and maximizes battery life.

Green Hills Software
Santa Barbara, CA.
(805) 965-6044.
[www.ghs.com].

http://www.cotsjournalonline.com/home/article.php?id=100038