<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div>Hi, Byoungyoung. I'm not sure I quite understand your objection. If you have this:</div><div><br></div><div><blockquote type="cite">A *a = new B();</blockquote></div><div><br></div><div>where 'a' is a global variable, we have no guarantee that it is <i>still</i> the same 'B' object when we actually analyze any specific function. After all, some other function could have an 'a = nullptr;' pretty much anywhere. Without cross-translation-unit, whole-program analysis, we can't make a definite guarantee that 'a' points to the same object for the entire lifetime of the program.</div><div><br></div><div>We currently don't model this "correctly" even if you use a constant pointer:</div><div><br></div><div><blockquote type="cite">A * const a = new B();</blockquote></div><div><br></div><div>because we do per-function analysis, and by the time we've entered any function body, 'a' has already been initialized. We ought to treat it the same as this:</div><div><br></div><div><blockquote type="cite">B a;</blockquote></div><div><br></div><div>which is probably what you should be doing anyway if you really have a global object that lasts for the lifetime of the program. Using 'new' may not be safe during static initialization (i.e. before 'main'), and if the constructor takes (tainted?) arguments, then you're potentially subject to the <a href="http://www.parashift.com/c++-faq/static-init-order.html">static initialization order fiasco</a>.</div><div><br></div><div>Currently, the only sort of global values we handle are constant integers. The general issue is tracked internally at Apple by <<a href="rdar://problem/11720796">rdar://problem/11720796</a>> and a similar specific case is on our public bug tracker at <a href="http://llvm.org/bugs/show_bug.cgi?id=13673">http://llvm.org/bugs/show_bug.cgi?id=13673</a>.</div><div><br></div><div>Our "todo list" of sorts would be our bug-tracking system at <a href="http://llvm.org/bugs">http://llvm.org/bugs</a>. If you have an entire self-contained concrete example that you believe should work, please file a bug.</div><div><br></div><div>Sorry for the negative answers,</div><div>Jordan</div><div><br></div><div>P.S. Our handling of 'new' in particular is fairly weak right now; there's some infrastructure work discussed on the bug tracker at <a href="http://llvm.org/bugs/show_bug.cgi?id=12014">http://llvm.org/bugs/show_bug.cgi?id=12014</a> that ought to result in us correctly tracking the types of objects that come from 'new'.</div><div><br></div><br><div><div>On Sep 19, 2012, at 12:09 , Byoungyoung Lee <<a href="mailto:lifeasageek@gmail.com">lifeasageek@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">I really appreciate your help! With that ipa.txt documentation, now I<br>understand how Clang IPA is working. The reason it's not tainted on my<br>test program before was that I haven't specified the control flows<br>between class allocation routines and tainting routines. After giving<br>the control flows specifically to these routines, it works great!<br><br>But still, it seems like current IPA does not handle the global<br>constructors? i.e. when the constructor is invoked as it is declared<br>as the global variables (A *a = new B(); // "a" is the global<br>variable). Since there's no explicit control flows to this<br>constructors (I think this will be compiled into .ctors section for<br>ELF binaries and invoked by loaders), current IPA analyzer cannot<br>handle this case I guess. Is this a sort of TODO-list or could you<br>direct me some documentations mentioning this?<br><br>Thanks,<br>Byoungyoung<br><br>On Tue, Sep 18, 2012 at 9:36 PM, Anna Zaks <<a href="mailto:ganna@apple.com">ganna@apple.com</a>> wrote:<br><blockquote type="cite"><br>On Sep 18, 2012, at 5:15 PM, Byoungyoung Lee <<a href="mailto:lifeasageek@gmail.com">lifeasageek@gmail.com</a>> wrote:<br><br><blockquote type="cite">Hello Anna,<br><br>Thanks for your answer, Anna. I just wanted to make sure that there's<br>no current support for handling virtual function calls for the taint<br>analysis.<br><br>I'm thinking to implement the taint-analysis which supports the<br>virtual function calls. When Checker captures the statement like A *a<br>= new B(); // A is a parent class of B<br>, I would re-assign a's clang::Decl with class B so that following<br>virtual function calls would be made using class B's declarations. I'm<br>wondering this approach would be working? Or could you suggest me<br>better ways to handle this issue?<br></blockquote><br>The logic for reasoning about polymorphism should be done inside the analyzer core engine as it is not specific to the taint checker. Essentially, when 'a->foo()' is called, we will check if 'a' points to the object 'B' at runtime. If yes, we would inline the call for B's implementation of 'foo'. Jordan has started on adding the reasoning about polymorphism to the analyzer. I am not sure why this particular case is not handled yet, but there can be a lot of edge cases one might need to handle.<br><br>You can read clang/docs/analyzer/IPA.txt for more information on how we deal with inter procedural analyses (including polymorphism or dynamic dispatch). This is one of the more complex areas of the analyzer.<br><br>Cheers,<br>Anna.<br><blockquote type="cite"><br>Thanks,<br>Byoungyoung<br><br>On Tue, Sep 18, 2012 at 4:35 PM, Anna Zaks <<a href="mailto:ganna@apple.com">ganna@apple.com</a>> wrote:<br><blockquote type="cite">Hi Byoungyoung,<br><br>Taint analysis relies on the general clang infrastructure for propagating the taint through/into virtual (and regular) calls. Currently, the static analyzer core is not smart enough to de-virtualize the call in this example. However, we are actively working on better IPA support for C++.<br><br>Said that, we would only resolve the function if the analyzer has enough information to de-virtualize. By default (when not enough info is available), the analyzer core would treat the call as opaque. This is the desired behavior. Even for the taint checker, you might only want to propagate the taint into the specific function if you are sure that there is a path on which that would occur.<br><br>Cheers,<br>Anna.<br><br>On Sep 18, 2012, at 12:47 PM, lifeasageek <<a href="mailto:lifeasageek@gmail.com">lifeasageek@gmail.com</a>> wrote:<br><br><blockquote type="cite">Hello,<br><br>I'm playing with Checker to implement taint-analysis for C++<br>applications. Refering GenericTaintChecker.cpp, I've implemented my<br>simple taint-analysis but it seems like tainted symbols are not<br>propagated for virtual function calls and Checker cannot handle the<br>C++ class runtime polymorphism?<br><br>From my understanding, when checker sees virtual function call<br>expression, it only knows the declared class type, not the actually<br>allocated class type. In the example code below I've written, when<br>Checker sees g_table->append(), it only knows g_table is the member<br>function of ShapeTable, not of ShapeTableArray.<br><br>Could you tell me how to handle this C++ runtime polymorphism issues?<br>Can I force it to visit all the possible (or concrete) virtual<br>functions when Checker sees the virtual function calls?<br><br>------------------------------------------------------<br>class ShapeTable {<br>public:<br> virtual void append(int value) = 0;<br> virtual int search(int value) = 0;<br> ShapeTable();<br>};<br><br>class ShapeTableArray :public ShapeTable {<br>public:<br> ShapeTableArray() : curPosition(0) {<br> entries = (int*)malloc(sizeof(int) * MAX_ENTRIES);<br> }<br><br> void append(int value) {<br> entries[curPosition++] = value;<br> return;<br> }<br><br> int search(int value) {<br> for (int i=0; i<MAX_ENTRIES; i++) {<br> if (entries[i] == value)<br> return i;<br> }<br> return NOT_AVAILABLE;<br> }<br>private:<br> int *entries;<br> int curPosition;<br>};<br><br>int main(void){<br> ShapeTable *g_table = new ShapeTableArray();<br> g_table->append(0x1234);<br> g_table->search(0x1234)<br><br>}<br><br>Thanks,<br>Byoungyoung<br><br><br><br><br>--<br>View this message in context: <a href="http://clang-developers.42468.n3.nabble.com/Checker-taint-analysis-with-virtual-functions-runtime-polymorphism-handling-tp4026757.html">http://clang-developers.42468.n3.nabble.com/Checker-taint-analysis-with-virtual-functions-runtime-polymorphism-handling-tp4026757.html</a><br>Sent from the Clang Developers mailing list archive at <a href="http://Nabble.com">Nabble.com</a>.<br>_______________________________________________<br>cfe-dev mailing list<br><a href="mailto:cfe-dev@cs.uiuc.edu">cfe-dev@cs.uiuc.edu</a><br>http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev<br></blockquote><br></blockquote></blockquote><br></blockquote><br>_______________________________________________<br>cfe-dev mailing list<br><a href="mailto:cfe-dev@cs.uiuc.edu">cfe-dev@cs.uiuc.edu</a><br>http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev<br></blockquote></div><br></body></html>