[cfe-dev] GSoC 2012: Static Function Blacklisting

Matthieu Monrocq matthieu.monrocq at gmail.com
Thu Mar 29 11:23:14 PDT 2012


Le 29 mars 2012 18:51, Michael Han <Michael.Han at autodesk.com> a écrit :

> 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
>
>
I agree with David that a blacklist approach is doomed to failure because
of the opacity, in general, of function declarations. A whitelist... would
just be a maintenance nightmare.

On the other hand, for attributes, there is the possibility of specifying
that attributes should appear on the first declaration of a function, and
that subsequent declarations (and definitions) cannot *add* to the list
(they may specify less).

You could perhaps put in place a "property" system:
__attribute__((__property__("reentrant", "realtime")), which though an
extension to Clang is perhaps sufficiently generic to warrant consideration
(you would have to check with Douglas Gregor and Ted Kremenek at least).
And specify that for this attribute, a subsequent declaration/definition
cannot gain a property (it might be looser).

Then, since it would be recorded in the function type, you could statically
check that it works.

One thing to consider, however, is the difficulty to do so for template
functions. This is, in essence, similar to `noexcept`, and the Standard
specifies a form `noexcept(boolean-expression)` to allow expressing
conditions on template functions/methods. This makes things a bit harder,
no doubt.

Perhaps that templated code should be kept out of the loop in your project,
or at least, dependant annotations.

-- Matthieu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20120329/7e3eca16/attachment.html>


More information about the cfe-dev mailing list