[so] Fwd: IxLabs Challenge: Elfs, dwarfs and checkers

Octavian Purdila opurdila at ixiacom.com
Fri Dec 8 15:43:07 EET 2006


http://cs.pub.ro/~ixlabs/?page_id=56
 
Bugs have their important part in the developers everyday life, and for the 
most of us, it’s not the happiest part either. Not surprisingly, programmers 
thought: what if we can write some programs to catch the bugs for us? This 
kinds of programs are known as program checkers (or checkers for short) and 
are further classified as static and dynamic checkers.

The dynamic checkers are those which are catching the bugs during the run (or 
simulated run) of the original program (instrumented with the checker’s code 
sometimes). The static checkers are employing an entirely different process: 
instead of running the original code (instrumented or not), they are 
analyzing the source code, intermediate code or even the final binary/machine 
code in order to find bugs. 

This challenge is about researching in the domain of binary static checkers, 
specifically, for Linux ELF objects augmented with DWARF information. We 
would like to find out your ideas about types of checking, various scenarios 
and techniques that you think would be feasible with such an approach.

Here are a few ideas from which you can start:
- determining the call graph for all functions, including the static and 
inline ones 
- determining the context type for all the functions of a kernel module (e.g. 
if the function is going to be called in interrupt and/or process context)
- determining if a kernel function is called from an inappropriate context

Your paper should not be longer then 10 pages and should contain:
- your ideas about the kinds of bugs you can catch with such an approach
- a high-level overview of how you will make use of the ELF, DWARF or machine 
code info in order to actually catch the bugs
- a description of the tools or libraries and how you plan to use them for 
this task
- a simple prototype to demonstrate the feasibility of one of your ideas (any 
language will do)

To participate please submit your paper no later then January 26th 2007. We 
will announce the winner on January 29th 2007.

And, as if the challenge isn’t cool enough in itself, an ipod nano is waiting 
for the winner.



More information about the so mailing list