Probl

1
Problèmes de sécurité avec le logiciel

• Novembre 2007

2
Sécurité informatique

• Lutilisation de microcontrôleurs (ou DSP), comme
  tout autre équipements programmés, introduit un
  risque quil est difficile de quantifier.
• Il est plus facile de faire une analyse de risque
  avec un système uniquement matériel (pas de
  logiciel).

3
Défaillance des missiles Patriot
Exemple

• 25 février 1991, guerre du Golfe, part I
• 28 morts suite à la non interception dun missile
  Scud !
• Ou était le bogue ?

4
Défaillance des missiles Patriot

• Horloge interne du système Patriot.
• Lhorloge interne additionnait à chaque 0.1 sec.
  1/10.
• 1/10 exige en base 2 un nombre infini de
  décimales.
• 0.00011001100110011001100110011001100
• Donc, à chaque 10e de seconde, lerreur est de
• 0.00000000000000000000000110011001100

5
Défaillance des missiles Patriot

• Correspond à 0.000000095 seconde !
• Semble négligeable, mais après 100 heures
  dattente, cela devient
• 0.0000000951006060100.34 seconde
• Vitesse dun missile Scud 1676 m/s.

Linterception du missile est raté par ½ km !
6
Défaillance de la fusée Ariane 5
Exemple

• 4 juin 1996
• Explosion de la fusée 40 secondes après le
  lancement
• Coût de recherche/développement de la fusée
• 7 milliards
• Perte de 500 M au lancement.

7
Défaillance de la fusée Ariane 5

• Encore une fois, ou était le bug ?
• Défaillance du logiciel en charge du système de
  référence inertiel.
• Vitesse horizontale de la fusée codée sur un
  nombre réel de 64 bits.
• Conversion en un nombre entier de 16 bits.
• Débordement car valeur gt 32767 !
• Et Boum !

8
Black out du 14 août 2003
Exemple

• Nord-est des États-Unis Ontario

Welcome to Toronto
9
Black out du 14 août 2003

• Plus grand black out de lhistoire de lAmérique
  du Nord.
• Parmi les conséquences
• A affecté 50 millions de personnes.
• Pertes financières de 10 G.
• Défaite du gouvernement ontarien à lautomne 2003.

10
Séquence des événements

• 12h15
• Des données incorrectes rendent un système de
  diagnostic non-fonctionnel en Ohio.
• Lestimateur détat du MISO génère de mauvaises
  données.
• Aide les opérateurs à gérer le réseau
• Une ligne 230 kV hors service fausse les données
  car le MISO SE assume quelle est en service.

11
Séquence des événements

• 13h31
• La centrale Eastlake en Ohio sarrête.

12
Séquence des événements

• 14h02
• Défaillance dune ligne 345 kV à cause dun arbre
  à Walton Hill en Ohio.
• A ce point pas de problèmes si le soft suit.
  Mais la loi de Murphy va sappliquer ici ?.

13
Séquence des événements

• 14h14
• Une condition de course entre des portions de
  logiciel corrompt les données.
• Cela aura de graves conséquences, car les
  opérateurs de la salle de contrôle du réseau
  électrique de lOhio ne recevront bientôt plus
  aucun signal dalarme!
• Ce problème surgit au pire moment

14
Séquence des événements

• 14h27
• Un second arbre entraîne la défaillance dune
  autre ligne de 345 kV.
• Les opérateurs ne voient rien sur leur écrans.
• La ligne se réenclenche.

15
Séquence des événements

• Grosse erreur des opérateurs
• À 14h32, un opérateur dun autre réseau averti
  les opérateurs en Ohio quune ligne sest
  déconnectée puis sest rebranchée.
• Ces derniers nont rien vu, leur système de
  gestion des alarmes est corrompu.
• Ce premier signe dun problème na pas été pris
  en compte !!!

16
Séquence des événements

• 14h41
• Le serveur en charge des alarmes entre en
   shutdown . Mise en marche du système de
  secours (gestion des alarmes).
• 14h54
• Défaillance de ce système. On tente de le
  redémarrer, mais en vain.

17
Séquence des événements

• 15h05 Un autre arbre entraîne la défaillance
  dune ligne 345 kV à Parma.

44
18
Séquence des événements

• 15h08
• Redémarrage du serveur de gestion des alarmes.
  Les opérateurs pensent avoir un système
  opérationnel ! Ce nest pas le cas.
• La perte de la ligne de Parma nétant pas
  signalée, ils ne peuvent la corriger.

19
Séquence des événements

• 15h17
• Baisse de tension sur le réseau électrique en
  Ohio. Les opérateurs ne font rien.

20
Séquence des événements

• 15h17
• Baisse de tension sur le réseau électrique en
  Ohio. Les opérateurs ne font rien.

21
Séquence des événements

• 15h19
• Le téléphone sonne à nouveau. Un opérateur dun
  réseau voisin annonce quune ligne est en
  probablement en défaillance (voir 15h05). Mais
  les opérateurs en Ohio indiquent que tout est
  normal. Sauf que leurs données sont fausses

22
Séquence des événements

• 15h32
• A cause des transferts de puissance une ligne de
  345 kV entre en oscillation et touche un arbre.
• 1200 MVA de puissance doit passer ailleurs.

88
23
Séquence des événements

• 15h35
• Le téléphone sonne encore. On commence enfin à
  comprendre que ça ne va pas.
• 15h39
• Perte dune ligne de 138 kV en Ohio.

24
Séquence des événements

• 15h41
• La ligne qui avait eu une défaillance vers 14h27
  tombe définitivement.

55
25
Séquence des événements

• Les effets des pannes cumulatives commencent à se
  faire sentir sur le réseau.

26
Séquence des événements

• 15h41 et 15h46 Deux sectionneurs se déclenchent
  au nord de lOhio, le coupant du réseau voisin,
  en raison de la défaillance dune ligne à 345 kV
  et de 15 lignes à 138 kV.
• A ce moment, c'eut été la dernière chance de
  sauver le réseau en déconnectant la ville de
  Cleveland.

27
Séquence des événements

• 16h06 La tension sur le réseau de lOhio est
  très instable. Perte totale du contrôle du
  réseau. Une autre ligne de 345 kV tombe.
• Le sort en est jeté.

28
Séquence des événements

• 16h09m02 Grosse oscillation de voltage. Le
  réseau de lOhio pompe 2 GW de puissance du
  Michigan.

29
Séquence des événements

• 16h10m34 Défaillance de plusieurs lignes au
  Michigan et en Ohio. Gros déficit de puissance.
  Grandes surtensions dans lest entrainant la
  déconnection automatique de centrales électriques
  pour les protéger.

30
Séquence des événements
31
Séquence des événements

• 16h10m37 Lest et louest du Michigan ne sont
  plus connectés ensemble.

32
Séquence des événements

• 16h10m38 Cleveland se détache du réseau (trop
  tard).

33
Séquence des événements

• 16h10m39
• 3.7 GW est sucé de lest à partir de lOntario
  vers le nord de lOhio et le sud du Michigan.

34
Séquence des événements

• 16h10m40 Inversion du flot de puissance. 2GW
  entre en Ontario. Et revient une demie seconde
  plus tard !!!

35
Séquence des événements

• 16h10m45 Louest de lOntario nest plus branché
  à lest. Arrêt dune première centrale en
  Ontario.

36
Séquence des événements

• 16h10m46 Le réseau de létat de New York se
  sépare de celui de la Nouvelle Angleterre.

37
Séquence des événements

• 16h11m57 Dernières lignes se déconnectent entre
  lOntario et le Michigan.
• 16h13 Fin de la cascade. Black out !
• 256 centrales se sont déconnectées du réseau pour
  se protéger. 85 après la déconnection des
  différents réseaux électriques.
• Les américains blâmeront les canadiens!
• Mais cest un problème logiciel en Ohio qui est
  la source de ce gros bordel !

38
Les centrales qui sont tombées au combat !
39
Le logiciel avait été testé en simulation

• Mais faut croire que cette situation navait pas
  été simulée !

40
Therac 25

• Un traitement anti-cancer mortel !
• 11 de ces machines installées au Canada et aux
  États-Unis.
• 6 personnes ont été victime doverdose de
  radiations.
• Pire accident de lhistoire des accélérateurs
  appliqués aux traitements médicaux.

41
Therac 25

• Cette machine de 3e génération avait deux modes
  de fonctionnement
• Mode rayon X
• Mode électrons rapides.
• Ce dernier mode est utilisé pour obtenir des
  doses profondes.

42
Linstallation
43
La table tournante
44
Modes de fonctionnement

• En mode électrons
• Niveau dénergie ajustable de 5 à 25 MeV. Des
  aimants dispersent le faisceau délectrons à un
  niveau sécuritaire.
• En mode photon (ou rayon X)
• Niveau dénergie de 25 MeV. Requiert la présence
  dun atténuateur pour disperser et rendre
  uniforme le faisceau de rayon X.

45
Linterface homme-machine

• Minimaliste

46
Laccident de Tyler (au Texas)
47
Treatment monitor task (Treat)

• Utilise la variable Tphase pour savoir à quelle
  étape on est dans le traitement.
• Tphase sélectionne la routine à exécuter.
• Tphase 1
• Datent Data Entry
• Communique avec le Keyboard handler task

48
Variable globale commune

• Data Entry Complete Flag.
• Indique quand la prescription correcte est
  entrée.
• Si activé, ce bit indique à la routine Treat de
  passer de Tphase 1 à Tphase 3.

49
Variable globale commune

• Par contre, nassure pas que la prescription à
  été toute entrée !
• Si accidentellement lopérateur retourne le
  curseur sur la ligne de commande ? Data Entry
  Complete Flag devient vrai.

50
Routine Datent
51
Routine Magnet
Prend 8 secondes à sexécuter
Remis à 0 lors de la première exécution !!!
52
Routine Magnet
Ce bout de code nest plus exécuté !!!
53
Cest la course à la catastrophe

• Lopérateur descend le curseur à la ligne de
  commande avant la fin de lédition des
  paramètres.
• ? Data Entry Completetrue.
• La routine Ptime sest exécutée au moins une
  fois.
• ? Bending magnet flagfalse.

54
Cest la course à la catastrophe

• Lédition du mode et de lénergie arrive trop
  tard.
• Car sorti de Datent et Tphase3.

55
Cest la course à la catastrophe

• Lajustement est alors incorrect et non conforme
  avec ce qui est affiché sur linterface homme
  machine.
• Donc, pas la bonne dose et pas le bon mode.
• Risque d  underdose  ou doverdose !

56
Mais en plus(comme si cétait pas assez)

• Le registre MEOS est sur 2 octets. La partie
  haute est utilisée par Datent pour ajuster les
  paramètres de fonctionnement.
• La partie basse est utilisée par la routine Hand
  qui ajuste la table tournante et les collimateurs
  en fonction du mode et de lénergie sélectionné.

57
Mais en plus(comme si cétait pas assez)

• Donc, avec le bug précédent, si on change le
  mode/énergie, Hand fait les changements, mais pas
  Datent.
• Et aucune détection de linconsistance des
  ajustements est fait, car il est connu quun
  logiciel ne fait pas derreur

58
Mais en plus(comme si cétait pas assez)

• Et si le mode par défaut dans Datent envoie 25
  MeV (mode rayons-X) alors que Hand est ajusté
  dans le mode électrons, le patient recevra une
  dose extrême de radiation.

59
Et ainsi
60
Et, ce ne sera pas le seul bug que lon trouvera
sur Therac 25
61
Et, ce ne sera pas le seul bug que lon trouvera
sur Therac 25
62
Et, ce ne sera pas le seul bug que lon trouvera
sur Therac 25
63
Lincident de Yakima (état de Washington)
64
Cest encore la course à la catastrophe

• Registre Class3 à 8 bits.
• Routine Set Up Test appelée continuellement tant
  que non complétée.
• Incrémentation de Class3 à chaque appel
• Mais 255 1 256 ? 0 sur 8 bits.
• Regardez le test fait dans Lmtchk.
• Vérification pas faite et

65
Était-ce évitable ?

• Bonne question.
• Le problème majeur est de tester toutes les
  conditions possibles que le logiciel peut
  rencontrer.
• Impossible parfois de découvrir les failles en
  simulation.

66
Voyons dautres exemples
67
Un risque de course (race hazard)

• Bien connu en électronique.
• A la source des glitches.

68
Un risque de course (race hazard)

• Table de Karnaugh
• On ajoute une
  porte logique
  de plus

69
Un risque de course (race hazard)

• Problème réglé

70
Un risque de course (race hazard)

• Malheureusement pas aussi simple au niveau
  software !
• Supposez deux threads quasi-identiques

71
Un risque de course (race hazard)

• Valeur initiale de la variable globale i0.
• Question
• Si les deux threads sont exécutés de façon
  concurente quelle sera la valeur de i après leur
  exécution ?

72
Un risque de course (race hazard)

• Réponse
• Parfois 1, parfois 2.
• Résultat imprévisible.

73
Important

• Lexécution des programmes nest plus la bonne
  vieille exécution déterministique, instruction
  après instruction.
• Interruptions
• Multi-threads
• Multi-CPU.

74
Linterblocage (deadlock)

• Si plusieurs threads partagent une même ressource
  un problème peut survenir si cette ressource
  nest pas libérée.
• On parle alors dinterblocage.
• Les threads attendent que la ressource se libère
  et rien de se passe

75
Un diner de philosophes

• Schéma

76
Un diner de philosophes

• Contraintes
• Une fourchette ne peut être prise que par un
  philosophe à la fois.
• Il faut éviter quun philosophe crève de faim en
  attendant une fourchette.
• Il est possible que plus dun philosophe mange au
  même moment.

77
Que font les philosophes

• Les philosophes réfléchissent
• Puis prennent deux fourchettes (lune à droite,
  lautre à gauche)
• Puis mangent à satiété
• Et déposent leurs fourchettes, pour replonger à
  nouveau dans leur réflections.

78
Que font les philosophes

• En code machine
• Assumons que les philosophes savent comment
  réfléchir et comment manger.
• Reste à gérer les fourchettes.

79
Gestion de fourchettes

• Identifions chaque philosophe par un nombre i,
  allant de 0 à 4.
• Ainsi définissons pour chacun, la fourchette
  gauche et la fourchette droite
• Et un sémaphore par fourchette

80
Gestion de fourchettes

• Essayons donc de gérer les fourchettes comme
  suit
• Quen pensez-vous ?

81
Gestion de fourchettes

• Si tous les philosophes prennent leur fourchette
  de droite ? gros problème !
• Tout le monde attends que la fourchette à sa
  gauche devienne disponible.
• Interblocage !

82
Ça nous prend un gaucher

• Si lun des philosophe est gaucher et prend sa
  fourchette gauche en premier, alors sa fourchette
  de droite reste disponible pour son collègue et
  il y en a au moins un qui peut manger.
• Et, ça débloque le système !

83
Ou, on limite le nombre de mangeurs simultanés

• Voici un bout de code ou on limite le nombre de
  mangeurs simultanés
• footman est un multiplex initialisé à 4.