Embedded Systems Design Europe - May 2008 - (Page 27)

medical no prior knowledge of the software. Recently the CDRH’s Ofﬁce of Science and Engineering Laboratories (OSEL) has been investigating the use of static analysis technology to assist in this task. This article gives a brief introduction to static analysis and explains how we used this technique to detect ﬂaws. STATIC ANALYSIS Historically, static analysis has been used mainly to enforce syntax checks and coding standards in software. Over the last few years, a new breed of static analysis tools, based on light-weight formal methods, has emerged that can be used to detect potentially fatal ﬂaws in the software. The ﬂaws detected by these static analysis tools include runtime errors, such as buffer overruns, null pointer dereferences, race conditions, resource or memory leaks, and dangerous casts. Some advanced tools also incorporate a facility to detect inconsistencies in the code, such as redundant conditions or erroneous assumptions that may indicate programmer misunderstandings. Typically, when a potential ﬂaw is found in the software, the tool generates a warning that allows the user to see not only where the ﬂaw occurs, but the conditions that must hold in order for it to occur. An advanced static analysis tool typically operates by performing an abstract or symbolic execution of the program. During this execution, program variables containing actual concrete values are replaced by corresponding symbolic values. The analysis proceeds by using these symbolic values to follow all possible paths through the code. Along each path, all possible symbolic values are recorded. As this execution proceeds, the analysis may learn facts about the variables and how they relate to each other. It uses these facts to reﬁne associated symbolic values and check for potential errors. If any of the values is determined to result in an error at any point along the path, a corresponding warning is issued. As an example, consider the code Listing 1 Example showing a NULL pointer dereference 24 25 26 27 28 29 30 31 32 33 34 35 unsigned int x; char *p, *q GetXValue (&x); if (x < 100) { printf (“x is less than 100”) if (x == 10) q= NULL p = &x; x = *q; } snippet shown in Listing 1. When analyzing this code, the static analysis tool computes symbolic values for the variables x, p, and q along all possible paths in the program. As it navigates through these paths, the tool learns facts about the variables and uses them to reﬁne their corresponding symbolic values. Along the path comprising lines 29 through 35 for instance, the tool learns that x can only hold values between 0 and 100. Therefore, it reﬁnes the symbolic value associated with x to the range [0..100]. Further, it learns that when x is equal to 10, the pointer q is assigned the value NULL. Thus, the tool associates the symbolic value NULL with q, provided the predicate (x == 10) is true. Finally, on line 34, when q is dereferenced, the tool determines that a possible symbolic value for q may be NULL and issues a corresponding ‘NULL Pointer Dereference’ warning to indicate the same. A common problem with static analysis tools is the generation of false positives—warnings reported by the tool that are not genuine errors. False positives are generally caused due to a lack of domain-speciﬁc knowledge about the code. Typically, this involves variables that can only hold speciﬁc values and can never be assigned the erroneous symbolic values as computed through static analysis. A high falsepositive rate is undesirable as it could result in needless effort for the user and may result in true positives (errors) being overlooked. While completely eliminating false positives is not possible, most static analysis tools deal with this problem by providing users with conﬁguration parameters to control the analysis. For example, the maximum number of paths explored per procedure may be speciﬁed to increase or limit the searchspace for the tool. These conﬁguration parameters help provide the tool with the missing domain-speciﬁc knowledge required for accurate analysis, while allowing users to select the level of analysis most appropriate for their application. CASE STUDY: POST-MARKET STATIC ANALYSIS At OSEL, we used static analysis for the post-market review of a commercial medical device. The aim of this analysis was to determine all possible potential causes for failure in the software and to assess compliance to established software and quality control standards. GrammaTech’s CodeSonar static analysis tool was employed to carry out the analysis. CodeSonar is a source-code analysis tool that performs a wholeprogram, interprocedural analysis on C/C++ code to identify complex programming bugs that can result in system crashes, memory corruption, and other serious problems. The software for the device under review was implemented largely in C/ C++, with some macros deﬁned using low-level assembly code. The software was deployed in the form of three independent modules, comprising approximately 200,000 lines of code. As the compiler used by the manufacturer was nonstandard, a mock environment was created based on the doc27 www.embedded.com/europe | embedded systems design europe | MAY 2008 http://www.embedded.com/europe

Table of Contents Feed for the Digital Edition of Embedded Systems Design Europe - May 2008

Embedded Systems Design Europe - May 2008 Contents Microsoft Provides Embedded Roadmap Enea Buys Developers Irish Start-Up Raises Funds for Telecom FPGAs Kontron Promotes COM Express Nano Mentor Nucleus Platform Provides UI for Atmel Small Form Factor Boards Head for the SUMIT Proffibus Advances IO-Link Integration Embedded Developers Cautious on Multicore Auto Cooperation Improves Test Altera Launches DO-254 Partner Network Building an ‘Instant-Up’ Real-Time Operating Systems An Architecture for Reusable Embedded Systems Software Free up Bandwidth in PCI Express Evaluating Software in Medical Devices Circuit Sensitivity in Analog Circuits Choosing Flash Memory New Products Advertising Contacts

Embedded Systems Design Europe - May 2008

For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.