[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