Pushing the Boundary of Mostly Automatic Program Proof

info@adacore.com adacore.com
Pushing the Boundary
of Mostly Automatic
Program Proof
Yannick Moy
Copyright © AdaCore
High Integrity Software 2022 Conference - October 11, 2022

The Verifying Compiler
A verifying compiler uses mathematical and logical reasoning to check the
correctness of the programs that it compiles.
Sir Tony Hoare, Journal of the ACM, 2003
2

Our formally veriﬁed microkernel, seL4, is now used across the world
in a number of applications that keeps growing.
June Andronick, Successes in Deployed Veriﬁed Software, 2019
The Verifying Compiler in Practice
3

The Auto-Active Approach
4

• Use programming language as speciﬁcation language
5

• Leverage array of automatic provers
6

• Limit speciﬁcations to what can be “mostly” automated
7

• Limit speciﬁcations to what can be “mostly” automated
• Use “ghost code” to reach fully automatic proof
8

The Auto-Active Approach in SPARK
• Use Ada as programming language and specification language (contracts)
• Leverage automatic provers Alt-Ergo, COLIBRI, cvc5, Z3
• Specifications are limited by the language (“contracts”) and best practices
• Code marked as “ghost” is only used for verification
9

Low-Hanging Fruits with Program Proof
10

• Absence of runtime errors
• no exception raised (predeﬁned or explicitly in the code)
• no reads of uninitialized data
11

• Correct API usage
• correct input context when calling functions
• correct sequencing of calls on data
12

• Correct API usage
• correct input context when calling functions
• correct sequencing of calls on data
• Data invariants respected
• “permanent” invariants that should hold always
• “boundary” invariants that should hold for client code
13

Initialization is in general guaranteed by
sticking to an initialization policy checked
by a data-ﬂow algorithm
More complex initialization patterns
require specifying:
• what parts of objects are initialized
• under which conditions
Mix of boolean conditions and arithmetic is
a strong suit of automatic provers
SPARK programming language has
constraints and speciﬁcation features that
make it straightforward:
• memory safety amounts to checking
non-nullity of pointers and that indexes
are in bounds
• numerical type safety amounts to
checking that computations don’t
divide by zero or exceed bounds
(Integer) (Linear) Arithmetic is a strong suit
of automatic provers
Absence of Runtime Errors
14

Initialization is in general guaranteed by
sticking to an initialization policy checked
by a data-ﬂow algorithm
More complex initialization patterns
require specifying:
• what parts of objects are initialized
• under which conditions
Mix of boolean conditions and arithmetic is
a strong suit of automatic provers
SPARK programming language has
constraints and speciﬁcation features that
make it straightforward:
• memory safety amounts to checking
non-nullity of pointers and that indexes
are in bounds
• numerical type safety amounts to
checking that computations don’t
divide by zero or exceed bounds
(Integer) (Linear) Arithmetic is a strong suit
of automatic provers
Absence of Runtime Errors
15

Correct sequencing of calls expressed in
preconditions and postconditions:
• state of parameters wrt prescribed
automaton
• global state wrt prescribed automaton
Possibly using imported ghost functions
to express state
Resource reclamation (e.g. dynamic
memory deallocation)
Based on simple boolean conditions
Correct input context:
• value of parameters respect
conditions beyond type safety
• lifetime of pointer parameters
consistent with their use
• relations between parameters are
respected
• global state respects constraints
Preconditions that usually rely on mix of
arithmetic and boolean conditions
Correct API Usage
16

Correct sequencing of calls expressed in
preconditions and postconditions:
• state of parameters wrt prescribed
automaton
• global state wrt prescribed automaton
Possibly using imported ghost functions
to express state
Resource reclamation (e.g. dynamic
memory deallocation)
Based on simple boolean conditions
Correct input context:
• value of parameters respect
conditions beyond type safety
• lifetime of pointer parameters
consistent with their use
• relations between parameters are
respected
• global state respects constraints
Preconditions that usually rely on mix of
arithmetic and boolean conditions
Correct API Usage
17

Type invariants (“boundary” invariants)
only hold outside the unit:
• possibly violated locally
• restored before returning to client
Used to hide data invariant from client
unit
Same kinds of properties as predicates
Type predicates (“permanent” invariants)
always hold:
• subset of values from the base type
• conditions on bounds of arrays
• relations between ﬁelds of structures
(e.g. inequality comparisons)
• conditions on ﬁeld initialization
Same mix of arithmetic and boolean
conditions as before
Data Invariants Respected
18

Type invariants (“boundary” invariants)
only hold outside the unit:
• possibly violated locally
• restored before returning to client
Used to hide data invariant from client
unit
Same kinds of properties as predicates
Type predicates (“permanent” invariants)
always hold:
• subset of values from the base type
• conditions on bounds of arrays
• relations between ﬁelds of structures
(e.g. inequality comparisons)
• conditions on ﬁeld initialization
Same mix of arithmetic and boolean
conditions as before
Data Invariants Respected
19

Stretch Goals with Program Proof
20

• Prove full functional behavior
21

• Prove the implementation of complex data structures
• absence of runtime errors
• data invariants respected
• functional behavior
22

• Prove the implementation of complex data structures
• absence of runtime errors
• data invariants respected
• functional behavior
• Prove numerical algorithms
• exact result of computations
• bounds on the approximation wrt mathematical computation
23

Need to express the specification as
contracts, usually as a form of refinement:
• concrete types refine an ideal model
(mathematical integers, sets, maps…)
• concrete implementation respects the
ideal computation on models
• contracts can use quantification and
abstraction
Best practices: no existential, abstract
important properties
Need to write ghost code (assertions, loop
invariants) through interaction with
automatic provers
Prove Full Functional Behavior
24
https://blog.adacore.com/i-cant-believe-that-i-can-prove-that-it-can-sort

Example: sorting algorithms
• ideal model of bag / multiset
• sorting preserves model
• property uses quantification
• property should use abstraction: being
sorted on subrange, being the
maximum on subrange
With suitable properties, and little
adequate ghost code, this is easily proved
by automatic provers
Need to express the specification as
contracts, usually as a form of refinement:
• concrete types refine an ideal model
(mathematical integers, sets, maps…)
• concrete implementation respects the
ideal computation on models
• contracts can use quantification and
abstraction
Best practices: no existential, abstract
important properties
Need to write ghost code (assertions, loop
invariants) through interaction with
automatic provers
Prove Full Functional Behavior
25
https://blog.adacore.com/i-cant-believe-that-i-can-prove-that-it-can-sort

Need to structure the code to separate
concerns:
• different types provide different views
of the data with different models
• complexity is encapsulated at each
level through abstraction
Best practices: use privacy to hide
implementation and verification details
Need to write ghost code (lemmas for
induction) through interaction with
automatic provers
Prove Complex Data Structures
26
https://blog.adacore.com/research-corner-auto-active-verification-in-spark

Example: red-black trees for bare-metal
• level 1: binary trees
• level 2: sorted trees
• level 3: balanced trees
• properties at each level encoded as
type invariants on private types
size of contracts = 2 x size of code
size of ghost code = 5 x size of code
Implementation constraints matter: same
with dynamic allocation has four times
less ghost code
Need to structure the code to separate
concerns:
• different types provide different views
of the data with different models
• complexity is encapsulated at each
level through abstraction
Best practices: use privacy to hide
implementation and verification details
Need to write ghost code (lemmas for
induction) through interaction with
automatic provers
Prove Complex Data Structures
27
https://blog.adacore.com/research-corner-auto-active-verification-in-spark

Algorithms on integers:
• refine mathematical operations
• efficient implementations on machine
integers require bitwise
manipulations
Exploit dedicated support of bitvectors in
automatic provers
Algorithms on reals:
• implement control algorithms
• expectation is to remain “close” to the
ideal computation on reals despite
rounding errors and approximations
Exploit dedicated support of floats in
automatic provers
Prove Numerical Algorithms
28
https://blog.adacore.com/proving-the-correctness-of-gnat-light-runtime-library

Example: multi-place integer arithmetic
• mix of signed integers and modular
integers
• a lot of non-linear operations
(multiplications, shifting, division, mod)
size of contracts = 0.15 x size of code
size of ghost code = 5 x size of code
Proof of ≈100 lemmas requires use of all
four automatic provers: Alt-Ergo, COLIBRI,
cvc5, Z3
Algorithms on integers:
• refine mathematical operations
• efficient implementations on machine
integers require bitwise
manipulations
Exploit dedicated support of bitvectors in
automatic provers
Algorithms on reals:
• implement control algorithms
• expectation is to remain “close” to the
ideal computation on reals despite
rounding errors and approximations
Exploit dedicated support of floats in
automatic provers
Prove Numerical Algorithms
29
https://blog.adacore.com/proving-the-correctness-of-gnat-light-runtime-library

Challenges with Program Proof
30

• Left-Over Principle of automation
• automation fails humans on the more complex cases
• solution: …
31

• solution: better interaction mechanisms
32

• Predictability of proof results
• automatic provers are based on heuristic search
• solution: …
33

• solution: know the low-hanging fruits from the stretch goals
34

• Stability of proof results
• minor changes in code or tool can lead to losing proofs
• solution: …
35

• Stability of proof results
• minor changes in code or tool can lead to losing proofs
• solution: prover redundancy and advances in automatic proof technology
36

The Verifying Compiler
If the project is successful, a verifying compiler will be available as a standard tool
in some widely used programming productivity toolset.
Sir Tony Hoare, Journal of the ACM, 2003
37

Pushing the Boundary of Mostly Automatic Program Proof

More Related Content

Similar to Pushing the Boundary of Mostly Automatic Program Proof (20)

More from AdaCore (20)

Recently uploaded (20)

Pushing the Boundary of Mostly Automatic Program Proof