Explaining Hyperproperty Violations

Abstract

Hyperproperties relate multiple computation traces to each other. Model checkers for hyperproperties thus return, in case a system model violates the specification, a set of traces as a counterexample. Fixing the erroneous relations between traces in the system that led to the counterexample is a difficult manual effort that highly benefits from additional explanations. In this paper, we present an explanation method for counterexamples to hyperproperties described in the specification logic HyperLTL. We extend Halpern and Pearl's definition of actual causality to sets of traces witnessing the violation of a HyperLTL formula, which allows us to identify the events that caused the violation. We report on the implementation of our method and show that it significantly improves on previous approaches for analyzing counterexamples returned by HyperLTL model checkers.

Explaining Hyperproperty Violations

“…Note that, under the assumption that all states of the original system are uniquely labeled and there exists a state for every combination of output variables, the function δ C is uniquely determined. 1 A counterfactual automaton for our running example is described in the full version of this paper [22].…”

“…1, because there is no transition that explains the step from t 2 [1] to t 2 [2]. It is, however, a trace of the counterfactual automaton T C t2 (see full version [22]), which encodes the set of counterfactual worlds for the trace t 2 . The fact that we consider executions that are not part of the original system allows us to infer that only the first high input was an actual cause in our running example.…”

“…We use the algorithm of [36] as a black box (see App. A.2 in [22] for a formal definition of alternating automata and App. A.3 in [22] for the translation from LTL to alternating automata).…”

“…A.2 in [22] for a formal definition of alternating automata and App. A.3 in [22] for the translation from LTL to alternating automata). For the computation of contingencies we use an additional feature of the algorithm of [36] -the algorithm returns an accepting run tree T of A φ on t , with annotations of nodes that represent atomic subformulas of φ that take part in the satisfaction of φ.…”

“…3, the instance Security in & out refers to a system which leaks high security input by not satisfying a noninterference property, the Drone examples consider a leader-follower drone scenario, and the Asymmetric Arbiter instances refer to arbiter implementations that do not satisfy a symmetry constraint. Specifications can be found in the full version of this paper [22]. Our first observation is that the cause candidate C can be efficiently computed thanks to the iterative computation of unsatisfiable cores (Sect.…”