Global Sources
EE Times-Asia
Stay in touch with EE Times Asia
EE Times-Asia > Memory/Storage

Security inadequate in RTOSs

Posted: 16 Dec 2002 ?? ?Print Version ?Bookmark and Share

Keywords:rtos? real-time operating system? security system attack? memory protection? memory management?

Last fall, investigations by the FBI and other agencies revealed that the Al Qaeda terrorist group had circumvented security measures on numerous systems in the United States so it could monitor and collect data from high-tech companies, utilities, and government offices.

With growing evidence that cyber terrorists may be planning attacks on computer-controlled civilian targets, the distinction between military and government systems, and private and commercial systems has become meaningless where security is concerned. It is clear that commercial entities must make their systems just as secure against internal attacks as military and government entities do, and the primary defense is the mechanisms residing in RTOSs.

Fortunately, security standards for military and government applications have included protection against internal attacks for a long time, with methodologies that have been perfected over the years for embedded systems such as those used in the F-35 Joint Strike Fighter and the S-92 Sikorsky helicopter. They include DO-178B, common criteria evaluation-assurance levels (EAL) 1-7, ARINC-653 and multiple independent levels of security (MILS).

DO-178B provides guidelines for the production of airborne-systems equipment software that is safe and airworthy. It describes techniques and methods to ensure the reliability of such software and is used to secure Federal Aviation Administration (FAA) approval of digital computer software. The Common Criteria for Information Technology Security Evaluation defines seven EALs for system security, with Level 7 being the highest, providing maximum security. These standards set up the criteria that a developer must meet in order to have an application certified but they do not tell you how to go about designing your application to meet the standard. That is entirely up to the developer.

All system threats - whether a bug, a virus, or a hacker - can result in one of two malfunctions within the system: unauthorized access to a protected portion of memory, or denial-of-service affecting either the CPU or memory.

The very fact that a virus or a hacker has invaded a system means that damage has already been done, since their presence is usually discovered only because a malfunction has been detected. Thus, protection from internal attacks is based on the principle of "containment," meaning that destructive activity is confined to a single compartment or segment of the system and not allowed to cross over into other compartments, thus, limiting the amount of damage it can do. Containment is accomplished through two main strategies: memory protection and guaranteed resource availability.

Memory protection is the process through which the data and instructions of one program are protected from being changed by the unauthorized actions of another program. Memory management, usually implemented through a hardware memory management unit (MMU), is a key element in memory protection. Through the process of partitioning, it ensures that portions of memory are reserved for the use of particular programs, and that no other program uses those segments of memory.

However, memory protection does not defend the system against denial-of-service attacks, one of the more common virus strategies. The denial-of-service that everyone is familiar with is the attack from outside - such as the ones that occurred in February 2000 when Yahoo, CNN and eBay were brought down by denial-of-service attacks that reputedly caused more than $1 billion in losses.

But there is a form of denial-of-service that is more insidious. It is an internal attack that occurs when an activity in one portion of a system drains the resources of the system, either by consuming all of the CPU's processing power by sending a never-ending series of requests for service to the CPU, or by sending endless messages that must be allocated memory from the system memory pool. To protect against denial-of-service, guaranteed availability of resources is needed in the time domain, which refers to CPU cycles, and the space domain, which refers to memory.

Guaranteed resource availability prevents both of these kinds of attacks by putting limits on how much of the memory and the CPU's resources any particular task can ask the system to use on its behalf.

We use an approach called "hard currency." In the space domain, hard currency means that a certain "budget" of memory is allocated to each address space and a portion of that memory, rather than memory from the system pool, must be made available to the RTOS when services are requested. If a bug or virus begins to proliferate in a particular address space, the address space's memory budget will be exhausted, and no further RTOS services can be requested.

- John A. Carbone

VP Marketing

Green Hills Software Inc.

Article Comments - Security inadequate in RTOSs
*? You can enter [0] more charecters.
*Verify code:


Visit Asia Webinars to learn about the latest in technology and get practical design tips.

Back to Top