C I S PA HELMHOLTZ CENTER FOR INFORMATION SECURITY

Bernd Finkbeiner, Stefan Oswald, Noemi Passing, Maximilian Schwenger

VERIFIED RUST MONITORS FOR LOLA SPECIFICATIONS

AN AGE-OLD QUESTION

QUIS CUSTODIET IPSOS CUSTODES?

~ Juvenal (100-200ad)

QUIS CUSTODIET IPSOS CUSTODES?

3

Cannot be trusted! MONITOR

observes

QUIS CUSTODIET IPSOS CUSTODES?

3

Cannot be trusted!

Why trust the monitor?

MONITOR

observes

QUIS CUSTODIET IPSOS CUSTODES?

3

Cannot be trusted!

Why trust the monitor?

MONITOR

observes

Our Goal: Verify the Monitor!

QUIS CUSTODIET IPSOS CUSTODES?

4

01010010 01010110 00110010 00110000

Never injure humans. Obey orders. Protect yourself.

Lola Specification

observes MONITOR

Our Goal: Verify the Monitor!

QUIS CUSTODIET IPSOS CUSTODES?

4

01010010 01010110 00110010 00110000

Never injure humans. Obey orders. Protect yourself.

Lola Specification

observes

Impl Monitor { ##[invariant = … ] while let Some(i) = get_input() { … }}

Rust Code

MONITOR

Our Goal: Verify the Monitor!

Compilation

QUIS CUSTODIET IPSOS CUSTODES?

4

01010010 01010110 00110010 00110000

Never injure humans. Obey orders. Protect yourself.

Lola Specification

observes

Impl Monitor { ##[invariant = … ] while let Some(i) = get_input() { … }}

Rust Code

MONITOR

Our Goal: Verify the Monitor!

Compilation

+ Annotation + Generation

QUIS CUSTODIET IPSOS CUSTODES?

4

01010010 01010110 00110010 00110000

Never injure humans. Obey orders. Protect yourself.

Lola Specification

observes

Impl Monitor { ##[invariant = … ] while let Some(i) = get_input() { … }}

Rust Code

verifies MONITOR

Our Goal: Verify the Monitor!

Compilation

+ Annotation + Generation

QUIS CUSTODIET IPSOS CUSTODES?

4

01010010 01010110 00110010 00110000

Never injure humans. Obey orders. Protect yourself.

Lola Specification

observes

Impl Monitor { ##[invariant = … ] while let Some(i) = get_input() { … }}

Rust Code

verifies MONITOR

Our Goal: Verify the Monitor!

Compilation

+ Annotation + Generation

t1,8t1,7t1,5 t1,6t1,4t1,3t1,2t1,1

o2,8o2,7o2,5 o2,6o2,4o2,3o2,2o2,1

o1,8o1,7o1,5 o1,6o1,4o1,3o1,2o1,1

i3,8i3,7i3,5 i3,6i3,4i3,3i3,2i3,1

i2,8i2,7i2,5 i2,6i2,4i2,3i2,2i2,1

i1,8i1,7i1,5 i1,6i1,4i1,3i1,2i1,1

STREAM-BASED MONITORING WITH LOLA

5

input i1

input i2

input i3

output o1 ::= i3 + 3

output o2 ::= i1 + i2 + o1

trigger o2 > 7

sensors

t1,8t1,7t1,5 t1,6t1,4t1,3t1,2t1,1

o2,8o2,7o2,5 o2,6o2,4o2,3o2,2o2,1

o1,8o1,7o1,5 o1,6o1,4o1,3o1,2o1,1

i3,8i3,7i3,5 i3,6i3,4i3,3i3,2i3,1

i2,8i2,7i2,5 i2,6i2,4i2,3i2,2i2,1

i1,8i1,7i1,5 i1,6i1,4i1,3i1,2i1,1

STREAM-BASED MONITORING WITH LOLA

5

input i1

input i2

input i3

output o1 ::= i3 + 3

output o2 ::= i1 + i2 + o1

trigger o2 > 7

sensors

o2,8o2,7o2,5 o2,6o2,4o2,3o2,2o2,1

o1,8o1,7o1,5 o1,6o1,4o1,3o1,2o1,1

i3,8i3,7i3,5 i3,6i3,4i3,3i3,2i3,1

i2,8i2,7i2,5 i2,6i2,4i2,3i2,2i2,1

i1,8i1,7i1,5 i1,6i1,4i1,3i1,2i1,1

STREAM-BASED MONITORING WITH LOLA

5

input i1

input i2

input i3

output o1 ::= i3 + 3

output o2 ::= i1 + i2 + o1

trigger o2 > 7

sensors

tH2,8tH2,7tH2,5 tH2,6tH2,4tH2,3tH2,2tH2,1

a1,8a1,7a1,5 a1,6a1,4a1,3a1,2a1,1

STREAM-BASED MONITORING WITH LOLA

6

sensorsinput alt output tooHigh ::= alt.offset(by: -1, dft: 0) > 500 ∧ alt > 500 ∧ alt.offset(by: +1, dft: 0) > 500 trigger tooHigh

tH2,8tH2,7tH2,5 tH2,6tH2,4tH2,3tH2,2tH2,1

a1,8a1,7a1,5 a1,6a1,4a1,3a1,2a1,1

STREAM-BASED MONITORING WITH LOLA

6

sensorsinput alt output tooHigh ::= alt.offset(by: -1, dft: 0) > 500 ∧ alt > 500 ∧ alt.offset(by: +1, dft: 0) > 500 trigger tooHigh

tH2,8tH2,7tH2,5 tH2,6tH2,4tH2,3tH2,2tH2,1

a1,8a1,7a1,5 a1,6a1,4a1,3a1,2a1,1

STREAM-BASED MONITORING WITH LOLA

6

fails @ t=1

fails @ t=|σ|

sensorsinput alt output tooHigh ::= alt.offset(by: -1, dft: 0) > 500 ∧ alt > 500 ∧ alt.offset(by: +1, dft: 0) > 500 trigger tooHigh

tH2,8tH2,7tH2,5 tH2,6tH2,4tH2,3tH2,2tH2,1

a1,8a1,7a1,5 a1,6a1,4a1,3a1,2a1,1

STREAM-BASED MONITORING WITH LOLA

6

fails @ t=1

fails @ t=|σ|

never fails

sensorsinput alt output tooHigh ::= alt.offset(by: -1, dft: 0) > 500 ∧ alt > 500 ∧ alt.offset(by: +1, dft: 0) > 500 trigger tooHigh

THREE PHASES

7PREFIX MONITOR LOOP POSTFIX

fn postfix() { a-1 > 500 ∧ a0 > 500 ∧ a+1 > 500 }

fn prefix() { a-1 > 500 ∧ a0 > 500 ∧ a+1 > 500 }

THREE CODE FRAGMENTS

8MONITOR LOOPPREFIX POSTFIX

while let Some(…) = get_input() { a-1 > 500 ∧ a0 > 500 ∧ a+1 > 500 }

fn postfix() { a-1 > 500 ∧ a0 > 500 ∧ a+1 > 500 }

fn prefix() { 0 > 500 ∧ a0 > 500 ∧ a+1 > 500 }

THREE CODE FRAGMENTS

8MONITOR LOOPPREFIX POSTFIX

while let Some(…) = get_input() { a-1 > 500 ∧ a0 > 500 ∧ a+1 > 500 }

fn postfix() { a-1 > 500 ∧ a0 > 500 ∧ a+1 > 500 }

fn prefix() { 0 > 500 ∧ a0 > 500 ∧ a+1 > 500 }

THREE CODE FRAGMENTS

8MONITOR LOOPPREFIX POSTFIX

while let Some(…) = get_input() { a-1 > 500 ∧ a0 > 500 ∧ a+1 > 500 }

fn prefix() { 0 > 500 ∧ a0 > 500 ∧ a+1 > 500 }

fn postfix() { a-1 > 500 ∧ a0 > 500 ∧ 0 > 500 }

THREE CODE FRAGMENTS

8MONITOR LOOPPREFIX POSTFIX

while let Some(…) = get_input() { a-1 > 500 ∧ a0 > 500 ∧ a+1 > 500 }

fn prefix() { 0 > 500 ∧ a0 > 500 ∧ a+1 > 500 }

fn postfix() { a-1 > 500 ∧ a0 > 500 ∧ 0 > 500 }

THREE CODE FRAGMENTS

8MONITOR LOOPPREFIX POSTFIX

while let Some(…) = get_input() { a-1 > 500 ∧ a0 > 500 ∧ a+1 > 500 }

I. ERADICATE MOST CONDITIONALS II. MEMORY ACCESSES BECOME CONSTANTS

PERFORMANCE BENEFITS

9

Interpretation [CAV’19]

Compilation

438ns

6ns (1.4%)

1.535μs

63ns (4%)

VERIFICATION

10

LOLA

RUST

t = 0

stream ≜ infinite sequence of values

VERIFICATION

10

LOLA

RUST

t = 0

stream ≜ infinite sequence of values

memory ≜ finite excerpt of stream

VERIFICATION

11

LOLA

RUST

t = 0

stream ≜ infinite sequence of values

memory ≜ finite excerpt of stream

VIPERt = 0

= = = = = = =

= = = =

GHOST MEMORY

GHOST MEMORY IN ACTION

12

##[invariant="forall i: usize ::: (0 <<= i &&& i < μ(a)) ==>= mem.get_a(i) === gm.get_a(iter - i) "]

##[invariant=“new_tooHigh === gm.get_a(iter - 2) > 500 ∧ …”]

while let Some(input) = get_input() {

mem.add_input(&input);

[[ EVALUATION LOGIC ]]

mem.store(new_tooHigh); gm.store(new_tooHigh);

if trigger_1 { emit( trigger_1_msg) } }

EXPERIMENTS

13

altitude

EXPERIMENTS

13

Verified Rust Monitors for Lola Specifications 15

Time [s] Memory [MB]

0

200

400

600

800

1,000

(a) Altitude Monitor

Time [s] Memory [MB]

0

1,000

2,000

3,000

4,000

5,000

(b) Network Traffic Monitor

Fig. 4: Results of 20 runs in terms of running time (blue, in seconds) and memoryconsumption (orange, in MB) for the verification of the annotated Rust code ofthe specification, where the altitude of a drone is monitored (cf. Listing 1.1),and the network traffic monitor specification.

is checked by the Z3 [21] smt solver. Thus, our toolchain enables completelyautomatic proof checking.

The experiments were conducted on a machine with a 3.1GHz Dual-Core Inteli5 processor with 16GB of ram. The artifacts for the evaluation are available ongithub.5 In all experiments, the compilation itself has a negligible running timeof under ten milliseconds and memory consumption of less than 4MB, mainlydue to the RTLola frontend. As expected, the verification of the annotated rustcode using Prusti and the Viper toolkit takes significant time and memory. Whilethe translation into the smt model is deterministic and can be parallelized, theverification with Z3 exhibits generally high and unpredictable running time.

We discuss the results of compiling and verifying three Lola specification ofvarying size. The process works flawlessly on two of them while the third oneoccasionally runs into timeouts and inconclusive verification results.

First, we consider the specification from Listing 1.1, where the altitude ofa drone is monitored. The results in terms of both running time and memoryconsumption for 20 runs are depicted in Figure 4a. Note that the y-axis displaysboth the running time in seconds (left plot) and the memory consumption inmegabytes (right plot). The plot shows that the running time never exceeds600s with a median of 225s. The memory consumption is significantly morestable ranging between 648 and 711MB with one outlier (914MB).

While the first specification was short and illustrative, the second one is morepractically relevant. The specification monitors the network traffic of a serverbased on the source and destination IP of requests, tcp flags, and the lengthof the payload [6]. The specification counts the number of incoming connectionsand computes the workload, i.e., the number of bytes received over push requests.

5 https://github.com/reactive-systems/Lola2RustArtifact

altitude

EXPERIMENTS

13

Verified Rust Monitors for Lola Specifications 15

Time [s] Memory [MB]

0

200

400

600

800

1,000

(a) Altitude Monitor

Time [s] Memory [MB]

0

1,000

2,000

3,000

4,000

5,000

(b) Network Traffic Monitor

Fig. 4: Results of 20 runs in terms of running time (blue, in seconds) and memoryconsumption (orange, in MB) for the verification of the annotated Rust code ofthe specification, where the altitude of a drone is monitored (cf. Listing 1.1),and the network traffic monitor specification.

is checked by the Z3 [21] smt solver. Thus, our toolchain enables completelyautomatic proof checking.

The experiments were conducted on a machine with a 3.1GHz Dual-Core Inteli5 processor with 16GB of ram. The artifacts for the evaluation are available ongithub.5 In all experiments, the compilation itself has a negligible running timeof under ten milliseconds and memory consumption of less than 4MB, mainlydue to the RTLola frontend. As expected, the verification of the annotated rustcode using Prusti and the Viper toolkit takes significant time and memory. Whilethe translation into the smt model is deterministic and can be parallelized, theverification with Z3 exhibits generally high and unpredictable running time.

We discuss the results of compiling and verifying three Lola specification ofvarying size. The process works flawlessly on two of them while the third oneoccasionally runs into timeouts and inconclusive verification results.

First, we consider the specification from Listing 1.1, where the altitude ofa drone is monitored. The results in terms of both running time and memoryconsumption for 20 runs are depicted in Figure 4a. Note that the y-axis displaysboth the running time in seconds (left plot) and the memory consumption inmegabytes (right plot). The plot shows that the running time never exceeds600s with a median of 225s. The memory consumption is significantly morestable ranging between 648 and 711MB with one outlier (914MB).

While the first specification was short and illustrative, the second one is morepractically relevant. The specification monitors the network traffic of a serverbased on the source and destination IP of requests, tcp flags, and the lengthof the payload [6]. The specification counts the number of incoming connectionsand computes the workload, i.e., the number of bytes received over push requests.

5 https://github.com/reactive-systems/Lola2RustArtifact

Verified Rust Monitors for Lola Specifications 15

Time [s] Memory [MB]

0

200

400

600

800

1,000

(a) Altitude Monitor

Time [s] Memory [MB]

0

1,000

2,000

3,000

4,000

5,000

(b) Network Traffic Monitor

Fig. 4: Results of 20 runs in terms of running time (blue, in seconds) and memoryconsumption (orange, in MB) for the verification of the annotated Rust code ofthe specification, where the altitude of a drone is monitored (cf. Listing 1.1),and the network traffic monitor specification.

is checked by the Z3 [21] smt solver. Thus, our toolchain enables completelyautomatic proof checking.

The experiments were conducted on a machine with a 3.1GHz Dual-Core Inteli5 processor with 16GB of ram. The artifacts for the evaluation are available ongithub.5 In all experiments, the compilation itself has a negligible running timeof under ten milliseconds and memory consumption of less than 4MB, mainlydue to the RTLola frontend. As expected, the verification of the annotated rustcode using Prusti and the Viper toolkit takes significant time and memory. Whilethe translation into the smt model is deterministic and can be parallelized, theverification with Z3 exhibits generally high and unpredictable running time.

We discuss the results of compiling and verifying three Lola specification ofvarying size. The process works flawlessly on two of them while the third oneoccasionally runs into timeouts and inconclusive verification results.

First, we consider the specification from Listing 1.1, where the altitude ofa drone is monitored. The results in terms of both running time and memoryconsumption for 20 runs are depicted in Figure 4a. Note that the y-axis displaysboth the running time in seconds (left plot) and the memory consumption inmegabytes (right plot). The plot shows that the running time never exceeds600s with a median of 225s. The memory consumption is significantly morestable ranging between 648 and 711MB with one outlier (914MB).

While the first specification was short and illustrative, the second one is morepractically relevant. The specification monitors the network traffic of a serverbased on the source and destination IP of requests, tcp flags, and the lengthof the payload [6]. The specification counts the number of incoming connectionsand computes the workload, i.e., the number of bytes received over push requests.

5 https://github.com/reactive-systems/Lola2RustArtifact

altitude

EXPERIMENTS

13

Verified Rust Monitors for Lola Specifications 15

Time [s] Memory [MB]

0

200

400

600

800

1,000

(a) Altitude Monitor

Time [s] Memory [MB]

0

1,000

2,000

3,000

4,000

5,000

(b) Network Traffic Monitor

Fig. 4: Results of 20 runs in terms of running time (blue, in seconds) and memoryconsumption (orange, in MB) for the verification of the annotated Rust code ofthe specification, where the altitude of a drone is monitored (cf. Listing 1.1),and the network traffic monitor specification.

is checked by the Z3 [21] smt solver. Thus, our toolchain enables completelyautomatic proof checking.

The experiments were conducted on a machine with a 3.1GHz Dual-Core Inteli5 processor with 16GB of ram. The artifacts for the evaluation are available ongithub.5 In all experiments, the compilation itself has a negligible running timeof under ten milliseconds and memory consumption of less than 4MB, mainlydue to the RTLola frontend. As expected, the verification of the annotated rustcode using Prusti and the Viper toolkit takes significant time and memory. Whilethe translation into the smt model is deterministic and can be parallelized, theverification with Z3 exhibits generally high and unpredictable running time.

We discuss the results of compiling and verifying three Lola specification ofvarying size. The process works flawlessly on two of them while the third oneoccasionally runs into timeouts and inconclusive verification results.

First, we consider the specification from Listing 1.1, where the altitude ofa drone is monitored. The results in terms of both running time and memoryconsumption for 20 runs are depicted in Figure 4a. Note that the y-axis displaysboth the running time in seconds (left plot) and the memory consumption inmegabytes (right plot). The plot shows that the running time never exceeds600s with a median of 225s. The memory consumption is significantly morestable ranging between 648 and 711MB with one outlier (914MB).

While the first specification was short and illustrative, the second one is morepractically relevant. The specification monitors the network traffic of a serverbased on the source and destination IP of requests, tcp flags, and the lengthof the payload [6]. The specification counts the number of incoming connectionsand computes the workload, i.e., the number of bytes received over push requests.

5 https://github.com/reactive-systems/Lola2RustArtifact

Verified Rust Monitors for Lola Specifications 15

Time [s] Memory [MB]

0

200

400

600

800

1,000

(a) Altitude Monitor

Time [s] Memory [MB]

0

1,000

2,000

3,000

4,000

5,000

(b) Network Traffic Monitor

Fig. 4: Results of 20 runs in terms of running time (blue, in seconds) and memoryconsumption (orange, in MB) for the verification of the annotated Rust code ofthe specification, where the altitude of a drone is monitored (cf. Listing 1.1),and the network traffic monitor specification.

is checked by the Z3 [21] smt solver. Thus, our toolchain enables completelyautomatic proof checking.

The experiments were conducted on a machine with a 3.1GHz Dual-Core Inteli5 processor with 16GB of ram. The artifacts for the evaluation are available ongithub.5 In all experiments, the compilation itself has a negligible running timeof under ten milliseconds and memory consumption of less than 4MB, mainlydue to the RTLola frontend. As expected, the verification of the annotated rustcode using Prusti and the Viper toolkit takes significant time and memory. Whilethe translation into the smt model is deterministic and can be parallelized, theverification with Z3 exhibits generally high and unpredictable running time.

We discuss the results of compiling and verifying three Lola specification ofvarying size. The process works flawlessly on two of them while the third oneoccasionally runs into timeouts and inconclusive verification results.

First, we consider the specification from Listing 1.1, where the altitude ofa drone is monitored. The results in terms of both running time and memoryconsumption for 20 runs are depicted in Figure 4a. Note that the y-axis displaysboth the running time in seconds (left plot) and the memory consumption inmegabytes (right plot). The plot shows that the running time never exceeds600s with a median of 225s. The memory consumption is significantly morestable ranging between 648 and 711MB with one outlier (914MB).

While the first specification was short and illustrative, the second one is morepractically relevant. The specification monitors the network traffic of a serverbased on the source and destination IP of requests, tcp flags, and the lengthof the payload [6]. The specification counts the number of incoming connectionsand computes the workload, i.e., the number of bytes received over push requests.

5 https://github.com/reactive-systems/Lola2RustArtifact

altitude flight phase

EXPERIMENTS

13

Verified Rust Monitors for Lola Specifications 15

Time [s] Memory [MB]

0

200

400

600

800

1,000

(a) Altitude Monitor

Time [s] Memory [MB]

0

1,000

2,000

3,000

4,000

5,000

(b) Network Traffic Monitor

Fig. 4: Results of 20 runs in terms of running time (blue, in seconds) and memoryconsumption (orange, in MB) for the verification of the annotated Rust code ofthe specification, where the altitude of a drone is monitored (cf. Listing 1.1),and the network traffic monitor specification.

is checked by the Z3 [21] smt solver. Thus, our toolchain enables completelyautomatic proof checking.

The experiments were conducted on a machine with a 3.1GHz Dual-Core Inteli5 processor with 16GB of ram. The artifacts for the evaluation are available ongithub.5 In all experiments, the compilation itself has a negligible running timeof under ten milliseconds and memory consumption of less than 4MB, mainlydue to the RTLola frontend. As expected, the verification of the annotated rustcode using Prusti and the Viper toolkit takes significant time and memory. Whilethe translation into the smt model is deterministic and can be parallelized, theverification with Z3 exhibits generally high and unpredictable running time.

We discuss the results of compiling and verifying three Lola specification ofvarying size. The process works flawlessly on two of them while the third oneoccasionally runs into timeouts and inconclusive verification results.

First, we consider the specification from Listing 1.1, where the altitude ofa drone is monitored. The results in terms of both running time and memoryconsumption for 20 runs are depicted in Figure 4a. Note that the y-axis displaysboth the running time in seconds (left plot) and the memory consumption inmegabytes (right plot). The plot shows that the running time never exceeds600s with a median of 225s. The memory consumption is significantly morestable ranging between 648 and 711MB with one outlier (914MB).

While the first specification was short and illustrative, the second one is morepractically relevant. The specification monitors the network traffic of a serverbased on the source and destination IP of requests, tcp flags, and the lengthof the payload [6]. The specification counts the number of incoming connectionsand computes the workload, i.e., the number of bytes received over push requests.

5 https://github.com/reactive-systems/Lola2RustArtifact

Verified Rust Monitors for Lola Specifications 15

Time [s] Memory [MB]

0

200

400

600

800

1,000

(a) Altitude Monitor

Time [s] Memory [MB]

0

1,000

2,000

3,000

4,000

5,000

(b) Network Traffic Monitor

Fig. 4: Results of 20 runs in terms of running time (blue, in seconds) and memoryconsumption (orange, in MB) for the verification of the annotated Rust code ofthe specification, where the altitude of a drone is monitored (cf. Listing 1.1),and the network traffic monitor specification.

is checked by the Z3 [21] smt solver. Thus, our toolchain enables completelyautomatic proof checking.

The experiments were conducted on a machine with a 3.1GHz Dual-Core Inteli5 processor with 16GB of ram. The artifacts for the evaluation are available ongithub.5 In all experiments, the compilation itself has a negligible running timeof under ten milliseconds and memory consumption of less than 4MB, mainlydue to the RTLola frontend. As expected, the verification of the annotated rustcode using Prusti and the Viper toolkit takes significant time and memory. Whilethe translation into the smt model is deterministic and can be parallelized, theverification with Z3 exhibits generally high and unpredictable running time.

We discuss the results of compiling and verifying three Lola specification ofvarying size. The process works flawlessly on two of them while the third oneoccasionally runs into timeouts and inconclusive verification results.

First, we consider the specification from Listing 1.1, where the altitude ofa drone is monitored. The results in terms of both running time and memoryconsumption for 20 runs are depicted in Figure 4a. Note that the y-axis displaysboth the running time in seconds (left plot) and the memory consumption inmegabytes (right plot). The plot shows that the running time never exceeds600s with a median of 225s. The memory consumption is significantly morestable ranging between 648 and 711MB with one outlier (914MB).

While the first specification was short and illustrative, the second one is morepractically relevant. The specification monitors the network traffic of a serverbased on the source and destination IP of requests, tcp flags, and the lengthof the payload [6]. The specification counts the number of incoming connectionsand computes the workload, i.e., the number of bytes received over push requests.

5 https://github.com/reactive-systems/Lola2RustArtifact

altitude flight phase

Detected implicit assumption on input stream!

EXPERIMENTS

13

Verified Rust Monitors for Lola Specifications 15

Time [s] Memory [MB]

0

200

400

600

800

1,000

(a) Altitude Monitor

Time [s] Memory [MB]

0

1,000

2,000

3,000

4,000

5,000

(b) Network Traffic Monitor

Fig. 4: Results of 20 runs in terms of running time (blue, in seconds) and memoryconsumption (orange, in MB) for the verification of the annotated Rust code ofthe specification, where the altitude of a drone is monitored (cf. Listing 1.1),and the network traffic monitor specification.

is checked by the Z3 [21] smt solver. Thus, our toolchain enables completelyautomatic proof checking.

The experiments were conducted on a machine with a 3.1GHz Dual-Core Inteli5 processor with 16GB of ram. The artifacts for the evaluation are available ongithub.5 In all experiments, the compilation itself has a negligible running timeof under ten milliseconds and memory consumption of less than 4MB, mainlydue to the RTLola frontend. As expected, the verification of the annotated rustcode using Prusti and the Viper toolkit takes significant time and memory. Whilethe translation into the smt model is deterministic and can be parallelized, theverification with Z3 exhibits generally high and unpredictable running time.

We discuss the results of compiling and verifying three Lola specification ofvarying size. The process works flawlessly on two of them while the third oneoccasionally runs into timeouts and inconclusive verification results.

First, we consider the specification from Listing 1.1, where the altitude ofa drone is monitored. The results in terms of both running time and memoryconsumption for 20 runs are depicted in Figure 4a. Note that the y-axis displaysboth the running time in seconds (left plot) and the memory consumption inmegabytes (right plot). The plot shows that the running time never exceeds600s with a median of 225s. The memory consumption is significantly morestable ranging between 648 and 711MB with one outlier (914MB).

While the first specification was short and illustrative, the second one is morepractically relevant. The specification monitors the network traffic of a serverbased on the source and destination IP of requests, tcp flags, and the lengthof the payload [6]. The specification counts the number of incoming connectionsand computes the workload, i.e., the number of bytes received over push requests.

5 https://github.com/reactive-systems/Lola2RustArtifact

Verified Rust Monitors for Lola Specifications 15

Time [s] Memory [MB]

0

200

400

600

800

1,000

(a) Altitude Monitor

Time [s] Memory [MB]

0

1,000

2,000

3,000

4,000

5,000

(b) Network Traffic Monitor

Fig. 4: Results of 20 runs in terms of running time (blue, in seconds) and memoryconsumption (orange, in MB) for the verification of the annotated Rust code ofthe specification, where the altitude of a drone is monitored (cf. Listing 1.1),and the network traffic monitor specification.

is checked by the Z3 [21] smt solver. Thus, our toolchain enables completelyautomatic proof checking.

The experiments were conducted on a machine with a 3.1GHz Dual-Core Inteli5 processor with 16GB of ram. The artifacts for the evaluation are available ongithub.5 In all experiments, the compilation itself has a negligible running timeof under ten milliseconds and memory consumption of less than 4MB, mainlydue to the RTLola frontend. As expected, the verification of the annotated rustcode using Prusti and the Viper toolkit takes significant time and memory. Whilethe translation into the smt model is deterministic and can be parallelized, theverification with Z3 exhibits generally high and unpredictable running time.

We discuss the results of compiling and verifying three Lola specification ofvarying size. The process works flawlessly on two of them while the third oneoccasionally runs into timeouts and inconclusive verification results.

First, we consider the specification from Listing 1.1, where the altitude ofa drone is monitored. The results in terms of both running time and memoryconsumption for 20 runs are depicted in Figure 4a. Note that the y-axis displaysboth the running time in seconds (left plot) and the memory consumption inmegabytes (right plot). The plot shows that the running time never exceeds600s with a median of 225s. The memory consumption is significantly morestable ranging between 648 and 711MB with one outlier (914MB).

While the first specification was short and illustrative, the second one is morepractically relevant. The specification monitors the network traffic of a serverbased on the source and destination IP of requests, tcp flags, and the lengthof the payload [6]. The specification counts the number of incoming connectionsand computes the workload, i.e., the number of bytes received over push requests.

5 https://github.com/reactive-systems/Lola2RustArtifact

altitude

On corrected spec:

6 – 16min 1.38 – 1.66GB

2 T/O (10%) 4 fails (20%)

flight phase

Detected implicit assumption on input stream!

EXPERIMENTS

13

Verified Rust Monitors for Lola Specifications 15

Time [s] Memory [MB]

0

200

400

600

800

1,000

(a) Altitude Monitor

Time [s] Memory [MB]

0

1,000

2,000

3,000

4,000

5,000

(b) Network Traffic Monitor

Fig. 4: Results of 20 runs in terms of running time (blue, in seconds) and memoryconsumption (orange, in MB) for the verification of the annotated Rust code ofthe specification, where the altitude of a drone is monitored (cf. Listing 1.1),and the network traffic monitor specification.

is checked by the Z3 [21] smt solver. Thus, our toolchain enables completelyautomatic proof checking.

The experiments were conducted on a machine with a 3.1GHz Dual-Core Inteli5 processor with 16GB of ram. The artifacts for the evaluation are available ongithub.5 In all experiments, the compilation itself has a negligible running timeof under ten milliseconds and memory consumption of less than 4MB, mainlydue to the RTLola frontend. As expected, the verification of the annotated rustcode using Prusti and the Viper toolkit takes significant time and memory. Whilethe translation into the smt model is deterministic and can be parallelized, theverification with Z3 exhibits generally high and unpredictable running time.

We discuss the results of compiling and verifying three Lola specification ofvarying size. The process works flawlessly on two of them while the third oneoccasionally runs into timeouts and inconclusive verification results.

First, we consider the specification from Listing 1.1, where the altitude ofa drone is monitored. The results in terms of both running time and memoryconsumption for 20 runs are depicted in Figure 4a. Note that the y-axis displaysboth the running time in seconds (left plot) and the memory consumption inmegabytes (right plot). The plot shows that the running time never exceeds600s with a median of 225s. The memory consumption is significantly morestable ranging between 648 and 711MB with one outlier (914MB).

While the first specification was short and illustrative, the second one is morepractically relevant. The specification monitors the network traffic of a serverbased on the source and destination IP of requests, tcp flags, and the lengthof the payload [6]. The specification counts the number of incoming connectionsand computes the workload, i.e., the number of bytes received over push requests.

5 https://github.com/reactive-systems/Lola2RustArtifact

Verified Rust Monitors for Lola Specifications 15

Time [s] Memory [MB]

0

200

400

600

800

1,000

(a) Altitude Monitor

Time [s] Memory [MB]

0

1,000

2,000

3,000

4,000

5,000

(b) Network Traffic Monitor

Fig. 4: Results of 20 runs in terms of running time (blue, in seconds) and memoryconsumption (orange, in MB) for the verification of the annotated Rust code ofthe specification, where the altitude of a drone is monitored (cf. Listing 1.1),and the network traffic monitor specification.

is checked by the Z3 [21] smt solver. Thus, our toolchain enables completelyautomatic proof checking.

The experiments were conducted on a machine with a 3.1GHz Dual-Core Inteli5 processor with 16GB of ram. The artifacts for the evaluation are available ongithub.5 In all experiments, the compilation itself has a negligible running timeof under ten milliseconds and memory consumption of less than 4MB, mainlydue to the RTLola frontend. As expected, the verification of the annotated rustcode using Prusti and the Viper toolkit takes significant time and memory. Whilethe translation into the smt model is deterministic and can be parallelized, theverification with Z3 exhibits generally high and unpredictable running time.

We discuss the results of compiling and verifying three Lola specification ofvarying size. The process works flawlessly on two of them while the third oneoccasionally runs into timeouts and inconclusive verification results.

First, we consider the specification from Listing 1.1, where the altitude ofa drone is monitored. The results in terms of both running time and memoryconsumption for 20 runs are depicted in Figure 4a. Note that the y-axis displaysboth the running time in seconds (left plot) and the memory consumption inmegabytes (right plot). The plot shows that the running time never exceeds600s with a median of 225s. The memory consumption is significantly morestable ranging between 648 and 711MB with one outlier (914MB).

While the first specification was short and illustrative, the second one is morepractically relevant. The specification monitors the network traffic of a serverbased on the source and destination IP of requests, tcp flags, and the lengthof the payload [6]. The specification counts the number of incoming connectionsand computes the workload, i.e., the number of bytes received over push requests.

5 https://github.com/reactive-systems/Lola2RustArtifact

altitude

On corrected spec:

6 – 16min 1.38 – 1.66GB

2 T/O (10%) 4 fails (20%)

flight phase

I. SUCCESSFULLY DETECTED SPECIFICATION ERROR II. VERIFIED MONITORS FOR COMPLEX SPECIFICATIONS

Detected implicit assumption on input stream!

CONCLUSION

EXPERIMENTS

13

Verified Rust Monitors for Lola Specifications 15

Time [s] Memory [MB]

0

200

400

600

800

1,000

(a) Altitude Monitor

Time [s] Memory [MB]

0

1,000

2,000

3,000

4,000

5,000

(b) Network Traffic Monitor

Fig. 4: Results of 20 runs in terms of running time (blue, in seconds) and memoryconsumption (orange, in MB) for the verification of the annotated Rust code ofthe specification, where the altitude of a drone is monitored (cf. Listing 1.1),and the network traffic monitor specification.

is checked by the Z3 [21] smt solver. Thus, our toolchain enables completelyautomatic proof checking.

The experiments were conducted on a machine with a 3.1GHz Dual-Core Inteli5 processor with 16GB of ram. The artifacts for the evaluation are available ongithub.5 In all experiments, the compilation itself has a negligible running timeof under ten milliseconds and memory consumption of less than 4MB, mainlydue to the RTLola frontend. As expected, the verification of the annotated rustcode using Prusti and the Viper toolkit takes significant time and memory. Whilethe translation into the smt model is deterministic and can be parallelized, theverification with Z3 exhibits generally high and unpredictable running time.

We discuss the results of compiling and verifying three Lola specification ofvarying size. The process works flawlessly on two of them while the third oneoccasionally runs into timeouts and inconclusive verification results.

First, we consider the specification from Listing 1.1, where the altitude ofa drone is monitored. The results in terms of both running time and memoryconsumption for 20 runs are depicted in Figure 4a. Note that the y-axis displaysboth the running time in seconds (left plot) and the memory consumption inmegabytes (right plot). The plot shows that the running time never exceeds600s with a median of 225s. The memory consumption is significantly morestable ranging between 648 and 711MB with one outlier (914MB).

While the first specification was short and illustrative, the second one is morepractically relevant. The specification monitors the network traffic of a serverbased on the source and destination IP of requests, tcp flags, and the lengthof the payload [6]. The specification counts the number of incoming connectionsand computes the workload, i.e., the number of bytes received over push requests.

5 https://github.com/reactive-systems/Lola2RustArtifact

Verified Rust Monitors for Lola Specifications 15

Time [s] Memory [MB]

0

200

400

600

800

1,000

(a) Altitude Monitor

Time [s] Memory [MB]

0

1,000

2,000

3,000

4,000

5,000

(b) Network Traffic Monitor

Fig. 4: Results of 20 runs in terms of running time (blue, in seconds) and memoryconsumption (orange, in MB) for the verification of the annotated Rust code ofthe specification, where the altitude of a drone is monitored (cf. Listing 1.1),and the network traffic monitor specification.

is checked by the Z3 [21] smt solver. Thus, our toolchain enables completelyautomatic proof checking.

The experiments were conducted on a machine with a 3.1GHz Dual-Core Inteli5 processor with 16GB of ram. The artifacts for the evaluation are available ongithub.5 In all experiments, the compilation itself has a negligible running timeof under ten milliseconds and memory consumption of less than 4MB, mainlydue to the RTLola frontend. As expected, the verification of the annotated rustcode using Prusti and the Viper toolkit takes significant time and memory. Whilethe translation into the smt model is deterministic and can be parallelized, theverification with Z3 exhibits generally high and unpredictable running time.

We discuss the results of compiling and verifying three Lola specification ofvarying size. The process works flawlessly on two of them while the third oneoccasionally runs into timeouts and inconclusive verification results.

First, we consider the specification from Listing 1.1, where the altitude ofa drone is monitored. The results in terms of both running time and memoryconsumption for 20 runs are depicted in Figure 4a. Note that the y-axis displaysboth the running time in seconds (left plot) and the memory consumption inmegabytes (right plot). The plot shows that the running time never exceeds600s with a median of 225s. The memory consumption is significantly morestable ranging between 648 and 711MB with one outlier (914MB).

While the first specification was short and illustrative, the second one is morepractically relevant. The specification monitors the network traffic of a serverbased on the source and destination IP of requests, tcp flags, and the lengthof the payload [6]. The specification counts the number of incoming connectionsand computes the workload, i.e., the number of bytes received over push requests.

5 https://github.com/reactive-systems/Lola2RustArtifact

altitude

On corrected spec: 6 – 16min

1.38 – 1.66GB 2 T/O (10%) 4 fails (20%)

flight phase

Detected implicit assumption on input stream

MORE INFORMATION: Compiled Code: • Github → Lola2RustArtifact In Paper: • Specification Analysis • Concurrent Implementation

BOTTOM LINE: • Quis Custodiet Ipsos Custodes?

Viper does! • Successful verification • Highly performant Code

QUIS CUSTODIET IPSOS CUSTODES?

5

01010010 01010110 00110010 00110000

Never injure humans. Obey orders. Protect yourself.

Lola Specification

observesImpl Monitor { #"invariant = … ] while let Some(i) = get_input() { … }}

Rust Code

verifies MONITOR

Our Goal: Prove the Monitor Correct!