[cfe-dev] GSoC 2012: Static Function Blacklisting

[Michael Han]

Hi Mark,

We happen to write a very similar tool that we use in Autodesk to help us enforce certain coding standard on a large code base. For example, we have functions that annotated as reentrant which has two constraints: it should not access any named declared static data, and it should only call functions that also annotated as reentrant. The tool is basically a recursive AST visitor that checks the AST properties (call graph, variable declaration and access pattern), and we don't do any analysis at the moment but still quite useful to find some bugs.

Some comments on your questions

> Can the annotations/attributes in clang be extended in this manner 
> (ignoring example syntax)?
You can add any attributes you like but to get them up stream would be hard as adding attributes is adding language extension and Clang definitely doesn't want to include arbitrary domain specific attributes. If you take a look at the attribute definition file, the attributes there are either from standard, or Clang built in, or already available in GCC (like thread safe annotations). One idea of extending attribute system is to take a look at the Clang "annotate" attribute which you can embedded arbitrary literals so technically you can get your own annotation DSL inside the "annotate" attribute. 

> Can attributes be assigned to functions without altering the source 
> (the library case)?
It is possible and what we did in our tool is to redeclare the library / 3rd party functions with annotated attributes, and in Clang Sema, merge the attributes into function types. 

> Does this sound like a good/feasable summer of code project?
It should be very useful as there are many low-hanging fruits out there that could be reached by this. A more ambitious goal would be to extend Clang by providing a framework to encode the attributes and the "rules" (e.g. a white/black call list of a function) so clang users could add their own domain specific checks without reinvent the wheel again.

Cheers
Michael

-----Original Message-----
From: cfe-dev-bounces at cs.uiuc.edu [mailto:cfe-dev-bounces at cs.uiuc.edu] On Behalf Of David Chisnall
Sent: Thursday, March 29, 2012 2:18 AM
To: Mark McCurry
Cc: cfe-dev at cs.uiuc.edu
Subject: Re: [cfe-dev] GSoC 2012: Static Function Blacklisting

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


_______________________________________________
cfe-dev mailing list
cfe-dev at cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev