||seL4: A verified operating system
|“seL4: Formal verification of an operating-system kernel”
(Research Highlight), Gerwin Klein, June Andronick, Kevin Elphinstone, Gernot Heiser, David Cock, Philip Derrin, Dhammika Elkaduwe, Kai Engelhardt, Rafal Kolanski, Michael Norrish, Thomas Sewell, Harvey Tuch and Simon Winwood, Communications of the ACM 53
:6, June 2010, pp107–115
Survey question! The core of the seL4 correctness proof is the forward simulation relation described in §4.4 and illustrated in Figure 6. (I believe insane category theorists would describe this as a kind of “Galois connection.”) Explain how the forward simulation relation would work in the restricted domain of seL4’s scheduling policy (Figure 3). What abstract state (σ) is implied by Figure 3? What concrete state would you expect the implementation to maintain? What does an abstract scheduling operation perform (what does M_1 do)? Finally, what is the relation between abstract and concrete states?
||The CompCert compiler
Survey questions! 1. The seL4 paper, and our class discussion on 1/25, discussed the forward simulation that shows the functional correctness of seL4’s implementation relative to its spec. The CompCert paper also discusses functional correctness, in Section 2, but it does not use simulation. Describe at least two ways that Equation (1) differs from a forward simulation.
2. Section 4.3 gives the following relation between original registers and allocated registers: “R(r) = R'(φ(r)) for all pseudo-registers r live at point 𝓁.” Say that CompCert’s designer made a mistake in the definition of “live pseudo-registers,” so that in some cases, a pseudo-register was incorrectly considered dead at point 𝓁 (even though its value was used at some later point). What would be a consequence of this mistake?
||A verified kernel subsystem
Survey questions! 1. Jitk security filters are defined in SCPL, a new language, but the kernel verifier—the most important contribution—accepts BPF filters as input. SCPL requires an additional proof layer, a burden. What is an advantage of SCPL?
2. The last paragraph of §5.3 seems very precisely worded. When the authors say Lemma 3 “provides a strong sanity check on the internal consistency of our encoder and decoder,” is this simply another way of saying Lemma 3 proves the correctness of their encoder and decoder? Why or why not?
||A Coq-verified kernel
Survey question! Section 3.4 concerns the semantics of partially-active multicore machines. Given a program P, and a behavior set denoted [[*]], [[P]]_pt(A) describes the observable behaviors when only the CPUs in A are “active,” in the sense the paper defines. Each element of this set may contain observable actions from *any* CPU, either in A or in (C – A). Is there any conceptual difference between the kinds of actions [[P]]_pt(A) will contain for CPUs in A and those for CPUs in (C – A)?
||More on CertiKOS
||Using an “autoactive” verifier
Survey question! Which parts of the Ironclad Apps ecosystem are trusted (i.e., unverified) in the proof of Remote Equivalence?
||Presidents’ Day holiday
Survey question! Give one or more “ensures” clauses for the YieldTo procedure defined in §4.6, in either English text or Boogie-like pseudocode. Your clauses should enforce the invariants on which the Verve Nucleus depends.
||Permutation presentations, dependent types,
question! Consider the “log_commit()” pseudocode in Figure 14. The correctness
proof would not go through if any of the disk_sync() calls were
removed. Roughly speaking, how would the proof of atomic_two_write()
fail if the second call to disk_sync() were removed?
||Verdi: Distributed systems verification
The Figure 10 sequence numbering transformer depends on “int” (https://coq.inria.fr/library/Coq.ZArith.Int.html). Would it be possible to use CompCert’s “int32” or “int64” instead? How would the proof need to change?
1. The Verdi key-value store specification uses per-key traces (page 364 of Verdi), whereas the IronKV key-value store specification uses a transition relation on an abstract hash-table state (Figure 11 on page 10 of IronFleet). Contrast these approaches.
2 (optional but recommended).
The Verdi key-value store implementation https://github.com/uwplse/verdi/blob/master/systems/VarD.v#L110 supports five operations, get, put, delete, compare-and-swap, and compare-and-delete. Now consider the “high-level spec for IronKV” in Figure 11. Write a new version of this spec that supports at least one additional operation from VarD. (NB: In Dafny, the “::” operator means “such that,” not “cons.”)
||Coq work/project discussion
||Bugs in verified code
Survey questions! 1. Which of the bugs listed in Figure 3 could be fixed by using a TCP transport shim rather than a UDP transport shim?
2. What properties would the TCP shim need to have to actually fix those bugs?
Survey question! 1. Describe the meaning of the “-*” definition from Section 3 in intuitive terms.
2. Give a heap that distinguishes ls(10,10) and ils(10,10) (part of Exercise 4). (A heap “distinguishes” two assertions if it meets one assertion, but not the other.)
||Concurrent separation logic
||Weak memory models
Note! This paper has an extensive appendix. Only print pp1–17.
Survey questions! 1. Which of the following relations must be transitive? sb, mo, rf, sw, hb.
2. Why does concurrent separation logic avoid needing protocol assertions (box things)?
Survey question! Given a singly-linked RCU list of ints, the following code returns the first int (or -1 if the list is empty):
head = rcuReadStart(list);
i = head ? head->data : -1;
This code should verify given the RCU specifications in Figure 3, but if you switched the order of the
i assignment with
rcuQuiescentState, the code would be incorrect and would not verify. Why not? Give an intuitive answer, a specific answer involving Figure 3, or, preferably, both.
Survey question! Give at least one example of a common file system operation or optimization that satisfies the no-op definition (definition 5). How does the no-op definition make proofs easier?
Survey question! In §6 we are told that “It is important for the ExpressOS kernel to maintain proper mappings between the file descriptors (fd) of the user-level helper and those of the application.” Important for security, for functional correctness, or both? Explain your answer.
||Project proposal discussion
Survey questions! 1. Allocation in BoogiePL is represented by “havoc e; assume …;”. What would be different if this translation used “assert” instead of “assume”?
2. The “assume” clause for the allocation in Fig.3 reads “e ≠ null /\ typeof(e)=Example /\ Heap[e,allocated]=false”. Briefly explain the purposes of these three clauses.
Cocoon can be analogized to a compiler such as CompCert. What is Cocoon's output language, and what assumptions does Cocoon verification make about that output language?
- Certified assembly languages
“The Bedrock Structured Programming System: Combining Generative Metaprogramming and Hoare Logic in an Extensible Program Verifier”, Adam Chlipala, Proc. ICFP 2013
“Mostly-Automated Verification of Low-Level Programs in Computational Separation Logic”, Adam Chlipala, Proc. PLDI 2011
- Verifying subsystems and applications
“Investigating Safety of a Radiotherapy Machine Using System Models with Pluggable Checkers”, Stuart Pernsteiner, Calvin Loncaric, Emina Torlak, Zachary Tatlock, Xi Wang, Michael D. Ernst, and Jonathan Jacky, Proc. CAV 2016.
“From Network Interface to Multithreaded Web Applications: A Case Study in Modular Program Verification”, Adam Chlipala, Proc. POPL 2015
- Distributed systems
“Synthesis of Self-Stabilizing and Byzantine-Resilient Distributed Systems”, Roderick Bloem, Nicolas Braud-Santoni and Swen Jacobs, Proc. CAV 2016
“Model Checking at Scale: Automated Air Traffic Control Design Space Exploration”, Marco Gario, Alessandro Cimatti, Cristian Mattarei, Stefano Tonetta and Kristin Yvonne Rozier, Proc. CAV 2016
“Ivy: Safety Verification by Interactive Generalization”, Oded Padon, Kenneth McMillan, Aurojit Panda, Sharon Shoham, Proc. PLDI 2016
“Formal specification and verification of CRDTs”, Peter Zeller, Annette Bieniusa, and Arnd Poetzsch-Heffter, Proc. FORTE 2014
- More whole-OS verification
- Formal methods falling short of verification