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

Koh, Nicolas; Li, Yao; Li, Yishuai; Xia, Li-yao; Beringer, Lennart; Honoré, Wolf; Mansky, William; Pierce, Benjamin C.; Zdancewic, Steve

doi:10.1145/3293880.3294106

Cited by 36 publications

(27 citation statements)

References 40 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…For instance, we might give a console write function the "consuming-style" specification {has ext(write(v); ; k)} write(v) {has ext(k)}, stating that if before calling write(v) the program has permission to write the value v and then do the operations in k, then after the call it is left with permission to do k. (We could reverse the pre-and postcondition for a "trace-style" specification, in which the external state records the history of operations performed by the program instead of the future operations allowed.) In this paper, we use interaction trees [13] as a means of describing a collection of allowed traces of external events. Interaction trees can be thought of as "abstract traces with binding"; for instance, we can write x ← read; ; write (x + 1); ; k x to mean "read a value, call it x, write the value x + 1, and then continue to do the actions in k using the same value of x.…”

Section: External State As Ghost Statementioning

confidence: 99%

“…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).…”

Section: Introductionmentioning

confidence: 99%

See 1 more Smart Citation

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

Mansky

Honoré

Appel

2020

Programming Languages and Systems

Self Cite

View full text Add to dashboard Cite

Separation logic is a useful tool for proving the correctness of programs that manipulate memory, especially when the model of memory includes higher-order state: Step-indexing, predicates in the heap, and higher-order ghost state have been used to reason about function pointers, data structure invariants, and complex concurrency patterns. On the other hand, the behavior of system features (e.g., operating systems) and the external world (e.g., communication between components) is usually specified using first-order formalisms. In principle, the soundness theorem of a separation logic is its interface with first-order theorems, but the soundness theorem may implicitly make assumptions about how other components are specified, limiting its use. In this paper, we show how to extend the higher-order separation logic of the Verified Software Toolchain to interface with a first-order verified operating system, in this case CertiKOS, that mediates its interaction with the outside world. The resulting system allows us to prove the correctness of C programs in separation logic based on the semantics of system calls implemented in CertiKOS. It also demonstrates that the combination of interaction trees + CompCert memories serves well as a lingua franca to interface and compose two quite different styles of program verification.

show abstract

Section: External State As Ghost Statementioning

confidence: 99%

Section: Introductionmentioning

confidence: 99%

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

Mansky

Honoré

Appel

2020

Programming Languages and Systems

Self Cite

View full text Add to dashboard Cite

show abstract

“…Alternatively, one can use the extracted code to run tests cases against the itree computation, possibly finding bugs before significant effort is spent verifying properties. Koh et al [2019] have found this methodology to be useful in other contexts.…”

Section: Itrees Are Extractablementioning

confidence: 99%

“…Additionally, in many cases, we can compose ITrees in such a way that they remain executable, that is by writing an executable scheduler that coordinates the ITree behaviors. This means that, besides proving properties of the resulting system, we can extract executable test cases [Koh et al 2019].…”

Section: Composition With the Environmentmentioning

confidence: 99%

Interaction trees: representing recursive and impure programs in Coq

Xia

Zakowski

et al. 2019

Proc. ACM Program. Lang.

Self Cite

View full text Add to dashboard Cite

We present interaction trees (ITrees), a general-purpose data structure in Coq for formalizing the behaviors of recursive programs that interact with their environment. ITrees are built of uninterpreted events and their continuations-a coinductive variant of a "free monad. " We study the compositional properties of interpreters built from event handlers and show how to use them to implement a general mutual recursion operator. The resulting theory enables equational reasoning about ITrees up to weak bisimulation. Using this theory, we prove the termination-sensitive correctness of a compiler from a simple imperative source language to an assembly-like target whose meanings are given as an ITree-based denotational semantics. Crucially, the correctness proof follows entirely by structural induction and the equational theory of combinators for control-flow graphs, which are built on top of the mutual recursion operator. ITrees are also executable, e.g. through extraction, making them suitable for debugging, testing, and implementing executable artifacts.

show abstract

“…Another alternative was to use freer monads introduced by Kiselyov et al [17], whose definition did not need a representation of striclty positive types using containers at all. There were already several encodings to model different kinds of monadic effects using freer monads: McBride [21] defines a General monad to model general recursion as effect, Letan et al [19] use the Program monad initially presented in the operational package known from Haskell 11 to reason about a small imperative language, and Koh et al [18] identify interaction trees as a suitable tool to verify functional correctness of a server implemented in C.…”

Section: :22mentioning

confidence: 99%

One Monad to Prove Them All

Dylus¹,

Christiansen

Teegen

2019

Programming

View full text Add to dashboard Cite

One Monad to Prove Them All is a modern fairy tale about curiosity and perseverance, two important properties of a successful PhD student. We follow the PhD student Mona on her adventure of proving properties about Haskell programs in the proof assistant Coq.On the one hand, as a PhD student in computer science Mona observes an increasing demand for correct software products. In particular, because of the large amount of existing software, verifying existing software products becomes more important. Verifying programs in the functional programming language Haskell is no exception. On the other hand, Mona is delighted to see that communities in the area of theorem proving are becoming popular. Thus, Mona sets out to learn more about the interactive theorem prover Coq and verifying Haskell programs in Coq.To prove properties about a Haskell function in Coq, Mona has to translate the function into Coq code. As Coq programs have to be total and Haskell programs are often not, Mona has to model partiality explicitly in Coq. In her quest for a solution Mona finds an ancient manuscript that explains how properties about Haskell functions can be proven in the proof assistant Agda by translating Haskell programs into monadic Agda programs. By instantiating the monadic program with a concrete monad instance the proof can be performed in either a total or a partial setting. Mona discovers that the proposed transformation does not work in Coq due to a restriction in the termination checker. In fact the transformation does not work in Agda anymore as well, as the termination checker in Agda has been improved.We follow Mona on an educational journey through the land of functional programming where she learns about concepts like free monads and containers as well as basics and restrictions of proof assistants like Coq. These concepts are well-known individually, but their interplay gives rise to a solution for Mona's problem based on the originally proposed monadic tranformation that has not been presented before. When Mona starts to test her approach by proving a statement about simple Haskell functions, she realizes that her approach has an additional advantage over the original idea in Agda. Mona's final solution not only works for a specific monad instance but even allows her to prove monad-generic properties. Instead of proving properties over and over again for specific monad instances she is able to prove properties that hold for all monads representable by a container-based instance of the free monad. In order to strengthen her confidence in the practicability of her approach, Mona evaluates her approach in a case study that compares two implementations for queues. In order to share the results with other functional programmers the fairy tale is available as a literate Coq file.If you are a citizen of the land of functional programming or are at least familiar with its customs, had a journey that involved reasoning about functional programs of your own, or are just a curious soul looking for the next story about monads ...

show abstract

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

Cited by 36 publications

References 40 publications

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

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

Interaction trees: representing recursive and impure programs in Coq

One Monad to Prove Them All

Contact Info

Product

Resources

About