Dataflow: Add support for call context restrictions on sources/sinks. #6932
Conversation
|
Is it correct to conclude that this PR makes it possible to chain together multiple configurations without losing call the context (i.e., by using |
Short answer: No. |
|
|
||
| /** A flow configuration feature for use in `Configuration::getAFeature()`. */ | ||
| class FlowFeature extends TFlowFeature { | ||
| abstract string toString(); |
No abstract predicates in user-visible classes.
| * Implies both of the above and additionally ensures that the entire flow | ||
| * path preserves the call context. | ||
| */ | ||
| FlowFeature getAFeature() { none() } |
I wonder if fieldFlowBranchLimit should also be made a feature (only trouble is, we would have to limit the possible values up-front).
| sc instanceof SummaryCtxNone or | ||
| cc instanceof CallContextNoCall |
I think this logic warrants a comment.
| @@ -3613,7 +3663,8 @@ private predicate pathIntoCallable( | |||
| sc = TSummaryCtxSome(p, ap) | |||
| or | |||
| not exists(TSummaryCtxSome(p, ap)) and | |||
| sc = TSummaryCtxNone() | |||
| sc = TSummaryCtxNone() and | |||
| not config.getAFeature() instanceof FeatureEqualSourceSinkCallContext | |||
Would be nice with a comment about why this is only relevant for FeatureEqualSourceSinkCallContext.
This adds support for restricting the flow paths returned by the data flow library in 3 ways:
FeatureHasSourceCallContext:Assume that sources have some existing call context to disallow
conflicting return-flow directly following the source.
FeatureHasSinkCallContext:Assume that sinks have some existing call context to disallow
conflicting argument-to-parameter flow directly preceding the sink.
FeatureEqualSourceSinkCallContext:Implies both of the above and additionally ensures that the entire flow
path preserves the call context.
The text was updated successfully, but these errors were encountered: