[Soot-list] Call graphs and excluding libraries

[John A Toman]

Hello!

I'm trying to use Soot for an interprocedural analysis but I'm having trouble getting a callgraph. I'm analyzing a web application that depends on several libraries, each of which have their own dependencies. These dependencies aren't interesting to my analysis but without them I can't seem to get a reliable call-graph.

I'm invoking Soot as follows:

java -cp ./soot-trunk.jar:./myanalysis -pp -soot-class-path /path/to/application/classes:/paths/to/app/library/jars -no-bodies-for-excluded -x 'freemarker' -w -p cg.cha enabled:false -p cg.spark enabled:true,verbose:true -p wjtp.myanalysis on com.acme.DummyMain -allow-phantom-refs

where freemarker is the package name of the library I'm not interested in (I exclude the freemarker.jar from the soot class path in the above invocation too)[

With these options Spark builds a callgraph, but the results are strange. For instance, the possible types analysis dies because (as far I as can tell) it thinks that a call to <java.security.AccessController: java.lang.Object doPrivileged(java.security.PrivilegedAction)>

potentially resolves to <org.apache.commons.logging.LogFactory$1: java.lang.Object run()>.

Without the -no-bodies-for-excluded option Spark churns for a while until it reaches some part of the Freemarker library that relies on Jython. However, the Jython jar also has unmet dependencies which cause Spark to choke...

In short: how do I configure Soot to ignore missing/uninteresting library calls with the least effort possible?

Thanks!

[Steven Arzt]

Hi John,

 

That’s strange, your command-line looks good to me in principle. Your exclusion is not correct, you have to provide package or class names which would probably be something like com.freemarker.*. Soot does not search for substrings here, but for packages. Another option would be not to explicitly exclude these classes, but simply not have them on the Soot classpath. In that case, they will automatically become phantom classes.

 

The other question is whether you really want to prepend the JVM’s classpath to your Soot classpath using –pp if you are ok with ignoring libraries at some other place. Is there a specific reason for not excluding the JDK as well? As recommended above, I would just remove it from the Soot classpath.

 

The strange call edge you are experiencing doesn’t sound right to me. Can you provide a minimal working example that provides the same kind of callgraph with similar wrong edges, but has a more manageable size for debugging?

 

Best regards,

  Steven

[John A Toman]

Hi Steven,

The freemarker library actually does put all its classes in the top-level freemarker.* package so I believe that my -x usage is correct.

As for your first point, I have been including all of the libraries (including the JDK libraries) because my first attempts to use Soot without them failed with missing class errors; I inferred that Soot would not function properly unless I included all classes that could be potentially referenced by the program being analyzed. If I understand you correctly there is some combination of flags and classpaths that will instruct Soot to simply ignore library classes (including the JDK). If this is true, what is the behavior of, say, the IFDS solver in the presence of these ignored libraries? If an application class calls into library method foo() that has been excluded what does Soot do with that call?

With regards to the strange call resolution, that problematic call statement appears to be in a library class that I wish to exclude anyway so the problem may become moot if I can figure out the above problem. Although it may still be a bug :)

Thanks!

John

[Steven Arzt]

Hi John,

 

If the package names are freemarker.*, it’s important to put the asterisk into the exclusion option on the Soot command line as well. Otherwise, Soot will assume that there is a single class called “freemarker” which you would like to exclude.

 

If your code under analysis references a class which is not on the Soot classpath and –allow-phantom-refs is used, this class will automatically be considered as a phantom. Nothing will be loaded, because Soot cannot know where to load it from. If you exclude a class, its structure (method signatures, etc.) will be loaded, but it will be marked as a library class. If you specify –no-bodies-for-excluded, Soot will not load any bodies for those classes, even if some code tries to access the body. Therefore, not putting the class on the classpath is the most rigorous option for guaranteeing that it will not be loaded.

 

Your analysis then needs to deal with such cases. If you have a call to a.foo() and the type of the variable “a” refers to a phantom class, there will not be a callgraph edge from the call site to anywhere and thus there will not be an IFDS call edge. There will, however, still be an IFDS call-to-return edge in which you can detect that you are dealing with such an exclusion case and apply e.g., an external library model to make up for the information loss. Depending on your analysis, you might also be able to simply ignore the effects of the method call on your data flow abstraction, that’s something you as the analysis designer need to decide.