“Since human
beings themselves are not fully debugged yet, there will be bugs in your code
no matter what you do.”
-Chris Mason, Zero-defects memo (quoted
in Microsoft Secrets, Cusumano and Selby)
Most of the programmers usually think that the
code is perfect, once it complied without returning any warning or errors. Are
you one among them? Well, this assumption won’t help you always, especially
when you play with C language. Since ‘C’ is an imperative (procedural) systems
implementation language, it more closed to the system memory and low-level
architecture. So, if doing something wrong with memory, which will directly
affect the whole system in fact! Well, a static code analyzer like “Splint” can
point out these defects especially in Embedded Linux.
Introduction
In embedded system, almost all
programs have to run “24x7” continuously! This makes sense about the efficient
usage of the system memory. If a particular application unnecessarily taking considerable
amount of memory, then this will probably cause for the “system crash”.
Linux is made up of ‘C’ so that
when it comes to the Linux programming in embedded, an extra care should be
required in memory consumption as well as coding efficiency. A typical compiler
will only check the typo-syntactical errors but never check where the memory
leak is occurring. Here comes the importance of specially designed tools for
static code analysis.
“Splint (Secure Programming
Lint)” is a tool for statically checking C programs for security
vulnerabilities and programming mistakes. Splint becomes “handy” when it comes
to the embedded world, especially dealing with Linux.
The advantage of
splits includes but not limits to the following
- Ability to interpret special ‘annotations’ to the source code, which gives it stronger checking than is possible just by looking at the source alone. Annotations are stylized comments that document assumptions about functions, variables, parameters and types.
- Splint is “cross- platform” tool so that it can use in both x86 and ARM architecture machines.
- Better customization to select what types of errors are reported using command line flags and stylized comments in the code.
- Full freedom to the user. Users can define new annotations and an associated check to extend Splint’s checking ability.
- Splint can check the infinite loop problem that couldn’t able to do by a run-time checker such as ‘valgrind’.
- Splint is free software released under the terms of the GNU (General Public License).
Ideally speaking,
Splint can be use in almost all C programs and can find the bugs in user
specific manner. The common (some of them can be find only with splint!)
problems that can be fixed through the Splint are listed below.
- Using possibly undefined storage or returning storage that is not properly defined.
- Violations of information hiding.
- Dangerous aliasing.
- Problematic control flow such as likely infinite loops, fall through cases or incomplete switches, and suspicious statements.
- Dangerous macro implementations or invocations.
- Violations of customized naming conventions.
- Buffer overflows vulnerabilities.
- Modifications and global variable uses that are inconsistent with specified interfaces.
- Memory management errors including uses of dangling references and memory leaks.
- De-referencing a possibly null pointer.
- Type mismatches, with greater precision and flexibility than provided by C compilers.
How
to start with Splint?
Well, the answer
is very simple. The best way to learn to use Splint, of course, is to actually
use it. The splint can be run by simply putting
Splint *.c
Where *.c means
that you can list out more than one C file with splint. Splint alone normally
show many warnings. So its up-to the user to taken care about all those, else
one can suppress the warning by providing a suitable “flag”.
A typical
example:
The following code snippet just check the different characters
which entered by the user. Though the initial ugly code is vulnerable, it not
returns any error when it compiles!
 |
| initial code snippet |
Splint can be run by splint
file_name.c, where the ‘file_name’ contains the above code.
The splint’s output for the above code snippet shows below.
 |
| splint’s output |
The splint’s warnings are highlighted in yellow colour
for better understandability. Splint won’t fix the above vulnerabilities by
default. User should take the decision and fixed it by applying the patches.
The below code
snippet shows fixed source code. Please note that, this code is just for explaining
the use of splint but not for the functional meaning.
 |
| fixed code snippet |
Conclusion
Splint is a very powerful tool for
static C code analysis. Since splint is cross platform, it can be efficiently
use in embedded systems that mainly deal with ARM architecture .Though splint
shows much kind of warnings and errors, it’s totally up-to the user to taken
care and fixes it.
Learn
the splint; play in embedded world, that too with free of cost!
