Global Sources
EE Times-Asia
Stay in touch with EE Times Asia
?
EE Times-Asia > Embedded
?
?
Embedded??

Benefits of high assurance software engineering

Posted: 11 Jul 2013 ?? ?Print Version ?Bookmark and Share

Keywords:embedded systems? high-assurance web server? HAWS? safety-critical? CPU?

Because they are easy to create and the way most embedded programmers learn to employ concurrency, threads often get overused. Furthermore, embedded systems developers often have the mistaken impression that a proliferation of processes will exhaust too many system resources relative to threads.

While threads are certainly lighter weight than a full-blown process, the distinction has become increasingly less important in modern embedded systems. Another reason for thread overuse can be attributed to the fact that the original real-time operating systems created in the 1980s and early 1990s did not support memory-protected processes at all. Developers became accustomed to threads, and their legacy lives on.

Contrary to popular belief, designers should strive for a one-to-one ratio between threads and processes. In other words, each memory-protected component should contain a minimum number of threads. The key reason is that multi-threaded processes are often the cause of subtle synchronisation problems that result in memory corruption, deadlock, and other faults.

The use of virtual memory processes forces developers to create well-defined inter-process communication interfaces between components. Each component can be independent unit tested by exercising these interfaces. This thread-less component philosophy avoids some of the nastiest vulnerabilities that plague embedded software.

Least privilege
Components must be given access to only those resources (e.g., communication pathways, I/O devices, system services, information) that are absolutely required. Access control must be mandatory for critical system resources and information. Insecure systems typically allow any program ('programme' for plan) to access the file system, launch other programs, and manipulate system devices.

For example, browser buffer overflow vulnerabilities may enable an attacker to access any file because the web browser has the privilege to access the entire file system. There is no reason why a web browser should have unfettered access to the entire file system.

The web browser either should have write access only to a dedicated, browser-specific directory (out of which the user can carefully decide what can leave the sandbox), or all browser write requests can require user approval via a dialogue box. Read access can be limited to a white list of files known to be required for browser operation. The web browser's runtime stack should not be executable.

Every component of the entire system should be designed with least privilege in mind, and it is always best to start with no privilege and work up to what is needed rather than start with the kitchen sink and whittle away privileges.

For another example, let's consider the common operating system function of launching a new process. One original UNIX method, fork(), creates a duplicate of the parent process, giving the child all the same privileges (e.g., access to file descriptors, memory) as the parent.

The developer then must close descriptors and otherwise try to limit the child's capabilities. This requires an unrealistic prescient knowledge of all system resources accessible to a process. Thus, errors in the use of this interface have often led to serious vulnerabilities.

In a secure operating system, the default process creation mechanism establishes a child without access to any of the parent's capabilities for memory, devices, or other resources.

The creator can systematically provide capabilities to the child, building up a strictly limited privilege process. The child must also obtain its physical memory resources from its parent, ensuring that a process cannot drain the system or otherwise affect other critical processes with a fork bomb.

About the author
David Kleidermacher, Chief Technology Officer of Green Hills Software, joined the company in 1991 and is responsible for technology strategy, platform planning, and solutions design. He is an authority in systems software and security, including secure operating systems, virtualisation technology, and the application of high robustness security engineering principles to solve computing infrastructure problems. Mr. Kleidermacher earned his bachelor of science in computer science from Cornell University.

This article is excerpted from Embedded Systems Security, by David and Mike Kleidermacher, used with permission from Newnes, a division of Elsevier. Copyright 2012. All rights reserved.

To download the PDF version of this article, click here.


?First Page?Previous Page 1???2???3



Article Comments - Benefits of high assurance software ...
Comments:??
*? You can enter [0] more charecters.
*Verify code:
?
?
Webinars

Seminars

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

?
?
Back to Top