[cfe-dev] GSoC 2012: Static Function Blacklisting

[Anna Zaks]

As was mentioned before, it's important to decide how you will deal with multiple translation units.

For example, you have: foo() that calls bar() that calls m(). Each is defined in its own translation unit. m() calls a non-reentrant function and only foo is annotated as "may_only_call(reentrant)".
The options here are:
 - The user should annotate all of the functions as "may_only_call(reentrant)". Bad for the user.
 - The analyzes is done in llvm, which has an ability to link in code from different translation units. That's not what the current static analyzer is doing, so would this be a separate tool?
 - Come up with a framework of storing the intermediate results between the analyzes of different translation units. Most likely, this is the direction the current clang static analyzer will take at some point; however, this is a challenging problem.
 - Only perform the check for the callees  that are either explicitly annotated or have definitions is in the current translation unit. Unless you want to be ambitious, this is probably your best option.

Also, I think both "may_only_call" and "does_not_call" annotations would be useful. One can imagine the second being less maintenance for security checking (as in "does not perform IO/accesses network").

Cheers,
Anna.
On Mar 30, 2012, at 7:04 AM, Mark McCurry wrote:

>>> 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.
> 
> As of so far my searching has only resulted in finding the standard
> set of __attribute__() declarations defined in clang.
> ie
> http://clang-analyzer.llvm.org/annotations.html
> http://clang.llvm.org/docs/LanguageExtensions.html
> 
> Are these the annotations you are referring to or have I overlooked something?
> ie is there an __attribute__(annotate()) ?
> 
>> 
>>> 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.
> 
> I am not too sure how ambitious to be with the scope of this project,
> but I certainly do intend to make it an easily extended system, such
> that it will apply to a variety of use cases.
> 
> --Mark
> 
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev