[cfe-dev] GSoC 2012: Static Function Blacklisting

Mark McCurry mark.d.mccurry at gmail.com
Wed Mar 28 13:15:02 PDT 2012


Hello,

For this Google Summer of Code I would like to propose adding a static
analysis tool to clang to verify that some set of functions is never
called from some entry point.
This static analysis would be capable of using some function
annotations to determine which functions can and cannot be called to
satisfy this requirement.

Example:

void func(void) __attribute__((does_not_call_foo))
{
    foo();//analyzer emits an error here
}

OR

void bar(void)
{
    foo();
}

void func(void) __attribute__((does_not_call_foo))
{
    bar();//analyzer emits an error within here
}

Why would this be useful?
1) Security - it can be used to audit what functions can possibly be
called from some entry point (ie verifying that no network functions
are accessed)
2) Rentrant Code Checks - it could verify that no global state is
accessed (from functions (or objects with a alteration to the
proposal))
3) Real-time Safety - it can check what system/library calls are made
to verify that latency goals can be meet.

Real-time safety is the primary motivation for me, after seeing some
of the issues that exist within the linux audio community.
The primary issue is that it is very easy to mistakenly create
non-real-time safe code and it is possible for this mistake to go
unnoticed for a large period of time.
Some simple mistakes that can be found are calls to locking mutexes,
calls to memory allocation, IO, and other blocking functions.
With static analysis many of these issues can be found and taken care of.

This analysis would likely need to be supplemented with some
blacklist/whitelist for functions not defined in the analyzed source
ie libraries.

Can the annotations/attributes in clang be extended in this manner
(ignoring example syntax)?
Can attributes be assigned to functions without altering the source
(the library case)?
Does this sound like a good/feasable summer of code project?

General comments are welcome.

--Mark McCurry



More information about the cfe-dev mailing list