_______________
Lynx Software Technologies has built and supported real-time operating systems (RTOSes) since 1988. We have witnessed hardware and embedded software technologies evolve and have supported our customers through the design, development, integration, certification, deployment, and support of software systems across mission-critical applications in AVIONICS, INDUSTRIAL, AUTOMOTIVE, UNMANNED SYSTEMS, DEFENSE, SECURE LAPTOPS, CRITICAL INFRASTRUCTURE, and other markets.
In POSIX, an executing instance of a program is called a process. To be conformant with the POSIX standard, processes must be kept separate through the use of memory protection. An operating system (OS) that supports multiple processes is referred to as a “multiprocessing” OS.
It is important to understand that not all OSes that claim to support some of the POSIX APIs actually support the POSIX process model and its separation of processes into their own memory address spaces. Many OSes run proprietary APIs with a wrapper layer over them so that they can claim support for a subset of POSIX APIs. However, if your OS doesn’t have proper address space separation for processes, a bad pointer or invalid memory access can corrupt data in the applications. For instance, an invalid pointer access can corrupt an entirely different application, corrupt the kernel, crash the system, and can lead to bugs that are extremely difficult to understand and fix.
If you are looking at an operating system for FACE™ support, you must be aware that only the Operating System Segment (OSS) Safety-Extended Profile and General Purpose Profile require supporting the fork() system call. FACE™ OSes that only support the Safety-Base Profile and lesser profiles are not required to support the fork() system call. If you are considering a FACE™ OS that does not support both the fork() system call and the POSIX process model with its separated address spaces, you could be setting yourself up for future debugging headaches.>
POSIX assumes that each process in a system resides in a different address space. In order to do this, LynxOS-178 uses the Memory Management Unit (MMU) of the processor to physically isolate the processes from each other so that they cannot access each other’s memory; this makes systems more robust by preventing one process from reaching over and accidentally (or illicitly) accessing the address space of another process.
Each process is assigned its own private memory in RAM. This memory may be located anywhere in physical RAM. The addresses used within a process are virtual addresses which are translated at run-time to their physical memory locations by the MMU. These virtual addresses compose the process’ virtual address space.
A process’ virtual-to-physical address space translations are private to that process. The memory addresses owned by the process can only be read or written by that process and cannot be accessed by other processes. This prevents processes from corrupting — or snooping on — each other’s memory.
Figure 1
As shown in Figure 1 (above), a process’ virtual address space is composed of segments:
If a thread in a process attempts to address a physical page that is not mapped to it by the MMU, an exception is generated. The exception sends a signal to the offending thread, which has a default action of terminating the process. Alternatively, the thread may catch the signal for user-defined actions, if desired. We will discuss POSIX threads and signals in greater detail in pending articles.