boogie 2011 hi-lite

Why Hi-Lite Ada?

Jerome Guitton, Johannes Kanig,Yannick Moy (AdaCore)

Boogie Workshop - August 1st, 2011

Overview

Introduction

Ada 2012 and Alfa

Ada and Why

The translation

Outline

Introduction

Ada 2012 and Alfa

Ada and Why

The translation

Unit Proof - I

Motivation

I Allow gradual replacement of tests by program verificationI Provide other means of verification when formal verification

fails:I VCs too complex for automated toolsI manual proofs too costlyI program constructs out of scopeI aspects to be proved out of scope (timing, memory,

termination)

Concept

I Apply formal verification and tests on a per-function basis

I Tests still available to complement program verification

I Has been applied at Airbus to avionics software Level A

Unit Proof - II

Problems

I Expertise: required for writing contracts and carrying proof

I Duplication: contract not shared between testing and proof

I Isolation: unit test and unit proof cannot be combined

I Confusion: not the same semantics for testing and proof

I Debugging: contracts and proof cannot be executed

Hi-Lite : Test and Proof

French research project started in May 2010, over 3 years

Motivation

I Source language: Ada

I Combine test and proof in a single contract based technology

I Same language and semantics for test and proof

I Application to existing projects should be possible

I Ease of use: Automation

The upcoming avionics standard DO-178C

Outline

Introduction

Ada 2012 and Alfa

Ada and Why

The translation

New Forms of Expressions in Ada 2012

I if-expressions:

(if X = 0 then 0 else 1 / X)

I case-expressions:

type Week_Day is

(Mon , Tue , Wed , Thu , Fri , Sat , Sun);

...

(case X is

when Mon .. Fri => True

when others => False)

I quantified expressions:

(for all I in X’Range => X (I) > 0)

(for some I in X’Range => X (I) > 0)

Contracts

A function with pre- and postcondition

function Search (S : String; C : Character)

return Natural

with

Pre => (S /= ""),

Post =>

((if Search ’Result /= 0 then

S (Search ’Result) = C)

and

(for all X in

S’First .. Search ’Result - 1 =>

S (X) /= C));

The Alfa Subset of Ada

Definition

I Includes all features suitable for program verification

I Excludes pointers, concurrency, exceptions

I No side effects in annotations

I No ambiguous expressions

Classification of each function

I Non-Alfa: only very light restrictions

I Partially in Alfa: signature and contract of the function are inAlfa, no restriction on the body

I (Entirely) in Alfa: signature, contract and body of thefunction are in Alfa, only functions at least partially in Alfaare called

Alfa and Ada

Alfa and Non-Alfa code can be freely mixed

I Automatic detection of functions that are (partially or fully) inAlfa

I Only those functions are translated to Why

I Remaining code can be covered by testing

Rationale

I You don’t need to write all your code in Alfa

I Application to legacy code base

I Allow packages with complex code (pointers, concurrency)

Outline

Introduction

Ada 2012 and Alfa

Ada and Why

The translation

The GNATprove tool

Automatic Effects Computation

Procedure

I First phase of GNATprove

I Compute localized effects of each function (do not take intoaccount effects of called functions)

A few restrictions to Ada to maintain correctness

I No function pointers

I No implicit aliasing

I These situations are recognized by the compiler (work inprogress)

An Ada ProgramSpec for package A

typesglobal vars

function declscontracts

Body for package A

local typeslocal varsfunctions

An Ada ProgramSpec for package A

typesglobal vars

function declscontracts

Body for package A

local typeslocal varsfunctions

Spec for package B

Body for package B

A First Idea for Why Files

code forspec of A

code forbody of A


code forspec of A

code forbody of A

code forspec of B

code forbody of B


code forspec of A

code forbody of A

code forspec of B

code forbody of B

Achieved

I Ada visibility modeled

I circular dependenciesavoided

I (mutual) recursion evenacross packages


code forspec of A

code forbody of A

code forspec of B

code forbody of B

Achieved




Problem

I Effects on local variables introduce new dependencies

I Example: function in B modifies indirectly local variable of A


code forspec of A

code forbody of A

code forspec of B

code forbody of B

Achieved




Problem

I Effects on local variables introduce new dependencies

I Example: function in B modifies indirectly local variable of A

I circular dependency!

Our Proposed Solution

code for types andvars in spec of A

code for types andvars in body of A

code for funcsin spec of A

code for funcsin body of A

Our Proposed Solution

code for types andvars in spec of A

code for types andvars in body of A

code for funcsin spec of A

code for funcsin body of A

code for types andvars in spec of B

code for types andvars in body of B

code for funcsin spec of B

code for funcsin body of B

Outline

Introduction

Ada 2012 and Alfa

Ada and Why

The translation

Ada Integer Types

New type definition:

type One_Ten is range 1 .. 10;

Subtype (inherits base range):

subtype One_Ten_Integer is

Integer range 1 .. 10;

Inserted checks

I Range check on assignment (or parameter passing)

I Overflow check on intermediate operations on the base type

Ada Integer Types in Why

type t

predicate t_in_range (x : int) = -128 <= x <= 127

logic t_to_int : t -> int

logic t_of_int : int -> t

parameter t_of_int_ :

n : int ->

{ t_in_range (n) } t { t_to_int (result) = n }

parameter t_in_range_ :

n : int ->

{ t_in_range (n) } int { result = n }

axiom t_range :

forall x : t. t_in_range (t_to_int (x))

...

Execution Semantics for Assertions - I

Objective

I Same semantics for test and proof

I Assertions should be runtime error free

Possibilities

I Consider assertions with runtime errors as falseI Implicit assumptions in the case of preconditions

I Consider assertions with runtime errors as incorrectI Additional VCs to prove absence of runtime errors in specsI No implicit assumptions

I Hi-Lite: second possibility has been chosen for clarity

Execution Semantics for Assertions - II

Example in Ada

function Add (X, Y : One_Ten) return One_Ten

with Pre => (X + Y < 10);

Translation to Why

let add (x : one_ten) (y : one_ten) =

{ true }

ignore

(one_ten_range_

(one_ten_to_int (x) + one_ten_to_int (y)) < 10);

assume

{ one_ten_to_int (x) + one_ten_to_int (y) < 10 };

... (* translated body of function Add *)

Loop Assertions - I

The trivial translation:

Ada loop

while C loop

pragma Assert (P);

...

end loop;

Why translation

while C do

{ P }

...

done

Does not reflect runtime behavior:

I Assertion not executed when C is always false

I Assertion not executed after end of loop

Loop Assertions - II

Our translation

if c then

try

while true do (* infinite loop *)

{ invariant c and p}

...

if not c then raise Exit

done

with Exit -> ();

Quantified Expressions

A pathological example

(for all J in 1 .. 10 =>

(if J = 5 then J /= 1 / 0 else False))

A simple approach

∀ 1 ≤ j ≤ 10. if j = 5 then 0 6= 0 else true

Proposed by an anonymous referee

∀ 1 ≤ j ≤ 10.(∀ 1 ≤ j ′ ≤ j − 1. if j ′ = 5 then 0 6= 0 else true) and(∀ 1 ≤ j ′ ≤ j − 1. if j ′ = 5 then j ′ 6= 1/0 else false)⇒ if j = 5 then 0 6= 0 else true

Conclusion

Hi-Lite

I Allow combining test and proof

I Easy adoption of formal verification, applied to new andexisting projects

Future Work

I Migration to Why3

I Verification of consistency of contracts

boogie 2011 hi-lite

Technology