Le modle 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
-- Contractualisé -- Fautes -- Malveillances
-- Systèmes à transitions -- Machines
abstraites -- Logique temporelle
-- Ressource, rôle -- Contrôle daccès --
Contrainte, contrat
Politique de disponibilité
Spécification du système
Environnement dindisponibilité

• Prouver quun système donné garantit ces
  propriétés compte tenu dun certain environnement
  dindisponibilité
• Étude de cas moins ambitieuse

-- Contraintes temporelles -- Notion de droit de
disposer -- Respect de lenvironnement contractuel
Propriété de disponibilité
3
Propriétés intéressantes en logique temporelle

• Propriétés dinvariance
• 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 lorsquil 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é dinvariance (safety property)

• Autre appellation propriété de sûreté
• Exprimée avec lopé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é lexclusion
  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 lopérateur  jusquà  U ou un
  équivalent comme  précède  Pr
• Informellement,
• - introduction dun ordre explicite entre les
  évènements
• Exemples de ce type de propriété
• Prop4 la ressource R ne peut être accordée à Pi
  que sil en fait la demande
• Prop5 SG accorde la ressource R selon lordre
  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 lopé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 lobtiendra
• 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 lon 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 lobligation
  daccorder la ressource
• Mais conformément au contrat
• Introduction de la propriété de précédence pour
  exprimer des priorité daccè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 dy 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 lon souhaiterait pouvoir exprimer
• FPropd2 (ai (d) ? ?(?ri ? (?pi ? d0))

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é
• Lenvironnement 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 

ti
tk
N
Nd
ti
tk
N-d
tid
ti
tk
N
Nd
ti
tk
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 daccès
• P(?)
• F(?)
• Propriétés de contrôles daccès
• P1 cohérence de politique
• ??(P(?) ? F(?))
• P2 contrôle daccès politique fermée
• ?(start(?) ? P(?))
• P3 contrôle daccè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 lobligation disposer
• P6 respect de lobligation de disposer en temps
  fini
• ?(O-startf(?) ? ?start (?))
• P7 respect de lobligation 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 lobligation de rendre
  disponible
• P8 respect de lobligation de terminer en temps
  fini
• ?(O-donef(?) ? ?done (?))
• P9 respect de lobligation de terminer en temps
  borné
• ?(O-doneb(?,d) ? ??ddone (?))

19
Politique de disponibilité ? et propriétés

• Les contrats
• Expression daxiomes 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 lenvironnement
  dindisponibilité
• 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
  lexpression 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 nud 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 nud 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 nud qui lui est associé, pour
  pouvoir commencer à boire
• 1 Bouteille / arête -gt 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

28
"Implémentation 4 phi" de CM_84 en Promela

• define Number_Philo 5
• mtype fork, token
• bool req_consNumber_Philo false
• bool start_consNumber_Philo false
• bool done_consNumber_Philo true
• bool left_fork_at_meNumber_Philo true
• bool left_fork_dirtyNumber_Philo true
• bool left_tokenNumber_Philo false
• bool right_fork_at_meNumber_Philofalse
• bool right_fork_dirtyNumber_Philofalse
• bool right_tokenNumber_Philotrue
• 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

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_consmy_id true) -gt
  atomic done_consmy_idfalse
• req_consmy_id true
• /accès/ (req_consmy_id true)
• (left_fork_at_memy_id true)
  (right_fork_at_memy_id true)
• ( (left_tokenmy_id false)
  (left_fork_dirtymy_id false) )
• ( (right_tokenmy_id false)
  (right_fork_dirtymy_id false) )
• -gt atomic left_fork_dirtymy_idtrue
• right_fork_dirtymy_idtrue
• req_consmy_idfalse
• start_consmy_idtrue
• /libération/
• (start_consmy_id true) -gt atomic
  start_consmy_idfalse
• done_consmy_id true

30
"Implémentation 4 phi" de CM_84 en Promela

• /R1G demande de la fourchette gauche/
• (req_consmy_id true)
• (left_fork_at_memy_idfalse)
• (left_tokenmy_idtrue)
• -gt atomic to_left!token
• left_tokenmy_idfalse
• /R1D demande de la fourchette droite/
• (req_consmy_id true)
• (right_fork_at_memy_idfalse)
• (right_tokenmy_idtrue)
• -gt atomic to_right!token
• right_tokenmy_idfalse

31
"Implémentation 4 phi" de CM_84 en Promela

• /R2G envoi de la fourchette gauche/
• start_consmy_id false
• (left_fork_at_memy_idtrue)
• (left_fork_dirtymy_id true)
• (left_tokenmy_idtrue)
• -gt atomic to_left!fork
• 
  left_fork_at_memy_idfalse
• left_fork_dirtymy_idfalse
  
• /R2D envoi de la fourchette droite/
• start_consmy_id false
• (right_fork_at_memy_idtrue)
• (right_fork_dirtymy_id true)

32
"Implémentation 4 phi" de CM_84 en Promela

• /R3G réception du jeton gauche /
• from_left?token -gt left_tokenmy_idtrue
• /R3D réception du jeton droit /
• from_right?token -gt right_tokenmy_idtrue
• /R4G réception de la fourchette gauche /
• from_left?fork -gt atomicleft_fork_at_memy
  _idtrue
• left_fork_dirtymy_idfalse
• /R4D réception de la fourchette droite /
• from_right?fork -gt atomic
  right_fork_at_memy_idtrue
• right_fork_dirtymy_idfalse
• od

33
"Implémentation 4 phi" de CM_84 en Promela

• init
• atomic left_fork_at_me4false
• left_fork_dirty4false
• left_token4true
• right_fork_at_me1true
• right_fork_dirty1true
• right_token1false
• 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_cons1 true)
• define demande2 (req_cons2 true)
• define demande3 (req_cons3 true)
• define demande4 (req_cons4 true)
• define mange1 (start_cons1 true)
• define mange2 (start_cons2 true)
• define mange3 (start_cons3 true)
• define mange4 (start_cons4 true)
• ( ((demande0) -gt (ltgt (mange0)))
• ((demande1) -gt (ltgt (mange1)))
• ((demande2) -gt (ltgt (mange2)))
• ((demande3) -gt (ltgt (mange3)))
• ((demande4) -gt (ltgt (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 --gt "initial"
• - étiquette en réception d'un jeton (en
  l'occurrence le gauche) --gt "R3G"
• define initial1 philosophe1_at_initial
• define r3g1 philosophe1_at_R3G
• define initial2 philosophe2_at_initial
• define r3g2 philosophe2_at_R3G
• define initial3 philosophe3_at_initial
• define r3g3 philosophe3_at_R3G
• define initial4 philosophe4_at_initial
• define r3g4 philosophe4_at_R3G
• Expression de P'4
• ( ( (ltgt initial1) -gt (ltgt r3g1) )
• ( (ltgt initial2) -gt (ltgt r3g2) )
• ( (ltgt initial3) -gt (ltgt r3g3) )
• ( (ltgt initial4) -gt (ltgt r3g4) )
• )
• -gt

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.84e08 Transitions
  3.13029e09 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