C#/Java: Content based model generation improvements.

[michaelnebel]

If we apply the content based model generator to

• The Java SDK we get around 80k models.
• The .NET 8 Runtime we get around 500k models.

Many of these models are undesirable, primarily because of one of the following reasons

1. Due to the lack of type constraints, we get lots of models as "data" could have originated from lots of different implementations (and conversely for stores).
2. A model reads from a synthetic field that no other model writes to (and conversely).

With the changes proposed in this PR, applying the content based model generator to

• The Java SDK we get around 4k models.
• The .NET 8 Runtime we get around 5k models.

The issues are addressed in the following way:

1. We make a rough filtering on the APIs: Content based model generation is only considered for an API if the formula below holds for that particular API (the reasoning behind this is also listed as a code comment and the magic numbers 2 and 3 in the formula below are definitely up for debate. If another approach should be taken - e.g. maybe something like filtering APIs based on input and return types then we can discuss this as well). Applying this constraint to the target APIs from the Java SDK removes approximately 2% og the possible target APIs for summary generation, which indicates that this is not an especially invasive constraint.
   • # summaries <= 2 * #number of parameters + 3
2. We only include a summary for an API that reads or stores into a synthetic field, if there exists a "chain" of APIs with summaries such that data originates from non-synthetic content and targets non-synthetic content. The canonical example for this are get and set methods that uses a private backing field X. In this case we would like to generate the summaries set : Argument[0] -> Argument[this].SyntheticField[X] and get : Argument[this].SyntheticField[X] -> ReturnValue, but we only want to do this in case both methods exists. If only the get method exists, then it retrieves information from a "dead" synthetic field. The synthetic chaining is currently based on access path equality but that restriction could potentially be loosened a bit, but I suspect that this only has limited impact on the generated summaries.

Note that the changes in this PR doesn't change the production version of the model generation and only impacts model generated by the recently introduced --with-contentbased-summaries.
Further changes are still required for this to be production ready, but the changes in this PR are self contained.

[michaelnebel]

DCA looks good!

[hvitved]

Some initial comments.

[hvitved]

Alternatively, we could make the restriction per parameter. I.e., if a method has only one summary for Argument[0] then include it, but if it has more than, say 3, summaries for Argument[1] then exclude those.

[michaelnebel]

Yes, that could also be interesting.
Would it be acceptable if I do that experiment as a follow up?
As it is now we "only" exclude approximately 2% of all the possible target APIs with this limitation.

[hvitved]

Yes!

[hvitved]

Shouldn't we restrict to syntPathEntry here? Otherwise it looks like we will compute O(n^2) paths.

[michaelnebel]

Uh - this was intended as a helper predicate, but it looks like we need to fold it into the declarations where it is used to avoid the O(n^2).

[hvitved]

I wonder if it is simply enough to say that we will include a synthetic field if it is part of some input specification and part of some output specification. That should also handle cases such as

setAll // input: Argument[0], output: ReturnValue.SyntheticField[Foo].Element
get // input: Argument[0].SyntheticField[Foo], output: ReturnValue

list = setAll("taint");
x = list[0];
sink(get(x));

[michaelnebel]

I also thought about that as a possible "improvement" (instead of using "path" equality we could "hash" paths with synthetics (basically just print the synthetics in the order they are shown in the path and then compare that)). This would allow path continuations as the one you mention there.
Is it acceptable that we attempt this as a follow up?

[hvitved]

I was actually thinking of something even simpler where the order is not taken into account, but yes follow-up is fine.

[michaelnebel]

We could also try without order; However, I am quite sure that we need the "chaining" logic. It turned out that it is not uncommen that we produce summaries like SyntheticField[A] -> SyntheticField[A] (without other mentions on the synthetic field A) or SyntheticField[A] -> SyntheticField[B] and SyntheticField[B] -> SyntheticField[A], if we don't restrict the use of synthetics.

[hvitved]

"internal" instead of "dead"?

[michaelnebel]

Sure! I will add a commit to the re-factor PR that changes this.