Qu'est-ce que MISRA et comment le faire cuire

Peut-être que chaque développeur de programmes pour microcontrôleurs a probablement entendu au moins une fois parler de normes de codage spéciales conçues pour aider à augmenter la sécurité et la portabilité de votre code. L'une de ces normes est MISRA. Dans cet article, nous examinerons plus en détail ce qu'est ce standard, quelle est sa philosophie et comment l'utiliser dans vos projets.

Beaucoup de nos lecteurs ont entendu dire que PVS-Studio prend en charge la classification de leurs alertes selon la norme MISRA. PVS-Studio couvre actuellement plus de 100 règles MISRA C: 2012 et MISRA C ++: 2008.

Cet article vise à tuer trois oiseaux avec une pierre:

1. Dites ce qu'est MISRA pour ceux qui ne sont pas familiers avec cette norme;
2. Rappeler au monde intégré ce dont nous sommes capables;
3. Pour aider à approfondir le cours des affaires pour les nouveaux employés qui développeront également notre analyseur MISRA;

J'espère que je pourrai le rendre intéressant. Commençons donc!

L'histoire de MISRA

L'histoire de MISRA a commencé il y a longtemps. Puis, au début des années 90, le programme du gouvernement britannique sous le nom indicatif "Safe IT" a alloué des fonds à divers projets, d'une manière ou d'une autre liés à la sécurité des systèmes électroniques. Le projet MISRA (Motor Industry Software Reliability Association) lui-même a été fondé pour créer un guide pour le développement de logiciels pour les microcontrôleurs dans les véhicules terrestres - dans les voitures en général.

Ayant reçu un financement de l'État, l'équipe MISRA s'est mise au travail et, en novembre 1994, a publié son premier guide: " Lignes directrices pour le développement de logiciels basés sur les véhicules ". Ce guide n'est pas encore lié à un langage spécifique, mais je dois l'avouer: le travail était impressionnant et concernait probablement tous les aspects imaginables du développement de logiciels embarqués. Soit dit en passant, les développeurs de ce guide ont récemment célébré le 25e anniversaire d' une date aussi importante pour eux.

Lorsque le financement de l'État a pris fin, les membres de la MISRA ont décidé de continuer à travailler ensemble sur une base informelle - cela continue à ce jour. En fait, MISRA (en tant qu'organisation) est une communauté d'intervenants de diverses industries de fabrication d'automobiles et d'avions. Maintenant, ces parties sont:

• Voitures à moteur Bentley
• Ford Motor Company
• Jaguar land rover
• Systèmes diesel Delphi
• HORIBA MIRA
• Protean électrique
• Services d'ingénierie Visteon
• L'université de leeds
• Ricardo uk
• ZF TRW

Des acteurs du marché très forts, non? Sans surprise, leur première norme liée au langage, MISRA C, est devenue largement acceptée par les développeurs embarqués critiques. MISRA C ++ est apparu un peu plus tard. Progressivement, les versions des normes ont été mises à jour et affinées pour couvrir les nouvelles fonctionnalités des langues. Au moment d'écrire ces lignes, les versions actuelles sont MISRA C: 2012 et MISRA C ++: 2008.

Philosophie et exemples de règles

Les caractéristiques les plus distinctives de MISRA sont son incroyable attention aux détails et son extrême minutie pour assurer la sécurité. Les auteurs ont non seulement rassemblé en un seul endroit tous les «trous» C et C ++ qui leur venaient à l'esprit (comme, par exemple, les auteurs du CERT) - ils ont soigneusement élaboré les normes internationales de ces langages et noté toutes les façons imaginables et inconcevables de faire des erreurs. Et puis ils ont pris et ajouté les règles sur la lisibilité du code d'en haut - c'est pour rendre plus difficile l'introduction d'une nouvelle erreur dans du code déjà propre.

Pour comprendre l'étendue du sérieux, considérez quelques règles tirées de la norme.

D'une part, il existe de nombreuses bonnes règles appropriées qui doivent toujours être suivies à tout moment, quel que soit le but de votre projet. Pour la plupart, ils sont conçus pour éliminer les comportements indéfinis / non spécifiés / dépendants de l'implémentation. Par exemple:

• N'utilisez pas la valeur d'une variable non initialisée
• N'utilisez pas le pointeur FILE après avoir fermé le flux
• Toutes les fonctions non nulles doivent renvoyer une valeur.
• Le compteur de boucle ne doit pas avoir de type virgule flottante
• ... etc.

D'un autre côté, il y a des règles dont les bénéfices se trouvent à la surface, mais qui (du point de vue des projets ordinaires) ne sont pas si coupables de briser:

• N'utilisez pas goto et longjmp
• Chaque commutateur doit se terminer par défaut
• N'écrivez pas de code inaccessible
• N'utilisez pas de fonctions variables
• N'utilisez pas l'arithmétique d'adresse (sauf [] et ++ )
• ...

De telles règles ne sont pas non plus mauvaises et, combinées aux précédentes, elles donnent déjà une augmentation tangible de la sécurité, mais est-ce suffisant pour des systèmes embarqués hautement responsables? Ils sont utilisés non seulement dans l'industrie automobile, mais aussi dans la fabrication d'aéronefs, l'aérospatiale, l'armée et le médical.

Nous ne voulons pas, en raison d'une erreur logicielle, de certains patients irradiés par une machine à rayons X avec une dose de 20 000 rad , donc les règles habituelles «quotidiennes» ne suffisent plus. L'enjeu est la vie humaine et d'énormes sommes d'argent, et la minutie doit être incluse. Ici, le reste des règles MISRA entrent en scène:

• Le suffixe «L» dans le littéral doit toujours être en majuscules (le petit «l» peut être confondu avec l'unité)
• N'utilisez pas l'opérateur virgule (cela augmente les chances de faire une erreur)
• Ne pas utiliser de récursivité (une petite pile de microcontrôleurs peut facilement déborder)
• Les corps des instructions if , else , for , while , do doivent être placés entre accolades (vous pouvez potentiellement faire une erreur si le code n'est pas aligné correctement )
• N'utilisez pas de mémoire dynamique (car il est possible de l'allouer sans succès à partir du tas, en particulier dans les microcontrôleurs)
• ... et beaucoup, beaucoup de ces règles.

Souvent, les gens qui rencontrent MISRA pensent que la philosophie de la norme est "d'interdire ceci et d'interdire cela". En fait, c'est le cas, mais seulement en partie.

Oui, la norme a de nombreuses règles similaires, mais son but n'est pas d'interdire tout ce qui est possible, mais d'énumérer des moyens tous ou tous de violer d'une manière ou d'une autre la sécurité du code. Pour la plupart des règles, vous choisissez de les suivre ou non. Je vais l'expliquer plus en détail.

Dans MISRA C, les règles se répartissent en trois catégories principales: obligatoires, obligatoires et consultatives. Obligatoire - ce sont des règles qui ne doivent être violées sous aucun prétexte. Par exemple, cette section inclut la règle «ne pas utiliser la valeur d'une variable non initialisée». Les règles requises sont moins strictes: elles permettent la possibilité d'un rejet, mais uniquement si ces écarts sont soigneusement documentés et justifiés par écrit. Les règles restantes sont incluses dans la catégorie Avis - ce sont des règles qui ne doivent pas être suivies.

MISRA C ++ est un peu différent: la catégorie Obligatoire y manque et la plupart des règles appartiennent à la catégorie Obligatoire. Par conséquent, en fait, vous avez le droit de violer n'importe quelle règle - n'oubliez pas de documenter les écarts. Il existe également une catégorie Document - ce sont des règles obligatoires (les écarts ne sont pas autorisés), qui sont associés à des pratiques courantes comme «Chaque utilisation de l'assembleur doit être documentée» ou «la bibliothèque de plug-ins doit être conforme à MISRA C ++».

Qu'y a-t-il d'autre

En fait, MISRA ne consiste pas seulement en un ensemble de règles. En fait, c'est un manuel pour écrire du code sûr pour les microcontrôleurs, et donc il est plein de toutes sortes d'utilités. Examinons-les en détail.

Tout d'abord, la norme contient une description assez approfondie du contexte: pour ce qui a été créé, pourquoi C ou C ++ a été choisi, les avantages et les inconvénients de ces langages.

Nous connaissons bien les vertus de ces langues. Oui, et sur les lacunes, en général aussi :) Quelle est la complexité élevée, la spécification incomplète de la norme et la syntaxe qui permettent de faire une erreur très facilement, puis de rechercher une erreur pendant longtemps. Par exemple, vous pourriez accidentellement écrire ceci:

for (int i = 0; i < n; ++i); { do_something(); } 

Pourtant, il y a une chance qu'une personne ne remarque pas un point - virgule supplémentaire , non? Vous pouvez également écrire comme ceci :

 void SpendTime(bool doWantToKillPeople) { if (doWantToKillPeople = true) { StartNuclearWar(); } else { PlayComputerGames(); } } 

Il est bon que le premier et le deuxième cas soient facilement pris en compte par les règles MISRA (le premier est MISRA C: 13.4 / MISRA C ++: 6.2.1, le second est MISRA C: 13.4 / MISRA C ++: 6.2.1).

En plus de décrire les problèmes, la norme contient un grand nombre de conseils sur ce que vous devez savoir avant de commencer: sur la façon de configurer le processus de développement MISRA, sur l'utilisation d'analyseurs statiques pour vérifier la conformité du code, sur quels documents vous devez conserver et comment remplir, et ainsi de suite et ainsi de suite.

À la fin, il y a des applications qui contiennent: une liste courte et un tableau récapitulatif des règles, une petite liste de vulnérabilités C / C ++, un exemple de documentation des écarts par rapport à la règle, ainsi que plusieurs listes de contrôle conçues pour vous aider à ne pas vous perdre dans toute cette bureaucratie.

Comme vous pouvez le voir, MISRA n'est pas seulement un ensemble de règles, mais presque toute une infrastructure pour écrire du code sécurisé pour les systèmes embarqués.

Utilisez dans vos projets

Imaginez une situation: vous allez écrire un programme pour un système embarqué très nécessaire et responsable. Ou vous avez déjà un programme, mais vous devez le «transférer» à MISRA. Comment vérifier la conformité de votre code avec la norme? Devez-vous vraiment le faire manuellement?

La vérification manuelle du code n'est pas une tâche facile et potentiellement impossible. Non seulement chaque réviseur devrait examiner attentivement chaque ligne de code, mais il devrait également connaître la norme par cœur. Horreur!

Par conséquent, les développeurs MISRA eux-mêmes sont invités à utiliser l'analyse statique pour tester votre code. En effet, en fait, l'analyse statique est un processus de révision de code automatisé. Vous exécutez simplement l'analyseur sur votre programme et en quelques minutes, vous recevrez un rapport sur les violations potentielles de la norme. Ce dont vous avez besoin, non? Il vous suffit de consulter le journal et de corriger la réponse.

Question suivante: à quel moment commencez-vous à utiliser MISRA? La réponse est simple: le plus tôt sera le mieux. Idéalement, avant même de commencer à écrire du code, car MISRA suppose que vous suivez la norme tout au long de la vie de votre code.

Bien sûr, il n'est pas toujours possible d'écrire MISRA dès le début. Par exemple, il arrive souvent qu'un projet ait déjà été partiellement ou entièrement mis en œuvre, mais le client souhaitait que le projet soit conforme à la norme. Dans ce cas, vous devrez effectuer une refactorisation approfondie du code existant.

C'est là que l'écueil apparaît. Je dirais même qu'un rocher sous-marin apparaît. Que se passe-t-il si vous prenez un analyseur statique et vérifiez la conformité du projet «ordinaire» avec la norme MISRA? Spoiler: vous pouvez avoir peur.

Bien sûr, l'exemple de l'image est exagéré. Ici, vous pouvez voir le résultat de la vérification d'un projet suffisamment grand, qui en fait n'a jamais été pensé pour travailler sur des microcontrôleurs. Néanmoins, lors de la vérification d'un code existant, vous pouvez très bien voir une, deux, cinq, voire dix mille opérations d'analyseur. Et dans tout ce tas, de nouvelles opérations seront perdues qui ont été émises dans le code qui vient d'être écrit ou modifié.

Que faire à ce sujet? Est-il vraiment nécessaire de mettre toutes les choses de côté et de s'asseoir pour réparer tous les anciens positifs?

Nous savons que la première fois qu'un projet est vérifié, beaucoup de points positifs apparaissent assez souvent et nous avons développé une solution qui vous aidera à bénéficier immédiatement de l'analyseur, sans arrêter le travail. Cette solution est appelée une "base de suppression".

Suppress-bases est le mécanisme PVS-Studio qui permet de supprimer massivement les messages de l'analyseur. Si vous vérifiez le projet pour la première fois et y découvrez plusieurs milliers de positifs, il vous suffit de les ajouter à la base de suppression et la prochaine fois que vous exécuterez l'analyseur, il ne vous enverra aucun avertissement.

Ainsi, vous pouvez continuer à écrire et à modifier le code de la manière habituelle, et en même temps, vous ne verrez des avertissements que sur les erreurs qui viennent d'être introduites dans le projet. Dans le même temps, vous profiterez au maximum de l'analyseur ici et maintenant, sans être distrait par le ratissage d'anciennes erreurs. Quelques clics - et l'analyseur est implémenté! Vous pouvez lire des instructions détaillées à ce sujet ici .

Vous pourriez probablement vous demander: «Attendez, que faire des réponses cachées?» La réponse est assez simple: ne les oubliez pas et corrigez-les tranquillement. Vous pouvez, par exemple, placer la base de suppression dans le système de contrôle de version et autoriser uniquement les validations qui n'augmentent pas le nombre d'opérations. Ainsi, petit à petit, votre "rocher sous-marin" est tôt ou tard vidé et il n'en restera plus aucune trace.

D'accord, l'analyseur est implémenté et maintenant nous sommes prêts à continuer. Que faire ensuite? Affaires claires - pour travailler avec le code. Mais que faut-il pour pouvoir déclarer la conformité à la norme? Comment prouver que votre projet est conforme à MISRA?

Le fait est qu'il n'y a pas de «certificat» spécial que votre code est conforme à MISRA. Comme le stipule la norme elle-même, le suivi du code de conformité doit être effectué par deux parties: le client du logiciel et le fournisseur du logiciel. Le fournisseur développe un logiciel conforme à la norme et remplit les documents nécessaires. Le client, pour sa part, doit s'assurer de la véracité des données de ces documents.

Si vous êtes vous-même à la fois client et développeur de votre propre logiciel, la responsabilité de la conformité à la norme incombera uniquement à vos épaules :)

En général, pour prouver la conformité de votre projet, vous aurez besoin de documents de preuve. La liste des documents que les développeurs de projets doivent préparer peut varier, mais MISRA en propose certains comme référence. Examinons cet ensemble plus en détail.

Pour revendiquer la conformité à la norme, vous aurez besoin de quelques éléments:

• En fait, un projet dont le code est conforme aux règles obligatoires et obligatoires
• Guider le plan d'application
• Documentation de tous les avertissements du compilateur et de l'analyseur statique
• Documentation de tous les écarts par rapport aux règles requises
• Résumé de la conformité aux lignes directrices

Le premier est un plan de conformité. C'est votre tableau le plus important, et ce sera lui qui enverra l'examinateur à tous les autres documents. Dans sa première colonne est une liste des règles MISRA, dans le reste, il est noté si des écarts par rapport à ces règles ont été identifiés. Ce tableau ressemble à ceci:

La norme recommande de construire votre projet avec plusieurs compilateurs, ainsi que d'utiliser deux analyseurs statiques ou plus pour vérifier la conformité de votre code. Si le compilateur ou l'analyseur génère une sorte d'avertissement associé à la règle, vous devez le noter dans le tableau et le document: pourquoi l'opération ne peut pas être éliminée, si elle est fausse, etc.

Si l'une des règles ne peut pas être vérifiée avec un analyseur statique, vous devez effectuer la procédure de révision du code. Cette procédure doit également être documentée, après quoi un lien vers cette documentation doit être ajouté au plan de conformité.

Si le compilateur ou l'analyseur statique s'avère correct, ou si des violations de code réelles ont été détectées lors du processus de révision du code, vous devez soit les corriger, soit les documenter. Encore une fois, en attachant un lien vers la documentation du tableau.

Ainsi, un plan de conformité est un document par lequel vous pouvez trouver de la documentation pour tout écart identifié dans votre code.

Maintenant, un peu sur la documentation des écarts par rapport aux règles. Comme je l'ai déjà mentionné, une telle documentation n'est nécessaire que pour les règles requises, car vous ne pouvez pas violer les règles de niveau obligatoire et les règles consultatives ne peuvent pas être suivies sans aucune documentation.

Si vous décidez de déroger à la règle, la documentation doit contenir:

• Numéro de règle brisé
• Emplacement exact de l'écart
• La validité de l'écart
• Preuve que l'écart ne compromet pas la sécurité
• Implications potentielles pour les utilisateurs

Comme vous pouvez le voir, cette approche de la documentation vous fait sérieusement penser si la violation en vaut la peine. Cela est fait spécifiquement pour violer les règles requises n'était pas bon :)

Maintenant sur le résumé de la conformité aux règles. Ce document est peut-être le plus simple à remplir:

La colonne centrale est remplie avant de commencer à travailler avec le code, et la colonne la plus à droite se trouve une fois que votre projet est prêt.

Il est tout à fait raisonnable de poser une question: pourquoi avez-vous besoin de spécifier des catégories de règles, si elles sont déjà spécifiées dans la norme elle-même? Le fait est que la norme permet "d'augmenter" la règle dans une catégorie plus stricte. Par exemple, un client peut vous demander de déplacer une règle de conseil dans une catégorie. Une telle «augmentation» doit être effectuée avant de travailler avec le code, et un résumé du respect des règles permet de le constater clairement.

Avec la dernière colonne, tout est simple: il suffit de noter si la règle est utilisée, et si oui, y a-t-il des écarts par rapport à elle.

Cette table entière est nécessaire pour que vous puissiez voir rapidement les priorités des règles et si le code les correspond. Si vous êtes soudain intéressé à connaître la raison exacte du rejet, vous pouvez toujours vous référer au plan de conformité et trouver la documentation dont vous avez besoin.

Vous avez donc soigneusement écrit le code en suivant les règles MISRA. Vous avez élaboré un plan de conformité et documenté tout ce que vous pouviez documenter, et rempli un résumé de conformité. Si cela est vrai, vous avez reçu du code très propre, très lisible et très fiable que vous détestez maintenant :)

Où vivra votre programme maintenant? Dans un appareil d'IRM? Dans un capteur de vitesse ordinaire ou dans le système de pilote automatique d'un satellite spatial? Oui, vous êtes passé par un chemin bureaucratique sérieux, mais ce sont des bagatelles. Comment ne pas être méticuleux lorsque de vraies vies humaines sont en jeu?

Si vous avez réussi et réussi à atteindre une fin victorieuse, je vous félicite sincèrement: vous écrivez du code sécurisé de haute qualité. Je vous remercie!

L'avenir des normes

Enfin, je veux parler un peu de l'avenir des normes.

MISRA vit et se développe actuellement. Par exemple, au début de 2019, «The MISRA C: 2012 Third Edition (First Revision)» a été annoncé - une norme mise à jour et complétée par de nouvelles règles 2012. Dans le même temps, ils ont annoncé la sortie prochaine de MISRA C: 2012 Amendement 2 - C11 Core, la norme 2012, dans laquelle des règles seront ajoutées qui couvriront les versions du langage C pour 2011 et 2018 pour la première fois.

Ne reste pas immobile et MISRA C ++. Comme vous le savez, la dernière norme MISRA C ++ remonte à 2008, donc la version la plus ancienne du langage qu'elle couvre est C ++ 03. Pour cette raison, il existe une autre norme, similaire à MISRA, et elle s'appelle AUTOSAR C ++. Il a été initialement conçu comme une continuation de MISRA C ++ et était destiné à couvrir les versions ultérieures du langage. Contrairement à son cerveau, AUTOSAR C ++ est mis à jour deux fois par an et prend actuellement en charge C ++ 14. Une nouvelle mise à niveau est prévue vers C ++ 17, puis C ++ 20, etc.

Qu'est-ce que j'ai commencé avec une autre norme? Le fait est qu'il y a un peu moins d'un an, les deux organisations ont annoncé l'unification de leurs normes en une seule. Désormais, MISRA C ++ et AUTOSAR C ++ deviendront un standard unique, et maintenant ils seront développés ensemble. Je pense que c'est une excellente nouvelle pour les développeurs écrivant sous des microcontrôleurs C ++, et pas moins une excellente nouvelle pour les développeurs d'analyseurs statiques. Il y a encore beaucoup de travail préféré à venir! :)

Conclusion

Aujourd'hui, nous avons beaucoup appris sur MISRA: nous avons lu l'histoire de son apparition, étudié des exemples de règles et la philosophie de la norme, examiné tout ce dont vous avez besoin pour utiliser MISRA dans vos projets, et même regardé un peu vers l'avenir. J'espère que vous comprenez mieux maintenant ce qu'est MISRA et comment le cuisiner!

Selon la vieille tradition, je laisserai ici un lien vers notre analyseur statique PVS-Studio. Il est capable de trouver non seulement des écarts par rapport à la norme MISRA, mais également une vaste gamme d' erreurs et de vulnérabilités. Si vous souhaitez essayer PVS-Studio vous-même, téléchargez la version de démonstration et vérifiez votre projet.

Ceci conclut mon article. Je souhaite à tous les lecteurs une bonne année et un bon week-end de nouvel an!

Liens annexes

1. Georgy Gribkov - " Sécurité à vitesse maximale - comment écrire du code C / C ++ fiable pour les systèmes embarqués ."
2. PVS-Studio est un analyseur de code statique .
3. Collaboration PVS-Studio & KEIL 5 .

Si vous souhaitez partager cet article avec un public anglophone, veuillez utiliser le lien vers la traduction: George Gribkov. Qu'est-ce que MISRA et comment le faire cuire .