Vérification de propriétés LTL sur des programmes C par génération d'annotations

HAL Id: inria-00568947

https://hal.inria.fr/inria-00568947

Submitted on 24 Feb 2011

HAL is a multi-disciplinary open access

archive for the deposit and dissemination of

sci-entific research documents, whether they are

pub-lished or not. The documents may come from

teaching and research institutions in France or

L’archive ouverte pluridisciplinaire HAL, est

destinée au dépôt et à la diffusion de documents

scientifiques de niveau recherche, publiés ou non,

émanant des établissements d’enseignement et de

recherche français ou étrangers, des laboratoires

Vérification de propriétés LTL sur des programmes C

par génération d’annotations

Nicolas Stouls, Julien Groslambert

To cite this version:

Nicolas Stouls, Julien Groslambert. Vérification de propriétés LTL sur des programmes C par

généra-tion d’annotagénéra-tions. [Rapport de recherche] 2011, pp.16. �inria-00568947�

programmes C par génération d'annotations

Ni olas Stouls

∗

(Ni olas.Stoulsinsa-lyon.fr)

UniversitédeLyon,INRIA

INSA-Lyon,CITI,F-69621,Fran e

Julien Groslambert

(Julien.Groslamberttrusted-labs. om)

Trusted-Labs

5rueduBaillage,F-78000Versailles

28septembre 2008

Résumé

Ce travailproposeune méthodede véri ationde propriétés

tem-porellesbaséesurlagénérationautomatiqued'annotationsde

program-mes.Lesannotationsgénéréessontensuitevériéespardesprouveurs

automatiquesviaun al uldeplusfaiblepré ondition.Notre

ontribu-tionviseàoptimiserunete hniqueexistante degénération

d'annota-tions,and'améliorerl'automatisationdelavéri ationdesobligations

depreuveproduites.

Cetteappro heaétéoutillée souslaformed'un pluginau seinde

l'outilFrama-Cpourlavéri ationdeprogrammesC.

Mots lef:Preuveautomatique,programmesC,propriétésLTL

1 Introdu tion et état de l'art

Propriétés temporelles Une bran he importante de lavéri ation

logi- ielle s'intéresse à lavéri ation de propriétés de sé urité de systèmes.Elle

onsisteà exprimer, dansunelogique adéquate,les propriétés requisesdans

le ahierdes harges,puisàlavalidationde elles- i.Lanaturedespropriétés

quel'on souhaitevérierpeut-êtretrèsvariée.Ellepeut allerdela

onden-tialité des données (Le ode se ret de la arte doit resté ondentiel),

au ontrle d'a ès (Seul un terminal identié peut débiter la arte).

Nousnousintéressonsi i àune lassede propriétés dé rivant l'évolution du

systèmeau ours du temps :les propriétés temporelles.

Annotations de programme Pour vérierlerespe td'unespé i ation

par un programme, il est possible de travailler au niveau du ode sour e

eninsérant desannotationslogiques(invariants etpré/post- onditions). Les

∗

CetravailaétépartiellementsupportéparleprojetPFC(Plate-FormedeConan e)duple

ipouvaitaisément ombiner preuve formelle etvalidation àl'exé ution [8℄.

Cependant, les langages d'annotations ne permettent généralement pas

d'-exprimerdire tement despropriétés temporelles.Représentermanuellement

sous forme d'un ensemble d'annotations, une propriété temporelle, s'avère

un travail fastidieux. De e fait, il a été proposé de générer de façon

systé-matique lesannotations asso iéesà une propriététemporelle.

État de l'art Une première proposition de génération automatique

d'an-notations à partirde propriétés temporelles aété proposée par Huisman et

Trentelman [12℄. Ces travaux se sont intéressés à la génération

d'annota-tionsJMLàpartird'unlangagedepropriétés temporellesappeléJTPL.Ces

travauxont par lasuite étéétendus àlalogique temporelle linéaire.Les

fon-dationsthéoriquesetla orre tiondelaméthodeontétéétablisdans[7℄.Ces

travauxontégalement donné lieuà l'implantation d'unprototype JAG, qui

apermisd'expérimenterl'appro hedansle adredelavalidationpartestet

par véri ation par preuve.

L'appro hedegénérationd'annotationsàpartirdepropriétéstemporelles

s'estmontrée pertinente dansle adre de la véri ation dynamique des

an-notationsgénérées,notammentdansle adredelavalidationparletest.Par

ontre, la véri ation statique par génération d'obligations de preuve s'est

heurtée, dans la pratique, à deux problèmes majeurs : (i) bien que les

an-notations al uléessoient orre tes,ellesnesontparfoispassusantespour

résoudre les obligations de preuve générées; (ii) les annotations générées

entraînent une explosion ombinatoire du nombre et de la omplexité des

obligations de preuves. Pour pallier a es problèmes, l'utilisateur doit :(i)

ajoutermanuellement desinvariantssupplémentaires, faisant lelienentrele

programmeetlapropriété.(ii)intervenirpourguiderlapreuvedefaçon

inter-a tive enséle tionnant leshypothèsesné essaires àlapreuve.Globalement,

esétapesdemandent uneforte onnaissan edusystème,delapropriété, du

fon tionnement duprouveur etdumé anismede génération d'annotations;

Contributions Àtraverslestravauxexposésdans epapier,notreobje tif

estdefavoriserl'automatisation du pro essusde véri ation,en minimisant

esdeuxlimitations.Pour ela,nousproposonsde nouveauxalgorithmesde

génération d'annotations, permettant de générer une partie deshypothèses

supplémentaires, qui étaient auparavant é ritesmanuellement, touten

opti-misant lenombreetlaforme desannotations générées.

Sommaire Dans un premier temps nous illustrons nos motivations en

présentant un exemple lrouge que nous déroulerons jusqu'au bout de et

n,nousprésentonsnos ontributionsense tions5,6et7,avantde on lure.

2 Exemple l rouge

int pt=3;

/*global invariantinv pt:

0 ≤

pt

≤ 3

;*/

intstatus=0;

/*global invariantinvst:

0 ≤

status

≤ 1

;*/ //ensures

0 ≤ \

result

≤ 1

; intinit()

{

...

}

//ensures

0 ≤ \

result

≤ 1

; int ommit()

{

...

}

//ensures

0 ≤ \

result

≤ 1

; intmain(){ /*loopinvarianti: 

0 ≤

status

≤ 1 ∧ 0 ≤

pt

≤ 3



∧ (

pt

= 0 ⇒

status

= 0);

*/ while( pt>0){ status=init();

if (status

&&

ommit

()

)gotolabel_ok; pt--;

}

return0;

label_ok :return1;

}

Figure1  ProgrammeC dé rivant une transa tion en deuxétapes

Pour illustrer l'appro he dé rite dans et arti le nous utilisons le

frag-ment deprogramme Cprésenté en gure2.Ce derniers'inspiredudomaine

des arte à pu e et illustre l'une des problématiques de es programmes

ritiques : réaliser une transa tion par l'appel su essif de deux opérations

(init et ommit). Le nombre d'essais est limité à 3 et la fon tion renvoie

une valeur diérente de 0 si et seulement si les deux opérations on pu être

appeléessu essivement sans erreur.

((¬

RETURN

(

init

) ∨ ¬

status

) ⇒ ¬

CALL

(

ommit

))

Figure 2 Propriétéd'atomi ité à vérier

Nousproposonsdevérierque eprogrammerespe telaformuledé rite

engure2.Celle- i exprimeunepropriétéd'atomi ité : ommit n'estappelé

que si init a été appelé juste avant et a terminé sans erreur. Notons que

la logique LTL utilisée a été étendue ave des prédi ats (Call et Return )

permettant d'exprimerle faitqu'une opération soit appelée ous'arrête.

0

1

status and Return(init_trans)

not Call(commit_trans)

status and Return(init_trans) and not Call(commit_trans)

True

à traduire la formule en un automate de Bü hi (gure 3) qui sera ensuite

réé ritsouslaformed'annotationsdansleprogrammeC.Latradu tionLTL

versBü hi estréalisée par l'outil LTL2BA[5 ℄ etnesera pasdétailléei i.

3 Langage onsidéré

3.1 Sémantique de tra es asso iée à un programme

La sémantiqueobservationnelle d'unprogramme

P

peutêtre représentée parunsystèmedetransitions,dontlesétatssontdesétatsobservablesdu

programme. Les états observables sont les états dans lesquel se trouve le

système au moment d'un appel ou d'un retour d'opération. En plus des

variables du systèmes esétats ontiennent don un ouple dedonnées

sup-plémentaires:si 'estunappelouunretourd'opérationetlenomde

l'opéra-tion on ernée.Nousreprésentons esinformationsave deuxvariables

Oper

et

St

ontenant respe tivement le nomdel'opération etsonstatut (Callou Return ).Unextraitdusystèmedetransitionsasso iéauprogrammelrouge

estdé riten gure4.

cpt=3

Status=3

St=Call

...

cpt=3

Status=3

St=Call

cpt=3

Status=...

Oper=main

Oper=init

Oper=init

St=Return

Figure4Extraitdusystèmedetransitionsasso iéauprogrammelrouge

La sémantique d'un programme

P

peut être dénie par l'ensemble des tra esdesonsystèmedetransitions.Intuitivement,unetra eestlaséquen e

desétats d'un hemindu systèmede transitions,partant de l'étatinitial.

3.2 Sémantique des annotations de programme

Un programmepeutêtreannotépar desassertionslogiques.Celles- ine

modient passon omportement (don sasémantique), maispermettent

d'-exprimerdespropriétésquel'onveutvérierà ertainspointsduprogramme.

I inousneparlonsqued'invariants,depré- onditionsetdepost- onditions.

Dénition 1 (Sémantique des assertions) Nous dénissons la

séman-tique des assertions d'un programme

P

par rapportà une tra e

σ

de

P

.

Annotation Sémantique

I(I)

∀i.σ(i) |= I

Precondition(

op

, P)

I(Oper =

op

∧ St =

Call

⇒ P)

ablesd'annotations 1

,quisont desvariables nepouvant pasêtreutiliséepar

leprogramme,maisseulement dansles annotations:



D(v,

Init

)

:dé laration de

v

ave Init ommevaleur initiale.



A(v, E)

:assignationde

v

par

E

.L'expression

E

ne peutavoir d'eet debord surl'étatdu programme.

3.3 Sémantique des automates de Bü hi de sûreté

Dans ette arti le, nous nous fo alisons sur la omposante sûreté des

propriétés temporelles. C'est pourquoi, nous rappelons la dénition de la

stru ture d'automate de Bü hide sûreté et quelquesrésultatsimportants à

proposde ette lasse d'automates.

Dénition 2 (Automate de Bü hi de sûreté) Soit

PRED

l'ensembledes prédi ats surlesétatsduprogramme. UnautomatedeBü hidénisur

PRED

est un triplet

hQ, q

0

,

Ri

où



Q

est unensemble ni d'états del'automate, 

q

0

∈ Q

est l'état initial del'automate,



R

⊆ Q × PRED × Q

est un ensembleni de règles de transition.

Nousnotons

BUCHI

l'ensembledesautomatesdeBü hi .Unautomatede Bü hipeutse syn hroniser ave une tra e

σ

d'unprogramme

P

grâ e àune fon tionde syn hronisation.

Dénition 3 (Fon tion de syn hronisation) Soit

A

= hQ, q

0

,

Ri

un au-tomate de Bü hi et

σ

∈ PATH

une tra e. La fon tion de syn hronisation

sync

: BUCHI × PATH × N → 2

Q

est dénie ré ursivement par :



sync(A, σ, 0) = {q

0

}

 Pourtout

i >

0

:

sync(A, σ, i) =







q

′













∃P ∈ PRED · ∃q ∈ Q·





σ(i − 1) |= P∧

q

∈ sync(A, σ, i − 1)∧

hq, P, q

′

_{i ∈ R}











Onditqu'unautomatedeBü hi

A

a epteunprogramme

P

siet seule-ment si, haque tra e

σ

de

P

vérie :

(C

Sync

) ∀i ∈ 0..

len

(σ).sync(A, σ, i) 6= ∅

4 Génération de onditions susantes

En nous basant sur les résultats de [6℄ montrés dans [7℄, nous pouvons

dénirlesannotationsprésentéesengure5 ommesusantespourgarantir

lasyn hronisation d'unprogramme ave un automatede Bü hi.

Soit

P

un programme.Soit

A

= hQ, q

0

,

Ri

un automate de Bü hi de sûreté. L'ensemble des lausesd'annotation CLAUSE

Ann

A

orrespondant à

A

sont : CLAUSE

Ann

A

=

CLAUSE

Decl

A

∪

CLAUSE

T rans

A

∪

CLAUSE

Sync

A

telque CLAUSE

Decl

A

=

S

q∈Q

 D(v

q

,

true)

si

q

= q

0

D(v

q

,

false) si q 6= q

0



CLAUSE

T rans

A

=

S

q∈Q

n

A(v

q

,

W

_q

′

∈

Q∧(q

′

_,P,q)∈R

(P ∧ v

q

′

))

o

CLAUSE

Sync

A

=

{I(

W

q∈Q

(v

q

))}

Figure5Annotationsdesyn hronisationetdedes riptiondelapropriété

Dans le adre de la véri ation par preuve des annotations générées,

nous faisons appel à un générateur d'obligations de preuve (OP) basé sur

un al ul de plus faible pré ondition (WP). Les OP générées sont ensuite

dé hargéessurunprouveurautomatique.Cellesasso iéeàlapropriété

tem-porelle (don issues des annotations de la gure 5) ont la forme dé rite en

gure 6. Intuitivement :si l'automate était syn hronisé avant la transition

(

H

1

), alors il doit être syn hronisé après la transition (But). Pour prouver ela, nous avons omme hypothèses elles liées au ode de syn hronisation

del'automate (

H

2...n

) et elles liéesau orps du programme(

H

n+1...m

).

H

1

W

NbStates

i=0

\

old

(

urStates

[i]) 6= 0

H

2...n

/*Hypothèses issues de CLAUSE

T rans

A

*/

H

n+1...m

/*Hypothèses liées au orps de l'opération */

But

W

NbStates

i=0

urStates

[i] 6= 0

/* CLAUSE

Sync

A

*/

Figure 6 Forme généraledesobligationsde preuve générées

Cettestru ture renddi ile lapreuve automatique, ar:

 Les

H

n+1...m

sontdi ilement exploitablespour lapreuve.En eet,il n'existe pas d'hypothèse faisant le lien entre les états du programme

etles états de l'automate.

 L'hypothèse

H

1

,indiquant quel'on est syn hroniséave au moins un étatdel'automate, estsouvent tropfaible.Eneet,s'il existeun état

pour lequel au une transitionn'est possible, alors il faut être apable

de montrer que l'on ne pouvait pas y être. On retombe alors dans le

premierproblème.

De efait,nousproposons,danslesse tionssuivantes,denouveaux

algo-rithmes de génération d'annotations. Ceux- ivont s'atta her(i) à exploiter

les hypothèses sur le ontexte du programme, par le biais d'une

axiomati-sation de l'automate de la propriété, qui fera le lien entre les hypothèses

H

n+1...m

et

H

2...n

, (ii) à limiter la disjon tion sur les états du But et de l'hypothèse

H

1

,en ex luant desétats inatteignables.

L'obje tif de ette se tion est d'optimiser le pro essus de génération

d'annotations en vue d'obtenir des obligations de preuve qui puissent être

dé hargées par unprouveurautomatique. Pour e faire, nousproposons :

 enentréeetsortiede haqueopération,d'ajouterdansdespréet

post- onditionsdonnant laliste desétatsde syn hronisation possibles, an

deréduireles disjon tions

H

1

etBut.

 une axiomatisation de l'automate, permettant d'ajouter dans les

hy-pothèses de l'obligation de preuve, un lien logique entre les états du

programmeet es del'automate.

5.1 Ajout de spé i ation aux opérations

Prin ipe Dans ertains as,pourgarantirquelapropriétén'estpasviolée,

ilestné essairedesavoirqueleprogrammenepeutpasêtresyn hroniséave

un état donné. Comme la véri ation est ee tuée pour haque opération,

indépendamment de son ontexte, nous proposons don d'atta her e type

d'informationsàlapré- onditionetàlapost- onditionde haqueopération.

Mise en ÷uvre Dans un premier temps, nous allons onsidérer que

l'u-tilisateur aura la harge de pré iser, pour haque opération, les états ave

lesquels elle- inepeutpasêtresyn hronisée.Ense tion6,nousproposerons

diérentes méthodes permettant de générer automatiquement une première

approximationde esannotations.

5.2 Axiomatisation de l'automate

Prin ipe Il n'est souvent pas susant d'aner l'ensemble des états

pos-siblement syn hronisés en débutetn d'opération pour vérierqu'une

pro-priété est respe tée par un programme. En eet, e statut peut dépendre

du ontexte de l'appel. C'est pourquoi, nous proposons de raner la vue

que l'on a du système et de onsidérer non plus seulement le dernier état

de syn hronisation ( urStates ), mais aussi ha une des transitions pouvant

avoir été fran hies pour mener à l'un de esétats ( urTrans ). I i, une

tran-sition

tr

estdé rite parun étatde départ(transStart

(tr)

), unétatd'arrivée (transStop

(tr)

) etune ondition de fran hissement (transCond

(tr)

). L'ajout de estransitionspermetnotamment d'établirque,siau unedestransitions

atteignantunétat

E

donnén'asa onditiondefran hissementvériée,alors lesystèmene peutpasêtre syn hroniséave

E

.

Miseen÷uvre Dansunsou isdesimpli ation,laspé i ationde haque

nous mémorisons également le pré édent ensemble des états syn hronisés

ave le système( urStates Old

).

/* logi integertransStart(integer tr);

 axiomtransStart

0

:transStart(0)=/*Étatde départ delatransition 0*/;

 axiomtransStart

1

:transStart(1)=/*Étatde départ delatransition 1*/;

 ...

 logi integertransStop(integer tr);

 axiomtransStop

0

:transStop(0)=/*Étatd'arrivée delatransition 0*/;

 axiomtransStop

1

:transStop(1)=/*Étatd'arrivée delatransition 1*/;

 ...

 predi atetransCond(integer tr)=



(tr = 0 ⇒ . . .

/*Conditiondelatransition0*/

) ∧



(tr = 1 ⇒ . . .

/*Conditiondelatransition1*/

) ∧

 ... */

Figure 7 Axiomatisation de l'automatede lapropriété vériée

L'automate étant onstant, il est dé rit sous la forme de onstantes

logiques (d'axiomes), omme montré en gure 7. Pour exploiter et

auto-mate, nous introduisons également diérents invariants indiquant, par

ex-emple, que l'on ne peut pas être syn hronisé ave un état dans lequel le

systèmen'apaspu allerpar lefran hissement d'unetransition(gure 8).

/* globalinvariantNon-atteignabilité

1

:



∀st; 0 ≤ st <

NbStates

∧







∀tr; 0 ≤ tr <

NbTrans

⇒

urTrans

[tr] = 0 ∨

transStop

(tr) 6= st ∨

¬

transCond

(tr) ∨

urStates Old

[

transStart

(tr)] = 0







⇒

urStates

[st] = 0;

*/

Intuitivement:pourqu'unétat

st

nesoitpassyn hronisé,ilsutque, pourtoutetransition

tr

:soit

tr

n'estpasmémorisée omme fran hie, soit elle ne mène pas à

st

, soit sa ondition de fran hissement est fausse, soit lesystème n'était passyn hronisé ave son état de départ

àl'instant d'avant.

Figure 8 Exemple d'invariant de non-atteignabilité généré

Le ode issu de la lause CLAUSE

Sync

A

(gure 5) et permettant de syn- hroniser le programme ave l'automate est don adapté par rapport aux

travaux initiaux [6℄ pour prendre en ompte les nouvelles données

intro-duites.Un exemple estprésentéen gure9.

Ave la mémorisation des transitions et l'introdu tion de divers inv

ari-antspermettant de lieretd'exploiter lesdiérentesinformations, lenombre

d'obligationsdepreuveaugmentetrèsrapidement ave lenombred'étatsou

de transitions. Dans la se tion suivante, nous proposons diérentes

analy-ses statiques permettant de prévoir des as impossibles, an de réduire le

Oper

=

op_ ommit/*Nomde l'opération*/;

St

=

Call/*Statutde l'opération(Appelou retour)*/; /*Miseàjour desan iens états*/

for

(

st

= 0 ;

st

<

NbStates

;

st

+ +)

{ urStatesOld

[

st

] =

urStates

[

st

]

; urStates

[

st

] = 0

}

/*Miseàjour destransitionsetdesétats*/

for

(

tr

= 0 ;

tr

<

NbTrans

;

tr

+ +)

{ tmp

=

urStates

Old

[

transStart

(

tr

)] ∧

transCond; urTrans

[

tr

] =

tmp;

urStates

[

transStop

(

tr

)] =

urStates

[

transStop

(

tr

)] ∨

tmp }

Figure 9 Code de syn hronisation généré

6 Limitation de l'explosion ombinatoire

Dans ettese tion,toutl'enjeu onsisteàréduirestatiquementlesespa es

d'étatsetde transitions a eptésenentrée etsortiede haqueopération.

Notons que la orre tion du système ne peut pas être altérée par es

simpli ations. En eet, si la spé i ation est trop simpliée et qu'un état

atteignable en est retiré, alors le ode qui est généré pour al uler la

syn- hronisation ave l'automatemènera dansun étatinterditetles obligations

preuve ne pourrons pasêtre vériées.

Pour spé ier les opérations, nous proposons une appro he en 2 temps.

Dansunpremiertemps,nousspé ionslesopérationsàpartirdelapropriété.

Cette première appro he grossière est ensuite ranée par propagation des

ontraintes au traversdu ot de ontrle, par interprétationabstraite.

6.1 Sur-approximation depuis la propriété

Les gardes des transitions de l'automate sont dé rites en termes

d'ex-pressions,portant surlesvariablesduprogramme,etdeprédi ats,dé rivant

l'appel ou le retour d'une opération. En s'abstrayant des expressions, il est

possibled'exploiterlesprédi atspourprédirestatiquementqu'unetransition

nepeutpasêtrefran hie par l'appel ouleretour d'uneopérationdonnéeet

pour pouvoirretirer ette transitionde laspé i ation del'opération.

Par exemple, l'appel de l'opération ommit ne peut fran hirau une des

transitionsdelapropriétédé riteengure3.Sapré- onditionseréduitdon

aufran hissement de latransitionallant de l'état0 versl'état 1.

post- ondition,tellesquePré

(

Op

).

transestl'ensembledestransitionsquipeuvent être fran hies par l'appel d'Op etque Pré

(

Op

).

état est l'ensemble desétats de syn hronisation autorisés. Il estalors possible, àpartir de l'automatede

lapropriété, de al ulerune sur-approximationdelaspé i ation de haque

opération omme suit:

Pré

(

Op

).

trans

← {tr |

l'appeld'Op n'est pasinterditpar tr

}

Pré

(

Op

).

état

←

transStop

[

Pré

(

Op

).

trans

]

Post

(

Op

).

trans

← {tr |

leretourd'Op n'est pasinterditpar tr

}

Post

(

Op

).

état

←

transStop

[

Post

(

Op

).

trans

]

Oùlanotation

F

[E]

est l'image de l'ensemble

E

par lafon tion

F

.

Cette première appro he permet de retirer des transitions dire tement

interdites. Enn, laspé i ation de l'opération main peutêtre ranée, ar

étant l'unique point d'entrée du programme étudié, ses états d'entrée sont

né essairementdesétatsinitiauxdelapropriété.Danslesse tionssuivantes,

nous proposons de propager es ontraintes à travers le ot de ontrle du

programme.

6.2 Propagation statique des ontraintes

À e stade du traitement, haque opération a une pré et une

post- ondition autorisant tous les états et toutes les transitions sauf eux qui

sont expli itement interdits par la propriété. Nous proposons maintenant

de propager es ontraintes en réalisant une interprétation abstraite

avant-arrière [2℄, où l'on ne onsidère que les états et les transitions de la

pro-priété(ons'abstraitdesexpressionsrelativesauxvariablesdusystème).Une

première passe (en avant) permet, pour haque opération, de propager sa

pré- ondition à travers son orps, jusqu'àrestreindre sapost- ondition par

rapportàl'ensembledesétats atteignables. Delamême manière, une

deux-ième passe (enarrière) permetde restreindrela pré- onditionà eux de ses

états quine mènent pasné essairement dansune post- onditioninterdite.

Cet algorithme est déni par indu tion sur l'ensemble des instru tions.

Étantdonnésunepré- ondition

P

etuneséquen ed'opérations

L

,lagure10 illustrelapropagationdelapré- onditionFwd

(P, L)

demanièreintuitivesur ertaines instru tions lé.

Lorsqu'unappeld'opérationestren ontrédurantlapasseenavant, 'est

lapost- onditiondel'opérationquidevientlapré- onditionpropagée,tandis

que durant la passe en arrière, 'est sa pré- ondition qui devient la

post- onditionpropagée.

ap-Fwd

(P, [ ]) ˆ

= P

Fwd

(P, (x = E) :: L) ˆ

=

Fwd

(P, L)

Fwd

(P,

Call

(

Op

) :: L) ˆ

=

Fwd

(

Post

(

Op

), L)

Fwd

(P, (

IF

(c) B

1

ELSE

B

2

) :: L) ˆ

=

let

p

1

, p

2

=

Fwd

(P, B

1

),

Fwd

(P, B

2

)

inFwd

(p

1

∨ p

2

, L)

Fwd

(P, (

return

e

) :: []) ˆ

=

(

trans

= {tr |

transStart

(tr) ∈ P.

état

∧

leretourd'Oppeutfran hirtr

}

état

=

transStop

[

Post

(

Op

).

trans

])

. . .

Figure10Exempledepropagationdepré- onditionsurquelques

instru -tions

peletde haqueretourd'opération.Ce oden'étant pasen oregénéré,ilest

don né essaire de le simuler en déterminant l'ensemble destransitions qui

peuvent être fran hies, omme l'illustrele as du retour. Dans l'algorithme

de propagationde lapost- ondition, l'appro he est similairemais 'est

l'in-stru tion d'appel qui né essite de al uler le fran hissement de transitions.

La post- ondition (resp. pré) d'une opération est alors l'interse tion entre

sapost- ondition (resp.pré) issuedela propriétéet ellepropagée par Fwd

(resp.Ba kward) :

Post

(

Op

) ←

Post

(

Op

) ∩

Fwd

(

Pré

(

Op

),

body

(

Op

))

Pré

(

Op

)

←

Pré

(

Op

)

∩

Ba kward

(

Post

(

Op

),

body

(

Op

))

Dans[11℄, esontlesvariablesd'annotationquisontpropagéesetla

prop-agation est ee tuée dans le sens ontraire. Par exemple, la pré- ondition

d'une opération

o

y al ulée omme l'union des pré- onditions des instru -tions de

o

,diminuée desprédi ats portant sur desvariables modiées avant leur apparition. Notre appro he est don beau oup plus ne, grâ e au fait

que l'on ne traite pas des prédi ats logiques mais des ensembles d'états et

detransitions.Nousne générons lesprédi ats asso iés qu'unefois toutes les

analysesee tuées.

Restri tionaux asd'utilisation Durant etteanalyse,l'intégralitédes

appels d'opération est observé. Il est don possible de re enser l'ensemble

des as d'utilisation de haque opération. Ainsi, lorsqu'une opération n'est

jamais appelée depuis ertains de ses états d'entrée autorisés, es derniers

sont supprimés de la liste, simpliant d'autant les obligations de preuve

générées. Lemême traitement est ee tuépourles post- onditions.

Spé i ation des bou les Propager une pré ou une post- ondition

re-vientàasso ierunespé i ationà haque(blo d')instru tion(s).En

ext while(1){ {pré int } if( )gotoLabelEndLoop; .../* Loopbody*/ {post int } } LabelEndLoop : {post ext }

Figure 11 Formed'unebou le (dansl'outil Frama-C) ave annotations

etdeluigénéreruninvariantentermedesétatsettransitionsdelapropriété.

Cetteétudeétantréaliséedansle adredel'outilFrama-C,nouspouvons

prendre en ompte les pré-traitements qu'ilee tue. Ainsi, toutebou le est

sous la forme dé rite en gure 11. Étant données ses deux pré- onditions

(dela bou le etde son orps) etses deux post- onditions, l'invariant d'une

bou le peuts'exprimer delamanière suivante:

// Loop invariant i:

(

Init

∧

Pré

ext

) ∨ (¬

Init

∧

Post int

)

oùInit estune variablefraî he,identiant lapremière itération.

Le al uldesassertions, orrespondàun al uldepointxeutilisantFwd

etBa kward à partirsoit dePré ext

,pour lapasse en avant,soit dePost ext

,

pour la passe en arrière. Au nal, l'introdu tion de la disjon tionpermet

d'anerl'invariant.Notonsquanddansnotre asparti uleroùl'on onnaitla

préetlapost- onditiondelabou le,lagénérationd'uninvariantdisjon tifne

seheurtepasaux oûtsthéoriquesdelagénérationd'invariantsdisjon tifs[3℄.

Ranement des post- onditions Enn, nous proposons de raner la

représentation manipulée des post- onditions pour augmenter la pré ision

des spé i ations. Pour e faire, nous onsidérons les états et transitions

autorisés en sortie d'une opération en terme des états d'entrée de elle- i.

Typiquement,onobtientdespost- onditionsdé omposéesen omportements

dela forme:

behaviorbu h

0

:

assumes urStates[0℄

6=

0

ensures.../*Post- onditionliée à l'état d'entrée 0 */

behaviorbu h

1

:

assumes urStates[1℄

6=

0

ensures.../*Post- onditionliée à l'état d'entrée 1 */

...

Comme l'ensemble possible des états d'entrée est onnu de l'appelant,

tions al ulées,en parti ulier dansles stru turesde ontrles pouvant avoir

plusieurs sour es(bou les, ibles degoto, sortiede onditionnelles, et ).

7 Développements réalisés

Lestravauxdé ritsi iontétéimplantésdansleplug-inAoraï,qui

s'in-tègredanslaplate-formeFrama-C 2

.DéveloppéeparleCEA-Listet

l'INRIA-Sa lay  Île-de-Fran e, Frama-C est une suite open-sour e d'outils dédiés à

l'analyse de programmes C annotés (ave le langage ACSL). La gure 12

résume la démar he générale de l'utilisation du Plug-in Aoraï et de ses

in-tera tions ave lesoutilsextérieurs.

Automate de Büchi

Simplifiée

LTL

LTL2BA

LTL

Calcul des annotations

Pré−traitement Frama−C

Programme C

annoté

Jessie pour Frama−C

Why

Prouveurs

Programme C

Figure 12  Vue généralede fon tion duplug-in

L'outil LTL2BA [5℄, développé au LSV 3

, est utilisé pour onstruire un

automatedebü hireprésentant unepropriétéLTL.Certainesrestri tionsde

langage nousobligent à retirer les expressions de la formule LTL initialeet

deles repla erensuite dansl'automateproduit.

Le plug-in Jessie [10℄ de Frama-C est ensuite utilisé pour l'analyse

dé-du tive du programme. En interne, il utilise l'outil Why [4 ℄ pour générer

les obligations de preuve et les dé harger sur diérents prouveurs tels que

Simplify 4

ouAlt-Ergo [1℄.

Appli ation au programme l rouge Lavéri ationdu programmel

rouge par rapport à la propriété présentée en gure 3 génère 10174

obli-gations de preuve en utilisant le al ul de WP lassique, ontre seulement

296 en utilisant la méthode de al ule a e du WP proposéepar K.

Rus-tan M. Leino [9℄ (implantée dans Why sous le nom de Fast WP). Cette

méthode onsisteànepassystématiquementséparerlesOPsliéesàunmême

bran hementdansleotde ontrleduprogramme.Lenombred'obligations

depreuve peutdon être réduit,maisleur omplexité estaugmentée.

2. http://www.frama- . ea.fr/

3. http://www.lsv.ens- a han.fr/~g asti n/ltl 2ba/ index .php

gure, puisque les OPs que nous générons sont souvent très simples grâ e

auxmultiples instan iationsréalisées.Deplus, ommeungrand nombredes

obligationsdepreuvegénéréessontsimilaires(nedièrentniparleurbut,ni

parleurshypothèsespertinentes 5

),alorsl'utilisation duWPe a e permet

de limiter la dupli ation de es obligations de preuve. En eet, omme la

granularité des propriétés vériée est l'appel et le retour d'opérations, le

ode se situant entre deux appels génère prin ipalement du bruit dans

lesobligations depreuve.

Ainsi,surles296 OPsgénérées,289 sontvériées automatiquement. Les

7restantessonta tuellementfausses.Eneet,lesobligationsdepreuvesont

généréesparleplug-inJessiequiesten oursde développement.Ainsi,ilne

prendpasen oreen ompte lavaleurinitialedestableauxdanslesOPsliées

àlavéri ationdes invariantslors de l'initialisation. 6

8 Bilan et perspe tives

Résultats obtenus Nous avons proposé une extension de travaux

exis-tants [6℄ dans le domaine de la véri ation de propriétés LTL, en axant

notre proposition sur l'aspe t automatique de la résolution des obligations

depreuve générées.

Dans un premier temps (se tion 5), nous avons renfor er la

spé i a-tiongénérée dansle but delierplus fortement leprogramme et l'automate,

simpliant d'autant les raisonnements possibleslors de la résolution

d'obli-gationsde preuve. Dans une deuxième partie (se tion 6), nous avons voulu

diminuer le nombre et la omplexité des obligations de preuve générées en

restreignant l'espa e d'états de la spé i ation. Pour e faire, nous

propa-geonsstatiquementles ontraintesliéessoitàlapropriétévériée,soitauot

de ontrle du programme.Toutes es propositions ont étévalidéespar une

implantation de 7400 lignesd'O aml au seindu plug-inAoraïde Frama-C.

Comparaisonave destravauxexistants Lapropagationdepropriétés

a été abordée dans diérents travaux, dont le plus pro he est elui réalisé

dans le as de l'outil Ja k [11℄, où les auteurs s'intéressent à la

propaga-tion d'annotations JML représentant des propriétés de haut niveau. Leur

appro he sedistinguede lanotreparladisso iationdespro essus. Eneet,

ils proposent une méthode itérative, onsistant à générer des annotations,

puis à les propager, né essitant ainsi la propagation de toutes les

annota-tions logiques. À l'inverse, l'appro he que nous présentons dans et arti le

onsisteà propagerles ontraintes liéesà lapropriétéde hautniveau,avant

5. Hypothèsesné essaires àlavalidationd'unepropriété.

desdiérentes annotationslors de leurpropagation.

Travaux futurs A tuellement,deuxaspe tssemblent importants:la

pré- ision des annotations générées et les hypothèses spé iques à la prise en

ompte delaviva ité.

D'un point de vue génération d'OP,il seraitpossible d'aner en ore la

propagationdesannotations généréesenremplaçant l'interprétation pardes

al uls de WP ou de SP. L'obje tif serait alors de pouvoir ara tériser, si

né essaire,lesétatspossiblesd'entréeousortied'uneopérationentermedes

valeursdes variables du programme.

Enn, la véri ation de la omposante viva itédes propriétés a été

pro-posée dans les travaux originaux et nos apports ne peuvent pas nuire à la

véri ationdesOPgénéréesen e sens.Nousprévoyonstoutefoisd'ee tuer

lemême typed'optimisations sur esobligationsdepreuve,an defavoriser

l'automatisme du mé anisme de véri ation. En parti ulier, il est possible

d'exploiter les mé anismes de variants présents dans le langage

d'annota-tionACSL.

Référen es

[1℄ S.Con hon,E.Contejean,andJ.Kanig. CC(X):E ientlyCombining

EqualityandSolvableTheorieswithoutCanonizers.In5thInternational

Workshop on SatisabilityModulo, Berlin,Germany, July2007.

[2℄ P. Cousot and R. Cousot. Abstra t Interpretation : a Unied Latti e

Modelfor Stati Analysisof Programs byConstru tion or

Approxima-tion ofFixpoints. InPOPL'77, pages238252. ACM,1977.

[3℄ Patri kCousotandRadhiaCousot. Systemati designofprogram

anal-ysis frameworks. In POPL'79,pages269282, 1979.

[4℄ J.-C. Filliâtre. Why : a multi-language multi-prover veri ation tool.

Resear h Report1366,LRI,Université Paris Sud,Mar h 2003.

[5℄ Paul Gastin and Denis Oddoux. Fast LTL to Bü hi automata

trans-lation. In Gérard Berry, Hubert Comon, and Alain Finkel, editors,

CAV'01, volume 2102 ofLNCS,pages 5365.Springer, 2001.

[6℄ J.Groslambert. Veri ation ofLTLonBevent systems.InB'2007,7th

International B Conferen e, LNCS, Besan on, Fran e, January 2007.

Springer-Verlag.

[7℄ Julien Groslambert. Véri ation de propriétés temporelles par

généra-tion d'annotations. PhD thesis, Universitéde Fran he-Comté,

the design of JML a ommodates both runtime assertion he king and

formal veri ation. S ien e of Computer Programming, 55(1-3) :185

208, 2005.

[9℄ K. RustanM.Leino. E ient weakestpre onditions. Information

Pro- essing Letters,93(6) :281288,2005.

[10℄ Y. Moy. Su ient pre onditions for modular assertion he king. In

InternationalConferen eon Veri ation, ModelChe king, andAbstra t

Interpretation, LNCS.SV,jan2008.

[11℄ M. Pavlova, G. Barthe, L. Burdy, M. Huisman, and J-L. Lanet.

En-for ing high-level se urity properties for applets. In J-J. Quisquater,

P.Paradinas,Y.Deswarte,andA.A.ElKalam,editors,CARDIS,pages

116. Kluwer, 2004.

[12℄ K. Trentelman and M. Huisman. Extending JML Spe i ations with

TemporalLogi . InAMAST'02,number2422inLNCS,pages334348.