The Technology Behind LynxOS v4.0's Linux ABI Compatibility
This article was originally published by LinuxDevices.com, June 4, 2002, at http://www.linuxdevices.com/articles/AT8943314364.html. With the kind permission of LinuxDevices.com, it is being reproduced here.
LynxOS® v4.0, the newest release of the POSIX®-conformant hard real-time operating system (RTOS), has support for Linux® ABI compatibility—where Linux application binaries can run unchanged in the LynxOS environment without necessitating source code recompilation. This white paper examines the issues surrounding ABI compatibility in general and describes the architecture of the Linux ABI compatibility layer on LynxOS v4.0.
What is ABI?
Application Binary Interface or ABI refers to the run-time interfaces between an application program and the OS environment where it is executing. The components of the OS environment that form the ABI for a particular OS are:
- Object file format
- Application Programming Interface (API) calls
- Dynamically linked libraries
- Run-time linking and loading
The OS environment usually provides a single
object file format by default for all applications within this environment. The various object file formats
that are used within the OS environment are A.OUT,
COFF, XCOFF and ELF. The OS
environment also consists of a set of well-defined
API calls
defined within the OS or in a set of dynamically linked libraries.
Application programs typically invoke these
API calls
to access OS services through the dynamically linked libraries.
The run-time linking and loading support in the OS facilitates
program execution by resolving all unresolved
API calls
in the application to the dynamically linked libraries at run-time.
The LynxOS ABI environment is shown in Figure 1.
Compatibility and its usefulness
ABI compatibility refers to the extent of run-time support provided by two different OS environments to support execution of application programs. The extent of ABI compatibility that exists between two OS environments dictates whether application programs that are created under one environment will run unchanged in the other environment. ABI compatibility if supported between two OS environments obviates the need to re-compile and re-link application programs built in one environment, in order to run in a different environment.
This has several benefits since it helps to surmount difficult legacy issues like unavailability of source code, unavailability of the technical expertise familiar with the application and unavailability of current resources.
ABI compatibility can extend to application programs executing in the following environments:
- Multiple releases of an operating system on a particular hardware platform—The issues associated with ABI compatibility in this environment usually involve the dynamic system libraries and the exported API calls that are used by application programs. Since the file format between two releases of an OS changes infrequently, the extent of ABI compatibility is directly related to the changes in API calls between the two OS releases. As long as the API calls do not change in the OS or libraries, applications built for an earlier release can run unchanged in the new release.
- Two completely different operating systems—ABI compatibility between two different operating systems is more complex. Ideally the two different operating systems ideally need to have the same object file format to ensure ABI compatibility. This gets to be harder between two disparate operating systems like Windows® and UNIX®. Secondly the two operating systems need to have a compatible set of API calls. The greater the level of API compatibility between the two OS environments, the easier it is to achieve ABI compatibility between them.
- Different hardware platforms—ABI compatibility between two different hardware platforms creates several additional problems that make it extremely complex. Besides the common object file format and API compatibility issues, the underlying processor architecture needs to be emulated through a virtual machine
LynxOS-Linux ABI layer: the technology
The LynxOS-Linux ABI compatibility layer provides Linux ABI compatibility on LynxOS and provides an execution environment for Linux application programs to run unchanged in a true hard real-time environment.
The Linux ABI compatibility support in LynxOS v4.0 creates an OS execution environment for Linux applications that is similar to the one provided by the Linux operating system. The key components that are provided for Linux ABI compatibility in LynxOS are described in the next sections.
Compatible object file format
LynxOS v4.0 uses the ELF (Executable and Linking Format) as its default object file format. This ensures file format compatibility with Linux, which also uses the ELF file format as its default and provides the basic platform for ABI compatibility.
Dynamic linking
All well-behaved Linux applications are linked dynamically by default. (The Linux Standards Base / LSB specification defines a Linux application as LSB-conforming only if it is dynamically linked.) The Linux OS environment by default builds an application with dynamically linked library dependencies that are subsequently resolved by the run-time linker and loader during program execution. The resolution of these shared library dependencies in Linux is done by the run-time linker and loader (ld-linux.so), which loads all the required dynamic libraries used by the application into memory, and resolves all unresolved references with these libraries. The dynamic linking support in LynxOS v4.0 follows the widely used UNIX System V (SVR4) ABI for dynamic linking of applications. Dynamically linked applications identify the run-time linker and loader (ld.so) in the application's file format at build-time. During program execution, ld.so loads all needed shared libraries into memory and resolves run-time dependencies.
The similarity of the dynamic linking support between Linux and LynxOS forms another key component of Linux ABI compatibility on LynxOS.
API compatibility
One of the most significant components needed to ensure Linux ABI compatibility on LynxOS is the availbility of a common API . Most Linux applications use a significant set of API calls that are provided by the Linux kernel. (Linux kernel v2.4.x provides over 200 system call APIs.) The ability of the LynxOS execution environment to duplicate the behavior of each of these system calls invoked by a Linux application is essential to ensuring its successful execution.
LynxOS being a UNIX/POSIX conforming RTOS has over 150 system calls that are similar with the Linux system call API . However to ensure that these system calls' behavior is identical to Linux, changes were made in the following areas:
- Some system calls that were not present in the LynxOS
API were
added to provide a higher level of compatibility with Linux (e.g.:
fchdir,setresuid,setresgid,wait4). - Signal numbers in LynxOS were changed to ensure a match with the Linux signal numbering scheme.
- The constants used for IOCTL calls in LynxOS were changed to match Linux.
- The error numbers that are returned by system calls (
errno) in LynxOS were changed to match Linux.
The resultant LynxOS system call API has an extremely high level of compatibility with the Linux system call API with very minimal overhead for the LynxOS kernel. This convergence between the two operating system APIs is the critical component to ensuring ABI compatibility between the two.
Dynamically linked libraries
Dynamically linked libraries in Linux provide additional sets of API functions that applications can dynamically link to, and the system call binding between Linux applications and the Linux kernel. The availability of Linux dynamic libraries in the LynxOS execution environment is essential for Linux ABI compatibility support on LynxOS v4.0.
LynxOS v4.0 uses a modified version of the Linux GLIBC dynamic library to resolve application calls at run-time. This modified GLIBC library provides the translation between Linux and LynxOS system calls. Application calls to GLIBC functions that are independent of system calls remain unchanged and are unaffected by the underlying LynxOS execution environment. However, application calls to Linux system calls are intercepted at the system call binding code in the modified GLIBC. Glue code was added in GLIBC to either call the LynxOS system call directly or make any modifications before the LynxOS system call invocation to ensure that the Linux system call behavior is achieved. Using this mechanism, a broad spectrum of Linux system calls is supported including Pthread interfaces, Asynchronous IO, Networking and other POSIX interfaces.
Further, any Linux dynamic library that does not have any system dependencies can be copied from Linux and used unchanged on LynxOS. The LynxOS run-time linker and loader recognizes the dynamic library dependency through the application ELF headers and proceeds to resolve application calls to these libraries (e.g.: libz.so.1, libjpeg.so.62 etc).
However, if an application uses a system call that is unsupported, it fails immediately and consistently since the corresponding system call binding does not exist in GLIBC.
Overall architecture and limitations
Thus the overall architecture of the LynxOS-Linux application compatibility layer, as shown in Figure 2, combines the described set of components to provide an OS execution environment capable of executing an extensive set of Linux applications.
Since the ABI compatibility support is tied to the system API compatibility and dynamic library support, LynxOS-Linux ABI compatibility is currently dependent on a Linux kernel and GLIBC pair. LynxOS v4.0 supports applications based on Linux kernel v2.4.x and GLIBC v2.2.2/v2.2.4.
The current implementation does not provide support for statically linked Linux applications, application that make direct system calls and applications that use a feature that is not supported in LynxOS (e.g.: /proc file system). However this is a subset of the total available Linux applications.
Compatibility testing
The compatibility testing of the Linux ABI compatibility layer was done using a combination of automated and manual testing.
The automated testing of the LynxOS ABI compatibility layer uses the BlueCat Linux automated test suite (ATS) that contains over 5000 tests of POSIX 1a, 1b and other Linux system call interfaces. These automated test suites were built in a Linux kernel v2.4.x/GLIBC v2.2.2 environment and run on the BlueCat Linux product for baseline qualification. These same test binaries were then executed unchanged on the LynxOS v4.0 execution environment and test results were compared to ensure no difference in results.
The manual testing involved testing advanced Linux applications with several system and application-supplied dynamic libraries. Several advanced applications were successfully tested like the Opera browser, ACE-ORB, Gnome and KDE.
Performance
The performance considerations of the Linux ABI compatibility layer focus on two main areas:
- Performance impact for LynxOS native applications
- Performance of Linux applications on LynxOS
The architecture of the Linux ABI compatibility layer on LynxOS is largely independent from the LynxOS native functionality. The kernel modifications that have been introduced to achieve better API compatibility mainly affect signal numbers, errno values and IOCTL values. These do not introduce any additional overhead and hence the performance of LynxOS native applications are completely unaffected by the ABI compatibility layer.
The performance of Linux applications on LynxOS is mainly dependent on the additional glue code that is introduced in the GLIBC library. However the glue code in most cases is very minimal, merely translating system call parameters and bit fields before invoking LynxOS system calls and translating it back to the application after the system call returns. This introduces very minimal overhead and the overall performance impact on the application is negligible.
Benefits
The Linux ABI compatibility layer on LynxOS v4.0 provides several benefits to customers:
- This capability provides support for Linux applications to run in a true hard real-time environment along with LynxOS native applications.
- The ability to execute a Linux application binary without recompilation surmounts the issue of unavailability of application source code. Proprietary applications can run without the need for any additional porting effort.
- In several instances, the technical resources that originally wrote the application may not be available to the company or allocated to different projects. In this case, the capability of avoiding source code recompilation could save the organization significant costs.
Conclusion
About
the author:
Arun Subbarao is Vice President of Engineering at LynuxWorks and is responsible for the LynxOS product development. Arun has more than 10 years experience in the OS and embedded industry working on UNIX, Linux, and RTOS development. His interests include operating systems, networking, and high availability.
The Linux ABI compatibility layer on LynxOS v4.0 creates a unique execution environment where Linux applications can run unchanged in a true hard real-time environment. It provides the ability to leverage innumerable open source as well as proprietary applications to better meet time-to-market needs in the creation of products in the embedded marketplace.
- 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)
Virtualization / RTOS News
- Using a Separation Kernel to add Military-Grade Security to Legacy Systems -8/10
- LynuxWorks VP of Marketing Speaks with TMC CEO Rich Tehrani -8/10
- LynuxWorks Addresses Safety Requirements for NextGen UAVs at AUVSI 2010 -8/3
- ARM Processor Support for LynxOS-SE RTOS Builds Secure Mobile Applications -7/13
- Keeping Embedded Software safe and Secure in an Unsafe World -6/10
- Embedded Systems Conference, Boston, MA, USA, Sep 21-22
- Introduction to BlueCat Embedded Linux, Oct 11-13
- Embedded Conference Scandinavia 2010, Stockholm, Sweden, Oct 19-20
