INF672 Protocol Safety and Verification. Karthik Bhargavan Xavier Rival Thomas Clausen

Transcription

1 INF672 Protocol Safety and Verication Karthik Bhargavan Xavier Rival Thomas Clausen 1

2 Course Outline Lecture 1 [Today, Sep 15] Introduction, Motivating Examples Lectures 2-4 [Sep 22,29, Oct 6] Network Protocol Verication: Spin Lectures 5-8 [Oct 13, 20, 27, Nov 3] Program Verication: Properties, Tools & Techniques Lecture 9 [Nov 10] Security Protocol Verication: ProVer Lecture 10 [Nov 17] Exam

3 Outline Modeling Protocols Examples in Promela Specying Properties Examples in LTL Verying Models Model-checking with SPIN

4 Protocols as Distributed Programs Protocols are programs that run on a network Reactive to non-deterministic environment Concurrent execution Asynchronous communication Distributed architecture

5 Formal Protocol Analysis How do we ensure that a protocol (and its implementation) achieves its intended goals? Can we formally state a correctness theorem? Can we (semi-)automatically prove such theorems? Can we (semi-)automatically nd counterexamples? Automation is often necessary There are too many cases to consider by hand Proofs and counterexamples should be reproducible

6 Testing vs. Verication Testing distributed programs is hard Dcult to observe events Dcult to control environment, scheduling, timing Too many scenarios and corner cases Verying their design should be easier Model the protocol in a high-level language Compose it with a model of the environment Analyze its traces for desired properties

7 Modeling Protocols Today, we shall very models written in Promela Promela: Process Meta Language [Holzmann 91] A language for communicating nite state machines Originally designed for communications protocols Can be analyzed by the Spin model checker Spin: Model checker for Promela

8 Example: Forwarding in a Network D S Each node runs a forwarding process It consults a static forwarding table It reacts to application requests and network events

9 Forwarder: Reactive, Non-Deterministic proctype forwarder (int me) { int next[nodes]; int ldest,src,dest; mtype m; } do :: net? ldest,dest,m -> :: ldest == me -> :: dest == me -> app_out! src,dest,m net! next[dest],dest,m :: app_in? me,dest,m -> :: dest == me -> skip net! next[dest],dest,m od Syntax: proctype describes a process mtype is an enumeration do/od is a while loop with non-determinism / is a conditional with non-determinism net?x,y,z receives a message on a channel net app_out!x,y,z sends a message on a channel app_out Features: Reactive to messages on multiple channels Non-deterministic, non-terminating

10 Forwarder: Channels and State mtype = {req, resp}; typedef table { } int next[nodes]; table fwd[nodes]; chan app_in[nodes] = [0] of {int, mtype}; chan app_out[nodes] = [0] of {int, int, mtype}; chan net[nodes] = [3] of {int, int, mtype}; Buffered Channel (size 3) Enables asynchronous communication. Synchronous channel proctype forwarder (int me) { int src,dest; mtype m; do :: net[me]? src,dest,m; :: dest == me -> app_out[me]! src,dest,m net[fwd[me].next[dest]]! src,dest,m :: app_in[me]? dest,m; :: dest == me -> skip net[fwd[me].next[dest]]! me,dest,m od }

11 Forwarder: Reactive, Non-Deterministic Control States: {l1,,l7} Does it terminate? Suppose no of nodes = N Global memory: fwd: N * N * N Local memory: me, src, dest: N m: mtype Finite state (rel to N) Non-deterministic Desired Property: forwarder only sends messages for itself on app_out (What kind of property is it?) l1 l2 l3 l4 l5 l6 l7 proctype forwarder (int me) { int src,dest; mtype m; do :: net[me]? src,dest,m; :: dest == me -> app_out[me]! src,dest,m net[fwd[me].next[dest]]! src,dest,m :: app_in[me]? dest,m; :: dest == me -> skip net[fwd[me].next[dest]]! me,dest,m od }

12

13 Modeling the Environment init{ fwd[0].next[0] = 0; fwd[0].next[1] = 1; fwd[0].next[2] = 1; fwd[1].next[0] = 0; fwd[1].next[1] = 1; fwd[1].next[2] = 2; fwd[2].next[0] = 1; fwd[2].next[1] = 1; fwd[2].next[2] = 2; Syntax: Init runs rst and sets up processes in the model arrays must be initialized cell-by-cell run starts a process instance } run forwarder(0); run forwarder(1); run forwarder(2); app_in[0]! 2,req; app_out[2]? 0,2,req; app_in[2]! 0,resp; app_out[0]? 2,0,resp; net net app_in app_in app_out app_out

14 Forwarder: Concurrent Execution proctype forwarder (int me) { int src,dest; mtype m; do :: net[me]? src,dest,m; :: dest == me -> app_out[me]! src,dest,m net[fwd[me].next[dest]]! src,dest,m :: app_in[me]? dest,m; :: dest == me -> skip net[fwd[me].next[dest]]! me,dest,m od } State Space (Set of traces): All possible interleavings of the two processes How large can this get? (Exponential growth!) proctype forwarder (int me) { int src,dest; mtype m; do :: net[me]? src,dest,m; :: dest == me -> app_out[me]! src,dest,m net[fwd[me].next[dest]]! src,dest,m :: app_in[me]? dest,m; :: dest == me -> skip net[fwd[me].next[dest]]! me,dest,m od }

15 Run SPIN to Simulate Execution Generates a random trace, message sequence chart. Veries all assertions in code. Very useful for nding simple bugs in the model.

16 Forwarder: Deadlock Freedom proctype forwarder (int me) { int src,dest; mtype m; do :: net[me]? src,dest,m; :: dest == me -> app_out[me]! src,dest,m net[fwd[me].next[dest]]! src,dest,m :: app_in[me]? dest,m; :: dest == me -> skip net[fwd[me].next[dest]]! me,dest,m od } Desired Property: Forwarders do not get stuck (What kind of property is it?) proctype forwarder (int me) { int src,dest; mtype m; do :: net[me]? src,dest,m; :: dest == me -> app_out[me]! src,dest,m net[fwd[me].next[dest]]! src,dest,m :: app_in[me]? dest,m; :: dest == me -> skip net[fwd[me].next[dest]]! me,dest,m od }

17 Preventing the Deadlock proctype forwarder (int me) { int src,dest; mtype m; do :: net[me]? src,dest,m; :: dest == me -> app_out[me]! src,dest,m net[fwd[me].next[dest]]! src,dest,m :: app_in[me]? dest,m; :: dest == me -> skip :: net[fwd[me].next[dest]]! me,dest,m; :: full(net[fwd[me].next[dest]]) -> skip; od } Desired Property: Forwarders do not get stuck (What kind of property is it?) Blocking statements: Reading from an empty channel Writing to a full channel Waiting on synchronous channel for input/output Modeling choices: Drop packets when network channel is full Guarantee that environment won t send too many requests

18 Modeling Network Errors Protocols operate on a faulty network Packets may get lost, or re-ordered Network links (edges) might go down Forwarders (nodes) might go down New links and nodes may (re-)appear proctype lossynetwork() { int src,dest; mtype m; end: do :: net[0]? src,dest,m :: net[1]? src,dest,m :: net[2]? src,dest,m od}

19 Specying and Verying Properties

20 Deadlock Freedom proctype forwarder (int me) { int src,dest; mtype m; end: do :: net[me]? src,dest,m; :: dest == me -> app_out[me]! src,dest,m net[fwd[me].next[dest]]! src,dest,m :: app_in[me]? dest,m; :: dest == me -> skip :: net[fwd[me].next[dest]]! me,dest,m; :: full(net[fwd[me].next[dest]]) -> skip; od } Desired Property: Forwarders do not get stuck (What kind of property is it?) Processes must either terminate or should visit innitely often an end state A notion of non-termination for reactive programs Cannot get stuck in a branch Must always return to the toplevel process loop Automatically veried by SPIN Analyzes all reachable (nite) traces of the top-level process

21 Partial Correctness proctype application () { int src, dest; mtype m; do :: app_in[0]! 2,req :: app_out[0]? 2,0, resp :: app_in[2]! 0, resp :: app_out[0]? 2,0, resp :: app_in[1]! 0, req :: app_out[0]? 1,0,req :: app_in[1]! 2,req :: app_out[2]? 1,2,req :: app_out[0]? src,dest,m -> assert(dest==0); :: app_out[1]? src,dest,m -> assert(dest==1); :: app_out[2]? src,dest,m -> assert(dest==2); od } Promela code may have assertions that get checked during verication An assert must hold in all states of all runs of the program Desired Property: forwarder only sends messages for itself on app_out (What kind of property is it?)

22 Eventual Delivery bit sent; bit received; proctype application () { int src, dest; mtype m; app_in[0]! 2,req; sent = 1; app_out[2]? 2,0, req; received = 1; app_in[2]! 0, resp app_out[0]? 2,0, resp } ltl deliver {always (sent implies eventually received)}; Every packet that is sent is eventually delivered Not really true on a lossy network; so we disable loss To avoid channel deadlocks, we restrict the application to a xed number of messages The goal is written in PTL (LTL) Whenever a message is sent, it is eventually received always == G, eventually == E

23 Properties for Routing Suppose we extend forwarder with a router process that computes and updates the forwarding table We can specy its goals using PTL X Loop Freedom: an invariant (safety property) that the table does not contain loops always!(fwd[0].next[2] == 1 && fwd[1].next[2] == 0) always is used to encode invariants PTL does not have quantiers so we must write separate invariants for each node

24 Properties for Routing Suppose we extend forwarder with a router process that computes and updates the forwarding table We can specy its goals using PTL Convergence: a total correctness (liveness) property that the table eventually converges to the correct values always eventually (fwd[0].next[2] == 1) always eventually (fwd[1].next[2] == 2)

25 How does SPIN work?

26 Explicit State Model Checking Promela is given a formal trace semantics: Each state consists of: 1. control state of each active process 2. values assigned to each local and global variable 3. messages waiting in each channel Every line of the Promela model translates to a transition relation between states Some transitions are disabled: e.g. 1 == 0, in? x (when in is empty), out! x (when out is full) Others may lead to new states: e.grun creates a processes, out creates a message, assignments change state,

27 Explicit State Model Checking Spin compiles a Promela model to a C program that enumerates all the traces of the model It checks that each property holds for each trace Simple brute-force method Number of reachable states is bounded Number of nite traces is bounded Number of innite traces is unbounded, but for the properties we are trying to prove (PTL), we only need innite traces that end in a loop Memory- and time-intensive but decidable In reality, quite a bit more sophisticated

28 Enumerating Traces The Promela semantics yields a state transition graph for each model Spin performs depth rst search (DFS) through this graph Find rst enabled transition, add it to the current trace, move to the next state If there is no enabled transition, backtrack to previous state and continue with next enabled transition Advantages of DFS: When verying a property, Spin can stop at the rst trace that violates that property Easy to construct a counterexample a property fails Requires less memory than BFS

29 State Space Explosion Number of states can be exponential grows very fast with the number of processes Suppose we have two linear processes, each with a single trace with m transitions What is the total number of traces of their parallel composition? Can you calculate the number of interleavings? (2m!) / (m!) 2 It is exponential in m (at the very least) Other causes for exponential growth PTL formulas translated to automata Non-deterministic processes determinized

30 Trace Enumeration Optimizations The total number of traces is often infeasible to enumerate for realistic protocols Many optimizations Partial Order Reduction: Not all interleavings need to be considered since many are equivalent Abstraction: Sets of states can be considered as an equivalence class with respect to some properties Symbolic State Representation: Sets of explicit states can be efciently represented and manipulated using symbolic data structures like Binary Decision Diagrams

31 Justying bounded (nite) models Is it ok to very TCP for 10 messages or a routing protocol for 3 routers? Yes, the goal is to nd bugs Model checking is primarily a bug-hunting tool Coq is better for doing precise proofs Yes, we can prove that the bounded model is a sound abstraction of the full unbounded model This is sometimes possible (e.g. see FDR) Yes, your verication problem obeys the small model hypothesis: for every flaw in the protocol, there exists a small instance that exhibits the flaw This is more or less folklore in some elds, best not to rely on it for critical properties

32 Trace Enumeration Optimizations The total number of traces is often infeasible to enumerate for realistic protocols Many optimizations Partial Order Reduction: Not all interleavings need to be considered since many are equivalent Abstraction: Sets of states can be considered as an equivalence class with respect to some properties Symbolic State Representation: Sets of explicit states can be efciently represented and manipulated using symbolic data structures like Binary Decision Diagrams More detailed algorithms in next lecture

33 Summary We looked at modeling and verying protocols in Promela and Spin Today s TD: Using SPIN. Download You have been given the SPIN models for the forwarding examples. Try them out. You have been given a partial model of TCP (just the client). Write the server and prove some properties. Can you write a simple routing process?

34 Routing Information Protocol (RIP) Each node n maintains a routing table hops D : number of hops to D (no weighted edges) next D : next router on the path to D Global progress: Initially: All nodes know their neighbors (hops = 1) Finally: All nodes know distance & successor to all other nodes Local processes: Periodically send routing table to all neighbors Locally update hops D to 1 + min(received hops D ) Optional: Use timeouts to detect link breakage Verication goals: Loop freedom: a safety property Convergence: a liveness property