4 ms·

To the extent that the model checker is complete and error free, and to the extent that that the model corresponds with that under instrumentation. I've been f

To the extent that the model checker is complete and error free, and to the extent that that the model corresponds with that under instrumentation. I've been far down that rabbit hole, and I've found cases where certain model checkers fail to find counterexamples that other model checkers find. Sometimes, this is due to errors in one or more of the checkers. Sometimes this is due to differences in representation. But, ultimately, the argument is epistemological. There is a corollary to the phrase: "Absence of proof isn't proof of absence": absence of a counterexample isn't an absence of a contradiction. As I've said, I love model checkers. But, they are not perfect, nor are they a panacea.

seattleeng 9y ago
That's very interesting, do you happen to have any toy examples where two model checkers differ?
- OscarCunningham 9y ago
  The other day I found an error in the Glucose SAT solver, but only when running with one of the options (-rcheck) changed away from its default setting. Glucose produced an alleged satisfying assignment that didn't actually work. So it's possible for mainstream SAT solvers to have errors, but I imagine their default configurations are very thoroughly tested.
  - schoen 9y ago
    It's interesting that the SAT solvers haven't put in a check at the very end to confirm that satisfying instances really satisfy the constraints, since that step is of course supposed to be the radically easy one! I guess their authors have had a lot of (usually well-placed) confidence in the solvers' logic and correctness.
    - OscarCunningham 9y ago
      When I told them about it they said that the -rcheck code was inherited from MiniSAT. Since it's also not enabled by default it's understandable that it hadn't been as thoroughly checked as usual. I wouldn't blame them if they just dump it instead of fixing it. But yes it is strange that it doesn't verify its outputs. On the other hand SAT solvers want to be as fast as possible and there shouldn't be a need to do it if the solver is operating correctly.
- nanolith 9y ago
  In early days of CBMC, it was possible to confuse it and get it to generate incorrect code for MiniSat. This is a representation issue. Those issues have long since been solved. Now CBMC's biggest problem is that of performance, and the developers are diligently working to improve this problem. When Z3 first came out, I built a machine model for a subset of ARMv7 and ran into a few cases that confused Z3, but worked fine in an equivalent MiniSat. However, this was years ago, and it appears -- although I have not verified this -- that the code in Z3 that I narrowed down in preparation to filing a bug report has already been fixed. The machine model has succumbed to bit rot; I abandoned the effort for a model I built on top of Coq. But, it would be interesting to attempt to fire it up again to see if it works now, and if so, use that to perform a binary search to find out when the fix was applied. It shouldn't be hard to create an example where two model checkers differ. Check current bug reports for two model checkers, and build a model that exploits the bug in one model checker but in which the other model checker works. These code bases are complex. They are increasingly infrequent, as the developers working on these model checkers are quite diligent, but subtle errors do exist.
nickpsecurity 9y ago
I said that about TLA+'s model checking. With things like Verasco, I figured a verified model checker could be done. As usual, I also searched for examples with SPIN since (a) they're used for similar things and (b) more people used SPIN in the past. Found this: https://www21.in.tum.de/~lammich/pub/nfm2016_por.pdf https://www21.in.tum.de/~lammich/pub/nfm2016_por.pdf Lammich was a name I recognized immediately for his work converting functional data structures to imperative ones in Isabelle/HOL. He and his collaborators have done quite a few interesting things so I'll just leave you the whole list: https://www21.in.tum.de/~lammich/ https://www21.in.tum.de/~lammich/ Far as lightweight methods, I recently summarized some recommendations with supporting case studies on Schneier's blog based on a message I sent someone trying to sell management on verification. It's a draft that I'm getting feedback on from various people rather than something I'm 100% solid on. The SPARK work combined with their book is still one of easiest methods in terms of automation achieved for covering specific properties that are often significant. https://www.schneier.com/blog/archives/2018/02/friday_squid_bl_612.html#c6769756 https://www.schneier.com/blog/archives/2018/02/friday_squid_...
colanderman 9y ago
Proof assistants are not magically bug-free. As others have said, an exhaustive model checker failing to find a counterexample is a proof. That you trust proofs more because you haven't yet seen a bug in a proof assistant speaks only to your personal experience, not to any logical truism. (That said, most models are not finite, and thus cannot be exhaustively checked. This is where proof systems do have a leg up. But that has nothing to do with bugs or representation of the system under test.)

seattleeng 9y ago

That's very interesting, do you happen to have any toy examples where two model checkers differ?

OscarCunningham 9y ago
The other day I found an error in the Glucose SAT solver, but only when running with one of the options (-rcheck) changed away from its default setting. Glucose produced an alleged satisfying assignment that didn't actually work. So it's possible for mainstream SAT solvers to have errors, but I imagine their default configurations are very thoroughly tested.
- schoen 9y ago
  It's interesting that the SAT solvers haven't put in a check at the very end to confirm that satisfying instances really satisfy the constraints, since that step is of course supposed to be the radically easy one! I guess their authors have had a lot of (usually well-placed) confidence in the solvers' logic and correctness.
  - OscarCunningham 9y ago
    When I told them about it they said that the -rcheck code was inherited from MiniSAT. Since it's also not enabled by default it's understandable that it hadn't been as thoroughly checked as usual. I wouldn't blame them if they just dump it instead of fixing it. But yes it is strange that it doesn't verify its outputs. On the other hand SAT solvers want to be as fast as possible and there shouldn't be a need to do it if the solver is operating correctly.
nanolith 9y ago
In early days of CBMC, it was possible to confuse it and get it to generate incorrect code for MiniSat. This is a representation issue. Those issues have long since been solved. Now CBMC's biggest problem is that of performance, and the developers are diligently working to improve this problem. When Z3 first came out, I built a machine model for a subset of ARMv7 and ran into a few cases that confused Z3, but worked fine in an equivalent MiniSat. However, this was years ago, and it appears -- although I have not verified this -- that the code in Z3 that I narrowed down in preparation to filing a bug report has already been fixed. The machine model has succumbed to bit rot; I abandoned the effort for a model I built on top of Coq. But, it would be interesting to attempt to fire it up again to see if it works now, and if so, use that to perform a binary search to find out when the fix was applied. It shouldn't be hard to create an example where two model checkers differ. Check current bug reports for two model checkers, and build a model that exploits the bug in one model checker but in which the other model checker works. These code bases are complex. They are increasingly infrequent, as the developers working on these model checkers are quite diligent, but subtle errors do exist.

nickpsecurity 9y ago

I said that about TLA+'s model checking. With things like Verasco, I figured a verified model checker could be done. As usual, I also searched for examples with SPIN since (a) they're used for similar things and (b) more people used SPIN in the past. Found this: https://www21.in.tum.de/~lammich/pub/nfm2016_por.pdf https://www21.in.tum.de/~lammich/pub/nfm2016_por.pdf Lammich was a name I recognized immediately for his work converting functional data structures to imperative ones in Isabelle/HOL. He and his collaborators have done quite a few interesting things so I'll just leave you the whole list: https://www21.in.tum.de/~lammich/ https://www21.in.tum.de/~lammich/ Far as lightweight methods, I recently summarized some recommendations with supporting case studies on Schneier's blog based on a message I sent someone trying to sell management on verification. It's a draft that I'm getting feedback on from various people rather than something I'm 100% solid on. The SPARK work combined with their book is still one of easiest methods in terms of automation achieved for covering specific properties that are often significant. https://www.schneier.com/blog/archives/2018/02/friday_squid_bl_612.html#c6769756 https://www.schneier.com/blog/archives/2018/02/friday_squid_...

colanderman 9y ago

Proof assistants are not magically bug-free. As others have said, an exhaustive model checker failing to find a counterexample is a proof. That you trust proofs more because you haven't yet seen a bug in a proof assistant speaks only to your personal experience, not to any logical truism. (That said, most models are not finite, and thus cannot be exhaustively checked. This is where proof systems do have a leg up. But that has nothing to do with bugs or representation of the system under test.)