Différents paramétrages

dvm.exec //_dvm.state

alpha_off

ovm.state ^ovm.exec //_ovm.state

Fig.5.3 –Diagramme de commutation des ex´ecutions d´efensive et offensive.

module BCV_dexec, on montre que pour tout ´etat s, si la v´erification de s

r´eussit alors les r´esultats des ex´ecutions offensive et d´efensive sont ´egaux.

Formellement, cette propri´et´e s’exprime en Coqpar :

Lemma safe_oexec : (s:dvm.state) (check s)→

(mws.alpha (dvm.exec s))=(ovm.exec (alpha_off s)).

La preuve s’effectue tr`es simplement par application du Lemme 2 et de la propri´et´e de validation crois´ee de la figure 5.3.

5.3.4 Différents paramétrages

Nous fournissons ici diff´erents param´etrages du v´erificateur de code octet correspondant aux analyses monovariante, polyvariante et hybride. Ceux-ci simplifient la tˆache de fournir le module de type Stackmap_Struct utilis´e pour le v´erificateur de code octet sur la fonction d’ex´ecution de la machine virtuelle abstraite en ne requ´erant que les contraintes n´ecessaires sur cette machine virtuelle. Ces param´etrages se veulent donc comme des points d’en-tr´ee directs dans la formalisation et dispensent l’utilisateur de la connais-sance de son organisation.

Vérification monovariante

Dans le cas d’une analyse monovariante, l’ensemble d’´etats manipul´e par la structure d’historique est r´eduit aux ´etats eux-mˆemes. `A ce type d’ana-lyse correspond donc une instance triviale Id_History_Struct du module

History_Struct o`u l’ensemble abstrait est l’ensemble des ´etats lui-mˆeme.

L’extension de l’ordre sur l’ensemble abstrait ^hist_less est alors directe-ment l’ordre sur les ´etats. La relation d’appartenance hist_in est l’´egalit´e.

Enfin, l’applicationhist_fold_rightd’une fonctionf est l’application def elle-mˆeme.

La structure d’historique fix´ee de cette mani`ere, les donn´ees n´ eces-saires sur la machine virtuelle abstraite pour construire un module de type

Stackmap_Structsont rassembl´ees dans la structure suivante :

D´efinition 21 Une structure de v´erification monovariante est d´efinie par la donn´ee d’une machine virtuelle abstraite, d’une fonction d’unification d´ e-croissante sur les ´etats, d’un ordre bien fond´e sur ces derniers avec un ´el´ e-ment maximum et d’une fonction d’ex´ecution monotone.

De mani`ere formelle :

Module Type MVS.

Declare Module avm : AVM.

Import avm.

Parameter unify : state →state→state.

Axiom unify_decr : (s:state)(decreases ? less_state (unify s)).

Axiom unify_eq : (s:state; s’:state) (unify s s’)=s’→ (clos_refl_trans ? less_state s’ s).

Axiom less_state_acc : (well_founded ? less_state).

Parameter top_st : state.

Axiom le_top_st : (a:state)(clos_refl_trans ? less_state a top_st).

Axiom exec_mon : (l:loc)(monotone ? less_state (exec l)).

End MVS.

Pour faire le lien avec la structure Stackmap_Struct, nous fournis-sons un foncteur de module (MVS2SMS). Ce foncteur utilise la structure

Id_History_Struct et les donn´ees d’un module de type MVS pass´e en ar-gument pour construire un module de typeStackmap_Struct.

Vérification polyvariante

Dans le cas d’une analyse polyvariante, l’unification entre un ´etat pro-venant d’un pas d’ex´ecution et la structure d’historique abstrait consiste

`

a rajouter cet ´etat `a l’ensemble. Pour que la v´erification termine, il faut donc montrer que l’ensemble d’historique abstrait est fini. Une des possibi-lit´es pour cela serait de montrer que l’ensemble des types manipul´es par la machine virtuelle est fini. Ainsi, puisque le nombre de variables locales et la taille maximale de la pile d’op´erandes sont connus, l’ensemble des ´etats manipul´es par la machine virtuelle est lui aussi fini. Cette solution est ce-pendant difficile `a mettre en œuvre car elle requiert soit une d´efinition du syst`eme de types de la machine virtuelle induisant par construction un en-semble fini de types (ce n’est pas le cas pour notre syst`eme de type) soit une

´enum´eration des types manipul´es par la machine virtuelle et la preuve que cette ´enum´eration est invariante par ex´ecution. Pour assurer que l’ensemble

d’historique abstrait est fini, nous pr´ef´erons fixer une taille maximale pour ce dernier et y placer un ´etat d’erreur si cette taille est atteinte (afin d’assurer la correction de l’analyse). Cette solution, plus simple pour les preuves, pr´ e-sente ´egalement l’avantage de pouvoir borner l’espace m´emoire utilis´e pour la v´erification d’un programme.

D´efinition 22 Une structure de v´erification polyvarianteest d´efinie par la donn´ee d’une machine virtuelle abstraite, d’une taille maximale pour les en-sembles manipul´es, d’un ´etat d’erreur, d’un ´etat maximum et d’une fonction d’ex´ecution monotone.

De mani`ere formelle :

Module Type PVS.

Declare Module avm.

Import avm.

Parameter max_length_set : nat.

Parameter err : state.

Axiom err_state_err : (err_state err).

Parameter top_st : state.

Axiom le_top_st : (a:state)(clos_refl_trans ? less_state a top_st).

Axiom exec_mon : (l:loc)(monotone ? less_state (exec l)).

End PVS.

Pour ce type de v´erification, nous instancions l’ensemble d’´etats de la structure d’historique par une structure d’ensemble

List_set_History_Struct utilisant une repr´esentation des ensembles math´ematiques sous forme de listes (librairie Coq ^ListSet). L’extension de l’ordre sur l’ensemble abstrait hist_less est l’ordre sur les cardinaux des ensembles. La relation d’appartenance hist_in est l’appartenance `a un ensemble. Enfin, `a l’application hist_fold_right est associ´ee l’application

fold_rightsur les listes.

Comme pour l’analyse monovariante, nous fournissons un foncteur de modulePVS2SMSprenant en argument un module de typePVS et satisfaisant le type de moduleStackmap_Struct.

Vérification hybride

La v´erification hybride est une variante des v´erifications monovariante et polyvariante o`u une l’unification entre ´etats n’intervient que dans des cas sp´ecifiques discrimin´es par une fonction d’optimisation (on cherchera par exemple avant d’unifier si les ´etats ont des adresses de retour identiques).

Une structure de v´erification hybride contiendra donc, outre la fonction d’optimisation, l’union des ´el´ements des v´erifications monovariante et poly-variante.

D´efinition 23 Une structure de v´erification hybride est donn´ee par une machine virtuelle abstraite, une fonction bool´eenne entre ´etats, une fonction d’unification d´ecroissante sur les ´etats, un ordre bien fond´e sur ces derniers avec un ´el´ement maximum, une fonction d’ex´ecution monotone, une taille maximale pour les ensembles manipul´es, un ´etat d’erreur, un ´etat maximum et enfin une fonction d’ex´ecution monotone.

De mani`ere formelle,

Module Type HVS.

Declare Module avm.

Import avm.

Parameter unify : state →state→state.

Axiom unify_decr : (s:state)(decreases ? less_state (unify s)).

Axiom unify_eq : (s:state; s’:state) (unify s s’)=s’→ (clos_refl_trans ? less_state s’ s).

Parameter opt_unify : state→state →bool.

Axiom less_state_acc : (well_founded ? less_state).

Parameter top_st : state.

Axiom le_top_st : (a:state)(clos_refl_trans ? less_state a top_st).

Axiom exec_mon : (l:loc)(monotone ? less_state (exec l)).

Parameter max_length_set : nat.

Parameter err : state.

Axiom err_state_err : (err_state err).

End HVS.

Pour construire un module de type Stackmap_Struct `a partir d’un mo-dule de typeHVS, le foncteur de moduleHVS2SMS utilise (comme pour l’ana-lyse polyvariante) la structure d’ensemble List_set_History_Struct. La fonction d’unification du moduleStackmap_Structest d´efinie en unifiant ou en rajoutant `a la structure d’historique les ´etats provenant de l’ex´ecution se-lon la fonctionopt_unify. La taille maximale des ensemblemax_length_set

et les propri´et´es sur la fonction d’unification garantissent la terminaison de l’algorithme.