## Abstract

We present \(\text {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 \(\text {HyperLTL}\), which extends linear-time temporal logic (LTL) with trace quantifiers and trace variables. \(\text {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 \(\text {RVHyper}\) can be used to detect spurious dependencies in hardware designs.

This work was partially supported by the German Research Foundation (DFG) as part of the Collaborative Research Center “Methods and Tools for Understanding and Controlling Privacy” (SFB 1223) and by the European Research Council (ERC) Grant OSARES (No. 683300).

Download conference paper PDF

## 1 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. \(\text {HyperLTL}\) [3] is a logic for expressing temporal hyperproperties, by extending linear-time temporal logic with *explicit* trace quantification. \(\text {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 \(\text {RVHyper}\), a runtime verification tool for monitoring temporal hyperproperties. \(\text {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 \(\text {RVHyper}\) in classical information-flow security, such as checking for violations of observational determinism. \(\text {HyperLTL}\) is, however, not limited to security policies. As an example of such an application beyond security, we show how \(\text {RVHyper}\) can be used to detect spurious dependencies in hardware designs.

## 2 \(\text {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 \(\text {RVHyper}\).

**Specification.** The input to \(\text {RVHyper}\) is a \(\text {HyperLTL}\) specification. \(\text {HyperLTL}\) [3] is a temporal logic for specifying hyperproperties. The logic extends \(\text {LTL}\) with quantification over trace variables \(\pi \) and a method to link atomic propositions to specific traces. The set of trace variables is \(\mathcal {V}\). Formulas in \(\text {HyperLTL}\) are given by the grammar

where \(a \in \text {AP}\) and \(\pi \in \mathcal {V}\). The finite trace semantics [2] for \(\text {HyperLTL}\) is based on the finite trace semantics of LTL. In the following, when using \(\mathcal {L}(\varphi )\) we refer to the finite trace semantics of a \(\text {HyperLTL}\) formula \(\varphi \). Let *t* be a finite trace, \(\epsilon \) denotes the empty trace, and |*t*| denotes the length of a trace. Since we are in a finite trace setting, \(t[i,\ldots ]\) denotes the subsequence from position *i* to position \(|t|-1\). Let \(\varPi _{ fin }: \mathcal {V}\rightarrow \varSigma ^*\) be a partial function mapping trace variables to finite traces. We define \(\epsilon [0]\) as the empty set. \(\varPi _{ fin }[i, \ldots ]\) denotes the trace assignment that is equal to \(\varPi _{ fin }(\pi )[i,\ldots ]\) for all \(\pi \). We define a subsequence of *t* as follows.

For example, above mentioned observational determinism can be formalized as the HyperLTL formula , where is the weak version of .

**Input and Output.** The input of \(\text {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 \in T\) represents a previously observed execution of the system under consideration. If \(\text {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 \(\varphi \) and a trace set *T*, \(\text {RVHyper}\) processes a fresh trace under consideration as depicted in Algorithm 1. The algorithm revolves around a *monitor-template* \(\mathcal {M}_\varphi \), which is constructed from the HyperLTL formula \(\varphi \). The basic idea of the monitor template is that it still contains every trace variables of \(\varphi \), 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.

\(\text {RVHyper}\) initializes the monitor template for each *k*-ary combination of traces in \(T\cup \{t\}\). If one tuple violates the hyperproperty, \(\text {RVHyper}\) returns that *k*-ary tuple of traces as a counter example, otherwise \(\text {RVHyper}\) returns *satisfied*.

**Trace Analysis: Minimizing Trace Storage.** The main obstacle in monitoring hyperproperties is the potentially unbounded space consumption. \(\text {RVHyper}\) uses a *trace analysis* to detect redundant traces, with respect to a given HyperLTL formula, i.e., traces that can be safely discarded without losing any information and without losing the ability to return a counter example.

\(\text {RVHyper}\)’s trace analysis is based on the definition of trace redundancy: we say a fresh trace *t* is \((T, \varphi )\)-redundant, if *T* is a model of \(\varphi \) if and only if \(T \cup \{t\}\) is a model of \(\varphi \). 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 \(\bigwedge _{\pi \in \mathcal {V}} \mathcal {L}(\mathcal {M}_\varphi [t'/\pi ]) \subseteq \mathcal {L}(\mathcal {M}_\varphi [t/\pi ])\). 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.** \(\text {RVHyper}\) uses a *specification analysis*, which is a preprocessing step that analyzes the HyperLTL formula under consideration. \(\text {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: \(\text {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: . If the resulting formula turns out to be unsatisfiable, \(\text {RVHyper}\) omits the symmetric instantiations of the monitor automaton, which turns out to be, especially in combination with \(\text {RVHyper}\)s *trace analysis*, a major optimization in practice [7].

**Implementation.** \(\text {RVHyper}\)^{Footnote 1} is written in . It uses *spot* for building the deterministic monitor automata and the *Buddy* BDD library for handling symbolic constraints. We use the \(\text {HyperLTL}\) satisfiability solver \(\text {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.

## 3 Detecting Spurious Dependencies in Hardware Designs

While \(\text {HyperLTL}\) has been applied to a range of domains, including security and information flow properties, we focus in the following on a classical verification problem, the independence of signals in hardware designs. We demonstrate how \(\text {RVHyper}\) can automatically detect such dependencies from traces generated from hardware designs.

**Input and Output.** The input to \(\text {RVHyper}\) is a set of traces where the propositions match the atomic propositions of the \(\text {HyperLTL}\) formula. For the following experiments, we generate a set of traces from the Verilog description of several example circuits by random simulation. If a set of traces violates the specification, \(\text {RVHyper}\) returns a counter example.

**Specification.** We consider the problem of detecting whether input signals influence output signals in hardware designs. We write to denote that the inputs \({\varvec{i}}\) do not influence the outputs \({\varvec{o}}\). Formally, we specify this property as the following \(\text {HyperLTL}\) formula:

where \(\overline{{\varvec{i}}}\) denotes all inputs except \({\varvec{i}}\). Intuitively, the formula asserts that for every two pairs of execution traces \((\pi _1,\pi _2)\) the value of \({\varvec{o}}\) has to be the same until there is a difference between \(\pi _1\) and \(\pi _2\) in the input vector \(\overline{{\varvec{i}}}\), i.e., the inputs on which \({\varvec{o}}\) may depend.

**Sample Hardware Designs.** We apply \(\text {RVHyper}\) to traces generated from the following hardware designs. Note that, since \(\text {RVHyper}\) observes traces and treats the system that generates the traces as a black box, the performance of \(\text {RVHyper}\) does not depend on the size of the circuit.

### Example 1

*(* xor*).* As a first example, consider the xor function \({\varvec{o}} = {\varvec{i}} \oplus {\varvec{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 Fig. 1. There is a black box combinatorial circuit, guarded by a multiplexer that selects between the two input vectors \({\varvec{i}}\) and \({\varvec{i}}'\) and an inverse multiplexer that forwards the output of the black box either towards \({\varvec{o}}\) or \({\varvec{o}}'\). Despite there being a syntactic dependency between \({\varvec{o}}\) and \({\varvec{i}}'\), there is no semantic dependency, i.e., the output \({\varvec{o}}\) does solely depend on \({\varvec{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 \({\varvec{i}}'\) to the output vector \({\varvec{o}}\) because the state of the latches may depend on it. We construct such a circuit that leaks information about \({\varvec{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 Fig. 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, \(\text {RVHyper}\) is able to scale up to thousands of input traces with millions of monitor instantiations (cf. Algorithm 1). \(\text {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), \(\text {RVHyper}\) has not found a violation for any of the runs. For instances where the property is violated, \(\text {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.

## 4 Conclusion

RVHyper monitors a running system for violations of a HyperLTL specification. The functionality of RVHyper thus complements model checking tools for HyperLTL, like MCHyper [8], and tools for satisfiability checking, like EAHyper [6]. RVHyper is in particular useful during the development of a \(\text {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.

## Notes

- 1.
The implementation is available at https://react.uni-saarland.de/tools/rvhyper/.

## References

Agrawal, S., Bonakdarpour, B.: Runtime verification of k-safety hyperproperties in HyperLTL. In: Proceedings of CSF, pp. 239–252. IEEE Computer Society (2016)

Brett, N., Siddique, U., Bonakdarpour, B.: Rewriting-based runtime verification for alternation-free HyperLTL. In: Legay, A., Margaria, T. (eds.) TACAS 2017. LNCS, vol. 10206, pp. 77–93. Springer, Heidelberg (2017). https://doi.org/10.1007/978-3-662-54580-5_5

Clarkson, M.R., Finkbeiner, B., Koleini, M., Micinski, K.K., Rabe, M.N., Sánchez, C.: Temporal logics for hyperproperties. In: Abadi, M., Kremer, S. (eds.) POST 2014. LNCS, vol. 8414, pp. 265–284. Springer, Heidelberg (2014). https://doi.org/10.1007/978-3-642-54792-8_15

Clarkson, M.R., Schneider, F.B.: Hyperproperties. J. Comput. Secur.

**18**(6), 1157–1210 (2010)Finkbeiner, B., Hahn, C.: Deciding hyperproperties. In: Proceedings of CONCUR, LIPIcs, vol. 59, pp. 13:1–13:14. Leibniz-Zentrum fuer Informatik (2016)

Finkbeiner, B., Hahn, C., Stenger, M.: EAHyper: satisfiability, implication, and equivalence checking of hyperproperties. In: Majumdar, R., Kunčak, V. (eds.) CAV 2017. LNCS, vol. 10427, pp. 564–570. Springer, Cham (2017). https://doi.org/10.1007/978-3-319-63390-9_29

Finkbeiner, B., Hahn, C., Stenger, M., Tentrup, L.: Monitoring hyperproperties. In: Lahiri, S., Reger, G. (eds.) RV 2017. LNCS, vol. 10548, pp. 190–207. Springer, Cham (2017). https://doi.org/10.1007/978-3-319-67531-2_12

Finkbeiner, B., Rabe, M.N., Sánchez, C.: Algorithms for model checking HyperLTL and HyperCTL\(^*\). In: Kroening, D., Păsăreanu, C.S. (eds.) CAV 2015. LNCS, vol. 9206, pp. 30–48. Springer, Cham (2015). https://doi.org/10.1007/978-3-319-21690-4_3

## Author information

### Authors and Affiliations

### Corresponding author

## Editor information

### Editors and Affiliations

## Rights and permissions

This chapter is published under an open access license. Please check the 'Copyright Information' section either on this page or in the PDF for details of this license and what re-use is permitted. If your intended use exceeds what is permitted by the license or if you are unable to locate the licence and re-use information, please contact the Rights and Permissions team.

## Copyright information

© 2018 The Author(s)

## About this paper

### Cite this paper

Finkbeiner, B., Hahn, C., Stenger, M., Tentrup, L. (2018). \(\text {RVHyper}\): A Runtime Verification Tool for Temporal Hyperproperties. In: Beyer, D., Huisman, M. (eds) Tools and Algorithms for the Construction and Analysis of Systems. TACAS 2018. Lecture Notes in Computer Science(), vol 10806. Springer, Cham. https://doi.org/10.1007/978-3-319-89963-3_11

### Download citation

DOI: https://doi.org/10.1007/978-3-319-89963-3_11

Published:

Publisher Name: Springer, Cham

Print ISBN: 978-3-319-89962-6

Online ISBN: 978-3-319-89963-3

eBook Packages: Computer ScienceComputer Science (R0)