RVHyper: A Runtime Verification Tool for Temporal Hyperproperties

We present RVHyper, a runtime verification tool for hyperproperties. Hyperproperties, such as non-interference and observational determinism, relate multiple computation traces with each other. Specifications are given as formulas in the temporal logic HyperLTL, which extends linear-time temporal logic (LTL) with trace quantifiers and trace variables. RVHyper processes execution traces sequentially until a violation of the specification is detected. In this case, a counter example, in the form of a set of traces, is returned. As an example application, we show how RVHyper can be used to detect spurious dependencies in hardware designs.


Introduction
Hyperproperties [4] generalize trace properties in that they not only check the correctness of individual computation traces in isolation, but relate multiple computation traces to each other. HyperLTL [3] is a logic for expressing temporal hyperproperties, by extending linear-time temporal logic with explicit trace quantification. HyperLTL has been used to specify a variety of information-flow and security properties. Examples include classical properties like non-interference and observational determinism, as well as quantitative information-flow properties, symmetries in hardware designs, and formally verified error correcting codes [8]. While model checking and satisfiability checking tools for HyperLTL already exist [5,8], the runtime verification of HyperLTL specifications has so far, despite recent theoretical progress [1,2,7], not been supported by practical tool implementations.
Monitoring hyperproperties is difficult: in principle, the monitor not only needs to process every observed trace, but must also store every trace observed so far, so that future traces can be compared with the traces seen so far. On the other hand, a runtime verification tool for hyperproperties is certainly useful, in particular if the implementation of a security critical system is not available. Even without access to the source code, monitoring the observable execution traces still detects insecure information flow.
In this paper, we present RVHyper, a runtime verification tool for monitoring temporal hyperproperties. RVHyper tackles this challenging problem by implementing two major optimizations: (1) a trace analysis, which detects all redundant traces that can be omitted during the monitoring process and (2) a specification analysis to detect exploitable properties of a hyperproperty, such as symmetry.
We have applied RVHyper in classical information-flow security, such as checking for violations of observational determinism. HyperLTL is, however, not limited to security policies. As an example of such an application beyond security, we show how RVHyper can be used to detect spurious dependencies in hardware designs.

RVHyper
In this section we give an overview on the monitoring approach, including the input and output of the monitoring algorithm and the two major optimization techniques implemented in RVHyper.
Specification. The input to RVHyper is a HyperLTL specification. HyperLTL [3] is a temporal logic for specifying hyperproperties. The logic extends LTL with quantification over trace variables π and a method to link atomic propositions to specific traces. The set of trace variables is V. Formulas in HyperLTL are given by the grammar ϕ ::= ∀π. ϕ | ∃π. ϕ | ψ , and where a ∈ AP and π ∈ V. The finite trace semantics [2] for HyperLTL is based on the finite trace semantics of LTL. In the following, when using L(ϕ) we refer to the finite trace semantics of a HyperLTL formula ϕ. Let t be a finite trace, denotes the empty trace, and |t| denotes the length of a trace. Since we are in a finite trace setting, t[i, . . .] denotes the subsequence from position i to position |t| − 1. Let Π fin : V → Σ * be a partial function mapping trace variables to finite traces. We define [0] as the empty set. Π fin [i, . . .] denotes the trace assignment that is equal to Π fin (π)[i, . . .] for all π. We define a subsequence of t as follows.
input : ∀ n HyperLTL formula ϕ, set of traces T , fresh trace t output: satisfied or n-ary tuple witnessing violation Algorithm 1: A high-level sketch of the monitoring algorithm for ∀ n Hy-perLTL formulas.
input : HyperLTL formula ϕ, redundancy free trace set T , fresh trace t output: redundancy free set of traces Tmin ⊆ T ∪ {t} Algorithm 2: Trace analysis algorithm to minimize trace storage.
For example, above mentioned observational determinism can be formalized as the HyperLTL formula ∀π. ∀π .
Input and Output. The input of RVHyper consists of a HyperLTL formula and the observed behavior of the system under consideration. The observed behavior is represented as a trace set T , where each t ∈ T represents a previously observed execution of the system under consideration. If RVHyper detects that the system violates the hyperproperty, it outputs a counter example, i.e, a k-ary tuple of traces, where k is the number of quantifiers in the HyperLTL formula.
Monitoring Algorithm. Given a HyperLTL formula ϕ and a trace set T , RVHyper processes a fresh trace under consideration as depicted in Algorithm 1. The algorithm revolves around a monitor-template M ϕ , which is constructed from the HyperLTL formula ϕ. The basic idea of the monitor template is that it still contains every trace variables of ϕ, which can be initialized with explicit traces at runtime. This way, the automaton construction of the monitor template is constructed only once as a preprocessing step.
RVHyper initializes the monitor template for each k-ary combination of traces in T ∪ {t}. If one tuple violates the hyperproperty, RVHyper returns that k-ary tuple of traces as a counter example, otherwise RVHyper returns satisfied.
Trace Analysis: Minimizing Trace Storage. The main obstacle in monitoring hyperproperties is the potentially unbounded space consumption. RVHyper uses a trace analysis to detect redundant traces, with respect to a given Hy-perLTL formula, i.e., traces that can be safely discarded without losing any information and without losing the ability to return a counter example.
RVHyper's trace analysis is based on the definition of trace redundancy: we say a fresh trace t is (T, ϕ)-redundant, if T is a model of ϕ if and only if T ∪ {t} is a model of ϕ. The idea, depicted in Algorithm 2, is to check if another trace t contains at least as much informations as t: we say a t dominates t if π∈V L(M ϕ [t /π]) ⊆ L(M ϕ [t/π]). For a fresh incoming trace, RVHyper performs this language inclusion check in both directions in order to compute the minimal trace set that must be stored to monitor the hyperproperty under consideration.
Specification Analysis: Decreasing Running Time. RVHyper uses a specification analysis, which is a preprocessing step that analyzes the HyperLTL formula under consideration. RVHyper detects whether a formula is (1) symmetric, i.e., we halve the number of instantiated monitors, (2) transitive, i.e, we reduce the number of instantiated monitors to two, or (3) reflexive, i.e., we can omit the self comparison of traces [7].
Symmetry is especially interesting because many information flow policies satisfy this property. Consider, for example, observational determinism: ∀π. ∀π . (O π = O π ) W (I π = I π ). RVHyper detects symmetry by translating this formula to a formula that is unsatisfiable if there exists no pair of traces which violates the symmetry condition: ∃π. ∃π . (O π = O π ) W (I π = I π ) (O π = O π )W (I π = I π ) . If the resulting formula turns out to be unsatisfiable, RVHyper omits the symmetric instantiations of the monitor automaton, which turns out to be, especially in combination with RVHypers trace analysis, a major optimization in practice [7].
Implementation. RVHyper 1 is written in C ++ . It uses spot for building the deterministic monitor automata and the Buddy BDD library for handling symbolic constraints. We use the HyperLTL satisfiability solver EAHyper [5,6] to determine whether the input formula is reflexive, symmetric, or transitive. Depending on those results, we omit redundant tuples in the monitoring algorithm. Specification. We consider the problem of detecting whether input signals influence output signals in hardware designs. We write i o to denote that the inputs i do not influence the outputs o. Formally, we specify this property as the following HyperLTL formula: where i denotes all inputs except i. Intuitively, the formula asserts that for every two pairs of execution traces (π 1 , π 2 ) the value of o has to be the same until there is a difference between π 1 and π 2 in the input vector i, i.e., the inputs on which o may depend.
Sample Hardware Designs. We apply RVHyper to traces generated from the following hardware designs. Note that, since RVHyper observes traces and treats the system that generates the traces as a black box, the performance of RVHyper does not depend on the size of the circuit.
Example 1 ( xor). As a first example, consider the xor function o = i ⊕ i . In the corresponding circuit, every j-th output bit o j is only influenced by the j-the input bits i j and i j . Example 2 ( mux). This example circuit is depicted in Figure 1. There is a black box combinatorial circuit, guarded by a multiplexer that selects between the two input vectors i and i and an inverse multiplexer that forwards the output of the black box either towards o or o . Despite there being a syntactic dependency between o and i , there is no semantic dependency, i.e., the output o does solely depend on i and the selector signal. When using the same example, but with a sequential circuit as black box, there may be information flow from the input vector i to the output vector o because the state of the latches may depend on it. We construct such a circuit that leaks information about i via its internal state.
Example 3 (counter). Our last example is a binary counter with two input control bits incr and decr that increments and decrements the counter. The corresponding Verilog design is shown in Figure 2. The counter has a single output, namely a signal that is set to one when the counter value overflows. Both inputs influence the output, but timing of the overflow depends on the number of counter bits.
Results. The results of multiple random simulations are given in Table 1. Despite the high complexity of the monitoring problem, RVHyper is able to scale up to thousands of input traces with millions of monitor instantiations (cf. Algorithm 1). RVHyper's optimizations, i.e., keeping only a minimal set of traces and reducing the number of instances by the specification analysis, are a key factor to those results. For the two instances where the property is satisfied (xor and mux), RVHyper has not found a violation for any of the runs. For instances where the property is violated, RVHyper is able to find counter examples. While counter examples can be found quickly for xor and mux2, the counter instances need more traces since the chance of finding a violating pair of traces is lower.

Conclusion
RVHyper monitors a running system for violations of a HyperLTL specification. The functionality of RVHyper thus complements model checking tools for Hy-perLTL, like MCHyper [8], and tools for satisifability checking, like EAHyper [6].
RVHyper is in particular useful during the development of a HyperLTL specification, where it can be used to check the HyperLTL formula on sample traces without the need for a complete model. Based on the feedback of the tool, the user can refine the HyperLTL formula until it captures the intended policy.