RTOS, virtualization for real-time systems, DO-178B and hypervisor for the most demanding embedded operating system applications...

Processes, Name Spaces and Virtual Memory Processes and the POSIX.1 standard

PARENT-CHILD PROCESSES

To be conformant with the POSIX®.1 standard, processes must be kept separate, and this is achieved through the use of memory protection and name spaces.

POSIX assumes that each process in a system resides in a different name space and has its own symbols tables. The Memory Management Unit (MMU) is used to physically isolate processes from each another so that they cannot trample on each other's memory.

Also commonly referred to as "multiprocessing," a process as defined by POSIX.1 will have its own name space. Two symbols defined globally will not conflict if they are located in two different processes, since they are in two different links.

Three processes mapped by the MMU into separate physical memory pages. Each process is virtually isolated from other processes and it is therefore impossible for one process to write over another process' address space (unless the programmer intentionally performs address mappings).
This diagram shows three processes mapped by the MMU into separate physical memory pages.  Each process is virtually isolated from other processes and it is therefore impossible (unless programmer intentionally perrtforms address mappings) for one process to write over another process' address space.
  • An executing instance of a program is called a process.
  • A process is created when a parent process invokes the system call fork().
  • A process may choose to execute a new program with the system call execve(). The program is read from its file and loaded into memory.
  • A process owns one or more threads, which execute the program code. The first thread is created by execve(), and begins executing in the function called main().
  • The program may be coded with calls to pthread_create(), which create additional threads. Each thread is a flow of control within the process.

Processes and virtual memory

  • Each process is assigned its own private memory in RAM. These memory locations may be anywhere in RAM.
  • The addresses used within programs are virtual addresses, which are translated at run time to indicate the real memory locations.
  • The translations are private to a process, so that only the process that owns the memory locations can access them. This insures that each process can only see and change its own memory, and cannot damage the memory owned by another process.

The set of virtual addresses that a process can access are called the process's virtual address space. A process virtual address space is composed of segments:

  • The text segment contains the program instructions.
  • The data segment contains global data and dynamically allocated data.
  • The stack segment contains the stacks owned by each thread.
  • Additional segments that are defined later.

The MMU translates the virtual addresses into physical addresses. If a process attempts to address a page that is not currently mapped to it, the MMU generates an exception. The exception sends a signal to the offending thread in which the default action is to terminate the process. Alteratively, the thread may catch the signal for user-defined actions, if desired.

For further information on MMUs, please read our technical white paper, "Using the Microprocessor MMU for Software Protection in Real-Time Systems." For information about partition operating systems, visit our white paper, "Partitioning Operating Systems Versus Process-based Operating Systems."

PARENT-CHILD PROCESSES

A LynuxWorks embedded OS is featured in this embedded system application:
Who else uses a LynuxWorks embedded operating system?
Security white papers
Keeping Embedded Software safe and Secure in an Unsafe World
A new, secure methodology is needed to separate systems of different security levels which run on shared resources—without compromising the performance of legacy systems. (EE Times Design, June 2010)
DO-178B Provides Certification Safety net
Developers of commercial avionics software must demonstrate compliance with DO-178 guidelines. The FAA has issued additional guidance for so-called DO-178B Reusable Software Components (RSCs as defined in AC20-148), which allow for reuse of certifications. (COTS Journal, November 2009)
Designing Safety-critical Avionics Software Using open Standards
Safety-critical avionics systems have continually grown more complex and software-intensive. Regulatory authorities and avionics manufacturers have responded with guidance such as DO-178B and RSC to ensure that software performs safely, with controlled development cost. (Boards and Solutions, September 2009)
Two Different Realms: RTOS Support for Safety-critical vs. Security-critical Systems
Safety- and security-critical system functions are evolving simultaneously, with different yet similar requirements. Modern RTOSes are stepping up to meet these needs. (VME and Critical Systems, June 2009)
Virtualization Makes Better use of Open-source OSes and apps
With the introduction of the embedded hypervisor, embedded systems can avoid certain performance or licensing issues inherent to open-source OSes and applications. (EE Times, March 23, 2009)
Secure Virtualization Technology can Extend the life of Legacy Systems
By combining the concept of virtualization and security, one can consolidate multiple legacy systems running on heterogeneous operating systems onto a single host system with high-assurance security. (Military Embedded Systems, January/February 2009)
Separation Kernel for a Secure Real-time Operating System
The technical foundation adopted for the so-called MILS architecture is a separation kernel like LynxSecure, which permits multiple functions to be realised on a common set of physical resources without unwanted mutual interference. (Boards and Solutions Magazine, February 2008)
Advances in Virtualization aid Information Assurance
Advances in the newest Intel® processors are making virtualization much easier to implement in security applications than ever before. (Embedded Computing Design, January 2008)
Protecting our most Vital Systems
Some significant defence programmes are already committed to a new approach to high-threat, high-asset-value systems. Rance DeLong explains MILS. (Components in Electronics, April 2007)
Perspectives: Security and the Separation Kernel
Today's avionics systems are designed to support more than one application, using a partitioned operating system and memory management units to ensure applications have adequate separation. (Avionics Magazine, April 2007)
MILS: An Architecture for Security, Safety, and Real Time
The unrelenting growth and integration of embedded controls, information processing, and communications has created a need for systems that provide robust protection for resources and services in the face of serious threats. (Embedded Technology Magazine, November 2006)
Partitioning Operating Systems Versus Process-based Operating Systems
Partitioning operating systems are the latest buzz, while processes, by contrast, have been around for over 30 years. Both provide memory protection, however, the intent behind them is very different.
DO-178B and the Common Criteria: Future Security Levels
Although there are similarities between the airborne safety-critical requirements in RTCA/DO-178B and the Common Criteria, ISO 14508, compliance with the higher levels of security in the Common Criteria demands meeting additional security requirements. (COTS Journal, April 2006)
Reusing Safety-Critical Software Components
Safety-critical systems often operate together as a single "system-of-systems," making it important that they meet the most stringent and rigorous requirements for safety-criticality. The failure of one module in a system could create other failures or vulnerabilities, or worse yet, failure of the system as a whole. (COTS Journal, August 2005)
Using the Microprocessor MMU for Software Protection in Real-Time Systems
With minimal impact to overall system performance, user tasks and the kernel can be protected from accidental corruption by using multiple protected address spaces.
Improving code Migration and Reuse
The unrelenting growth and integration of embedded controls, information processing, and communications has created a need for systems that provide robust protection for resources and services in the face of serious threats. (Embedded Computing Design, August 2006)
LynuxWorks: A case Study in Combat-ready Linux
As open source, especially Linux, makes its way into nearly every sector of the economy, one of the final frontiers is the military and aerospace market, where new applications must clear hurdles such as the FAA's rigorous DO-178B certification for aviation software. (Newsforge, December 2005)
FCS Program Rolls Forward in Formation
A wireless data network, with advanced communications and technologies, links soldiers with 18 new, lightweight manned and unmanned ground vehicles, unmanned aircraft, sensors and weapons—and it's all in one program. (COTS Journal, June 2005)
Embedded Tools Train an eye on Security
As embedded designers incorporate more security and safety needs into devices, embedded tools will have to evolve to provide capabilities needed both for product development and process management. (EE Times, September 2004)
Secure Operating Systems for Deeply Embedded Devices
As we add more intelligence to our embedded devices, we find that they are becoming increasingly integrated into our information technology infrastructure. Though system security is not a new concept, security-in-depth is a new paradigm developers are now starting to address. (RTC Magazine, September 2004)
LynxSecure Separation Kernel and Embedded Hypervisor LynxOS-SE Embedded RTOS RTOS: LynxOS-178 for software certification Luminosity Eclipse-based IDE
LynxOS Embedded RTOS Embedded Linux: BlueCat SpyKer Embedded-System Trace Tool

Industry Solutions

Migration

Industry Standards

Embedded Systems Technology

RTOS Training for Embedded Systems

Training at LynuxWorks

Embedded System Consulting

LynuxWorks Support

Embedded Systems

LynxOS RTOS Support

BlueCat Embedded Linux Support

Contact Us

About LynuxWorks

Press Room

Newsletter and Announcements

Careers

Site Map

Board Support Packages (BSPs)

BSP Device Drivers

BSP Targets by Operating System

BSP Targets by Form Factor

Third-party I/O Devices and Hardware

SynergyWorks: LynuxWorks partners


What is SynergyWorks?

Third-party add-ons for LynuxWorks operating systems

Copyright © LynuxWorks™, Inc. All rights reserved. Reproduction in whole or in part in any form or medium without express written permission of LynuxWorks is prohibited.