Theorem Proving

1
Theorem Proving

• One of the problems with model checking based
  methods is that they can be applied only to
  finite state systems.
• However, reasoning about infinite state systems
  is equally important and methods must be
  developed which enable a modeller to attack the
  infinite.
• However, the combined use of theorem proving and
  model checking is justified because they examine
  ALL BEHAVIOURS rather than simulation which do
  only a partial check.
• The biggest problem with theorem proving is its
  steep learning curve. It takes about 6 months to
  master a good automated theorem prover as PVS.

2
Theorem Proving - Definition

• Theorem proving could be defined as follows
  (Rushby 99)
• Specify the system, a required property, the
  assumptions, and necessary background theories as
  formulas in a single logic.
• Prove that background assumptions system
  is a model of the property.
• Theorem Proving works best on data intensive
  systems

3
Theorem Proving compared with Model Checking
(from Rushby 99)

• When theorem proving is used, the system is not
  restricted to finite-state (or even to a
  transition system)!!
• The required property is not restricted to
  invariance or eventuality properties that can be
  expressed in Computation Tree Logic (CTL)
• The assumptions are not restricted to fairness
  assumptions, but rather, they can be arbitrary
  theories
• However, with the increased freedom in logics and
  theories comes less automation and more involved
  human involvement in proofs

4
PVS Briefly

• PVS is a verification system. It provides a
  general purpose specification language integrated
  with a theorem prover, model checker and other
  tools
• PVS can be obtained free of charge for
  non-commercial purposes from SRI (URL
  http//www.csl.sri.com/pvs.html)
• PVS runs on SunOS, Solaris, IBM AIX, and Linux
• PVS has been applied in several areas
  safety-critical systems, hardware, distributed
  algorithms, and mathematics
• The use of PVS is best illustrated through an
  example that follows

5
Cache Coherency protocol (Futurebus) (Rushby 99)

• A multiprocessor system consists of several
  processes and a shared memory
• Each process maintains a local cache of the
  memory, and the state of this copy changes as
  memory is being written to, etc.
• Each change made by any processor must be
  reflected in other processors cache as well to
  maintain the notion of coherency

P1
P5
P2
P3
P4
MEM
6
Cache Coherency - 2

• The memory is organized into lines and for the
  purposes of this study, it is sufficient to
  consider the status changes of only a single line
• Each line has a status in a processors cache
• If a line status is INVALID, the line is not
  present in this cache
• If a line status is SHARED, the line is present
  in a read-only mode
• If a line status is EXCLUSIVE, the line is
  present for read-write access
• There are three key memory operations
• Read-shared get a shared copy of the line
• Read-modified get an exclusive copy of the line
• Write-back give up the exclusive copy

7
Cache Coherency - 3

• For the protocol to be correct, we should show
  that at most one processor has an exclusive copy
  of a single line in its cache
• cache_arrayN posnat THEORY
• BEGIN
• processor TYPE below(N)
• line_status TYPE invalid, shared,
  exclusive
• transactions TYPE idle, read_shared,
  read_modified, write_back
• protocol_state TYPE
• cache processor -gt line_status,
• transaction transactions,
• bus_master processor

8
Cache Coherency - 4

• ps, ps0, ps1 VAR protocol_state
• p_next(ps0, ps1) bool
• LET p bus_master(ps0), t
  transaction(ps0) IN
• (idle?(t) AND do_idle(ps0,
  ps1))
• OR (read_shared?(t) AND
  do_read_shared(ps0, ps1)(p))
• OR (read_modified?(t) AND
  do_read_modified(ps0, ps1)(p))
• OR (write_back?(t) AND
  do_write_back(ps0, ps1)(p))
• do_idle(ps0, ps1) bool (ps1 ps0)
• The Bus Master is the process that initiated
  the current event on the bus

9
Cache Coherency - 5

• p, q, r VAR processor
• do_read_shared(ps0, ps1)(p) bool
• invalid?(cache(ps0)(p)) AND
  shared?(cache(ps1)(p))
• AND ((EXISTS q exclusive?(cache(ps0)(q))
• AND NOT exlusive?(cache(ps1)
  (q))
• AND (FORALL r r/q
  IMPLIES
• exclusive?(cache(ps1
  )(r ))
• exclusive?(cache(ps
  0)(r ))))
• OR (FORALL q NOT
  exclusive?(cache(ps0)(q))
• AND NOT
  exclusive?(cache(ps1)(q))))
• This transition allows reading of a line in
  memory when no one has an exclusive copy of the
  line in its cache

10
Cache Coherency - 6

• do_read_modified(ps0, ps1)(p) bool
• shared?(cache(ps0)(p))
• AND (FORALL q cache(ps1)(q)
• IF p q THEN
  exclusive
• ELSIF
  shared?(cache(ps0)(q)) THEN invalid
• ELSE cache(ps0)(q)
  ENDIF)
• This transition makes the bus master
  exclusive, and invalidates all those processes
  who had a read access to the memory line

11
Cache Coherency - 7

• do_write_back(ps0, ps1)(p) bool
• exclusive?(cache(ps0)(p))
• AND cache(ps1) cache(ps0) WITH (p)
  invalid
• This function shows how the exclusive right
  is given up by the bus master

12
Initial State and Invariant assertions

• The next task is to identify the initial states
  and the alleged properties we want to verify.
• p_init(ps) bool FORALL p
  invalid?(cache(ps)(p))
• p_safe(ps) bool
• FORALL p, q
• exclusive?(cache(ps)(p)) AND
  exclusive?(cache(ps)(q))
• IMPLIES p q
• invariant THEOREM (p_init(ps) IMPLIES
  p_safe(ps))
• AND (p_safe(ps0) AND p_next(ps0,
  ps1) IMPLIES p_safe(ps1))

13
What does theorem proving look like?

• Now, the only thing to do is to actually prove
  our initial conjecture or come up with a
  counterexample. This is what the theorem
  prover PVS looks like in action
• invariant
• -----------
• 1 (FORALL (ps, ps0, ps1 protocol_state)
• (p_init(ps) IMPLIES p_safe(ps))
• AND (p_safe(ps0) AND p_next(ps0,
  ps1)
• IMPLIES
  p_safe(ps1)))
• Rule?

14
PVS in action - 1

• When the above goal is simplified with
  (skosimp) and (ground) which stand for
  skolemization and simplifying and propositional
  simplification, respectively, we get the
  following output
• This yields 2 subgoals
• invariant.1
• -1 p_init(ps!1)
• ---------
• 1 p_safe(ps!1)
• Rule?
• This branch of the proof is discharged with the
  strategy (grind)

15
PVS in action - 2

• We continue with our proof and get the following
• This completes the proof of invariant.1
• -1 p_safe(ps0!1)
• -2 p_next(ps0!1, ps1!1)
• ---------
• 1 p_safe(ps1!1)
• Rule?
• Now the applications of (expand p_next) and
  (ground) are used to divide the above problem to
  four cases.

16
PVS in action - 3

• Applying propositional simplification
• and decision procedures
• this yields 4 subgoals
• invariant 2.1
• -1 idle?(transaction(ps0!1))
• -2 do_idle(ps0!1, ps1!1)
• -3 p_safe(ps0!1)
• --------
• 1 p_safe(ps1!1)
• Rule?
• The above goal is proved by the (grind) strategy

17
PVS in action - 4

• Similarly, the last invariant can be proved as
  follows
• invariant.2.4
• -1 write_back?(transaction(ps0!1))
• -2 do_write_back(ps0!1,
  ps1!1)(bus_master(ps0!1))
• -3 p_safe(ps0!1)
• ----------
• 1 p_safe(ps1!1)
• Rule?
• This is proved by using the strategy (grind
  if-match all)

18
PVS in action - 5

• invariant.2.2
• -1 read_shared?(transaction(ps0!1))
• -2 do_read_shared(ps0!1,
  ps1!1)(bus_master(ps0!1))
• -3 p_safe(ps0!1)
• ------------
• 1 p_safe(ps1!1)
• Rule?

19
PVS in action - 6

• The previous theorem is proven by the following
  interactive proof
• (grind if-match NIL)
• ((1
• (inst 8 q!2)
• (assert)
• (inst 9 q!1)
• (assert)
• (inst 9 q!2)
• (assert))
• (2 (inst 6 p!1) (assert)))

20
PVS in action -7

• invariant.2.3
• -1 read_modified?(transaction(ps0!1))
• -2 do_read_modified(ps0!1, ps1!1)
  (bus_master(ps0!1))
• -3 p_safe(ps1!1)
• ----------
• 1 p_safe(ps1!1)
• Rule?
• This proof is once again started with (grind
  if-match NIL) but we run into a difficulty that
  we cant solve

21
PVS in action - 8

• -1 q!1 lt N
• -2 p!1 lt N
• -3 read_modified?(transaction(ps0!1))
• -4 shared?(cache(ps0!1)(bus_master(ps0!1)))
• -5 FORALL (q processor)
• cache (ps1!1) (q)
• IF bus_master(ps0!1) q
• THEN exclusive
• ELSIF shared?(cache(ps0!1)(q))
• THEN invalid
• ELSE cache(ps0!1)(q) ENDIF
• -6 FORALL (p processor)
• exclusive?(cache(ps0!1)(p))
• IMPLIES FORALL (q processor)
• exclusive?(cache(ps0!1)(q)) IMPLIES pq
• -7 exclusive?(cache(ps1!1)(p!1))
• -8 exclusive?(cache(ps1!1)(q!1))
• -----------------
• 1 p!1 q!1

22
PVS in action - 9

• The problem with the previous slide is that our
  specification doesnt say anything about a
  situation where a read_modified transaction is
  executed when someone is already in exclusive
  state
• However, this is in effect impossible, but to
  show it formally, we need to strengthen our
  safety invariant as follows If any processor
  has exclusive status, all the others must be
  invalid
• strong_p_safe(ps) bool
• FORALL p exclusive?(cache(ps)(p)) IMPLIES
• FORALL q q/p IMPLIES
  invalid?(cache(ps)(q))
• strong_invariant THEOREM
• (p_init(ps) IMPLIES strong_p_safe(ps))
• AND (strong_p_safe(ps0) AND
  p_next(ps0, ps1)
• IMPLIES strong_p_safe(ps1))

23
PVS and transition systems

• One of the most powerful, yet easy to grasp ideas
  in theoretical computer science is that of
  transition systems
• PVS has been adapted in such a way that it can
  handle the specification of transition systems as
  TABLES
• The example we will consider here relates to a
  cars cruise control system. Grab your seat and
  have fun!! )

24
PVS and transition systems 2

• The SCR method consists of state machines that
  interact with their environment by periodically
  sampling the values of monitored variables (i.e.
  inputs) and producing controlled variables (i.e.
  outputs).
• The state of an individual state machine is a
  mode
• Condition is a predicate on monitored variables
  (I.e. inputs)
• Event occurs when a monitored variable changes
  its value

25
PVS and transition systems - 3

• scr input, mode, output TYPE THEORY
• BEGIN
• condition TYPE predinput
• event TYPE predinput, input
• state TYPE mode mode, vars input
  
• transition_relation TYPE predstate,
  state
• mode_table TYPE mode, input, input -gt
  mode
• (notice that the new mode is
  specified as the function of the previous
• mode and the previous and the
  current inputs)

26
PVS and transition systems - 4

• trans (mt mode_table) transition_relation
  
• (LAMBDA (s, t state) mode(t)
  mt(mode(s), vars(s), vars(t)))
• the above definition constructs the
  transition relation from the mode table
• output_table TYPE mode, input, input -gt
  output
• the output table is constructed also from the
  previous mode and the previous and current inputs.

27
PVS and transition systems - 5

• The next task is to define what event
  constructors are
• event_constructor TYPE condition -gt
  event
• EC TYPE event_constructor
• p, q VAR input
• P VAR condition
• atT(P)(p, q) bool NOT P(p) P(q)
• atF(P)(p, q) bool P(p) NOT P(q)
• T(P)(p, q) bool P(p) P(q)
• F(P)(p, q) bool NOT P(p) NOT P(q)
• dc(P)(p, q) bool true

28
PVS and transition systems - 6

• The previous stuff was all preamble to the
  problem at hand. Heres the definition of the
  car cruise control system
• cruise THEORY
• BEGIN
• lever_pos TYPE activate, deactivate,
  resume
• engine_state TYPE off, ignition,
  running
• monitored_vars TYPE
• 
  engine engine_state,
• 
  toofast bool,
• brake
  bool,
• lever
  lever_pos

29
PVS and transition systems - 7

• modes TYPE off, inactive, cruise,
  override
• null TYPE
• IMPORTING scr monitored_vars, modes,
  null
• next we must start to define the conditions
  accordingly
• activatecondition LAMBDA (mmonitored_vars)
  activate?(lever(m))
• resume condition LAMBDA (mmonitored_vars)
  resume?(lever(m))
• runningcondition LAMBDA (m monitored_vars)
  running?(engine(m))
• Ignitedcondition LAMBDA (mmonitored_vars)
• 
  ignition?(engine(m)) OR running?(engine(m))

30
PVS and transition systems - 8

• brake condition LAMBDA (m
  monitored_vars) brake(m)
• toofastcondition LAMBDA (m
  monitored_vars) toofast(m)
• Then we will describe the rows of the table. To
  do that, we must define the notion of PC or
  pairwise conjunction. It is defined as a
  collection of functions that each take a list of
  event constructors and a list of conditions and
  conjoins their pairwise applications.
• PC(A)(a)(p, q) bool A(a)(p, q)
• PC(A, B)(a, b)(p, q) bool A(a)(p,q)
  B(b)(p, q)
• PC(A, B, C, D, E, FF, G)(a, b, c, d, e, f,
  g)(p, q) bool A(a)(p, q)
• B(b)(p, q) G(g)(p, q)

31
PVS and transition systems - 9

• original(s modes, (p, q monitored_vars)) modes
  
• LET
• x conds7 (ignited, running, toofast, brake,
  activate, deactivate,
• resume),
• X (LAMBDA (a,b,c,d,e,f,g EC)
  PC(a,b,c,d,e,f,g)(x)(p, q))
• IN TABLE s
• off TABLE
• -----------------------------------
  --------------------
• X( atT, dc, dc, dc, dc,
  dc, dc) inactive
• -----------------------------------
  --------------------
• ELSE
  off
  
• ---------------------------------------
  ----------------------
• ENDTABLE

32
PVS and transition systems 10

• inactive TABLE
• ------------------------------------
  -------------------
• X( atF , dc , dc , dc , dc ,
  dc , dc) off
• ------------------------------------
  -------------------
• X( T , T , dc , F ,
  atT , dc , dc) cruise
• ------------------------------------
  -------------------
• ELSE
  inactive
• ------------------------------------------
  --------------------
• ENDTABLE

33
PVS and transition systems - 11

• cruise TABLE
• -------------------------------------
  ------------------
• X( atF , dc , dc , dc , dc ,
  dc , dc) off
• -------------------------------------
  ------------------
• X( dc , atF , dc , dc , dc ,
  dc , dc) inactive
• -------------------------------------
  ------------------
• X( dc , dc , atT, dc , dc ,
  dc , dc) inactive
• -------------------------------------
  ------------------
• X( dc , dc , dc , atT, dc ,
  dc , dc) override
• -------------------------------------
  ------------------
• X( dc , dc , dc , dc , dc ,
  atT , dc) override
• -------------------------------------
  ------------------
• ELSE
  cruise
• --------------------------------------------
  ------------------ ENDTABLE

34
PVS and transition systems - 12

• override TABLE
• -------------------------------------
  ------------------
• X( atF , dc , dc , dc , dc ,
  dc , dc) off
• -------------------------------------
  ------------------
• X( dc , atF , dc , dc , dc ,
  dc , dc) inactive
• -------------------------------------
  ------------------
• X( T , T , dc , F ,
  atT, dc , dc) cruise
• -------------------------------------
  ------------------
• X( T , T , dc , F , dc
  , dc , atT) cruise
• -------------------------------------
  ------------------
• ELSE
  override
• --------------------------------------------
  ------------------
• ENDTABLE

35
PVS and transition systems - 13

• One more definition needed for the example to
  run is
• conds1type condition
• conds2type condition, condition
• conds7type condition, condition,
  condition, condition, condition,
• condition,
  condition

36
PVS and transition systems - 14

• When we typecheck the above description, a number
  of TCCs (Type Correctness Conditions) are
  generated and each one must be discharged by the
  theorem prover
• However, our table as is does not exhibit
  completely deterministic behaviour. We get the
  following sequent in proof
• Trying repeated skolemization, instantiation,
  and if-lifting
• this yields 8 subgoals
• original_TCC2.1
• -1 cruise?(s!1)
• -2 toofast(q!1)
• -3 deactivate?(lever(q!1))
• ----------
• 1 toofast(p!1)
• 2 deactivate?(lever(p!1))
• Rule?

37
PVS and transition systems - 15

• The problem on the last slide was that in cruise
  state the eventuality that toofast and deactivate
  both go from FALSE to TRUE is ambiguous
• In the spec, the first causes a transition to
  inactive mode, and the second one a transition to
  override mode.
• The problem is circumvented when we add the
  condition that toofast be FALSE when a transition
  from cruise to override mode are taken
• Also, the transition to inactive need to be
  conditioned on ignited staying TRUE.
• We should also use the axiom engine_prop
  AXIOM toofast(p) gt running(p)

38
PVS and transition systems - 16

• Once these changes are made, the TCCs may be
  proven by
• (then (grind)(lemma engine_prop)(grind
  if-match all))
• Once the TCCs have been discharged by PVS, we
  know that our resulting table is deterministic.
• 16 slides to say this simple thing !! ? !!
  I take the blame, alright.

39
Conclusion

• Theorem proving is much more labour intensive
  than model checking
• However, theorem proving provides the
  verification engineer with a way to attack the
  infinite by e.g. induction axioms and all
  theorems from set theory, and natural numbers.
• I warmly suggest that you take a look at the web
  pages of PVS and start to learn it while you
  study. You never know, after a couple of years,
  people who can do theorem proving might be the
  hottest studs in the job market !