À quels problèmes l'analyse de graphe d'appel statique déchiffre-t-elle?

Question

Quels problèmes trouverait-on en utilisant l'analyse statique des appels sur un programme? FxCop utilise l'analyse statique des graphes d'appel, quels problèmes trouve-t-elle en utilisant cette technique?

http://msdn.microsoft.com/library/bb429476.aspx
http://en.wikipedia.org/wiki/Callgraph

Toutes mes excuses pour mon manque de connaissances, j'ai trouvé quelques informations via Google, mais craignent qu'il est largement incomplète. Merci!

Answer 1

Voici ce que j'ai trouvé:

Call-graphiques sont utilisés pour détecter les problèmes en ce qui concerne l'exécution du programme, la violation des lignes directrices recommandées et d'éventuelles attaques d'injection de code.

En créant un graphique des relations d'appel entre diverses méthodes, il est facile de voir où les problèmes peuvent survenir à certains moments lorsque certaines méthodes sont appelées ou comment certaines méthodes sont appelées. Il est facile de voir quand une procédure/fonction peut être en violation des directives telles que le maintien de la modularité du code. Il est facile de voir où un code malveillant pourrait éventuellement être injecté à certains moments à cause de ces relations d'appel et de la façon dont elles sont structurées. De cette façon, les graphiques d'appel fournissent un contexte à l'analyse statique, produisant des résultats plus précis.

Puisque FxCop utilise des graphiques d'appels statiques, il est seulement capable de spéculer sur ce qui précède dans une certaine mesure.

Answer 2

En soi, l'appel-graphique est juste cela; il n'y a pas de "mauvais" graphiques d'appel (sauf si vous avez une vérification de style interdisant la récursivité). Le vrai problème est que pour comprendre comment le code à un point du programme peut être problématique, vous devez généralement comprendre la forme du monde (quelles sont les structures de données, quelles valeurs elles peuvent contenir, quelles relations elles peuvent avoir). avoir) au moment où ce point de code est actif. Le graphique d'appel montre comment l'exécution peut atteindre le point d'intérêt du code, et tout le code le long de ce chemin du graphe d'appel définit le contexte d'exécution du code. Cela permet à l'analyseur statique de produire une analyse «contextuelle», ce qui donne des réponses beaucoup plus précises.

Cela conduit à un deuxième problème: comment obtenir un graphique d'appel précis? Si vous avez un appel direct de B à partir de A, il est facile d'écrire «A appelle B» et de sentir que c'est un fait précis. Mais si A fait un appel à travers un pointeur indirect (pouvez-vous dire envoi de méthode virtuelle?) Tout à coup il n'est pas si clair exactement qui appelle A; vous finissez par A-pourrait-appeler-B1, A-pourrait-appeler-B2, ... Lequel A appelle réellement dépend en fait du contexte dans lequel A s'exécute ... oups, vous avez besoin du graphique d'appel pour fabriquer le graphique d'appel. Le genre de bonnes nouvelles est que vous construisez le graphique d'appel en partant du bas: "Je sais que c'est certainement vrai, donc cela doit sûrement être vrai". Aux endroits où l'analyseur ne peut pas le comprendre, il fait généralement une supposition conservatrice: ("Tous ces appels pourraient être possibles, je ne peux pas les exclure"). Ce conservatisme est l'une des principales causes de la précision de votre analyseur statique.