[cfe-dev] GSoC 2012: Static Function Blacklisting

[David Chisnall]

Hi Mark,

The general idea is something that's definitely useful.  I wrote a hacky ad-hoc tool with libclang to perform this kind of check for the xlocale code in FreeBSD and ensure that none of the reentrant functions was touching any global state or calling the non-reentrant versions and it would be great to see it done properly and generalised.

A few thoughts about the design though:

I am not convinced by the annotations.  A does-not-call-X attribute doesn't seem to be sufficiently expressive for this kind of test.  You'd need to whitelist dozens of functions at each call.  I would rather something that allowed you to tag functions with attributes like 'reentrant', or 'realtime' (the annotation attribute could be used here) and then another like __attribute__((may_only_call(reentrant))) to be applied to a function, that would only allow it to call functions whose declarations are marked as reentrant.  

Currently, the analyser does not perform any checking between compilation units.  That means that with your example, if bar() and func() were in different compilation units then the analyser would be quiet.  By only calling annotated functions the compilation unit containing func() would warn you if bar() did not have the required attribute or (if it did) the compilation unit containing bar() would warn you if foo() did not have the required attribute.

You might want to take a look at the thread safety annotations (holds lock and friends) for some inspiration.

David

On 28 Mar 2012, at 21:15, Mark McCurry wrote:

> 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
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev