Rennes - DeCert

CELTIQUE
Certification de logiciel par analyse
sémantique
Semantic Analysis for Software Certification
T. Jensen, F. Besson, D. Pichardie
Decert kick-off January 2009
 in brief
Improve on the Software Certification process :
I
by providing better test case generation
I
by proposing new types of semantics-based certificates
Provide the necessary semantic analysis tools
I
precise and efficient static program analysis
Application domains :
I
Safety-critical software in embedded C (subject to existing
certification procedures)
I
Extended byte-code verification of Java byte code
(proposing new kinds of certificates) for safety and
security.
 in brief
Improve on the Software Certification process :
I
by providing better test case generation
I
by proposing new types of semantics-based certificates
Provide the necessary semantic analysis tools
I
precise and efficient static program analysis
Application domains :
I
Safety-critical software in embedded C (subject to existing
certification procedures)
I
Extended byte-code verification of Java byte code
(proposing new kinds of certificates) for safety and
security.
 in brief
Improve on the Software Certification process :
I
by providing better test case generation
I
by proposing new types of semantics-based certificates
Provide the necessary semantic analysis tools
I
precise and efficient static program analysis
Application domains :
I
Safety-critical software in embedded C (subject to existing
certification procedures)
I
Extended byte-code verification of Java byte code
(proposing new kinds of certificates) for safety and
security.
Semantics-based program analysis
Numeric domains :
I
Linear and non-linear program invariants
I
Decision procedures and abstract domains
Object-oriented languages
I
OO memory models ; null-pointer analysis
I
concurrency : data races
I
class-based analyses and modularity
Analysis goals
I
safety properties (absence of run-time errors) and
I
security (confidentiality, proper use of resources)
Software certification
Certification of static analyses
Proof-carrying code from abstract intepretation
Software certificates : communicating proofs
I
compression, certified verifiers, witnesses
Software certification
Certification of static analyses
Proof-carrying code from abstract intepretation
Software certificates : communicating proofs
I
compression, certified verifiers, witnesses
Abstract interpretation-based PCC
Prouver l’inocuité d’un code mobile
Une approche le Proof Carrying Code [NeculaPopl’97]
⇒ envoyer un code avec une preuve vérifiable
Une panoplie de méthodes de preuve :
I
par ordinateur
I
par intimidation
I
par obfuscation
I
par épuisement
coqc <pgm> <battement de paupière> Qed
Prouver l’inocuité d’un code mobile
Une approche le Proof Carrying Code [NeculaPopl’97]
⇒ envoyer un code avec une preuve vérifiable
Une panoplie de méthodes de preuve :
I
par ordinateur
I
par intimidation
I
par obfuscation
I
SANS épuisement
coqc <pgm> <battement de paupière> Qed
Prouver l’inocuité d’un code mobile
Une approche le Proof Carrying Code [NeculaPopl’97]
⇒ envoyer un code avec une preuve vérifiable
Une panoplie de méthodes de preuve :
I
par ordinateur
I
par intimidation
I
par obfuscation
I
SANS épuisement
coqc <pgm> <battement de paupière> Qed
Limiter la TCB du PCC
PCC certifiée par interprétation abstraite
Expérimentation
Le PCC original [Necula’97]
Program semantics
Safety policy
Producer
Consumer
code
VCGen
Lemma
certificate
Kcheck
Can run
Rejected
Proof Carrying Proof Checkers [TCS’2006]
Consumer
Producer
Semantics
Safety policy
checker
proof
code
certificate
Kcheck
Unsound
Sound
checker
CanRun
Rejected
Spécification du vérifieur
checker : program → certificate → bool
checker_ok :∀ p cert , checker p cert=true → p phi
p φ formalise la politique de sécurité.
Le certificat contient :
I
des invariants calculés par interprétation abstraite ;
I
des ”preuves” dans un format dédié pour vérifier les
invariants proposés.
Écrire un vérifieur, c’est facile :
checker p cert = false
Écrire un vérifieur puissant ET efficace
PS : génération automatique de certificats
Spécification du vérifieur
checker : program → certificate → bool
checker_ok :∀ p cert , checker p cert=true → p phi
p φ formalise la politique de sécurité.
Le certificat contient :
I
des invariants calculés par interprétation abstraite ;
I
des ”preuves” dans un format dédié pour vérifier les
invariants proposés.
Écrire un vérifieur, c’est facile :
checker p cert = false
Écrire un vérifieur puissant ET efficace
PS : génération automatique de certificats
Spécification du vérifieur
checker : program → certificate → bool
checker_ok :∀ p cert , checker p cert=true → p phi
p φ formalise la politique de sécurité.
Le certificat contient :
I
des invariants calculés par interprétation abstraite ;
I
des ”preuves” dans un format dédié pour vérifier les
invariants proposés.
Écrire un vérifieur, c’est facile :
checker p cert = false
Écrire un vérifieur puissant ET efficace
PS : génération automatique de certificats
Abstraction Carrying Code (ACC) [Puebla et al’04]
Le producteur génère un résultat I par analyse statique
⇒ itération de point fixe, widening, narrowing
Le consommateur exécute checker qui :
I
Vérifie que I est un (post) point fixe
P] (I) v I
I
I est suffisamment fort
I v φ]
⇒ Par correction de l’interprétation abstraite, conclue P φ
Cas d’étude : vérification de bornes de tableaux
Langage :
I
bytecode while (push, pop, load, store, if cmp, goto, +,*,-
I
méthodes statiques (récursion)
I
tableaux d’entiers
I
champs statiques
Analyse : à base de polyèdres convexes [CousotHalbwachs’78]
Élagage [ESOP’06] : pour ne conserver que les invariants
nécessaires à la propriété
⇒ certificats plus petits
Le défi : un vérifieur Coq pour avaler les monstres
Loc(m, p) = (en−1 :: · · · :: e0 :: s] , l] ) ! n = nbArgs(m 0 )
n−1
^
]
]
∃R+S0 +A ~ ei = rold
v Pre(m 0 )
i  ∃R0 (l )
i=0





S→S0
]
xauxjy :: s [?/auxj ],
∃S 0 +{res} ~auxj :=res]
!
n−1
^
]
old
]
0
lS→S 0 u ∃R0 ~ (ei = ri )S→S 0  Post(m )S0 →S 0



 v Loc(m, p + 1)

i=0
Pre, Loc, Post ` (m, p) : InvokeStatic m’
where p is the index of the j−th InvokeStatic in m
Loc(m, p) = (e :: s] , l] ) ∃R+A (~res:=e] (l] )) v Post(m)
Pre, Loc, Post ` (m, p) : Return
Éloge de la paresse – c’est la philosophie du vérifieur
L’analyseur calcule :
I
Projection, enveloppe convexe, transformation linéaires
I
Inclusion
Le vérifieur ne calcule pas :
I
Accumule des conditions de vérifications
[Flanagan&Saxe,Popl’01]
I
Décharge les conditions de vérifications à l’aide de
certificats
Résultats expérimentaux
size score certificate size % decrease
Program
before after
BSearch
80 100%
20
11
45%
HeapSort
143 100%
65
25
61%
276 100%
90
42
53%
QuickSort
Random
883
83%
50
31
38%
Jacobi
135
50%
31
10
67%
LU
559
45%
206
96
53%
SparseCompRow
90
33%
34
6
82%
FFT
591
78%
194
50
74%
Score : pourcentage d’accès aux tableaux vérifiés statiquement
Dans la plupart des cas, l’élagage divise par 2 la taille des
invariants.
De manière évidente, petit score ⇒ grosse compression.
Où sont les bugs ? Partout !
p phi
/\ checker p cert = false
I
Le vérifieur est incomplet
I
L’analyseur est incorrect
I
L’analyseur est incomplet
Micromega : vérification réflexive de certificats
arithmétiques
Fast Arithmetic Tactics [Types’06]
the linear case and beyond
infeasible([e1 , . . . , en ]) := ∀x̄ ∈ D , ¬(
n
m
^
ei (x̄) > 0)
i=1
avec D ∈ {Z, Q, R}
e ::= e1 + e2 |e1 ∗ e2 |var|cst
I
Indécidable sur Z
I
Décidable sur R (Tarski’49)
⇒ une preuve sur R donne une preuve sur Z
Vérification de certificats
Lemma (checker-ok)
∃cert, checker(cert, [e1 , . . . , en ]) = true ⇒ infeasible([e1 , . . . , en ])
V
Trame d’une preuve de ∀x̄ ∈ Zn , ¬( m
i=1 ei (x̄) > 0)
change infeasible([e1,...,en]) ;
apply checker-ok ;
exists (oracle [e1,\dots, en]) ;
(* vm_compute ;*)
reflexivity.
Avantages de l’approche
I
Vérifier c’est plus rapide que prouver
I
Le vérifieur est plus facile à prouver correct
I
Ici, les oracles sont des algorithmes existants
I
Le terme de preuve reste petit : taille du but + taille du
certificat
Certificat de positivité : Positivstellensatz (Stengle 74)
Definition (Cone)
Soit P = [e1 , . . . , em ] une liste de polynômes.
I
ei ∈ Cone(P)
I
p1 ∈ Cone(P), p2 ∈ Cone(P) ⇒ p1 + p2 ∈ Cone(P)
I
p1 ∈ Cone(P), p2 ∈ Cone(P) ⇒ p1 ∗ p2 ∈ Cone(P)
I
p2 ∈ Cone(P)
Theorem (Positivstellensatz)
∃cert ∈ Cone(P), ∀x̄, cert(x̄) < 0 ⇒ infeasible([e1 , . . . , en ])
En fait, Stengle a prouvé que c’était complet sur R
(en remplaçant < 0 par = −1)
Génération de certificats
Soit [e1 , ..., em ] une liste de polynôme.
Un certificat est un élément du cone de la forme :
X
Y
C :=
pI ×
ei
I⊆{1,...,m}
i∈I
avec pI est une somme de carré.
I
Si les pI sont constants, c’est un problème linéaire :
X
min
pI | ∀I, pI > 0, ∀x, C(x) = 0, C(cst) < 0
I
Pour degré fixé, c’est un problème d’optimisation convexe
Méthodes des points intérieurs (polynomial)
Linear Matrices Inequalities – Semi-definite programming
Contribution Coq 8.2
I
Paramétré par un anneau ordonné (Evgeny Makarov)
(Z, Z), (Q, Q) , (R, {0, 1})
I
Traitement (naı̈f) de la logique propositionnelle
I
Certificats étendus pour l’arithmétique linéaire entière
cutting plans proofs + énumération
Prouveurs :
I
I
I
I
linéaire : Fourier (ou glpk)
non-linéaire : driver de Hol Light pour csdp
Quelques leçons :
Ltac trop lent
glpk n’est pas fiable
vm compute essentiel
Conclusion
Une architecture PCC en Coq
I
génération efficace de conditions de vérification
I
à base de vérifieurs réflexifs
I
utilisant des résultats d’analyses statiques
Cas d’étude : une analyse polyhèdrique
Travaux futurs :
I
Invariants non-linéaires
I
Étendre le langage
Couche objet ≡ control flow analysis
I
Étendre la logique des vérifieurs
Certificats pour SMT solver (demain)