Z3 SMT solver interactive tutorial

I was lucky enough to be tasked with solving this problem in Azure! We were changing the method by which node firewall rules were automatically generated, and wanted a way to verify equivalence between the old and new versions for each node. The brute force approach was clearly out: we'd have had to check 2^72 IPv4 packets (32-bit source address field, 16-bit source port field, 16-bit destination port field, 8-bit protocol field). I bummed around trying to figure out a way to transform the firewall rules into some kind of minimal normalized form for direct comparison, but the Z3 approach turned out to be shockingly simple. When Z3 is really well-suited for a problem, it feels like straight up magic.

If you want to spoil the implementation details for yourself, it goes like this:

1) Set up bit vector variables of the proper size for each field in the IPv4 packet header.

2) Encode each firewall rule as a restriction on the variables from (1), then conjoin them to form a logical representation of a firewall.

3) Task Z3 with finding values for the variables in (1) for which one firewall is true, and the other is false.

Here's a simple example which you can run directly in the linked demo page, using two integer fields (source and destination) for simplicity:

  (declare-const src Int)
  (declare-const dst Int)
  (define-fun matches ((srcLower Int) (srcUpper Int) (dstLower Int) (dstUpper Int)) Bool
    (and (<= srcLower src) (<= src srcUpper) (<= dstLower dst) (<= dst dstUpper))
  )

  (define-fun firewall1 () Bool
    (and
      (matches 0 10 20 30)
      (not (matches 5 10 25 30))
    )
  )

  (define-fun firewall2 () Bool
    (and
      (matches 1 10 20 30)
      (not (matches 5 10 25 30))
    )
  )

  (assert (not (= firewall1 firewall2)))
  (check-sat)
  (get-model)

In practice this solution ran very quickly - less than a second for firewalls with hundreds of rules. It also gave a counterexample if the firewalls were not equivalent, which could be matched with offending rules and was very useful for debugging.

It was recorded [1] and I have example code and additional resources (papers, etc) on my site [2].

[1]: https://youtube.com/watch?v=ruNFcH-KibY

[2]: http://jelv.is/talks/compose-2016/

If you want to do more, you can extend the same process to synthesizing programs, not just verifying them. It doesn't scale too far, but otherwise it's like magic.

http://www.cs.tau.ac.il/~msagiv/courses/asv/z3py/guide-examp...

I had to use it in a practical lab to figure out the input of some hashing function (that would almost always hash to 0). By knowing all the constraints, solving it to know what the input should be becomes quite easy (at least easy compared to brute force).