The Linux Foundation’s announcement of the ELISA (Enabling Linux in Safety Applications) project was of interest to us because it requires a significant effort in evaluating open source software for use in safety in critical applications and its goal to “improve processes, and to automate quality assessment and assurance.” The mission statement of the project is as follows:
“The mission of the Project is to define and maintain a common set of elements, processes and tools that can be incorporated into Linux-based, safety-critical systems amenable to safety certification.
The scope of the Project includes software and documentation development under an OSI-approved license supporting the mission, including documentation, testing, integration and the creation of other artifacts that aid the development, deployment, operation or adoption of the project.”
This is fairly big challenge and when successful it paves the way for incorporating Linux into applications that were prohibitive in the past, especially products requiring safety certifications. This post looks at the challenges inherent in adopting large open source projects for safety critical applications and the role of tools and specifically static analysis in that effort.
The Challenges of Using Open Source in Safety Critical Software
Safety critical systems are subject to different levels of hazard analysis based on the intended application. As such, it’s important to consider the application and required safety criticality level when evaluating the use/re-use of third party and open source need to be evaluated in the context of the criticality of the target system.
Consider ISO 26262, which defines the functional safety standards for automotive software and has different safety integrity levels (ASIL A, B, C, D), with D requiring the most rigour for development. It’s less likely that large open source operating system like Linux would be applied at the highest levels of integrity due to the fact that quality, security and testing requirements apply to all software even re-used, existing and third party code. However, not all automotive software has an immediate impact on safety, there are other less critical applications that are much better suited to third party operating systems and applications. These applications are the target for projects like ELISA and related projects such as SIL2LinuxMP and Realtime Linux.
Even at lower levels of safety integrity (IEC 61508 SIL 2, ISO 26262 ASIL B, for example) there are still certification hurdles that aren’t met by open source. First is “proven in use” which means that a product has demonstrated the reliability and robustness required through time used in the real world. Software that demonstrates an acceptably low failure rate in use for many hours of use is deemed to be “proven in use.” However, this criteria is only met with a certain version of software and hardware platform. Changing the software or hardware requires a restart on proving reliability. This is difficult to achieve with open source software since documentation and data collection are expensive and outside the scope of most projects.
Another hurdle that open source projects face is compliant development. Safety standards set out a set of engineering practices that are expected of a product based on the safety integrity level. Open source projects are likely not following such practices (nor would it make sense in most cases.) Although this might seem insurmountable, the SIL2LinuxMP project has a concept they call “Compliant non-compliant development” which attempts to bridge this gap. Essentially, this approach makes an equivalence between actual development practices used on a project with expected practices and supplement where needed. If such equivalences can’t be found, testing is used to supplement to create sufficient evidence of compliance. Although nothing is stated about the approach the ELISA project will use, it’s incorporating the SIL2LinuxMP project so presumably this approach remains.
The Role of Static Analysis
The ELISA project is in very early stages and nothing has been stated about tools. However, here are some of the applications of static analysis that we think are helpful with getting any third party and open source software more safe and secure:
- Detect complex defects and security vulnerabilities: Defects and security vulnerabilities are likely to exist in open source projects and advanced static analysis tools are good at detecting these even in code that has been in development and use for years. For example, concurrency defects often occur randomly and only after a system has been integrated completely on the final hardware platform. Advanced static analysis tools can detect security vulnerabilities that arise from malformed or tainted data outside expected values. Tainted data analysis helps to trace input data in the system to its use in the application and warn of any potential security vulnerabilities that arise. Automated analysis can provide the full control and data path for tainted data which allows for rapid remediation.
- Binary analysis provides insight and error detection of compiled code as object files, libraries and even executables. A unique capability of GrammaTech CodeSonar performs the same detailed analysis on binary code as it does on source. This can include system and third-party libraries that are provided without source code. Developers can ensure that the all code binary and source is up to the quality standard required for the project.
- Evaluate open source projects: Incorporating open source software is both a challenge and necessity in modern embedded software development. Static analysis tools can analyze third party source and binaries to discover defects and security vulnerabilities in software that could be impossible to test otherwise (without including it and running it, an expensive option).
- Determine Source Code Compliance: Safety standards are clear on using good programming techniques such as modularity, components, structured and object-oriented programming. It also requires the use of design and coding standards and language subsets such as MISRA C. In fact, these coding standards are mandatory for higher safety integrity levels SIL 3 and 4. Static analysis tools such as GrammaTech CodeSonar are very good for evaluating the state of compliance with these standards. Although it’s unlikely for an open source project to retroactively comply with strict coding standards, it’s instructive to know where large deviations occur.
- Accelerate certification evidence: Static analysis (and many other testing and lifecycle management tools) provide automated documentation to support testing, coding standard and quality/robustness evidence. Much of the manpower used in safety certifications is documentation and evidence production, automation and specifically static analysis reduces this burden significantly.
Summary
The ELISA project looks like a promising way forward for adopting Linux in safety critical applications. The project aims to tackle the big hurdles in adopting open source software in safety critical applications that require rigorous development practices. There’s an important role for software development tool automation in achieving these goals including a crucial role played by advanced static analysis.
