MISRA C 2012 vs MISRA C2 : comment effectuer la transition

Chez Secure Code Warrior, nous cherchons constamment à élargir notre offre de formation. Afin de permettre aux développeurs embarqués et aux responsables de la sécurité de concevoir des systèmes embarqués sécurisés, nous explorons le domaine de la sécurité des systèmes embarqués. Dans cet article, nous aborderons la norme MISRA C 2012 et expliquerons pourquoi sa conformité est essentielle pour bâtir des systèmes embarqués sécurisés.

Lorsque l'on écrit du code en C, il est très facile d'implémenter des éléments qui semblent corrects, mais qui sont fondamentalement erronés. Votre code peut compiler sans problème et même fonctionner correctement pendant un certain temps. Cependant, ce même code pourrait planter ou présenter un comportement indéfini si la taille de vos entrées ou votre mémoire augmente. Par exemple, un nombre d'entrée spécifique provoquant un dépassement d'entier, ou une séquence de caractères particulière entraînant un dépassement de tableau.

C'est là que la norme de codage MISRA C peut vous aider. Les règles, directives et bonnes pratiques établies par cette norme permettent aux développeurs d'écrire du code C sûr et fiable pour le développement embarqué.

MISRA C 2012, la version la plus récente de la norme, ajoute de nouvelles règles, améliore celles existantes et corrige certaines incohérences. Si vous utilisez encore une ancienne version, c'est le moment idéal pour effectuer la transition.

Qu'est-ce que la norme de codage MISRA C ?

La norme MISRA C inclut des directives de sécurité, de portabilité et de fiabilité du code pour le langage de programmation C. Le premier ensemble de directives a été publié en 1998 et était spécifique au langage C.

Cependant, depuis lors, le consortium MISRA développe également des normes de codage pour le C++. Chaque document MISRA C contient un ensemble de règles, des exemples non conformes et des sections détaillées sur les informations de base ayant contribué au développement desdites règles.

Le C et le C++ sont les langages les plus utilisés pour développer des logiciels embarqués. L'une des raisons principales est leur rapidité, ne possédant qu'un ou deux niveaux d'abstraction au-dessus du langage machine. Mais cela signifie également qu'écrire du code sûr, particulièrement en C, est difficile et sujet aux erreurs. Par exemple, dans la plupart des langages de haut niveau comme Java et C#, vous n'avez pas à vous soucier de détails triviaux comme le ramasse-miettes (garbage collection) ou le typage dynamique.

Cependant, en C, il n'existe aucun moyen prédéfini de collecter les déchets ; si vous allouez un espace mémoire pour une structure de données, vous devez le libérer manuellement une fois que vous avez fini de l'utiliser. Si vous ne le faites pas, le C, contrairement à d'autres langages, ne libérera pas la mémoire pour vous, ce qui entraînera une fuite de mémoire.

MISRA C 2004 (C2) vs MISRA C 2012 (C3) – Qu'est-ce qui a changé ?

MISRA C: 2012, également connu sous le nom de C3, a été publié pour la première fois en avril 2013. S'appuyant sur les travaux de milliers de personnes et d'organisations, C3 ajoute de nouvelles règles, améliore l'explication et le contexte de certaines règles existantes, et comble certaines lacunes.

C3 prend en charge la version C99 du langage, tout en conservant des règles pour l'ancien ISO C90. L'objectif principal de C3 était de réduire les coûts habituels liés à l'application des règles, tout en rendant l'utilisation du langage C plus sûre dans les systèmes critiques. Tout cela rend judicieux le passage à la nouvelle norme, si ce n'est pas déjà fait.

Dans l'ensemble, voici une liste des changements les plus significatifs :

• Correction des problèmes identifiés dans la version 2004.
• Augmentation significative du nombre de règles décidables. Une règle est décidable si un outil d'analyse peut vous aider à déterminer sa conformité.
• Les règles sont classées comme « requises », « consultatives » ou « obligatoires ». Les règles obligatoires ne doivent jamais être enfreintes, en aucune circonstance. Les règles requises et consultatives peuvent être violées dans des scénarios particuliers, à condition que la violation soit justifiée.
• Ajout de conseils sur la manière d'appliquer les règles au code généré automatiquement. C'est très important car les directives applicables au code écrit par l'homme ne s'appliquent pas toujours à celui généré par un outil.
• Suppression des règles trop généralisées qui interdisaient un comportement utilisateur raisonnable. Par exemple, il était auparavant recommandé de ne pas utiliser de macros du tout, car elles peuvent entraîner diverses difficultés et confusions (impossibilité de déboguer les macros, absence d'espaces de noms, etc.). Cela empêchait l'utilisation de macros, même dans des situations où elles pouvaient offrir une solution élégante, sûre et pratique. Dans MISRA C: 2012, de nouvelles règles concernant les macros ont été introduites, permettant de les utiliser avec précaution lorsque cela est approprié. Voir l'extrait suivant, tiré d'un document MISRA C, qui recommande l'utilisation d'une macro plutôt que d'une fonction.

Les règles MISRA C en action

Assez parlé, il est maintenant temps de passer à la pratique avec quelques règles MISRA C et des exemples de leur application.

Utiliser des types compatibles comme arguments de pointeur pour memcpy, memmove et memcmp

Les fonctions de la bibliothèque standard memcpy, memmove et memcmp effectuent un déplacement ou une comparaison octet par octet du nombre d'octets spécifié. La règle 21.15 de la norme MISRA C 2012 stipule que les deux paramètres de fonction doivent être des pointeurs vers le même type. Un appel de fonction avec des types de pointeurs incompatibles peut indiquer une erreur.

Considérez l'image suivante, extraite du document officiel de conformité MISRA. La règle est requise, décidable et s'applique à la fois au C90 et au C99.

Un exemple suit la description de la règle.

Comme vous pouvez le constater, étant donné que les objets sont de types différents (uint8_t et uint16_t), il s'agit d'une solution non conforme.

Les fonctions de manipulation de chaînes ne prenant pas de longueur en entrée ne doivent pas entraîner d'accès hors limites

Les fonctions de manipulation de chaînes issues de <string.h> qui ne prennent pas la longueur en entrée ne doivent pas entraîner d'accès hors limites. Les fonctions concernées sont : strcat, strchr, strcmp, strcoll, strcpy, strcspn, strlen, strpbrk, strrchr, strspn, strrstr et strtok. La règle est obligatoire, ce qui signifie qu'elle ne peut jamais être enfreinte, en aucune circonstance. Elle s'applique au C90 et au C99, et est indécidable.

L'exemple correspondant est :

Comme vous pouvez le voir, strcpy dans la fonction f1 copiera au-delà de la longueur de la chaîne, qui ne peut contenir que 5 caractères. Nous avons également une utilisation conforme et sûre de strcpy, où la chaîne n'est copiée que si le contenu de « str » tient dans la destination.

Valider les données reçues de l'extérieur

La directive 4.14 recommande de vérifier la validité des données reçues de sources « externes ». Une entrée externe peut être :

• Lue depuis un fichier.
• Lue depuis une variable d'environnement.
• Toute saisie utilisateur.
• Tout élément reçu via un canal de communication, par exemple une connexion TCP ou une API HTTP, etc.

Cette directive appartient à la catégorie requise et s'applique au C90 et au C99. La raison en est qu'un programme n'a aucun contrôle sur les données reçues de sources externes, ce qui signifie que ces données peuvent être invalides ou malveillantes. Par exemple, un programme attend qu'un utilisateur saisisse un nombre, mais l'utilisateur saisit une chaîne. Avant de traiter l'entrée, le programme doit vérifier qu'il s'agit bien d'un nombre.

Comment passer à MISRA C 2012

Le passage à MISRA C 2012 nécessitera une mise à jour de votre document de directives de codage. Si vous n'en utilisez pas et que vous vous appuyez plutôt sur un outil d'analyse statique (ce qui est le choix recommandé), vous devrez peut-être obtenir une version plus récente de l'outil. Voici trois outils qui vérifient la conformité MISRA C 2012 :

1. Cppcheck est un outil open source capable de vérifier les règles MISRA et de détecter divers types de bugs.
2. PC-lint Plus est un outil payant avec une période d'évaluation de 30 jours. En plus de vérifier la conformité MISRA C, il aide à identifier les bugs et vulnérabilités potentiels.
3. CodeSonar est un autre outil qui vérifie la conformité MISRA C et C++.

Il existe également quelques compilateurs capables de tester la conformité MISRA. Si une violation de règle est détectée, des avertissements ou des exceptions sont générés en conséquence. Par exemple, Green Hills Software fournit des compilateurs prenant en charge toutes les normes MISRA, pour les architectures 32 bits et 64 bits.

Utiliser Secure Code Warrior pour former les développeurs à MISRA C

Le produit phare de Secure Code Warrior, sa plateforme d'apprentissage, propose de nombreux défis interactifs, cours et évaluations pour aider les développeurs à écrire du code C/C++ sécurisé. Le contenu est spécifique aux frameworks et hautement engageant. Nos défis de codage C/C++:Embed s'inspirent des normes MISRA C, AUTOSAR C++ (MISRA C++) et IEC.

Les développeurs peuvent suivre des parcours d'apprentissage personnalisés pour identifier les vulnérabilités spécifiques au C/C++ et, surtout, apprendre à corriger ces bugs. Ils peuvent suivre leur progression, identifier leurs points faibles et même participer à des compétitions amicales avec leurs pairs. Découvrez comment nous aidons les secteurs de l'automobile et du transport grâce à nos solutions.

Vous voulez découvrir à quel point nos défis sont interactifs et axés sur l'embarqué ? Essayez quelques défis C/C++:Embed sur notre plateforme dès aujourd'hui !