# \(\text {RVHyper}\): A Runtime Verification Tool for Temporal Hyperproperties

## 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.

## 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 grammarwhere \(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 Open image in new window , where Open image in new window is the weak version of Open image in new window .

**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: Open image in new window \(\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: Open image in new window . 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}\)^{1} is written in Open image in new window . 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

**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 Open image in new window 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 of \(\text {RVHyper}\) on traces generated from circuit instances. Every instance was run 10 times with different seeds and the average is reported.

Instance | Property | Satisfied | # traces | Length | Time | # instances |
---|---|---|---|---|---|---|

xor | no | 18 | 5 | 12 ms | 222 | |

xor | yes | 1000 | 5 | 16913 ms | 499500 | |

counter | no | 1636 | 20 | 28677 ms | 1659446 | |

counter | no | 1142 | 20 | 15574 ms | 887902 | |

mux | yes | 1000 | 5 | 14885 ms | 499500 | |

mux2 | no | 82 | 5 | 140 ms | 3704 |

**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.

## Footnotes

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

## References

- 1.Agrawal, S., Bonakdarpour, B.: Runtime verification of k-safety hyperproperties in HyperLTL. In: Proceedings of CSF, pp. 239–252. IEEE Computer Society (2016)Google Scholar
- 2.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_5CrossRefGoogle Scholar
- 3.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_15CrossRefGoogle Scholar
- 4.Clarkson, M.R., Schneider, F.B.: Hyperproperties. J. Comput. Secur.
**18**(6), 1157–1210 (2010)CrossRefGoogle Scholar - 5.Finkbeiner, B., Hahn, C.: Deciding hyperproperties. In: Proceedings of CONCUR, LIPIcs, vol. 59, pp. 13:1–13:14. Leibniz-Zentrum fuer Informatik (2016)Google Scholar
- 6.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_29CrossRefGoogle Scholar
- 7.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_12CrossRefGoogle Scholar
- 8.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_3CrossRefGoogle Scholar

## Copyright information

Open Access This chapter is licensed under the terms of the Creative Commons Attribution 4.0 International License (http://creativecommons.org/licenses/by/4.0/), which permits use, sharing, adaptation, distribution and reproduction in any medium or format, as long as you give appropriate credit to the original author(s) and the source, provide a link to the Creative Commons license and indicate if changes were made. The images or other third party material in this book are included in the book's Creative Commons license, unless indicated otherwise in a credit line to the material. If material is not included in the book's Creative Commons license and your intended use is not permitted by statutory regulation or exceeds the permitted use, you will need to obtain permission directly from the copyright holder.