ViperCore: Core IVL for Separation Logic

• ViperCore is a core intermediate verification language that provides a formal foundation for reasoning about resource management and heap-manipulating assertions in separation logic.
• It employs two equivalent semantic interpretations—operational and axiomatic—to model non-deterministic behaviors and rigorously capture verification obligations.
• The framework underpins Viper’s toolchain by enabling modular verification, supporting both front-end translations and back-end verifiers with formal, verified semantics.

ViperCore is a core intermediate verification language (IVL) designed to serve as a precise semantic foundation for verification frameworks targeting variations of separation logic, most notably the Viper verification infrastructure. By capturing the essence of resource management and heap-manipulating assertions in a minimal, algebraic setting, ViperCore enables rigorous reasoning about the soundness of both front-end translations and back-end verifiers for complex, resource-aware program logics. The framework includes two provably equivalent semantic interpretations—operational and axiomatic—providing a formally verified substrate for automated verification tools (Dardinier et al., 2024).

1. Syntax and Structural Elements

ViperCore is defined over a semantic state space $\Sigma$ constructed atop an IDF algebra, encoding both the program store and permission-aware heap states. The language manipulates:

• Variables $x, y \in Var$
• Values $v \in Val$
• Field names $f \in FieldName$
• Assertions $A\subseteq\Sigma$, interpreted as sets of states
• Commands $C$ generated by the grammar:

$$C ::= inhale~A~|~exhale~A~|~havoc~x~|~x := e~|~skip~|~C;C~|~if~b~then~C_1~else~C_2~|~custom~C'$$

Here, \textit{inhale} and \textit{exhale} manipulate resources (heap and permissions), \textit{havoc} non-deterministically assigns a variable, \textit{assign} performs deterministic state updates, and \textit{custom} permits extensibility with user-supplied primitives (such as field updates).

Assertions and expressions ($e, b$) are semantic: they range over partial functions $\Sigma \to Val$ (for computations and predicates) and subsets of $\Sigma$ (for state properties), respectively.

2. Operational Semantics: Angelic and Demonic Choice

The operational semantics of ViperCore, given by the relation $x, y \in Var$0, models both angelic and demonic forms of non-determinism:

• Angelic choice occurs in \textit{exhale}, allowing arbitrary selection of witness resources to consume, thus favoring success of the verification obligation.
• Demonic choice is present in \textit{inhale}, where all possible ways of producing resources are considered, possibly leading to branching or failure.

The heap-permission algebra is formalized by a partial, commutative, associative operator $x, y \in Var$1. States must satisfy $x, y \in Var$2—the heap value map and heap permission map agree on domains.

Operational rules include:

• Inhale: $x, y \in Var$3
• Exhale: $x, y \in Var$4
• Assignment: $x, y \in Var$5 if $x, y \in Var$6
• Havoc: $x, y \in Var$7

Sequential composition and conditionals propagate both forms of non-determinism, reflecting their interaction with heap and permission state.

3. Axiomatic Semantics: Hoare-Separation Logic

Axiomatic semantics are captured by triples $x, y \in Var$8 for assertions $x, y \in Var$9. The semantics is strengthened by self-framing: assertions must be closed under resource erasure for irrelevant heap locations, ensuring modular reasoning à la separation logic.

The principal rules include:

• Skip/Sequence: Standard, subject to self-framing
• Inhale: $v \in Val$0, where $v \in Val$1 holds
• Exhale: $v \in Val$2 if $v \in Val$3, again requiring self-framing
• Assign/Havoc: Capture standard update and existential quantification over possible values
• Conditionals: Respect framing and propagate logical conjunction/disjunction on state predicates
• Frame Rule: Supports modular extension by unrelated resources

These rules abstract away operational branching by summarizing all executions that remain within the resource boundaries prescribed by the assertions.

4. Semantic Equivalence and Correctness

The formal relationship between operational and axiomatic semantics underpins the foundation for tool soundness:

• Soundness: If $v \in Val$4 is operationally correct in all $v \in Val$5, there exists $v \in Val$6 such that $v \in Val$7 holds.
• Completeness: If $v \in Val$8 and $v \in Val$9, then $f \in FieldName$0 with $f \in FieldName$1.

The equivalence is established by inductively relating the set of reachable states (operational) to the satisfaction of assertion triples (axiomatic), accounting for both angelic and demonic choices. This enables meta-theoretic reasoning about both front-end translation correctness and back-end prover reliability (Dardinier et al., 2024).

5. Instantiation for Viper: The ViperCore Model

ViperCore specializes $f \in FieldName$2 to model Viper’s heap and permission structures. The IDF (Indivisible, Discardable, Fractional) algebra is realized as:

• $f \in FieldName$3
• Heaps are merged pointwise, summing permissions up to 1, and heap values at locations with zero permission are erased.
• $f \in FieldName$4 iff $f \in FieldName$5.

States are extended to tuples with a Store component, with “agreement” ensuring that inhale/exhale affect only heap and permissions, not local variables. A custom command $f \in FieldName$6 models field updates, operationally requiring full permission.

Translation from Viper’s AST involves mapping each program statement to ViperCore’s primitive commands, rendering the semantics of high-level verification logic directly in terms of ViperCore (Dardinier et al., 2024).

6. Connections to Verification Back-Ends

ViperCore serves as the semantic pivot between front-end verifiers (e.g., concurrent separation logic) and back-ends for automated program proof:

• Symbolic Execution Back-End: An Isabelle/HOL function $f \in FieldName$7 implements Viper’s symbolic execution over symbolic states (store, permission chunks), using produce/consume to model inhale/exhale and CPS for control. Angelic choice in exhale matches the operational semantics: to exhale a wildcard permission, some positive quantity is removed. The following is shown: $f \in FieldName$8 $f \in FieldName$9 is operationally correct in all concrete states conforming to the symbolic state.
• Verification Condition Generation (VCG) Back-End: A big-step semantics $A\subseteq\Sigma$0 for Viper’s Boogie-style VCG employs a total heap, modeling demonic selection for resource removal. Each ViperCore execution $A\subseteq\Sigma$1 corresponds to a family of $A\subseteq\Sigma$2 executions, making precise the translation between concrete execution and VCG-style proof obligations (Dardinier et al., 2024).

7. Formalization and Applications

All technical results for ViperCore, covering the semantic models, operational and axiomatic equivalence, instantiations for Viper’s heap and permission system, and the correctness of two disparate back-ends, are formalized in Isabelle/HOL. The framework provides a uniform, verified foundation for reasoning about translational separation logic verifiers, enabling systematic proofs of soundness for toolchains that integrate different verification back-ends or accommodate front-end logics such as concurrent separation logic (Dardinier et al., 2024). A plausible implication is that ViperCore facilitates modular extension and reliable meta-theoretic analysis of diverse program verification workflows involving heap, permission, and resource-based invariants.