From 06c6ceda5084624d78d91029b3c06155f797c755 Mon Sep 17 00:00:00 2001 From: Owen Mansel-Chan Date: Thu, 21 Jan 2021 15:14:27 +0000 Subject: [PATCH] Make comment on BarrierGuard more specific The problem that this comment is trying to warn about is the following: say you have two subclasses of BarrierGuard BG1 and BG2, both of which contain some node g. Also assume that you have a configuration C which specifies BG1 as a barrier guard, but not BG2. Because g is contained in both classes, you will then still get the barrier guard definition from BG2 due to the way dynamic dispatch works in QL. --- ql/src/semmle/go/dataflow/internal/DataFlowUtil.qll | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/ql/src/semmle/go/dataflow/internal/DataFlowUtil.qll b/ql/src/semmle/go/dataflow/internal/DataFlowUtil.qll index 13c536a7a48..0482b23225c 100644 --- a/ql/src/semmle/go/dataflow/internal/DataFlowUtil.qll +++ b/ql/src/semmle/go/dataflow/internal/DataFlowUtil.qll @@ -1115,7 +1115,10 @@ predicate localFlow(Node source, Node sink) { localFlowStep*(source, sink) } * characteristic predicate precisely specifying the guard, and override * `checks` to specify what is being validated and in which branch. * - * It is important that all extending classes in scope are disjoint. + * When using a data-flow or taint-flow configuration `cfg`, it is important + * that any classes extending BarrierGuard in scope which are not used in `cfg` + * are disjoint from any classes extending BarrierGuard in scope which are used + * in `cfg`. */ abstract class BarrierGuard extends Node { /** Holds if this guard validates `e` upon evaluating to `branch`. */