Paul Parkinson

South African A&D Seminars

Tomorrow, I will be traveling to South Africa to present at the Wind River Aerospace & Defence Seminars which will be held in Pretoria and Cape Town next week. 

I'm really looking forward to the events, as we will be covering some interesting topics including the latest trends in Aerospace & Defence, including Safety and Security. This will also be the my first opportunity to present some new Wind River A&D customer case studies, which I hope the audiences will find interesting and informative. In the afternoons, we'll be providing some technical deep-dive sessions on Multicore, Virtualization and Hypervisor technologies, VxWorks 6.6 safety certification, and Wind River Linux. So it's a pretty packed agenda.

I'm also looking forward to seeing the scenery again which is stunning, particularly around Cape Town and Stellenbosch. Thunder City, on the outskirts of Cape Town, has three operational English Electric Lightnings, which is my all-time favourite military fast jet. It would provide the ideal way to see Table Mountain and The Cape in real style, but unfortunately, that's not part of the seminar programme. (For some interesting facts and anecdotes on the Lightning, the Wikipeda entry is well worth reading!).

RTLinux acquisition from FSMLabs

I was really pleased to see the news about Wind River's acquisition of RTLinux hard real-time Linux (ZDnet) from FSMLabs.

Linux is already starting to be used in certain types of Aerospace & Defence applications due to its maturity (which I discussed in the previous blogs: 'Linux in Aerospace & Defence' and 'Linux fit for Defence'), but these are mainly non real-time classes of applications where Linux has provided a good technical fit to the requirements. However, RTLinux technology extends the reach of Linux into real-time, because it achieves hard real-time performance where as some other real-time Linux implementations have only achieved soft real-time and have also forked the Linux kernel with proprietary extensions which could be a maintenance nightmare on A&D programmes with long in-service lifetimes.

You may be thinking that Linux as provides high performance on modern microprocessors, so does the distinction between soft and hard real-time really matter? In my view, it matters a great deal. 

• A real-time system is one which needs to complete a number of operations correctly by a specific deadline.
  
• In a hard real-time system, completion of the operations after the deadline is unacceptable and may even result in system failure.
• In a soft real-time system, deadline misses can be tolerated with degraded system performance.

Back in the days when I wrote host platform device drivers and libraries for high-performance multiprocessor DSP VMEbus (VITA) systems, I needed to develop stress tests to assess how the device drivers would perform under the severe loads which might be encountered in a deployed application. One test involved sending VME interrupts from a DSP (wikipedia) slave board to a host platform as fast as possible.  Of course, the DSP was able to generate interrupts at a very high sustained rate, and I was able to accurately measure with a VMEbus analyser the interrupt response times of the host platform and its operating system (which was either a multi-user OS or an RTOS). 

What was interesting when comparing the performance of the various operating systems, was not just the typical interrupt response times, but the variation between best case, worst case and average response times for each of the operating systems, especially in relation to increasing system load. This revealed that although some of the soft real-time platforms could achieve fairly respectable interrupt response times most of the time (especially under fairly light load), under severe load, the interrupt response times could vary dramatically. The hard real-time platforms (VxWorks in particular)produced much less variation.

The outcome was that the suitability of a particular host platform to the performance requirements of a specific application wasn't determined by its best-case response time, but on its worst-case response time. For me, this lesson has a direct bearing on the suitability of Linux for hard real-time applications; as RTLinux's hard real-time performance not only provides faster response, but also much better determinism and predictability, this will enable the adoption of Linux in a new class of applications. In A&D, I expect that Linux will now be able support certain types of radar and communications applications, etc.; but of course there will always be applications with such as EW (electronic warfare) systems and other sensors which even RTLinux will not address but they will instead will exploit the extreme hard real-time performance of VxWorks for a tactical advantage (for example, sub 2 microsecond interrupt response time on a 1GHz PowerPC), but these are at the two ends of the hard real-time spectrum.

So, now it's Linux - fit for hard real-time defence.

Linux fit for Defense

In an earlier blog, I commented on the potential use of Linux in Aerospace & Defense, but I didn't provide any background information to support my assertion that people seem to either love or hate Linux, and that often their views are formed from emotive arguments and prejudice rather than rational fact-based discussions.

Last week, Paul Tingey discussed some interesting examples of polarised views in different countries in a recent blog Open Source: Do you love or hate it? So, I thought I should comment on some of the views which have been expressed in relation to the use of Linux in defence.

In the article 'No Defense for Linux' (Design News), Green Hills Software CEO, Dan O'Dowd, shared his views into what he believes are potential security issues relating to the use of Linux in defence systems. The article is both interesting and thought provoking, and Mr. O'Dowd raises some important questions which do need to be considered.

A number of other bloggers have already commented on this article from a number of angles, the one's which I found the most interesting were Victor Yodaiken: Green Hills, foreigners and the gummi bear threat'; Dana Blankenhorn: 'Is Linux a Danger to National Security?', and  Perry E. Metzger: 'News Flash: Proprietary OS vendor dislikes Linux!'). However, I want to follow-up on two of the arguments in the article in particular, as they do not appear to stand up to close scrutiny:

1. Open Source peer review
   Mr O'Dowd asserted that "many eyes" are no defence against subversive or malicious code which could be used to undermine system security.  However, this argument is inconsistent with the accepted best practice for the definition of network security protocols. It has been well documented that security protocols, such as Wireless Equivalent Privacy (WEP), which was designed in isolation without peer review by security experts, was fundamentally flawed. The flaws are documented in Security of the WEP algorithm (Berkeley), and the lack of peer review is highlighted by Jon Edney and William Arbaugh in their book "Real 802.11 Security". This should be contrasted with the approach taken to develop 802.11 wireless security which uses the Advanced Encryption Standard (AES, wikipedia).
   
2. Vulnerabilities in Binary Code
   Mr. O'Dowd also asserted that 'source code inspection will never detect vulnerabilities that are only manifest in a system’s executable binary code', which is of course a valid statement. However, the example which he used to illustrate this doesn't actually support this argument. He cited the story of Ken Thompson, one of the original designers of the UNIX operating system, who installed a backdoor (a.k.a. Trojan Horse - wikipedia). Mr. O'Dowd said that Thompson "installed a back door in the binary code of Unix". This statement seem to be slightly ambiguous to me, and I wasn't sure if it meant that the backdoor was installed into the UNIX kernel, so I checked the original article by Ken Thompson 'Reflections on Trust ' (ACM) and found that states explicitly that the Trojan code was actually contained within the UNIX C compiler:
   

   "The actual bug I planted in the compiler would match code in the UNIX "login" command. The replacement code would miscompile the login command so that it would accept either the intended encrypted password or a particular known password. Thus if this code were installed in binary and the binary were used to compile the login command, I could log into that system as any user."

   So, the comparison between Linux and UNIX  does not appear to be valid in this instance because the GNU C compiler used in Linux is Open Source whereas the UNIX C compiler was not. So the Linux GNU C compiler can undergo source code inspection in the same way as the Linux kernel, so there will be no binary code that has not undergone source code review. Ken Thompson also described a very devious approach to install a backdoor into the UNIX C compiler, which would re-insert itself without when the compiler was recompiled. However, Ken Thompson acknowledged in his article that:
   

   "Such blatant code would not go undetected for long. Even the most casual perusal of the source of the C compiler would raise suspicions."

   A backdoor could be inserted into the GNU C compiler using the same technique, but this could be detected by disassembly of the compiler.

So, it would seem that at least some of the arguments against the use of Linux in defence systems do not seem to have a firm foundation based on facts. Don't get me wrong, I'm not saying that Linux is suitable for all types of defence application, but as I discussed previously, I do think we need to have an open mind.

Linux in Aerospace and Defense

In a recent blog entry, John Bruggeman considered the role of Linux in Automotive applications. He discussed the blurring of the distinction between car infotainment systems and driver assist systems. This got me thinking about the adoption of Linux in the Aerospace & Defence market, in particular the potential use of Linux and safety-critical avionics and military vehicles, which I hadn't really thought much about before.

It seems to me that people's attitudes towards Linux can be rather polarised at times - a bit like Marmite (wikipedia), people either love it or hate it. Over the years I've written applications and device drivers for a range of enterprise UNIX platforms and real-time operating systems, and whilst I've experienced for myself the relative merits of each of theses OSs for particular types of application, I've never felt threatened by the advent of Linux, I've just been curious as to its potential. So, I want to form a view on Linux in A&D from rational fact-based discussions not from emotive arguments and prejudice.

I've noticed the increasing adoption of Linux in A&D for mission-critical enterprise and embedded applications in recent times, for example RSTA-MEP and the Linux Crewstation (LinuxJournal) and Boeing P-8A Multi-Mission Maritime Aircraft (Linux Sys-Con) respectively. I suspect that this may be related to the maturing of the Linux kernel and the Carrier Grade Linux specification - these topics were recently discussed in Paul Tingey's blog Is Carrier Grade Linux Winning New Friends?, and Paul Anderson's blog Raising The Bar.

In the case of avionics there are different classes of systems: safety-critical systems, such as the head-down primary guidance flight displays (which use safety-certifiable RTOS such as VxWorks/Cert and VxWorks 653 and others); and non-critical systems (a.k.a. mission critical systems), which include secondary guidance systems such as digital map display (such as TARDIS) and Head-Up Displays (HUD), which although they do not have an RTCA DO-178B safety certification requirement today, this could possibly be mandated in the future.

In the case of military vehicles: there are programmes developing vehicles with electric motor propulsion under software control, such as SEP (Army Technology). As well as charging across battlefields, I imagine that such vehicles will be driven on public roads, which is quite similar to the civil automotive scenarios described in John's blog, and it's reasonable to expect that they would require safety certification under ISO/IEC-61508.

So, for these classes of A&D applications, what are the options for safety-certification using Linux?

There are Linux distributions which use a pristine source tree, so could this conceivably be used as a foundation for traceability and requirements-based testing for DO-178B safety certification?

What about the safety-certification cost (assuming DO-178B Level B-D), could this become economically viable if a trusted Linux profile with a reduced source lines of code (SLOC) count were defined?

If not, another alternative might be to consider a virtualization approach, perhaps using a MILS (Multiple Independent Levels of Security) architecture?