Le modèle de disponibilité (… en construction)

1. Le modèle de disponibilité(… en construction) Frédéric Cuppens Ahmed Bouabdallah Nora Cuppens-Boulahia

2. Conclusions dernière réunion -- Systèmes à transitions -- Machines abstraites -- Logique temporelle -- Contractualisé -- Fautes -- Malveillances --Ressource, rôle -- Contrôle d’accès -- Contrainte, contrat Politique de disponibilité Spécification du système Environnement d’indisponibilité • Prouver qu’un système donné garantit ces propriétés compte tenu d’un certain environnement d’indisponibilité • Étude de cas moins ambitieuse --Contraintes temporelles -- Notion de droit de disposer -- Respect de l’environnement contractuel Propriété de disponibilité

3. Propriétés intéressantes en logique temporelle • Propriétés d’invariance • Propriété de précédence • Propriétés de vivacité

4. Exemple pour illustrer les propriétés • Un ensemble de m processus Pi • Un système de gestion SG de la ressource R • Une ressource commune R • Deux variables booléennes utilisées par le protocole de communication entre les processus Pi et le gestionnaire SG : • Une variable ri gérée par le processus Pi : ri est positionnée à vrai lorsque le processus Pi demande la ressource R. Elle est positionnée à faux lorsqu’il la libère. • Une variable ai gérée par le système SG : ai est positionnée à vrai lorsque le système SG a accordé la ressource R au processus Pi.

5. Propriété d’invariance (safety property) • Autre appellation : propriété de sûreté • Exprimée avec l’opérateur « toujours »  • Informellement, - « les mauvaises choses ne peuvent (ne doivent pas) pas se produire » - en terme de spécification « ce que le système ne doit pas faire » • Exemple de ce type de propriété : l’exclusion mutuelle Prop1 : la ressource R est accordée a au plus un processus demandeur de cette ressource • Formule en logique temporelle FProp1 de Prop1 FProp1 : /\ (ai  aj) ij

6. Propriété de précédence • Exprimée avec l’opérateur « jusqu’à » U ou un équivalent comme « précède » Pr • Informellement, - introduction d’un ordre explicite entre les évènements • Exemples de ce type de propriété Prop4 : la ressource R ne peut être accordée à Pi que s’il en fait la demande Prop5 : SG accorde la ressource R selon l’ordre des demandes • Formule en logique temporelle FProp4 de Prop4 FProp4 : (ai  (ri U ai)) • Formule en logique temporelle FProp5 de Prop5 FProp5 : ((ri  rj aj) (aj U ai))

7. Propriété de vivacité (liveness property) • Exprimée avec l’opérateur « possible »  • Informellement, - « les bonnes choses vont effectivement se produire » - en terme de spécification « le comportement effectif attendu » • Exemples de ce type de propriété Prop2 : si le processus Pi demande la ressource R alors il l’obtiendra Prop3 : si le processus Pi obtient la ressource R alors il la libèrera • Formule en logique temporelle FProp2 et de Prop2 FProp2 : (riai) • Formule en logique temporelle FProp3 de Prop3 FProp3 : (airi)

8. Propriété de vivacité et disponibilitéRespect du contrat par le fournisseur • Propd1 : le système accordera la ressource partagée R à au plus n processus demandeurs de cette ressource et qui leur est permise • ai(d) variable positionnée à vrai lorsque la ressource R est accordée à Pi pour une durée d • pi le processus Pi a la permission de disposer de la ressource R • Ce que l’on souhaiterait pouvoir exprimer FPropd1 : ( /\ ((ri  pi)  ai(d)))) i  n,dIN

9. Propriété de vivacité et disponibilité : Respect du contrat par le fournisseur • Que se passe-t-il si (ri  pi) avec i  n ? • Le fournisseur est toujours dans l’obligation d’accorder la ressource • Mais conformément au contrat • Introduction de la propriété de précédence pour exprimer des priorité d’accès à la ressource

10. Propriété de vivacité et disponibilité : Respect du contrat par le demandeur • Propd2 : La ressource R doit être libérée une fois le délai de son attribution au processus Pi se soit écoulé ou que la permission d’y accéder lui a été retirée • ai(d) variable positionnée à vrai lorsque la ressource R est accordée à Pi pour une durée d • pi le processus Pi a la permission de disposer de la ressource R • Ce que l’on souhaiterait pouvoir exprimer FPropd2 : (ai (d) (ri  (pi  d=0))

11. Les composants du modèle Dispo • Définir le tuple [, , ,] • Le système temporel : prise en charge des aspects temporels • Les prédicats primitifs : spécification du système • La politique/propriétés de disponibilité • L’environnement de disponibilité (en cours)

12. Système temporel  • p • p • p • p U q • p • p S q N N tk ti N N N N

13. Système temporel  • Introduction des délais • d p • d p • Mais aussi, • (d p) pour introduire les « intervalles » t’i N-d t’k N ti tk N+d t’i+d t’i t’k N ti tk N+d

14. Prédicat primitifs  et propriétés • Les actions primitives ,  (pour le moment) • Les prédicats de base • Propriétés tangentes • start()  req() • done()  start() • pour simplifier req() start() done()

15. Politique de disponibilité et propriétés • Le contrôle d’accès • P() • F() • Propriétés de contrôles d’accès • P1 : cohérence de politique • (P()  F()) • P2 : contrôle d’accès politique fermée • (start()  P()) • P3 : contrôle d’accès politique ouverte • P1  P2  P3 • (F()  start())

16. Politique de disponibilité et propriétés • Les droits • Droitf() • Droitb(,d) • Axiomes • Droitf()  P() • Droitb(,d)  Droitf() • Propriétés relevant du droit de disposer • P4 : disponibilité en temps fini • (Droitf()  req()  start ()) • P5 : disponibilité en temps borné • (Droitb(,d))  req()  dstart ())

17. Politique de disponibilité et propriétés • Les obligations • O-startf() • O-startb(,d) • Axiomes • (O-startf()Droitf()) • (O-startb(,d)Droitb(,d)) • Propriétés relevant de l’obligation disposer • P6 : respect de l’obligation de disposer en temps fini • (O-startf()  start ()) • P7 respect de l’obligation de disposer en temps borné • (O-startb(,d)  dstart ())

18. Politique de disponibilité et propriétés • Les obligations • O-donef() • O-doneb(,d) • Axiome • (O-doneb(,d)O-donef()) • Propriétés relevant de l’obligation de rendre disponible • P8 : respect de l’obligation de terminer en temps fini • (O-donef()  done ()) • P9 : respect de l’obligation de terminer en temps borné • (O-doneb(,d)  ddone ())

19. Politique de disponibilité et propriétés • Les contrats • Expression d’axiomes propres • Exemples • (start ()  O-donef ()) • (start ()  O-doneb(,d)) • Obligations et contrats • P10 : Terminaison en temps fini • (start ()  done ()) • P11 : Terminaison en temps borné • (start ()  ddone ())

20. Conclusion/perspectives sur le modèle • Introduction des ressources • Introduction des rôles (abstraction des sujets demandeurs et allocataires) • Prise en compte de l’environnement d’indisponibilité • Malveillance • Non respect des contrats • Prise en compte des actions « non primitives » • Travaux de décomposition et conséquences sur les permissions les interdictions, les droits et les obligations

21. Étude de cas • Problème « des philosophes » • Le procédé • Identifier les ressources sensibles • Exprimer la politique de sécurité • permissions, interdictions, droits • Spécifier le système • Définir les transitions et actions associées • Formuler en fonction des prédicats utiliser pour l’expression des propriétés de disponibilité • Exprimer les propriétés de disponibilité conformément au modèle • Preuve de propriétés

22. Accès conflictuel à des ressources • Un nombre fini d'utilisateurs ont besoin d'accéder à des ressources • Conflits dus au caractère non partageable de chaque ressource • Intérêts pour la problématique de DISPO : • Interblocage / famine ~déni de service • Origines : • Spécification du système • gestion incorrecte des ressources • Environnement d'indisponibilité • Faute • Malveillance : comportement des utilisateurs • Paradigme général • Drinking philosophers problem (Chandy-Misra_84)

23. Drinking Philosophers Problem [CM_84] • Définitions préliminaires et hypothèses associées • Soit un graphe fini G non orienté : • À chaque nœud est associé un philosophe • À chaque arête est associé un nombre fini de bouteilles • Un philosophe ne peut boire que des bouteilles associées aux arêtes incidentes au nœud auquel il est associé • Deux philosophes voisins peuvent échanger des message de façon asynchrone, ainsi les bouteilles peuvent être échangées • Spécialisation du Drinking Philosophers Problem • Un philosophe assoiffé a besoin de toutes les bouteilles associées à toutes les arêtes incidentes au nœud qui lui est associé, pour pouvoir commencer à boire • 1 Bouteille / arête -> fourchette • Dining Philosophers Problem • Spécialisation du Dining Philosophers Problem • Le graphe est complet • Mutual exclusion problem

24. Politique de contrôle d'accès • Actions primitives A = {cons} • Prédicats de base : req(cons), start(cons), done(cons) • Contrôle d'accès • Permissions • P(cons) • Propriété de contrôle d'accès • P2 : (start(cons)  P(cons))

25. Politique et propriétés de disponibilité • Politique de disponibilité en temps fini • Droits •  ( Droitf(cons) ) • Obligations •  (¬ O-startf(cons) ) •  (¬ start(cons)  ¬ O-donef(cons)) •  (start(cons)  O-donef(cons)) • Propriétés de disponibilité • P4 :(Droitf(cons)  req(cons)  start(cons)) • P6 :(O-startf(cons)  start(cons)) • P8 :(O-donef(cons)  done(cons))

26. Analyse des propriétés de disponibilité P4' :(req(cons)  start(cons))  ( Droitf(cons) ) P4 :(Droitf(cons)  req(cons)  start(cons))  (¬ O-startf(cons) ) P6 :(O-startf(cons)  start(cons)) P8' : (start (cons)  done (cons))  (¬ start(cons)  ¬ O-donef(cons)) P8 : (O-donef(cons)  done(cons)) Condition suffisante Politique de disponibilité Politique de disponibilité Condition suffisante Politique de disponibilité

27. La solution [CM_84] au Dining Problem • Définitions préliminaires et hypothèses associées • À chaque fourchette est associé un Token (ainsi qu'un message) • Un philosophe ne peut demander une fourchette que s'il possède le jeton correspondant • forku(f) : le philosophe u possède la fourchette f, • reqfu(f) : le philosophe u possède le jeton pour la fourchette f • dirtyu( f ) : u possède la fourchette f qui est sale • thinkingu/hungryu/eatingu: le philosophe u est thinking/hungry/eating • Solution CM_84 • (R1) Requesting a fork f : • hungry, reqf (f), ~ fork(f) ® send request token for fork f (to the philosopher with whom f is shared); reqf (f) := false • (R2) Releasing a fork f : • ~ eating, reqf (f), dirty (f) ® send fork f (to the philosopher with whom fork f is shared); dirty(f) := false; fork(f) := false • (R3) Receiving a request token for f : • upon receiving a request for fork f ® reqf(f) := true • (R4) Receiving a fork f : • upon receiving fork f ® fork(f) := true {~dirty(f)} • Conditions initiales : • Toutes les fourchettes sont sales • chaque fourchette et chaque jeton associé sont détenus par des philosophes distincts • Le graphe de précédence H est sans cycle • u ® v (u précède v) ssi • Soit : u possède la fourchette partagée par u et v et la fourchette est propre, • Ou : v possède la fourchette qui est sale, • Ou : la fourchette est en transit de v vers u.

28. "Implémentation 4 phi" de CM_84 en Promela #define Number_Philo 5 mtype = {fork, token} bool req_cons[Number_Philo]= false bool start_cons[Number_Philo] = false bool done_cons[Number_Philo]= true bool left_fork_at_me[Number_Philo] = true bool left_fork_dirty[Number_Philo] = true bool left_token[Number_Philo] = false bool right_fork_at_me[Number_Philo]=false bool right_fork_dirty[Number_Philo]=false bool right_token[Number_Philo]=true chan un_to_2 = [2] of { byte } chan deux_to_3 = [2] of { byte } chan trois_to_4 = [2] of { byte } chan quatre_to_1 = [2] of { byte } chan un_to_4 = [2] of { byte } chan quatre_to_3 = [2] of { byte } chan trois_to_2 = [2] of { byte } chan deux_to_1 = [2] of { byte }

29. "Implémentation 4 phi" de CM_84 en Promela proctype philosophe(byte my_id; chan from_left; chan to_left; chan from_right; chan to_right ) { initial : do /*demande*/ :: (done_cons[my_id] == true) -> atomic{ done_cons[my_id]=false; req_cons[my_id]= true} /*accès*/ ::(req_cons[my_id] == true) && (left_fork_at_me[my_id] == true) && (right_fork_at_me[my_id]== true) && ( (left_token[my_id]== false) || (left_fork_dirty[my_id]== false) ) && ( (right_token[my_id] == false) || (right_fork_dirty[my_id] == false) ) -> atomic{ left_fork_dirty[my_id]=true; right_fork_dirty[my_id]=true; req_cons[my_id]=false; start_cons[my_id]=true} /*libération*/ :: (start_cons[my_id] == true) -> atomic{ start_cons[my_id]=false; done_cons[my_id]= true}

30. "Implémentation 4 phi" de CM_84 en Promela /*R1G : demande de la fourchette gauche*/ :: (req_cons[my_id] == true) && (left_fork_at_me[my_id]==false) && (left_token[my_id]==true) -> atomic{ to_left!token; left_token[my_id]=false} /*R1D : demande de la fourchette droite*/ :: (req_cons[my_id] == true) && (right_fork_at_me[my_id]==false) && (right_token[my_id]==true) -> atomic{ to_right!token; right_token[my_id]=false}

31. "Implémentation 4 phi" de CM_84 en Promela /*R2G : envoi de la fourchette gauche*/ :: start_cons[my_id] == false && (left_fork_at_me[my_id]==true) && (left_fork_dirty[my_id]== true) && (left_token[my_id]==true) -> atomic{ to_left!fork; left_fork_at_me[my_id]=false; left_fork_dirty[my_id]=false} /*R2D : envoi de la fourchette droite*/ :: start_cons[my_id] == false && (right_fork_at_me[my_id]==true) && (right_fork_dirty[my_id] == true) && (right_token[my_id]==true) -> atomic{ to_right!fork; right_fork_at_me[my_id]=false; right_fork_dirty[my_id]=false}

32. "Implémentation 4 phi" de CM_84 en Promela /*R3G : réception du jeton gauche */ :: from_left?token -> left_token[my_id]=true /*R3D : réception du jeton droit */ :: from_right?token -> right_token[my_id]=true /*R4G : réception de la fourchette gauche */ :: from_left?fork -> atomic{left_fork_at_me[my_id]=true; left_fork_dirty[my_id]=false} /*R4D : réception de la fourchette droite */ :: from_right?fork -> atomic{ right_fork_at_me[my_id]=true; right_fork_dirty[my_id]=false} od }

33. "Implémentation 4 phi" de CM_84 en Promela init { atomic { left_fork_at_me[4]=false; left_fork_dirty[4]=false; left_token[4]=true; right_fork_at_me[1]=true; right_fork_dirty[1]=true; right_token[1]=false; run philosophe(1, deux_to_1, un_to_2, quatre_to_1, un_to_4); run philosophe(2, trois_to_2, deux_to_3, un_to_2, deux_to_1); run philosophe(3, quatre_to_3, trois_to_4, deux_to_3, trois_to_2); run philosophe(4, un_to_4, quatre_to_1, trois_to_4, quatre_to_3) } }

34. Vérification avec Spin de P4' #define demande1 (req_cons[1] == true) #define demande2 (req_cons[2] == true) #define demande3 (req_cons[3] == true) #define demande4 (req_cons[4] == true) #define mange1 (start_cons[1] == true) #define mange2 (start_cons[2] == true) #define mange3 (start_cons[3] == true) #define mange4 (start_cons[4] == true) [] ( ((demande0) -> (<> (mange0))) && ((demande1) -> (<> (mange1))) && ((demande2) -> (<> (mange2))) && ((demande3) -> (<> (mange3))) && ((demande4) -> (<> (mange4))) ) • P4' n'est pas vérifiée, en raison de l'absence d'équité entre les gardes d'un même processus

35. Vérification avec Spin de P4' • Introduction d'une contrainte d'équité faible minimale (1 transition / philosophe) - étiquette en entrée de boucle --> "initial" - étiquette en réception d'un jeton (en l'occurrence le gauche) --> "R3G" #define initial1 philosophe[1]@initial #define r3g1 philosophe[1]@R3G #define initial2 philosophe[2]@initial #define r3g2 philosophe[2]@R3G #define initial3 philosophe[3]@initial #define r3g3 philosophe[3]@R3G #define initial4 philosophe[4]@initial #define r3g4 philosophe[4]@R3G • Expression de P'4 ( ( (<>[] initial1) -> ([]<> r3g1) ) && ( (<>[] initial2) -> ([]<> r3g2) ) && ( (<>[] initial3) -> ([]<> r3g3) ) && ( (<>[] initial4) -> ([]<> r3g4) ) ) -> ( [] ( (demande1 -> (<> mange1) ) && (demande2 -> (<> mange2) ) && (demande3 -> (<> mange3) ) && (demande4 -> (<> mange4) ) ) ) • (Mes remerciements à Stéphan Merz pour des échanges sur l'outil lwaaspin ainsi que sur la vérification de P'4)

36. Vérification avec Spin de P4' • Génération de l'automate de Büchi et du "Never Claim" associés à P'4 via l'outil ltl2ba • Résultats de vérification avec Spin 4.12 - équité faible entre processus - méthode de compression COLLAPSE ----------------------------------------------------------------------------------- depth 96: Claim reached state 71 (line 336) … depth= 1518837 States= 3.84e+08 Transitions= 3.13029e+09 Memory= 1321.419 (Spin Version 4.1.2 -- 21 February 2004) + Partial Order Reduction + Compression Full statespace search for: never claim + assertion violations + (if within scope of claim) acceptance cycles + (fairness enabled) invalid end states - (disabled by never claim) State-vector 140 byte, depth reached 1518837, errors: 0 3.41974e+07 states, stored (3.84365e+08 visited) 2.7605e+09 states, matched 3.14487e+09 transitions (= visited+matched) 4 atomic steps hash conflicts: 5.51716e+10 (resolved) (max size 2^19 states) -------------------------------------------------------------------------------------