[cfe-dev] Clang GenericTaintChecker limitations

[Divya Muthukumaran via cfe-dev]

Hi Artem,

On Fri, Aug 12, 2016 at 8:51 AM, Artem Dergachev <noqnoqneo at gmail.com>
wrote:

> All right, i see. Because the analyzer failed to initialize the global,
> upon analyzing get_item() as first command, it fails to inline get_item()
> because of the potentially infinite loop inside it. Then, upon analyzing
> get_item() after put_item(), it recalls that get_item() is too complex to
> inline, and skips the call as if no body is available (models the call
> "conservatively"). The return value of get_item() is conjured up, and
> therefore carries no taint.
>
> So, long story short, this code is already too complex for our analyzer.
> Our default options are tweaked for maximum bugs-per-second in general
> case, but maybe we could make an option to analyze deeply, no matter how
> much time it takes.
>
>
Ah Ok. Thanks for looking into this. If I had to do this bespoke for
analyzing my code, what would I have to change? Or is it too complex?



> For the reference, here's my test.c file and the way i patched
> GenericTaintChecker when tried to mimic your approach. I run it with
> debug.ExprInspection and without debug.TaintGeneric and produce a trimmed
> exploded graph with -analyzer-viz-egraph-graphviz -trim-egraph (the last
> option trims the exploded graph to keep only the path to the warning, which
> is in our case the debug.ExprInspection warning that says that the value
> we're analyzing is conjured rather than modeled properly; i added an extra
> variable to reduce the possible paths).
>
> On 8/11/16 8:07 PM, Divya Muthukumaran wrote:
>
>> Hi Artem,
>>
>> I'm not sure what the protocol is for posting code here. I was trying to
>> abstract the behaviour of a well-known
>> in memory key-value store into the following program so this may be too
>> much code to post here. Let me know
>> if you want me to give you an even more abstract version. And again,
>> thanks for your help!
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20160812/d7f0c6d6/attachment.html>