C#/Java: Content based model generation improvements. #17363
Conversation
76b9cdd
to
8473b8c
Compare
8473b8c
to
412551f
Compare
b5456a3
to
b7d00a4
Compare
4521dfd
to
30f3923
Compare
30f3923
to
0abc08c
Compare
|
DCA looks good! |
| exists(ContentSet head, PropagateContentFlow::AccessPath tail | | ||
| head = ap.getHead() and | ||
| tail = ap.getTail() and | ||
| (mentionsField(tail) or isField(head)) |
There was a problem hiding this comment.
nit: Remove parens and replace preceding and with |.
| * detection instead, as reads and stores would use a significant | ||
| * part of an objects internal state. | ||
| */ | ||
| private class ContentDataFlowSummaryTargetApi extends DataFlowSummaryTargetApi { |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
| exists(PropagateContentFlow::AccessPath tail, ContentSet head | | ||
| head = path.getHead() and | ||
| tail = path.getTail() and | ||
| ( |
There was a problem hiding this comment.
Same stylistic remark as above.
| hasSyntheticContent(read) and | ||
| hasSyntheticContent(store) and | ||
| ( | ||
| step(t1, read, t2, store) |
There was a problem hiding this comment.
Shouldn't we restrict to syntPathEntry here? Otherwise it looks like we will compute O(n^2) paths.
There was a problem hiding this comment.
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).
| * if both of these methods exist. | ||
| */ | ||
| pragma[nomagic] | ||
| predicate acceptReadStore( |
There was a problem hiding this comment.
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));
There was a problem hiding this comment.
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?
If we apply the content based model generator to
Many of these models are undesirable, primarily because of one of the following reasons
With the changes proposed in this PR, applying the content based model generator to
The issues are addressed in the following way:
getandsetmethods that uses a private backing fieldX. In this case we would like to generate the summariesset : Argument[0] -> Argument[this].SyntheticField[X]andget : Argument[this].SyntheticField[X] -> ReturnValue, but we only want to do this in case both methods exists. If only thegetmethod 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.