le mod le de disponibilit en construction l.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Le modèle de disponibilité (… en construction) PowerPoint Presentation
Download Presentation
Le modèle de disponibilité (… en construction)

Loading in 2 Seconds...

play fullscreen
1 / 36

Le modèle de disponibilité (… en construction) - PowerPoint PPT Presentation


  • 107 Views
  • Uploaded on

Le modèle de disponibilité (… en construction). Frédéric Cuppens Ahmed Bouabdallah Nora Cuppens-Boulahia. Conclusions dernière réunion. -- Systèmes à transitions -- Machines abstraites -- Logique temporelle. -- C ontractualisé -- Fautes -- Malveillances. -- Ressource, rôle

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Le modèle de disponibilité (… en construction)' - dino


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
le mod le de disponibilit en construction

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

Frédéric Cuppens Ahmed Bouabdallah

Nora Cuppens-Boulahia

conclusions derni re r union
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é

propri t s int ressantes en logique temporelle
Propriétés intéressantes en logique temporelle
  • Propriétés d’invariance
  • Propriété de précédence
  • Propriétés de vivacité
exemple pour illustrer les propri t s
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.
propri t d invariance safety property
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

propri t de pr c dence
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))

propri t de vivacit liveness property
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)

propri t de vivacit et disponibilit respect du contrat par le fournisseur
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

propri t de vivacit et disponibilit respect du contrat par le fournisseur9
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
propri t de vivacit et disponibilit respect du contrat par le demandeur
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))

les composants du mod le dispo
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)
syst me temporel
Système temporel 
  • p
  • p
  • p
  • p U q
  • p
  • p S q

N

N

tk

ti

N

N

N

N

syst me temporel13
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

pr dicat primitifs et propri t s
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()

politique de disponibilit et propri t s
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())
politique de disponibilit et propri t s16
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 ())
politique de disponibilit et propri t s17
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 ())
politique de disponibilit et propri t s18
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 ())
politique de disponibilit et propri t s19
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 ())
conclusion perspectives sur le mod le
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
tude de cas
É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
acc s conflictuel des ressources
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)
drinking philosophers problem cm 84
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
politique de contr le d acc s
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))
politique et propri t s de disponibilit
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))
analyse des propri t s de disponibilit
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é

la solution cm 84 au dining problem
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.
impl mentation 4 phi de cm 84 en promela
"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 }

impl mentation 4 phi de cm 84 en promela29
"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}

impl mentation 4 phi de cm 84 en promela30
"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}

impl mentation 4 phi de cm 84 en promela31
"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}

impl mentation 4 phi de cm 84 en promela32
"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

}

impl mentation 4 phi de cm 84 en promela33
"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)

}

}

v rification avec spin de p4
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
v rification avec spin de p435
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)
v rification avec spin de p436
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)

-------------------------------------------------------------------------------------