Utilisation des outils d ’analyse sémantique de code à EDF

1. Utilisation des outils d ’analyse sémantique de code à EDF

2. Sommaire • Contexte • Les outils d ’analyse de code • Analyse d ’un système classé de sûreté • le système de protection RPN-CP0 • Perspectives futures

3. Le contexte du nucléaire • En qualité de maître d ’ouvrage d ’installations nucléaires • EDF est responsable de la qualification des systèmes programmés importants pour la sûreté • Tendance à la généralisation des systèmes programmés • Salle de commande • Régulations et automatismes non importants pour la sûreté • Systèmes de protection et de sauvegarde • Coût de qualification des systèmes programmés non négligeable par rapport au coût total de qualification d’une installation

4. Le cadre réglementaire • La Règle fondamentale de sûreté • relative aux logiciels • des systèmes électriques classés de sûreté • ici contrôle-commande associé au système • Elle fournit un ensemble d ’exigences • suivant le classement du système • Et donne des pratiques acceptables

5. Champ d ’application de la RFS Système Électrique IPS (important pour la sûreté) Non-IPS Classé de sûreté IPS-NC (Non Classé de sûreté) Classé 1E Classé de sûreté et non 1E Parfois appelé 2E Système classé de sûreté et non-1E au titre des conditions de fonctionnement de dimensionnement Système classé de sûreté et non-1E au titre des conditions de fonctionnement complémentaires

6. Les types de systèmes utilisés • Systèmes les plus critiques (classement RFS classé 1E) • Systèmes spécifiques • Systèmes à base de produits catalogue de fournisseurs spécialisés • Fonctionnalités « simples » : actions de protection • Maîtrise totale du code source des systèmes programmés • Objet des évaluations actuelles • Systèmes classé sûreté non 1E • Systèmes standard du marché • Non maîtrise totale du code (notamment système d’exploitation) • Fonctionnalités variées : régulations, conduite, ...

7. Les pratiques actuelles de qualification • Relecture des documents produits • y compris les sources • Analyse des pratiques des fournisseurs • Suivi du développement des systèmes chez les fournisseurs • Mise en place de tests de recette en plateforme et sur site

8. Les objectifs du projet « Alcasar » • Maîtriser le coût de qualification des systèmes programmés : • en proposant des méthodes et outils • capables de fournir des informations indiscutables • ou pour diriger l’analyse sur des points sensibles. • Par exemple en effectuant des tests complémentaires • Les outils d’analyse sémantique de code • Une des techniques retenues par le projet • Une des pratiques acceptables donnée par la RFS « logiciels »

9. Les outils d ’analyse • Peu d’outils sur le marché • deux produits commerciaux • PolySpace Verifier (PolySpace Technologies) • MALPAS (Fluor Global Services) • un outil du domaine de la recherche • CAVEAT (partenariats CEA-EADS-EDF) • Deux technologies complémentaires • La logique de Hoare • CAVEAT, MALPAS • L ’interprétation abstraite • PolySpace Verifier

10. PolySpace : objectifs de l ’outil • Détecter les erreurs d ’exécution et les menaces dans un logiciel. • Analyse statique : l ’outil exploite le code source du logiciel (C ou ADA), sans l ’exécuter. • Élabore et travaille sur 2 modèles : • Un modèle abstrait de l ’application (fonctions, arbre d’appels, dictionnaire des variables, …), • Un modèle de toutes les exécutions possibles (Modèle de l ’application + domaines dans l’espace des valeurs des variables).

11. Erreurs et menaces détectées par l ’outil • Code mort & appel sans fin. • Erreurs certaines ou potentielles : • NIV / NIP (variable ou pointeur non initialisé) • U-OVFL (underflow, overflow) • ZDV (division par zéro) • COR (condition d’exécution incorrecte : index de tableau invalide, pointeur hors limite). • ASRT (assertion de l ’utilisateur)

12. Interface utilisateur • PolySpace comporte 2 outils : • le « verifier », pour lancer l ’analyse. • Création d ’un projet • Déclaration des fichiers sources, des chemins d ’include • Paramètres (précision, profondeur, …) • le « viewer », pour exploiter les résultats de l ’analyse : • Graphe d ’appel • Listes de variables et de leurs accès • Liste des erreurs et menaces • Visualisation du code source • Classification des résultats selon un code de couleur : rouge, vert, orange, gris.

13. Code des couleurs • Rouge : une erreur systématique a été détectée. • Exemple a = 0 suivi de c = b/a : ZDV • Gris : le code n ’est jamais exécuté. • Vert : l ’erreur ne peut pas se produire • Exemple : une variable est dans tous les cas affectée avant utilisation : NIV • Orange : incertitude ? Menace ? Fausse alerte ? • Il faut augmenter le niveau de précision.

15. CAVEAT : Logique de Hoare (1/2) • Objectif : Preuve de propriétés • Par utilisation de règles de réécriture suivant le type d ’instruction • Types de propriétés sur une fonction • Précondition • Postcondition • Assertion (sur un label dans le code) • Invariant de boucle • Propagation des propriétés sur le graphe d ’appel

16. CAVEAT : Logique de Hoare (2/2) • Mécanisme de synthèse de menaces int p,q,s; void fonction(int a,b) { int i; s=a+b; p=0; i=b; while (i>0) { p+=a; i--; } q=a/s; } synthèse menace « Pre : a+b0 » remontée menace : a+b0 remontée menace : s0 remontée menace : s0 menace division : s0

17. CAVEAT : Fonctionnalités • Recherche exhaustive de menaces • Types de menaces recherchées • division par zéro • utilisation de pointeurs nuls • débordement de tableaux • utilisation de variables non initialisées (pas de menace générée) • Affichées sous forme de préconditions • La preuve de la précondition montre l’innocuité de la menace • Preuves de propriétés issues des spécifications • Étude des domaines de variation des variables de sorties • propriétés exprimées sous forme de postconditions • Calcul de menaces complémentaires par ajout de propriétés • racine carrée, logarithme négatifs …

18. CAVEAT : Présentation des résultats • État des preuves des menaces du graphe d ’appel • fonction verte : Toutes les menaces sont prouvées localement. • fonction bleue : Toutes les menaces ont été prouvées par le contexte d ’appel de la fonction. • fonction rouge : Une menace n ’a pas pu être prouvée par l ’outil. • Le résidu de la preuve permet de connaître ce qui manque à la conclusion de la preuve • Preuve : activité itérative • fonction rose : Les menaces de la fonction n ’ont pas pu être générées.

20. Utilisation dans le cadre d ’une qualification • Rénovation du système de protection • des premières tranches nucléaires de 900 MWe • Remplace à l ’identique un système électronique analogique • Système RPN de mesure de la puissance neutronique du cœur • Code C + assembleur de 50 000 lignes de code • Partie système générique • Parties applicatives générées automatiquement à partir de SCADE • Contribution à l ’argumentaire de sûreté en cours

21. Méthode d ’analyse pour PolySpace

22. Travail à effectuer • Le code source C doit respecter la norme ANSI. Il doit y avoir un « main ». • Toutes les fonctions doivent être définies : • Création de « bouchons » pour les fonctions en assembleur, ou celles des bibliothèques. • Exemple : log10(x) -> assert(x>0)

23. Procédure d ’analyse : 3 phases • Vérification du code source (SCC) • CDFA : Control & Data Flow Analysis • Elabore le modèle de l ’application • SSA (Software Safety Analysis) • Elabore le modèle d ’exécution. • Décomposé en 4 sous-phases : • SSUA (vérifications locales à la fonction), • SSIA 1 (on propage les contraintes issues des fonctions appelantes) • SSIA 2 et SSIA 3 (on raffine la propagation des contraintes…)

24. Procédure d ’analyse SCC CDFA SSUA Erreur rouge : correction du code SSIA 1 Augmentation de la précision SSIA 2

25. Analyse du RPN dans son ensemble : résultats bruts • L ’augmentation de la sélectivité a été obtenue en travaillant sur les macro-commandes de la partie applicative. • Sur la partie système, il est beaucoup plus difficile de progresser.

26. Méthode d ’analyse pour CAVEAT

27. Phases d ’analyse de Caveat Ajout d ’hypothèses Conformité C Ansi Recherche var non initialisées Génération du projet Génération des menaces menaces non prouvées Analyse des résidus menaces prouvées Menaces potentielles : conditions d ’activation Pas de menaces

28. Bilan sur le système RPN • Parties applicatives • Toutes les menaces ont été générées et prouvées par l ’outil • Partie système • Analyse encore impossible dans son ensemble • Analyse possible unitairement • Limitations actuelles • Non prise en compte des alias • Gênant pour des logiciels gérant du matériel

29. Deux techniques complémentaires • L ’approche interprétation abstraite de PolySpace • Richesse des types de menaces détectées • Code mort • Arrondis dans l ’arithmétique entière et flottante • Mais pas d ’informations complémentaires en présence d ’orange • pour lever ou confirmer ce risque • La logique de Hoare de Caveat • Traite un sous ensemble des menaces • En cas d ’échec de preuve pour lever une menace • L ’outil exhibe une condition nécessaire pour lever la menace • Permet d ’orienter sur la cause et sa correction éventuelle

30. Les limitations actuelles • PolySpace • ne gère pas des octets ni des adresses, mais uniquement des variables et des pointeurs ; • exemple : affectation de variables par memcpy() • ne modélise pas l ’organisation physique de la mémoire • exemple : utilisation d ’adresses absolues + offset • Caveat • ne gère pas les alias • le passage d ’adresse de pointeur comme type entier dégrade la précision des résultats • les conditions d ’arrêt de boucle par une égalité donnent des menaces trop complexes

31. Perspectives • Étendre ces approches aux systèmes moins critiques • Code partiellement disponible • Problématique du multi-tâche • Volume et complexité du code • Promouvoir ces approches au niveau des fournisseurs • Adaptation des règles de codage pour en faciliter l ’analyse ? • Allègement de l ’effort de test unitaire