3.4.1 Introduction
Nous pr´esentons dans cette section une technique d’instrumentation du programme pour contrˆoler le flot d’information. Elle est tir´ee des travaux de Chudnov et Naumann [8]. Les nouvelles instructions incorpor´ees au programme imitent le comportement du moniteur de Russo et Sabelfeld. La s´emantique du programme et le mod`ele de s´ecurit´e sont donc les mˆemes que ceux d´ecrits dans la section 3.3. La suite de cette section s’organise comme suit. Nous commen¸cons par pr´esenter le m´ecanisme d’instrumentation. Nous examinons ensuite la configuration du programme instrument´e et ´etablissons la coh´erence du m´ecanisme.
3.4.2 Le m´ecanisme d’instrumentation
Rappelons que dans notre contexte, instrumenter le programme consiste `a ins´erer dans son code source des commandes pour s´ecuriser le flot d’information.
Le processus d’instrumentation est r´egi par les jugements de la forme G, S, I ` c I ˜c pour les commandes. La version instrument´ee de la commande c est ˜c, d´etermin´ee par c lui-mˆeme et le triplet S, G, I.
– S est une fonction qui associe `a chaque variable x de la commande c une variable d’ombre S(x) qui garde le niveau de s´ecurit´e courant de la variable x. On exige que S soit injective et son image Img(S) doit ˆetre disjointe de l’ensemble des variables de la commande c. Cette exigence permet d’´eviter d’´ecraser le contenu d’une variable d´ej`a existante avec la variable d’ombre d’une autre variable ou l’inverse.
– La liste finie G contient les noms des variables qui gardent les niveaux de s´ecurit´e des expressions de garde des blocs conditionnels et des boucles dans la r´egion courante de
TR-value S ` v I⊥ TR-var S ` x I S(x) TR-op ∀i ∈ {1, 2}. S ` ei I ˜ei S ` e1⊕ e2I ˜e1t ˜e2 TR-ord ∀i ∈ {1, 2}. S ` ei I ˜ei S ` e1 v e2I ˜e1t ˜e2
Table 3.4 – R`egles de transformation des expressions tir´ees de [8]
contrˆole de la d´ependance. On note Head(G) la tˆete de la pile qui correspond au niveau de s´ecurit´e du bloc conditionnel ou de la boucle la plus `a l’int´erieur.
– I est l’ensemble fini des listes de variables de la commande c qui pourraient ˆetre mises `a jour dans la branche non prise. Il y a une liste pour chaque bloc conditionnel et boucle.
La cardinalit´e de I not´ee |I| correspond au nombre de blocs conditionnels et boucles. On impose que |I| soit ´egal `a |G| et que l’image de S soit disjointe de l’ensemble G. Les r`egles de transformation vont maintenir ces conditions.
Les r`egles d’instrumentations pour les commandes font r´ef´erence aux jugements de la forme S ` e I ˜e pour les expressions. Ce jugement stipule que ˜e est le niveau de s´ecurit´e de l’expression e et correspond `a la borne sup´erieure des niveaux de s´ecurit´e de toutes les variables impliqu´ees dans l’expression. Ces r`egles sont ´enonc´ees dans la table 3.4.
R`egle de transformation des commandes
Le processus de transformation introduit des commandes suppl´ementaires pour traquer les flots implicites et explicites. Ces commandes imitent les op´erations du moniteur MV `a chaque ´
etape de l’ex´ecution du programme. La figure3.3 pr´esente les r`egles de transformation pour les commandes.
La r`egle TR-Assign introduit une nouvelle instruction d’affectation qui met `a jour la variable d’ombre S(x) avec la borne sup´erieure entre le niveau de s´ecurit´e de l’expression e et de celui du contexte. Le niveau du contexte est conserv´e dans la variable head(G), qui se trouve au-dessus de la pile G des niveaux des gardes.
D’apr`es la r`egle TR-If, le programme utilise une nouvelle variable d´enomm´ee x pour garder le niveau de s´ecurit´e de la garde du bloc conditionnel. Ceci est assur´e par la commande x := ˜ethead(G). Ensuite, chaque branche ci est transform´ee dans un environnement diff´erent,
o`u x est pouss´e au-dessus de la pile G des niveaux des expressions de gardes. L’ensemble des variables affect´ees dans la branche non prise est ajout´e `a I. La pile G refl`ete la d´ependance
du contrˆole sur la garde et l’ensemble I permet de prendre en compte les flots implicites. La r`egle TR-While est similaire `a TR-If. Le programme conserve toujours dans une nouvelle variable x le niveau de s´ecurit´e de la garde qui est mis `a jour `a chaque it´eration pour refl´eter la sensibilit´e aux flots. Le corps de la boucle est transform´e dans un nouvel environnement o`u x est pouss´e au-dessus de la pile G.
La famille des r`egles TR-Output* correspond directement aux comportements du moniteur pr´esent´es dans la table3.3 et d´ecrits dans la section3.3.5. Il est `a noter que seule une de ces r`egles est utilis´ee dans une transformation. On laisse aux utilisateurs comme dans le cas du mo- niteur hybride sensible aux flots, le choix d’une des strat´egies parmi TR-OutputFallstaop, TR-OutputDefault, TR-OutputSuppress ou TR-OutputDefault/Suppress.
Figure 3.3 – R`egles de transformation des commandes tir´ees de [8]
3.4.3 Configuration du programme instrument´e
Le syst`eme est constitu´e du programme instrument´e. L’´etat du syst`eme inclut la m´emoire m pour les variables originales, et la m´emoire mst pour les variables dans G et celles dans Img(S). Il est repr´esent´e par les configurations de la forme h˜c, m ] msti. Dans la suite, la partie mst de la m´emoire est consid´er´ee comme une repr´esentation de l’´etat du moniteur instrument´e.
Le programme instrument´e effectue des transitions de la forme : h˜c, m ] msti =⇒ h ˜β c0, m0]
mst0i o`u β est l’´ev´enement ´emis par la transition. On notera par
− →
β
=⇒ sa clˆoture transitive en concat´enant les ´etiquettes. Le programme transform´e commence dans la configuration h˜c, m0] mst0i o`u m0est la m´emoire initiale des variables et mst0 est l’´etat initial du moniteur
instrument´e. Ce dernier satisfait l’invariant : dom(mst) = Img(S) ∪ G.
On montre que si la m´emoire initiale et l’´etat du moniteur instrument´e sont disjoints, ils restent disjoints tout au long de l’ex´ecution du programme.
Observons que les structures G, S, et I sont utilis´es seulement pendant l’instrumentation et n’existent plus `a l’ex´ecution. Elles d´efinissent une vue d’une partie de la m´emoire du programme qui est utilis´ee pour abriter l’´etat du moniteur instrument´e.
Les auteurs ´etablissent formellement une correspondance entre l’´etat du moniteur instrument´e mst, et le contexte de contrˆole ∆ de la configuration du moniteur de Russo et Sabelfeld (paragraphe 3.3.6). Ils s’appuient sur cette correspondance pour prouver la coh´erence du m´ecanisme d’instrumentation.
3.4.4 Conclusion
Pour ˆetre coh´erent, un m´ecanisme d’instrumentation doit ˆetre `a la fois sˆur et transparent. La sˆuret´e dans notre contexte veut que le moniteur instrument´e n’accepte que les ex´ecutions sa- tisfaisant la non-interf´erence insensible `a la terminaison. La transparence quant `a elle, stipule que le moniteur instrument´e doit pouvoir mettre fin aux ex´ecutions non s´ecuritaires, mais ne doit en aucun cas changer le comportement observable du programme. Les auteurs ´etablissent la sˆuret´e et la transparence du m´ecanisme en montrant qu’un programme transform´e est ´equi- valent, du point de vue de son comportement visible, au mˆeme programme ex´ecut´e en pr´esence du moniteur de Russo et Sabelfeld du paragraphe pr´ec´edent. Ils aboutissent `a la conclusion que toute ex´ecution du programme transform´e satisfait la non-interf´erence insensible `a la terminaison.