VxWorks

The Advent of Multi-core MILS

By Paul Parkinson

It has been a rather long time since my previous blog post. I intended to post a blog before the holidays regarding our partner Curtiss-Wright's announcement about VxWorks MILS support on the VPX6-187, but I simply ran out of time! So here it is as my first blog post of 2013.

The Curtiss-Wright new release was actually quite a game changer. To the casual reader, it may just appear to be about the release of another board support package (BSP) on a leading-edge COTS processor card, but the fact that this BSP supports multi-core for a MILS architecture is what makes this announcement so significant.

When the MILS software architecture was proposed in 1984 by the computer scientist Dr. John Rushby, microprocessors at the time were inherently single-core, and computing performance advances were being driven by clock speed increases and die size, at a rate following Moore's Law.

Over the last decade, single-core processors with robust MMU partitioning have become sufficiently performant to enable viable MILS separation kernels (SK). In recent years, Wind River has implemented VxWorks MILS on single-core processor architectures (PowerPC MPC8548), and on multi-core processors, but only running on a single core (dual-core PowerPC MPC8641D, quad-core Intel Core i7).

However, with the VxWorks MILS Platform, Multicore Edition, the VxWorks MILS separation kernel now runs on all eight cores of the Freescale QoriQ P4080 processor concurrently. Yes that's right, I am talking about (MILS & multi-core) rather than (MILS XOR multi-core). This enables the integration of many MILS solutions on a single processor, creating reduced size, weight and power (SWaP) benefits - even high assurance security-critical systems have tough performance requirements.

The advent of multi-core processor architectures over the last few years has had a dramatic and disruptive effect on the embedded market. This has provided significant benefits in terms of reducing size, weight and power (SWaP), but has also presented some interesting challenges for safe and secure application domains.

For example, the global aerospace market has very mature processes for DO-178B safety-certification on single core processors. Similarly, the security community is approaching maturity for Common Criteria security evaluation on single core processors. But both segments are challenged when driving multicore systems through their respective processes.

There has also been an emerging trend in recent years of individual systems needing to meet both safety-certification and security evaluation, and now with the emergence of multi-core, this presents some new regulatory challenges, but the benefits will be worth the effort.

This convergence is discussed in more detail in the white paper 'Safety, Security and Multicore' which is available for download from the Wind River website.

For additional information from Wind River, visit us on Facebook.

Guest Blog: Qt Commercial 4.8.3 Released with Official Support for VxWorks

By Tuukka Turunen, Digia

This week, together with the Qt Project, Digia released version 4.8.3 of Qt Commercial. Developed together with Wind River, it now includes official support for VxWorks, Wind River's leading real-time operating system found in about one billion devices spanning a wide range of industries -- and can also be found in outer space!

Qt is an excellent tool to create interactive and dynamic user interfaces for VxWorks and the combination of an officially supported platform for commercial Qt licensees is a big step in the evolution of the product. Many of the improvements are also made available to open-source Qt users, though VxWorks itself is not available under an open-source license.

Qt runs seamlessly with VxWorks on a large variety of hardware, including embedded ARM and x86 processors. Both DKM and RTP modes are supported allowing the leverage of a wide array of different Qt functionality including OpenGL accelerated graphics, Qt Quick and WebKit to name a few examples. Naturally, the basic Qt modules are also well supported for ease of programming and portability.

More information and a video can be found from our earlier blog post on VxWorks.

In addition to VxWorks support, highlights of 4.8.3 include changes to better support Mac OS X 10.8 and QNX, as well as new WebKit (2.2.3). We have also made significant improvements to many modules, including QtCore, QtGui and QtNetwork.

As part of the Qt Project, Digia has also packaged and tested the open-source version of Qt 4.8.3, which feeds from the Qt Project 4.8 branch. We will keep providing patch releases to 4.8 as long as needed, we currently anticipate at least two more patch level releases. Qt 5 provides high compatibility with Qt 4 and we recommend all Qt users to migrate their active projects to Qt 5.0.0 when the final version release is available.

Qt 4.8.3 is now available as an update for all commercial SDK and stand-alone installer users via the Qt Commercial Customer portal. If you are not yet using the Qt Commercial SDK, you can try it out and get the SDK installer from the Qt Commercial Customer Portal. We also have tagged the Qt 4.8.3 release to the Qt Project repository.

Digia is very excited about this development and we look forward to continuing our collaboration with Wind River!

Tuukka Turunen is director of R&D at Digia, Qt Commercial and is responsible for the planning, creation, verification and delivery of Qt Commercial.

First Line of Defense

By Ka Kay Achacoso

Designing security into a device requires an understanding of the nature of the attacker.  The cost of security implementation, including  acquiring the technology carrying out the processes, scales up with attacker sophistication.  A rule of thumb is to make the device tampering cost higher than the benefits gained from a security breach.   

Wind River’s VxWorks real-time operating system platforms come with a set of simple security measures that protect the VxWorks applications against some clever hackers.  At the Intel Developers Forum (IDF) in San Francisco next week, we will be demonstrating several layers of protection that come with the operating system (booth No. 400).

In this blog post I will outline a few simple security measures, already available in the VxWorks platform, that deter attacks on the VxWorks system. 

For networked devices, remote access to a device can be protected by implementing a network firewall.  Certain security functions can be limited to be locally accessible only.  Wind River Firewall for VxWorks is already part of the market-specific platforms like Platform for Industrial Devices.   Security processes around firewall configuration access can be implemented.  For example, opening a port in the firewall requires authentication with username and password, or the administrator needs to be physically present to make changes.

Encryption can be applied to all messages passed through the network ports.  For example, Wind River Firewall can block all traffic, but open a window into an SSH shell. 

For additional security against VxWorks experts, it can be ensured that all software modules loaded are from a reliable source and unmodified.  For any modules loaded, including VxWorks kernel images, downloadable kernel modules (DKM), and real-time processes (RTP), attach a digital signature to it and make the loader verify that signature.    At IDF, our demonstration will show an example of our engineering team’s implementation of binary authentication to protect our devices from loading unauthorized software.

For those attackers who try to inject fault into a system in order to bring the whole device down, VxWorks kernel hardening features implements a series of measures to contain the fault to the rogue software and cleanly remove the faulty tasks without affecting the rest of the system.  As an example, these features will detect and report any attempts to write into the text section, preventing an attacker from changing program execution.

It may be possible that some or all of these security measures will sufficiently meet the required security needs.  Beyond these measures, if protection from highly sophisticated, heavily funded and organized attackers is required, there are other products and services from Wind River and our partners that can bolster your security.

 

For additional information from Wind River, visit us on Facebook.

Avionics Conference 2012

By Paul Parkinson

It's been a long time since my previous blog, as unfortunately I've been engrossed in a number of projects!

However, I have just got time to mention that I'm really looking forward to the Avionics Europe conference in Munich on 21-22 March. The conference programme is pretty packed, covering cockpit avionics and technologies for civil and military aircraft; and aircraft, spacecraft and UAV sensor payloads, diagnostics and certification.

I will be presenting a paper on "A Secure Virtualisation Approach to Support Multi-Level Secure Systems, Software Reuse and Incremental Certification" in the Embedded Software session on Wednesday afternoon.

The paper addresses how secure virtualisation approaches can be used to implement a system architecture to securely partition applications and data of different security domains on the same system (such as national Secret and NATO Secret data), whilst enabling the reuse of previously developed software applications and existing intellectual property in an open standards-based communications environment. The paper also includes a discussion on the requirements for supporting incremental safety-certification under RTCA DO-178C / EUROCAE ED-12C and Common Criteria security evaluation at high evaluation assurance levels, and the implementation architecture to support a role-based development process.

Wind River will also be exhibiting at the conference, so why not drop by our stand for a chat and to see a cool avionics display demo?

VxWorks Cert Now Supports ARM!

By Alex Wilson

Aerospace and defense has relied on rugged embedded vehicle mounted computers for many years, but as devices become more mobile, and with increased demand to reduce SWaP (Size, Weight, and Power), ARM-based computers become an interesting alternative.  Added to that is the wealth of functionality available in ARM devices that make it a good choice, not only to reduce SWaP in the core CPU, but to reduce overall chipset sizes to a single SoC.

If we look at an example of an ARM-based device, such as the TI OMAP3530, this is a perfect device with which to build a software defined radio for example. It has a high performance, low powered Cortex A8 Core, with numerous IO devices to help connectivity and display.  Designed as a mobile device, for example, it supports Android -- and the OMAP3530 is also well suited to other areas of A&D such as soldier mounted systems, or remote sensors.

When it comes to avionics systems, aircraft also have a range of devices, from the high end central control computers running multiple applications (such as the common core computer of the Boeing 787) down to remote sensors and actuators that run on 8- or 16-bit processors, and maybe do not need to use an operating system.  TI also produces devices targeted at this market, which not only reduce SWaP, but are tested to the required standards for avionics applications, including extended temperature ranges, and using avionics friendly packaging.  For example, the OMAP-3530, is available as a OMAP3530-HIREL (PDF Datasheet) with extended temperature ranges from -45C to +105C.

So with this in mind, it is great to see our leading real-time operating system's latest release with support for ARM processors.  VxWorks Cert already supports both Freescale and Intel, with certification evidence for RTCA DO-178B (EUROCAE ED-12B) Level A, and has been certified on platforms such as the Eurocopter EC-225 Helicopter, or Cobham900E series Air Refuelling Pods on the A330MRTT.  This latest release adds support for ARM Cortex A8 and A9, as well as some updates to the Freescale coverage.

Support for ARM Processors gives our safety-critical customers the choice and flexibility they needed in order to meet the tough SWaP, functionality, and certification requirements for the demanding avionics applications, and I am looking forwards to seeing some great innovations in the next few years!

 

For additional information from Wind River, visit http://www.facebook.com/WindRiverSystems.  

VxWorks Cert: Supporting Low Power Devices in Safety Critical Systems

By Bill Graham

Embedded microprocessors are steadily progressing towards more performance while maintaining or decreasing power requirements (more succinctly, the performance per watt is getting better and better). High performance processors that decrease system power requirements are desired in safety critical systems just as they are in the general embedded marketplace. Our recent release of VxWorks Cert Platform adds support for ARM processors to our safety critical VxWorks platform which compliments our current support for Intel Atom processors, both of which are important platforms for high capable but low power consumption devices.  Adding ARM to the supported list of architectures expands the application of the safety critical real-time operating system (RTOS) platform to new possibilities such as mobile, handheld and graphics-oriented devices.

The latest generations of ARM and Intel Atom processors are also central to highly integrated System on Chip (Soc) solutions that are commonplace in consumer devices but are seeing popularity in industrial, medical and aerospace and defense. These highly integrated platforms provide graphics, audio, video, and connectivity features in single package that is appealing for use in industrial control (e.g. HMI for process control), medical devices (e.g. infusion pump) and defense (e.g. avionics displays.) Having a safety critical runtime platform for these next generation devices allows our customers to leverage a commercial off the shelf (COTS) solution and have the choice of processor architecture that best suites their needs. As ARM and other low power platforms grow in the safety critical markets we look forward to seeing VxWorks Cert Platform grow with it.

 

For additional information from Wind River, visit http://www.facebook.com/WindRiverSystems.  

In embedded systems, a lifetime is a long time

By Bill Graham

The recent news about the demise of the Mars Rover Spirit (Mike Deliman blogged about this last week) and comments about how it succeeded its mission many times over, got me thinking about just how long product lifetimes are for embedded products (see "End of Mars mission: Way beyond warranty" by Bob McDonald at the CBC). In many industries using embedded software to control devices, the expected lifespan is decades which contrasts sharply to consumer devices where either software is upgraded constantly or we dispose of the device in a few years. On the other hand, embedded systems often exceed originally planned lifespans many times over. Case in point is the Mars Rover program, where Spirit operated six years beyond its original mission plan and rover Opportunity continues operation, surviving a harrowing journey and landing and a harsh Martian environment for so many years.

The point here is that these types of embedded systems, mission critical software needs to operate flawlessly not for days at a time (Mars is a long way for a service call!) but continuously for decades. Because of this, its important the software platform is rock solid and can be supported for the lifespan of the product. It boils down to risk management. Programs like the Mars rovers had so many other risks in the hardware, the delivery system, landing and operation that it makes sense to reduce risk wherever possible. From the software perspective, risk reduction is possible by going with a proven and reliable software platform, so at least the developers don't need to re-invent the wheel with a custom operating system, device drivers, middleware and homegrown tools. Wind River has a long relationship with the Jet Propulsion Laboratory and that trust and long term support has given the Mars Rover team the confidence they needed to trust an off-the-shelf solution.

We are sad to hear of the loss of rover Spirit but we're proud to be part of such a great space exploration success. We're equally proud to work with JPL and to have built up such a strong relationship with them. Indeed, lifespans of teams, relationships and products are often longer than anyone predicts.

Fun with VxWorks MILS 2.1

By Paul Parkinson

It’s been a while since my previous blog, as I have been rather preoccupied with responding to a number of RFPs. However, I’ve managed to find some time to work on some demos for VxWorks MILS 2.1, which has been fun.

VxWorks MILS 2.1 introduced support for Wind River Linux as a Guest OS (VxWorks Guest OS and High Assurance Environment (HAE) having been supported in the earlier VxWorks MILS 2.0 release). I wanted to get some more hands-on experience of using Wind River Linux as a Guest OS (GOS) running on the VxWorks MILS 2.1 Separation Kernel (SK). So, I started with a version of the Blaster Blastee demo which had been modified by one of my colleagues in Engineering to use a Linux GOS partition for the Blaster. (Blaster Blastee is a well-known Wind River demo which provides a nice flexible framework for blasting TCP or UDP packets between nodes, testing network connectivity and performance).

I thought it would be an interesting exercise to extend the demo to also use Linux in a second partition as the Blastee (receiver), to demonstrate the scalability and determinism of the MILS SK with multiple Linux virtual boards (VB).

This proved to be quite easy to configure, as I was able to use the same Linux kernel image as the Blaster virtual board, but with different boot parameters (as this virtual board was using a separate dedicated Gigabit Ethernet device on my target board, with its own IP address), and I just invoked the Blastee executable which had been built into the Linux GOS filesystem. Once I had added a timeslot allocation for the Blastee VB into the MILS system schedule, I was able to build and run the system and send packets between the two partitions via external Gigabit Ethernet interfaces.

(Side note: Alternatively, I could have sent packets directly between the two partitions either by using Secure IPC ports via the MILS SK according to pre-defined security policy, or even via an IP tunnel over SIPC, but I used the external Ethernet interfaces, as I wanted to extend the demo further).

The next step was to configure this Linux GOS-based system to send and receive packets via the two Ethernet ports to corresponding VxWorks GOS-based Blaster and Blastee virtual boards on a second board. This configuration can be used to simulate a Public Network and a Secure Network connection between two nodes (see diagram above). The original MILS Blaster Blastee demo also includes a trusted Security Audit partition, running in a High Assurance Environment, which monitors the audit log for each partition, and also a Rogue partition which attempts to illegally access the Secure Network interface to intercept traffic (which is of course prevented by the MILS SK). When this demo is running freely, the link lights on my Gigabit switch flicker away furiously, and the VxWorks MILS partitions report output via the multiplexed serial I/O output to a host console.

To really see inside the system, and to step through the interactions of the sender and receiver (Linux Blaster to VxWorks Blastee over the Secure Network, and VxWorks Blaster to Linux Blastee on the Public Network), I used Wind River Workbench to debug all four connections concurrently, using Linux user-mode agents in each of the Linux VBs, and On-Chip Debugging (OCD) via JTAG to debug the VxWorks Blaster and Blastee. In this way, I could step through the sending and receiving of packets in both directions over the two networks (rather than having to rely on printf(), which would have been difficult to correlate across multiple partitions). The screen shot shows the point at which I am stepping through send and receive (the size of the screen shot is constrained by my 19” monitor).

So, this demo shows how the High Assurance Environment, VxWorks GOS and Linux GOS can all run on top of the MILS Separation Kernel and still provide good network performance despite being in a time-partitioned environment.

Scalability: the key to product line success

By Bill Graham

An important requirement for an RTOS such as VxWorks is scalability. What this really means is being usable in many different types of devices, from small memory constrained, low power devices (possibly battery powered, hand held, mobile) to large scale systems, multiple nodes networked together, possibly using multicore in a multi-OS environment. Scaling down is equally important as scaling up. As my colleague Felix Baum had recently posted, flexibility is also critically important part of the equation, an RTOS must be configurable as needed by the developer and run on the hardware platforms they choose, and make the most of the hardware capabilities.

Why not just buy a specific RTOS for each project? This isn't really a viable option anymore. Our customers are looking for a tools and run-time platform they can rely on for a product line rather than an individual product. In the end this turns out the be the best solution both in terms of costs but also in reducing risk  and meeting difficult time-to-market targets. A common platform means reuse of code, expertise, tools and most importantly, "one neck to wring", one vendor and one point of contact to solve your problems.

Embedded product lines are usually varied in memory and CPU capabilities and may use different processor architectures from product to product. A tools and run-time platform that can be common amongst this variety of target systems is invaluable. For that to happen the RTOS must be scalable down to meet memory and CPU restrictions of the small, mobile and low power parts of the product line. The RTOS must also scale up to large multicore 64-bit processors that have many GB of RAM and disk space.

Moreover, the RTOS must support various configurations from a single processor (with or without memory management (MMU) support) to large multicore systems with mixed operating systems using embedded virtualization. Even if customers don't have these high end requirements yet they appreciate that their RTOS vendor can get them there. 

I think this is an important aspect of our recently announced 64-bit support for VxWorks. Not all of our customers require 64-bit support yet, the fact they can leverage this capability in the future is an important consideration. 

 

VxWorks: Pushing the Limits on System Flexibility

By Felix Baum

As you may already be aware, Wind River just released the latest version of our flagship real time OS offering, VxWorks. We worked hard to make sure that our customers can rely on it as a foundation to propel their solutions to market faster and enable them to differentiate their products from the competition by truly capitalizing on the flexibility of the leading edge silicon offerings from our partners.

Often when moving from single to multi-core processors, an SMP based solution seems like a logical next step. In SMP OS configuration, one instance of an operating system with one scheduler controls all of the cores and determines which task gets to run and on which core. 



In fact, if the original software was written without explicit assumptions on the execution order of the tasks/threads based on priority levels, there is little porting required to migrate over to a multi-core hardware system.

I do have to admit that during my 10+ years at Wind River, I have seen my share of code that used task priority as the only way to define the scheduling of events in the software. This code will fail miserably when you move it to a 2+ core system as an SMP scheduler will schedule the task with a highest priority to run first, and then will proceed to schedule the rest of the tasks, with the same or lower priority to run on the rest of the available cores. What is worse, the failure of such a design will show itself in intermittent race conditions that are notoriously hard to debug even with a top class tool like Wind River Workbench.

This, along with several other reasons, is why unsupervised AMP OS configuration is a good choice in certain designs, particularly when clients consolidate their design from many independent processors to run in a multi-core environment. In an AMP configuration, each core executes its own version of the OS and user application, and they do not have to be all the same. 

Some of the hardware architectures have 36-bit addressing and with the latest VxWorks on a dual core processor, you will be able to build two VxWorks 32-bit AMP images and load them side by side, covering 8 Gig of physical memory. This is extremely handy if your design has many peripherals that are memory mapped and your hardware engineer has set up a system with over 4 Gig of addressable memory. Of course if you have a 64-bit processor, this scenario is not applicable and you are better off running VxWorks in 64-bit mode.

As a number of processor cores continue to grow, I increasingly encounter customers with designs that are not fully satisfied with SMP or AMP only configurations. Often, I find that the best performance is achieved by partitioning cores so that a SMP operating system runs on the first few cores, while the rest are executing AMP configured OSes.

But what if your application is CPU intensive and one core will not be able to handle it? The latest VxWorks indeed comes with many innovative features, including  the elimination of the core 0 requirement for the SMP system, or what many folks call SMP m2n (any to any). You see, up until now, due to the fact that many multi-core systems coming out of reset rely on core 0 to partition the hardware, assign interrupts, initialize peripherals and such, SMP operating systems have to run from core 0 to any-core. With VxWorks, this is no longer a requirement and you will be able to run a SMP configured OS from any core to any core. So if you just happened to have 8 cores in your processor, you might run four independent VxWorks SMP images where each will control two cores.

Of course VxWorks, in addition to these configurations, allows for much finer application partitioning via CPU reservation and affinity features. VxWorks natively offers unparalleled flexibility in extracting the best performance out of hardware for your application needs. To take it a step further, if VxWorks is configured  for 64 or 32 –bit mode in conjunction with embedded virtualization technologies, such as on top of Wind River Hypervisor, the sky is the limit on the number of configurations possible when mixing and matching various operating systems and modes of OS operation between available cores.