Disponibilit� et logique temporelle

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

    Frédéric Cuppens      Ahmed Bouabdallah
              Nora Cuppens-Boulahia
   Conclusions dernière réunion
          -- Ressource, rôle       -- Systèmes à transitions           -- Contractualisé
          -- Contrôle d’accès      -- Machines abstraites              -- Fautes
          -- Contrainte, contrat   -- Logique temporelle               -- Malveillances



               Politique de            Spécification                  Environnement
               disponibilité           du système                     d’indisponibilité




 Prouver qu’un système
donné garantit ces propriétés                               -- Contraintes temporelles
                                       Propriété de
compte tenu d’un certain               disponibilité        -- Notion de droit de disposer
environnement d’indisponibilité                             -- Respect de l’environnement contractuel
 Étude de cas moins
ambitieuse                                                                     nora.cuppens@enst-bretagne.fr

                                                                                             2
Propriétés intéressantes en logique temporelle


 Propriétés d’invariance
 Propriété de précédence
 Propriétés de vivacité




                                   nora.cuppens@enst-bretagne.fr

                                               3
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.
                                                          nora.cuppens@enst-bretagne.fr

                                                                      4
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
                                                        nora.cuppens@enst-bretagne.fr

                                                                    5
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 : • i  rj  aj)  (aj U ai))
            ((r
                                                          nora.cuppens@enst-bretagne.fr

                                                                      6
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 : •  ai)
            (ri

 Formule en logique temporelle FProp3 de Prop3
   FProp3 : •i  ri)
            (a
                                                            nora.cuppens@enst-bretagne.fr

                                                                        7
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
                                                 nora.cuppens@enst-bretagne.fr

                                                             8
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




                                                     nora.cuppens@enst-bretagne.fr

                                                                 9
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 : •i (d)  (ri  (pi  d=0))
             (a


                                                 nora.cuppens@enst-bretagne.fr

                                                           10
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)




                                                       nora.cuppens@enst-bretagne.fr

                                                                 11
Système temporel 

 p
        N
 p
                     N

 p                     tk
                ti
        N

 pUq
        N

 p
                     N

 pSq
                     N
                              nora.cuppens@enst-bretagne.fr

                                        12
Système temporel 

 Introduction des délais
 d p

              t’ i   N-d t’k          N             ti              tk       N+d


 d p
 Mais aussi,
    (d p) pour introduire les « intervalles »



       t’ i          t’i+d t’k        N             ti              tk       N+d


                                                         nora.cuppens@enst-bretagne.fr

                                                                   13
Prédicat primitifs         et propriétés


 Les actions primitives ,        (pour le moment)
 Les prédicats de base

       req()              start()                 done()



 Propriétés tangentes
    start()  req()
    done()  start()
       pour simplifier


                                                     nora.cuppens@enst-bretagne.fr

                                                               14
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())
                                                     nora.cuppens@enst-bretagne.fr

                                                               15
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 ())
                                                      nora.cuppens@enst-bretagne.fr

                                                                16
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 ())
                                                        nora.cuppens@enst-bretagne.fr

                                                                  17
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 ())
                                                       nora.cuppens@enst-bretagne.fr

                                                                 18
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 ())

                                                  nora.cuppens@enst-bretagne.fr

                                                            19
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




                                                    nora.cuppens@enst-bretagne.fr

                                                              20
Étude de cas
   Problème « des philosophes »
   Le procédé
    1. Identifier les ressources sensibles
    2. Exprimer la politique de sécurité
         permissions, interdictions, droits
    3. 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é
    4. Exprimer les propriétés de disponibilité conformément au modèle
    5. Preuve de propriétés


                                                             nora.cuppens@enst-bretagne.fr

                                                                       21
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)
                                                          nora.cuppens@enst-bretagne.fr

                                                                    22
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
                                                                  nora.cuppens@enst-bretagne.fr

                                                                            23
  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))




                                                nora.cuppens@enst-bretagne.fr

                                                          24
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))
                                                   nora.cuppens@enst-bretagne.fr

                                                             25
Analyse des propriétés de disponibilité

 Condition suffisante         P4' :(req(cons)  start(cons))
 Politique de disponibilité
                                    ( Droitf (cons) )
                              P4 :(Droitf(cons)  req(cons)  start(cons))



 Politique de disponibilité        (¬ O-startf(cons) )
                              P6 :(O-startf(cons)  start(cons))



Condition suffisante          P8' : (start (cons)  done (cons))
Politique de disponibilité           (¬ start(cons)  ¬ O-donef(cons))
                              P8 : (O-donef(cons)  done(cons))

                                                                     nora.cuppens@enst-bretagne.fr

                                                                               26
    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.                                      nora.cuppens@enst-bretagne.fr

                                                                                                                                  27
"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 }
                                            nora.cuppens@enst-bretagne.fr

                                                      28
"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}




                                                                         nora.cuppens@enst-bretagne.fr

                                                                                   29
"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}

                                                             nora.cuppens@enst-bretagne.fr

                                                                       30
"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}
                                                                       nora.cuppens@enst-bretagne.fr

                                                                                    31
"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
 }
                                                     nora.cuppens@enst-bretagne.fr

                                                               32
"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)
         }
 }




                                                            nora.cuppens@enst-bretagne.fr

                                                                      33
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           nora.cuppens@enst-bretagne.fr

                                                                            34
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)

                                                                                                 nora.cuppens@enst-bretagne.fr

                                                                                                           35
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)
                                                                                   nora.cuppens@enst-bretagne.fr
-------------------------------------------------------------------------------------


                                                                                              36