Sound, Modular and Compositional Verification of the Input/Output Behavior of Programs

Abstract

We present a sound verification approach for verifying input/output properties of programs. Our approach supports defining highlevel I/O actions on top of low-level ones (compositionality), defining input/output actions without taking into account which other actions exist (modularity), and other features. As the key ingredient, we developed a separation logic over Petri nets. We also show how with the same specification style we can elegantly modularly verify "I/O-like" code that uses the Template Pattern. We have implemented our approach in the VeriFast verifier and applied it to a number of challenging examples.

From C to interaction trees: specifying, verifying, and testing a networked server

“…Its separation logic comes with a proof automation system, Floyd, that supplies tactics for symbolically executing a program while maintaining its pre-and postcondition [Cao et al 2018]. To support reasoning about external behavior in general-and the swap server's invocations of OS/network primitives in particular-we extend VST's logic with two abstract predicates [Penninckx et al 2015]; these are separation logic predicates that behave like resources but do not have a footprint in concrete memory. Instead they connect to VST's model of external state, which in this case represents the allowed network behavior of the program.…”

Connecting Higher-Order Separation Logic to a First-Order Outside World

“…Although this is a very simple program, it is not a natural fit for separation-logic-based verification tools, which model the behavior of C programs in terms of computation and memory rather than I/O. Several approaches have been suggested for reasoning about I/O in separation logic, for instance by Penninckx et al [18] and Koh et al [13]. Using the latter approach, we might specify the behavior of getchar with the Hoare triple {ITree(r ← read; ; k r)} x = getchar() {ITree(k x)}, relating the function call to an external read event: the program before the call to getchar must have permission to perform a sequence of operations beginning with a read, and after the call it has permission to perform the remaining operations (with values that may depend upon the received value).…”

Specification and verification of synchronisation classes in Java : a practical approach

“…Specification and Verification of Atomic Operations in GPGPU Programs. In SEFM 2015, pages [69][70][71][72][73][74][75][76][77][78][79][80][81][82][83]2015..…”

“…Any synchronisation construct needs to be instantiated with a protocol that specifies the correct behaviour of the algorithm. Current advances in Separation Logic-based specification and verification of protocols [36,73,22,69] shows the potential of an unified method that verifies a custom synchronisation construct w.r.t. its specified protocol.…”

“…In this direction, Penninckx employed Petri nets to model and reason about concurrent I/O based programs [73]. His technique for the specification and reasoning about tokens may be applicable here.…”