Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Dataflow: Add support for call context restrictions on sources/sinks. #6932

Merged
merged 5 commits into from
Nov 2, 2021

Conversation

aschackmull
Copy link
Contributor

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.

@MathiasVP
Copy link
Contributor

MathiasVP commented Oct 21, 2021

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 FeatureHasSourceCallContext)?

@aschackmull
Copy link
Contributor Author

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 FeatureHasSourceCallContext)?

Short answer: No.
Slightly longer answer: What you're considering won't work, since the assumed call contexts are quantified outside the generated paths, i.e. the paths are pluggable into any call context, so this rules out endpoints with specific call contexts, which you would need to match up to properly chain configs.


/** A flow configuration feature for use in `Configuration::getAFeature()`. */
class FlowFeature extends TFlowFeature {
abstract string toString();
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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() }
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wonder if fieldFlowBranchLimit should also be made a feature (only trouble is, we would have to limit the possible values up-front).

Comment on lines +3462 to +3473
sc instanceof SummaryCtxNone or
cc instanceof CallContextNoCall
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would be nice with a comment about why this is only relevant for FeatureEqualSourceSinkCallContext.

@aschackmull aschackmull force-pushed the dataflow/flow-features branch from 49e7e35 to 6eabb61 Compare October 27, 2021 11:58
@aschackmull aschackmull requested a review from a team as a code owner October 27, 2021 11:58
@github-actions github-actions bot added the Ruby label Oct 27, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants