CISPA - react.uni-saarland.de · Lola Specification es Impl Monitor { # invariant = … ] while...
Transcript of CISPA - react.uni-saarland.de · Lola Specification es Impl Monitor { # invariant = … ] while...
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!