-
Notifications
You must be signed in to change notification settings - Fork 0
Expand file tree
/
Copy pathGraphPathStateSearch.qll
More file actions
284 lines (266 loc) · 11.2 KB
/
GraphPathStateSearch.qll
File metadata and controls
284 lines (266 loc) · 11.2 KB
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
/**
* Like `GraphPathSearch`, this file defines a module for efficiently finding paths in a directional
* graph using a performant pattern called forward-reverse pruning.
*
* Additionally, this module is designed to track state through the paths it is looking for. For
* instance, we could use this graph to find recursive functions, which requires knowing how an end
* node was reached from a start node (the state).
*
* Like `GraphPathSearch`, this module uses forward-reverse pruning, wihch is a pattern that is
* useful for efficiently finding connections between nodes in a directional graph. In a first pass,
* it finds nodes reachable from the starting point. In the second pass, it finds the subset of
* those nodes that can be reached from the end point. Together, these create a path from start
* points to end points.
*
* As with the other performance patterns in qtil, this module may be useful as is, or it may not
* fit your needs exactly. CodeQL evaluation and performance is very complex. In that case, consider
* this pattern as an example to create your own solution that fits your needs.
*/
private import qtil.parameterization.SignatureTypes
private import qtil.parameterization.Finalize
/**
* Implement this signature to define a graph, and a search for paths within that graph tracking
* some state, using the `GraphPathStateSearch` module.
*
* ```ql
* module MyConfig implements GraphPathStateSearchSig<Node> {
* class State extends ... { ... };
* predicate start(Node n1) { ... }
* predicate edge(Node n1, Node n2) { ... }
* predicate end(Node n1) { ... }
* }
* ```
*
* To flow without state, use `GraphPathSearchSig` instead.
*/
signature module GraphPathStateSearchSig<FiniteType Node> {
/**
* The state to be tracked through the paths found by this module.
*
* For example, if searching for recursive functions, this class might be defined as:
*
* ```ql
* class State = Function;
* ```
*
* The `edges` predicate defined in this signature module decides how to forward this state, so
* the state may change as the path is traversed.
*/
bindingset[this]
class State;
/**
* The nodes that begin the search of the graph, and the starting state for those nodes.
*
* For instance, if searching for recursive functions, this predicate might hold for a Function
* and its state may be the Function itself.
*
* Ultimately, only paths from a start node to an end node will be found by this module.
*
* In most cases, this will ideally be a smaller set of nodes than the end nodes. However, if the
* graph branches in one direction more than the other, a larger set which branches less may be
* preferable.
*
* The design of this predicate has a great effect in how well this performance pattern will
* ultimately perform.
*/
predicate start(Node n1, State s1);
/**
* A directional edge from `n1` to `n2`, and the state that is forwarded from `n1` to `n2`.
*
* This module will search for paths from `start` to `end` by looking following the direction of
* these edges.
*
* As an example state transformation, a maximum search depth could be tracked at each edge and
* the new state would be the old state with the depth incremented by one. Alternatively, if
* searching for recursive functions, the state could be the starting function, and this edge
* relation would forward that function unchanged.
*
* The design of this predicate has a great effect in how well this performance pattern will
* ultimately perform.
*/
bindingset[s1]
bindingset[s2]
predicate edge(Node n1, State s1, Node n2, State s2);
/**
* The end nodes of the search, if reached with the given state.
*
* For instance, if searching for recursive functions, this predicate would likely hold when a
* function node is reached with the state being same function declaration (indicating flow from
* the start function to itself).
*
* Ultimately, only paths from a start node to an end node will be found by this module.
*
* The design of this predicate has a great effect in how well this performance pattern will
* ultimately perform.
*/
bindingset[s1]
predicate end(Node n1, State s1);
}
/**
* A module that implements an efficient search for a path that satisfies specified stateful
* constraints within a custom directional graph from a set of start nodes to a set of end nodes.
*
* For example, this module can be used to detect loops in the graph (perhaps to find recursive
* functions) by setting the "state" to be the start node, forwarding that state unchanged on each
* edge, and considering a node to be an end node if it is reached with itself as the state.
* Alternatively, the state could be used to track a maximum search depth, with a start state of
* zero that is incremented at each edge, and where the edge relation does not hold beyond a certain
* depth.
*
* To show discovered paths to users, see the module `CustomPathStateProblem` which uses this module
* as * its underlying search implementation.
*
* This module uses a pattern called "forward reverse pruning" for efficiency. This pattern is
* useful for reducing the search space when looking for paths in a directional graph. In a first
* pass, it finds nodes reachable from the starting point. In the second pass, it finds the subset
* of those nodes that can be reached from the end point. Together, these create a path from start
* points to end points.
*
* To use this module, provide an implementation of the `GraphPathSearchSig` signature as follows:
*
* ```ql
* module Config implements GraphPathSearchSig<Person> {
* class State extends Something { ... };
* predicate start(Person p, State s) { p.checkSomething() and s = p.getSomeStartValue() }
* predicate edge(Person p1, State s1, Person p2, State s2) { p2 = p1.getAParent() and s2 = s1.next() }
* predicate end(Person p, State s) { p.checkSomethingElse() and s.isValidEndState() }
* }
* ```
*
* The design of these predicate has a great effect in how well this performance pattern will
* ultimately perform.
*
* The resulting predicate `hasPath` should be a much more efficient search of connected start nodes
* to end nodes than a naive search (which in CodeQL could easily be evaluated as either a full
* graph search, or a search over the cross product of all nodes).
*
* ```ql
* from Person p1, State s1, Person p2, State s2
* // Fast graph path detection thanks to forward-reverse pruning.
* where GraphPathStateSearch<Person, Config>::hasPath(p1, s1, p2, p2)
* select p1, s1, p2, p2
* ```
*
* The resulting module also exposes two predicates:
* - `ForwardNode`: All nodes reachable from the start nodes, with member predicate `getState()`.
* - `ReverseNode`: All forward nodes that reach end nodes, with member predicate `getState()`.
*
* These classes may be useful in addition to the `hasPath` predicate.
*
* To track state as well as flow, use `GraphPathStateSearch` instead.
*/
module GraphPathStateSearch<FiniteType Node, GraphPathStateSearchSig<Node> Config> {
/**
* The set of all nodes reachable from the start nodes (inclusive).
*
* Includes the member predicate `getState()` which returns the state associated with this node at
* this point in the search.
*/
class ForwardNode extends Final<Node>::Type {
Config::State state;
ForwardNode() { forwardNode(this, state) }
/**
* Get the state associated with this forward node at this point in the search.
*/
Config::State getState() { result = state }
string toString() { result = "ForwardNode" }
}
/**
* The performant predicate for looking forward one step at a time in the graph.
*
* In `GraphPathSearch`, this is fast because it is essentially a unary predicate. The same is
* true here when the correct joins occur, such that (n, s) effectively act as a single value.
*
* For this reason, we use `pragma[only_bind_into]` to ensure the correct join order.
*/
private predicate forwardNode(Node n, Config::State s) {
Config::start(pragma[only_bind_into](n), pragma[only_bind_into](s))
or
exists(Node n0, Config::State s0 |
forwardNode(pragma[only_bind_into](n0), pragma[only_bind_into](s0)) and
Config::edge(n0, s0, n, s)
)
}
/**
* The set of all forward nodes that reach end nodes (inclusive).
*
* Includes the member predicate `getState()` which returns the state associated with this node at
* this point in the search.
*
* These nodes are the nodes that exist along the path from start nodes to end nodes.
*
* Note: this is fast to compute because it is essentially a unary predicate.
*/
class ReverseNode extends ForwardNode {
ReverseNode() {
// 'state' field and getState() predicate are inherited from ForwardNode
reverseNode(this, state)
}
override string toString() { result = "ReverseNode" }
}
private predicate reverseNode(Node n, Config::State s) {
forwardNode(pragma[only_bind_into](n), pragma[only_bind_into](s)) and
Config::end(n, s)
or
exists(Node n0, Config::State s0 |
reverseNode(pragma[only_bind_into](n0), pragma[only_bind_into](s0)) and
Config::edge(n, s, n0, s0)
)
}
/**
* A start node, end node pair that are connected in the graph.
*/
predicate hasConnection(ReverseNode n1, ReverseNode n2) { hasConnection(n1, _, n2, _) }
/**
* A start node, end node pair that are connected in the graph, and the states associated with
* those nodes.
*/
predicate hasConnection(ReverseNode n1, Config::State s1, ReverseNode n2, Config::State s2) {
Config::start(n1, s1) and
Config::end(n2, s2) and
(
hasPath(n1, s1, n2, s2)
or
n1 = n2 and s1 = s2
)
}
/**
* All relevant edges in the graph which participate in a connection from a start to an end node.
*/
predicate pathEdge(ReverseNode n1, ReverseNode n2) { pathEdge(n1, _, n2, _) }
/**
* All relevant edges in the graph, plus state, which participate in a connection from a start to
* an end node.
*/
predicate pathEdge(ReverseNode n1, Config::State s1, ReverseNode n2, Config::State s2) {
Config::edge(n1, s1, n2, s2) and
reverseNode(pragma[only_bind_into](n2), pragma[only_bind_into](s2))
}
/**
* A performant path search within a custom directed graph from a set of start nodes to a set of
* end nodes.
*
* This predicate is the main entry point for the forward-reverse pruning pattern. The design of
* the config predicates has a great effect in how well this performance pattern will ultimately
* perform.
*
* Example:
* ```ql
* from Person p1, Person p2
* where GraphPathSearch<Person, Config>::hasPath(p1, p2)
* select p1, p2
* ```
*
* Note: this is fast to compute because limits the search space to nodes found by the fast unary
* searches done to find `ForwardNode` and `ReverseNode`.
*/
predicate hasPath(ReverseNode n1, Config::State s1, ReverseNode n2, Config::State s2) {
Config::start(n1, s1) and
Config::edge(n1, s1, n2, s2)
or
exists(ReverseNode nMid, Config::State sMid |
hasPath(n1, s1, nMid, sMid) and
Config::edge(pragma[only_bind_out](nMid), pragma[only_bind_out](sMid), n2, s2)
)
}
}