1 - A. OURGHANLIAN Les outils d analyse sémantique de code Club SEE « Systèmes Informatiques de Confiance ». Le 31/01/02 Utilisation des outils d analyse

1 - A. OURGHANLIAN

Les outils d ’analyse sémantique de code

Club SEE « Systèmes Informatiques de Confiance ». Le 31/01/02

Utilisation des outils d ’analyse sémantique de

code à EDF

2 - A. OURGHANLIAN



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 - A. OURGHANLIAN



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 - A. OURGHANLIAN



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 - A. OURGHANLIAN



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

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

Parfois appelé 2E

6 - A. OURGHANLIAN



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 - A. OURGHANLIAN



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 - A. OURGHANLIAN



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 - A. OURGHANLIAN



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 - A. OURGHANLIAN



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 - A. OURGHANLIAN



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 - A. OURGHANLIAN



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 - A. OURGHANLIAN



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.

14 - A. OURGHANLIAN



15 - A. OURGHANLIAN



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 - A. OURGHANLIAN



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;}

menace division : s0

remontée menace : s0

remontée menace : s0

remontée menace : a+b0

synthèse menace « Pre : a+b0 »

17 - A. OURGHANLIAN



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 - A. OURGHANLIAN



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.

19 - A. OURGHANLIAN



20 - A. OURGHANLIAN



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 - A. OURGHANLIAN



Méthode d ’analyse pour PolySpace

22 - A. OURGHANLIAN



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 - A. OURGHANLIAN



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 - A. OURGHANLIAN



Procédure d ’analyse

SCCSCC

CDFACDFA

SSUASSUA

SSIA 1SSIA 1

SSIA 2SSIA 2

Erreur rouge : correction du codeErreur rouge : correction du code

Augmentation dela précisionAugmentation dela précision

25 - A. OURGHANLIAN



Analyse du RPN dans son ensemble : résultats bruts

2000 2001Sélectivité 60% 90%Nb verts 11117

Nb oranges > 3000 1262Nb rouges 243

Nb gris 1356Temps de calcul 9 jours 3 jours

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.

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 - A. OURGHANLIAN



Méthode d ’analyse pour CAVEAT

27 - A. OURGHANLIAN



Phases d ’analyse de Caveat

Génération du projet

Générationdes menaces

Analyse des résidus

Ajout d ’hypothèses

Pas de menaces

Menaces potentielles :

conditionsd ’activation

menaces prouvées

menacesnon prouvées

Conformité C AnsiRecherche var non initialisées

28 - A. OURGHANLIAN



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 - A. OURGHANLIAN



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 - A. OURGHANLIAN



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 - A. OURGHANLIAN



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

Documents

1 - A. OURGHANLIAN Les outils d analyse sémantique de code Club SEE « Systèmes Informatiques de Confiance ». Le 31/01/02 Utilisation des outils d analyse