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

Les outils d ’analyse de code Analyse d ’un système classé de sûreté 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

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

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

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

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, ... 3

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 4

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 » 5

Peu d’outils sur le marché 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 6

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

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)

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.

Rouge : une erreur systématique a été détectée. 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.

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 8

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

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 …

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.

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

Méthode d ’analyse pour PolySpace

Toutes les fonctions doivent être définies : 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)

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

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

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.

Méthode d ’analyse pour CAVEAT

Phases d ’analyse de Caveat Conformité C Ansi Recherche var non initialisées Ajout d ’hypothèses 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

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

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

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

Étendre ces approches aux systèmes moins critiques 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