Lynx announces LynxOS-178 compliance with FACE™ 3.0 specifications
San Jose, California, March 11, 2020 – Lynx Software Technologies, an innovator in modern platform...
White papers, articles, data sheets and brochures, and blog posts on a wide range of topics related to building secure, safe, and adaptable embedded software systems.
Lynx offers three primary support levels and custom engineering services to address every phase of our customer's product life cycles from initial system architecture to deployment:
Additional details can be found on our Support Page.
Our core products are real-time operating system (RTOS) and virtualization technologies. Depending on our customers' requirements, they may end up using our RTOS, our separation kernel (hypervisor), or our flagship technology, which is a complete development and integration framework, including Buildroot Linux, FreeRTOS support, and tools for building bare-metal applications.
Our competitors therefore range between proprietary RTOS companies such as Wind River Systems, Green Hills Software, DDC-I, and Sysgo to various other proprietary and/or open source virtualization and RTOS solutions.
For a list of the most common RTOS companies we see being used today for embedded and IoT projects, see our article, "What Are the Most Popular Real-Time Operating Systems 2020." To learn more about separation kernels and how they are distinct from RTOS-based hypervisors, read: "What is a Separation Kernel?"
When Lynx engages with prospective customers and analyzes the system requirements, we often identify gaps between the capabilities of off-the-shelf products and the desired system functionality. How that gap is addressed is really dependent on the preferred approach of the customer. For example, sometimes the intellectual property created in that work is something that they deem differentiated and worthy of owning. Often Lynx will deliver professional services to address the “gap”...
Evaluation versions of our products can be requested on our Get Started page.
Products are listed here:
The primary tools we provide are:
For a list of additional tools, please email us.
Yes. For a complete explanation of the cost considerations, please see our helpful article, "What is the Cost of a Board Support Package (BSP)?" or contact us directly and we would be happy to discuss your project with you. Note that because LYNX MOSA.ic allows builders to allocate CPU, Memory, and IO resources in a fine grained way (effectively providing architects with a "virtual motherboard"), the details of the system need to be fully described in software.
Linux fits into LYNX MOSA.ic in two ways. First, Buildroot embedded Linux is included with MOSA.ic as a pre-integrated guest OS. This means Buildroot Linux is easily deployed in one or multiple virtual machines in your design. Linux is useful should you require an advanced filesystem, network protocol, or to take advantage of its vast device driver library, or to run a Linux application, either your own or from the community.
Heterogenous designs are enabled where Linux is used to host complex software, such as a mySQL database or as a gateway to utilise accelerated hardware such as a GPGPU, for example, alongside another virtual machine running an RTOS to host a safety critical or real-time application. Second, Linux is helpful as a configuration, prototyping or debugging aid. It can be used temporarily during development, for example, to validate USB hardware is working before porting the driver to your RTOS environment.
Lynx uses open source and open standards in many places. Our RTOS is built with, and presents, the POSIX (Portable Operating System Interface), standard API set to applications. UNIX and Linux are built the same way and so are familiar and substantially compatible with LynxOS-178. Both our RTOS, LynxOS-178 and bare-metal target environments are built with the GCC compiler, additionally Lynx uses the GDB debugger and the Eclipse IDE.
No RISC-V based parts on market today support hardware virtualization, which is a fundamental requirement for LynxSecure. We are engaged with several semiconductor companies under NDA to understand their RISC-V based product plans. We intend to support this architecture once the necessary components with hardware virtualization support are rolled out.
In the picture below, the blue represents applications, with the largest one being Linux, the mid-sized one being an RTOS (ours or one from a 3 rd party) and smallest being a bare metal application. We have gone to 3D as we think it helps showcase the differences of our approach. The traditional architecture on the left has a large underlying operating system. The OS takes up space. It owns the hardware resources and the applications are completely reliant on its correct operation. The vertical lines represent calls from the virtual machines requesting processor resources (fork), memory resources (malloc) or IO (open, close, read, write API calls). The Lynx system on the left simply allocates hardware to the different virtual machines/applications. After that, the application has direct access to those resources it has been permitted to use. This allocation of resources cannot be modified after boot.
Both LynxSecure and LynxOS-178 rely on an external bootloader, and that is where secure boot needs to happen. Setting up secure boot is target specific. We have a how-to for x86 that describes how to digitally sign the LynxSecure binary and add keys to the BIOS to enable secure boot. On Xilinx the ATF (Arm Trusted Firmware) is used to control which parts of the SoC (CPU cores and FPGA) have access to which peripherals and memory. It also controls which SMC (system management calls), like “program FPGA”, the hypervisor and other parts of the SoC are allowed to make. Overall, a highly secure system can be built by following Xilinx specific guidance.
We have a customer building a secure gateway that has removed uboot and boots LynxSecure (with bare-metal and LynxOS-178 guests) direct from the Xilinx FSBL (first-stage bootloader).
Lynx supports Intel, Arm and Power (note that NXP since the early part of 2020 dropped the PowerPC term… we are working through our website and collateral to make these modifications) architectures. We do require hardware virtualization to be present in the component so in the case of Arm, our focus has been on the Armv8 architecture (Cortex-A5x and Cortex-A7x cores). Our primary silicon partnerships today are with Intel, NXP (both Arm and Power elements of the Layerscape families with plans for additional product areas including i.MX and S32x) and Xilinx. We are open to discussions for other silicon chips provided they include hardware virtualization support.
Given LynxSecure’s support of Arm Cortex A53 and A72 cores, the base fundamentals are in place to support a broad range of nVidia’s product portfolio. That said, support of components from nVidia is not part of Lynx’s committed roadmap at this moment in time. As Lynx starts to broaden its footprint in markets beyond aerospace, we continue to evaluate the right partnerships and components to align with our technology.
Lynx Software Technologies’ (Lynx) products and services fall under the jurisdiction of the U.S. Department of Commerce Export Administration Regulations (EAR). Lynx’s software, services, documentation, data, and other information about the Lynx Software Technologies software are “commercial items” as that term is defined in U.S. 48 CFR § 2.101. PLEASE NOTE: LYNX PRODUCTS AND SERVICES ARE NOT SUBJECT TO ITAR. Lynx’s commercial products have never been on the ITAR U.S. Munitions List (USML) (codified in U.S. 22 CFR § 121.1).
Lynx products classified under ECCN 5D002 are eligible for export under license exception “ENC.”
The Lynx Development Environment requires a Linux host. We use the RedHat package manager, a popular, open source package management utility. This is supported on Linux systems including RHEL, CentOS and Fedora.
Lynx was founded in 1988 and originally known as Lynx Real-Time Systems. The company changed its name to LynuxWorks in 2000 after acquiring, and merging with, ISDCorp (Integrated Software & Devices Corporation), an embedded systems company with a strong Linux background. In May 2014, the company changed its name to the present name, Lynx Software Technologies.
LynxSecure Simple Applications are bare-metal applications which runs directly on the CPU as native applications. With direct hardware access, LSAs can interface natively to almost all devices. A very few must be paravirtualized because certain guests do not have direct access to the underlying hardware; Lynx provides drivers for these paravirtualized LSAs.
LynxOS-178 is built to the high software design assurance standard of DO-178C, but the certification artifacts are optional, which means that all users of LynxOS-178 benefit from this high quality. If your project needs to be certified to some standard or if real-time determinism is needed, then LynxOS-178 is an excellent RTOS.
If you need certification to some standard (even if it’s not DO-178) you will need LynxOS-178. We develop LynxOS-178 using DO-178C processes. This is a rigorous standard, and customers that do not need DO-178 will still benefit from LynxOS-178’s certification package for their certification efforts.
If you need real-time determinism, then LynxOS-178 is currently the RTOS of choice on the LYNX MOSA.ic™ development framework. However, we will soon be supporting FreeRTOS as an out-of-box RTOS solution on LYNX MOSA.ic as well. You will then be able to choose between FreeRTOS and LynxOS-178 as off-the-shelf RTOS solution, according to which out-of-the-box RTOS best fits your system’s needs. We also have customers that have ported their own RTOS solutions in preference to LynxOS-178. We do not force customers to use LynxOS-178 even when they want an RTOS and need real-time determinism.
If neither certification nor real-time determinism is required for your project, then you do not need LynxOS-178. Buildroot, which is provided as part of LYNX MOSA.ic, or a 3rd party COTS OS (e.g. RedHat Linux or Windows) may be a better OS fit for your product.
FACE compliance refers to software has been modified to support the FACE application programming interfaces (APIs). FACE conformance requires that the software has been tested by third parties and verified to truly meet the standard.
LynxOS-178 is conformant to the 2.0 FACE specification. It is compliant with v3.0 and is scheduled to be conformant in Q3 2020.
First, LynxSecure runs Initial built in test (IBIT) and continuous built in test (CBIT) to validate the crucial hardware registers that control the partitioning of the system remain valid. By design it should be impossible to programmatically change these, so CBIT is intended for things like single-event upset (SEU), ie cosmic rays, but it also protects against a hw faults or weakness (like rowhammer).
Secondly, LynxSecure has an audit log. Guest VMs can be granted privilege to access the audit log and to receive an interrupt when events are stored. There are about 60 audit events, things like VM lacks permission to set the time, change the schedule, make hypercall X. The events can be filtered and actions defined should you wish to halt or reset a VM that generates event X. This detects badly behaved VMs or VMs attempting to “break out”.
Briefly, LynxSecure is a separation kernel, which is a minimal hypervisor. It is a static hypervisor that is configured on your host PC so that when it boots, it allocates target hw resources (cores, memory, peripherals) into fixed immutable virtual machines. The privileged setup code is discarded (for security) so that all that is left of LynxSecure is a set of event handlers to respond to and redirect interrupts and handle management calls like “shutdown”. The separation is achieved by hardware virtualization, which once configured, does not require active management (emulation, scheduling, etc). The goal of a separation kernel is to be minimal, elegant and efficient (LynxSecure is 15K on Arm). Initially (Rushby, 1981) this was so that formal methods could be used to prove separation for security, but more recently these properties have gained traction in the safety arena, to reduce safety certification costs and to provide multicore partitioning.
No. In contrast to other popular hypervisors built by software vendors targeting the embedded market, LynxSecure is not an OS, nor is it "built on" an RTOS. LynxSecure nether runs on top of an existing RTOS or explicitly leverages a helper RTOS. It is not a microkernel and only requires only a very minimal board support package (BSP). Additionally, LynxSecure never loads any high-level drivers (these interfaces are left to the Guest OS of your choosing), and does not run any system services (leaving it with no known attack vectors).
Yes. A separation kernel is a minimal, unique type of bare-metal (or Type-1) hypervisor. It is distinct in critical ways from Type-2 hypervisors, which require host operating systems (OS).
The concept behind a separation kernel is to place as little software between each OS and the hardware as possible. System functions are distributed and decentralized to avoid a single point of failure. Hardware resources (memory, IO, processor cores) are provisioned to each of the applications on boot and this cannot then be reconfigured, resulting in improved system security. Applications cannot interfere either maliciously or accidentally with other applications. The simplicity of LynxSecure (about twenty thousand lines of code) also simplifies the task of safety certification.
To learn more about separation kernels vs. operating systems, read: "What is a Separation Kernel?"
LynxSecure is a separation kernel. LYNX MOSA.ic is a software framework which includes LynxSecure as a foundational element. LYNX MOSA.ic also includes Buildroot Linux, bare-metal tools, and other operating systems (from Lynx, from 3rd parties and soon from open source) which customers can harness to get a head start in their development work...
Short answer: Lynx offers a NIST 800-53 package for LynxSecure, the current NIAP-supported certification and accredited process for critical systems. No new evaluations have been accepted for years (nor will they be accepted, as the SKPP is effectively dead).
Detailed answer: The Common Criteria for Information Technology Security Evaluation (ISO/IEC 15408) is an International standard for IT products. Common Criteria defines security evaluation assurance levels (EALs) ranging from EAL1 (least secure) to EAL7 (most secure) to describe the security level achieved by Security Targets (components) being evaluated (tested) against a Protection Profile.
For or a few years beginning in 2007, the Common Criteria included a profile for separation kernels called the Separation Kernel Protection Profile (SKPP) that real-time operating system (RTOS) providers such as Lynx, Wind River Systems, and Green Hills Software built products toward. The SKPP was sunset in 2011 by NIAP after problems with the first evaluation. The Common Criteria remains a useful standard, but no further SKPP evaluations will be accepted, and the SKPP is effectively dead. Instead, NIAP is directly supporting the certification and accreditation process for critical systems. NIST Special Publication 800-53, “Security and Privacy Controls for Federal Information Systems and Organizations” is a more general security approach that partly fills the SKPP gap. We offer a NIST 800-53 package for LynxSecure.
LynxSecure was designed to satisfy real-time, high assurance computing requirements used to regulate military and industrial computing environments, such as NIST, NSA Common Criteria, and NERC CIP. Developed and maintained in San Jose, California in accordance with FAA DO-178 Safety Quality Standards and DoD Risk Management Framework guidelines, LynxSecure is certified, fielded, and maintained on classified DoD networks. The product has undergone many security assessments including penetration testing and design review by independent government security authorities.
For the last several years, LynxSecure has gone through numerous delta certifications showcasing significant cost savings from the reuse of previously certified components that have remained unmodified throughout the lifecycle of a program’s tech refresh period. The technology has also enabled programs to effortless spawn derivative platforms into adjacent programs further maximizing component reuse. Lynx offers a DoD Risk Management Framework guide to aid the US Army’s security evaluation of the security enforcing properties of the platform. The package includes NIST security control traceability and Common Criteria Security Target traceability into the underlying kernel design requirements.
Our NIST security artefacts are for LynxSecure on x86. A block of services comes with the artefacts to train users how to adjust them for additional hardware. If desired, Lynx can engage in a discussion about professional services work to enact custom work for a specific customer.
LynxSecure doesn’t partition software, it partitions hardware into virtual machines in which software executes. Each virtual machine can be granted very fine-grained privileges; the system can use one guest to perform one critical system function, and another guest to perform another critical system function. There is no need to bestow all of the system trust in a single guest operating system.
In LynxSecure there is no root OS, helper OS, master OS, trusted OS, etc. Developers can however choose to emulate this approach by assigning all key system functionality to a guest OS of their choice. LynxSecure configures all partitioning in the system prior to the start of any guest OS. All hardware registers defining partitioning attributes (MMU, interrupt vectors, SMMU, PCIe, etc.) are set to the values required for the hardware to enforce the defined partitioning scheme. This includes CPU schedules, interrupt controllers, memory, devices, PCIe end points, DMA masters, etc. Once these registers are written/set, the code which performed the write is removed from the LynxSecure binary. From this point forward, it is literally not possible for LynxSecure to modify the defined partitioning, privileges, and security policies. Additional details are available in the LynxSecure Architecture guide (product documentation)
For every architecture, LynxSecure defines one or more shared memory regions between guest operating systems.
Each region is uni-directional/single-write.
Each region is zero copy from the perspective of the Separation Kernel. LynxSecure has no role in copying or moving data from user to supervisor to user privilege modes. This clean approach provides a high performance, secure memory region as the underlying foundation for more advanced protocols. For Linux, Lynx Simple Applications and LynxOS-178, Lynx also provides drivers for FIFOs and vEthernet (Intel now, Arm mid 2020) communications between guests, relying on the underlying zero copy shared memory as transport.
Solutions related to security are very SoC specific and dependent on key storage, cryptographic accelerators, and more. As such, it would be false to state that we have an off-the-shelf solution, when any solution will require a level of hardware-specific customization to leverage available resources.
Solutions that are based on an underlying RTOS may implement platform-specific solutions which can then be exposed by that RTOS via higher level APIs. However, this will likely require that a comprehensive RTOS BSP is available. LynxSecure is not an RTOS and it relies on fine-grain privileged operating systems to use the software stack selected by our customers for each purpose.
Customers using LynxSecure have created upgrade mechanisms which are platform or SoC specific solutions customized to their needs.
The LYNX MOSA.ic framework and architecture allows customers to deploy their favored network protection solution within the guest OS that they prefer and have consequently assigned with the necessary hardware privileges and security policies. Lynx has not invested to incorporate these capabilities within LynxOS-178 as we feel there are more fully featured solutions available at lower cost. On Intel platforms, the Virtual Device Server (VDS), a privilege-restricted Linux guest OS, provides an ideal location where additional network or packet inspection services could be easily added on behalf of the full system.
If LYNX MOSA.ic is described as "a software framework for building and integrating complex multi-core safety- or security-critical systems using independent application modules." What, then, are "independent application modules?"
Independent application modules are isolated, static virtual machine environments (and their guests) created by the separation kernel which enable system architects to simplify their system designs by better managing software complexity inheritance. Certain applications may only require simpler bare-metal environments. Others may require more complex Linux environments. Application environments can be (1) bare-metal; (2) RTOS, Windows, or other 3rd-Party OS; (3) Linux. They are governed by an information flow policy that ensures system security and they cannot be dynamically altered during runtime.
Yes. LynxSecure is a Separation Kernel that sets up and locks-down device partitioning at boot, prior to the start of guest OS. All security policies, hardware partitioning, and inter-guest memory access privileges are defined according to the engineer’s needs, with few design impositions due to the hypervisor. This allows builders to fine-tune the levels of complexity and safety- or security-criticality for each application module and to certify each module—and only the module(s) that require certification—independently.
The Architecture Configuration Policy is setup on the host PC using a modeling language, and compiled on the host into a bootable binary. That binary is self-contained and configures the target resources as described in your model immediately on power-on. The privileged code that does that is eliminated after the job is done, leaving the system secure.
Firstly, LynxSecure runs Initial built in test (IBIT) and continuous built in test (CBIT) to validate the crucial hardware registers that control the partitioning of the system remain valid. By design it should be impossible to programmatically change these, so CBIT is intended for things like single-event upset (SEU), ie cosmic rays, but it also protects against a hardware faults or weakness (like rowhammer). Secondly, LynxSecure has an audit log. Guest VMs can be granted privilege to access the audit log and to receive an interrupt when events are stored. There are about 60 audit events. The events can be filtered and actions defined should you wish to halt or reset a VM that generates event X.
On x86 there is a module—a bare-metal virtual machine (VM)—called LSAstore that intercepts a block device (disk or partition) and provides transparent encrypted disk storage. But otherwise this is not a standalone feature because this can be trivially done with a bare-metal VM.
There is a LynxSecure demo where a VM is given access to an encrypted storage area and a Yubikey USB digital key to unlock it and provide secure access to control a robot via IPC (FIFO). Shmem or virtNet IPC is also supported.
On x86 there is a module—a bare-metal virtual machine (VM)—called LSAstore that intercepts a block device (disk or partition) and provides transparent encrypted disk storage. LSAstore uses the OpenSSL FIPS object module.
But, in general, LynxSecure does NOT contain any certified cryptographic libraries. It is deliberately minimal (no console, no create-VM APIs, no login).
Our NIST security artifacts are for LynxSecure on x86. Our business model is that a block of services comes with the artifacts to train users how to tweak them for additional hardware. This task is expected to be easy enough to do within the block-of-time for all but really unusual devices. It would be more work for Lynx to update the NIST package for Arm, possibly a few months of work. But, we are looking for an excuse to do that work, and would be delighted to undertake it should you be interested in NIST security artifacts for LynxSecure on Arm.