OSDay 19 ou pourquoi le langage C est toujours vivant

Récemment (10-11 juin), la prochaine conférence scientifique et pratique OSDay s'est tenue à Moscou. Cette fois, la conférence a eu lieu à l'Institut de mathématiques. V.A. Steklov RAS. Officiellement, il était dédié aux outils de développement des plateformes d'exploitation et des logiciels système. Comme d'habitude, les sujets abordés lors de la conférence ne se sont pas limités à une déclaration formelle, et les questions soulevées ont été examinées sous différents angles et diverses approches de leur solution ont été discutées. Différents points de vue et approches - c'est, à mon avis, ce qui distingue la conférence des autres. Ainsi, par exemple, à la fin de la deuxième journée de la conférence, littéralement à la fermeture du rideau, Dmitry zavalishin ( dzavalishin ), l'un des organisateurs, a provoqué une discussion animée sur le fait que le langage de programmation C était en fait dépassé et qu'il fallait le développer (y compris les systèmes d'exploitation) au moins dans les langues gérées en mémoire. Je présenterai ma vision de cette discussion et d'autres sujets d'intérêt qui m'ont été soulevés lors de la conférence dans cet article. À qui c'est intéressant je demande sous kat.

Exposition

Je ne commencerai pas par un examen des rapports, mais par l'exposition, qui fait partie de la conférence. Plusieurs entreprises ont montré leur développement dans le domaine des logiciels système. Il s'agit principalement de systèmes d'exploitation, mais, par exemple, la société RED SOFT, en plus de l'OS, a introduit le SGBD «RED Database» basé sur le projet «Firebird» . J'ai déjà mentionné ce SGBD lors de l' examen d'une des conférences OSDay précédentes . De nouvelles informations pour moi, c'est qu'il a été porté sur l' architecture Elbrus .

La prise en charge de l'architecture Elbrus a été annoncée dans les produits d'autres exposants. Les informations que le système d'exploitation Alt-Linux exécute sur les processeurs Elbrus, bien sûr, ne sont pas devenues nouvelles pour moi. Les employés de Basalt-SPO, comme d'habitude, ont apporté un stand basé sur Elbrus et ont démontré le fonctionnement de leur système d'exploitation sur cette plate-forme. Mais le fait que sur la bannière QP OS, dont j'ai également parlé à plusieurs reprises dans les revues de conférence , ait déclaré le soutien aux processeurs Elbrus, m'a surpris. Après tout, nous avons fait beaucoup d'efforts pour porter Embox sur cette architecture, dont nous avons également parlé sur le hub Il s'est avéré que, malheureusement, ce n'est pas un port à part entière pour l'architecture e2k, le lancement a été effectué en mode de traduction de commande x86, qui, comme vous le savez, est présent dans les processeurs Elbrus.

La prise en charge de diverses plates-formes matérielles était une caractéristique de tous les exposants (à l'exception de RusBITech-Astra, mais ils ont, comme vous le savez, leur propre créneau). RED SOFT a montré son RED OS (si j'ai bien compris, alors c'est le successeur de GosLinux, qui est répertorié dans le registre national des logiciels) sur RaPi. QP OS a déclaré la prise en charge d'ARM. Mais de loin, Alt Linux était le plus multiplateforme. Des collègues ont montré du travail non seulement dans les Elbrus et le Baïkal nationaux, mais aussi, par exemple, sur une architecture relativement rare comme RISC-V .

Sécurité de l'information

Le sujet de la sécurité des logiciels est très large. Lors de la conférence, il a été expliqué à plusieurs reprises qu'il existe différents types de sécurité, plus précisément des définitions de ce qu'est la sécurité. Ils viennent de la sûreté, de la sécurité, de la fiabilité et ainsi de suite en anglais. Par conséquent, l'orateur parlait généralement du type de sécurité en question à l'heure actuelle. Bien que tout le monde ait convenu qu'il est difficile de parler de sécurité (sécurité) de l'information, si la sécurité fonctionnelle (sécurité) n'est pas assurée.

La convention de la division en sécurité - sûreté était clairement visible dans la section sur la sécurité de l'information. Par exemple, Alexander Popov ( a13xp0p0v ), un développeur de noyau Linux qui a fait une présentation «Comment STACKLEAK améliore la sécurité du noyau Linux» lors d'une conférence précédente , a présenté la «Carte des fonctionnalités de sécurité du noyau Linux», et la carte montre que la clé de la sécurité des informations réside dans domaines de logiciels de qualité. Après tout, la plupart des problèmes de sécurité sont standard: débordements de tampon, débordements de pile, ne pas vider la pile au retour d'un appel système, etc. Vous pouvez visualiser son projet sur github . Hier publié sur un habr

Le problème de l'imprécision du concept de sécurité des logiciels a également été démontré dans un rapport d'Ekaterina Rudina de Kaspersky Lab «Le modèle de maturité de la sécurité de l'Internet des objets pour établir, coordonner et limiter les exigences des systèmes d'exploitation». Il ressort du rapport que le concept de sécurité peut varier lorsqu'il est appliqué à différents domaines, et même à différents types d'appareils et de produits. Ce qui est évident, eh bien, pourquoi, par exemple, un antivirus sur votre bracelet de fitness. Par conséquent, l' Industrial Internet Consortium , qui comprend Kaspersky Lab, a suggéré d'utiliser le modèle IoT Security Maturity Model (IoT SMM) pour formuler le concept de sécurité pour un cas particulier.

Je pense qu'en raison de la séparation difficile de la sécurité et de la sûreté, il n'y a pas eu beaucoup de rapports sur la sécurité pure de l'information. Un exemple frappant d' un tel discours est le rapport du responsable d'OpenSSL, Dmitry Belyavsky, «Hébergement de logiciels: une approche du monde de l'Open Source». Dans lequel l'auteur a parlé des difficultés de soutenir les normes nationales de cryptographie.

Sécurité fonctionnelle

La sécurité fonctionnelle (logiciel de sécurité) sous une forme ou une autre était présente dans presque tous les rapports de la conférence. Après tout, si vous regardez plus en profondeur, même dans la discussion déjà mentionnée sur l'obsolescence du langage C, il a été compris que ce langage n'est pas sûr et avec son aide, il est très facile de «se tirer une balle dans le pied».

A en juger par les rapports de la conférence, l'amélioration de la sécurité fonctionnelle (fiabilité) des logiciels pour les participants se traduit par l'utilisation d'outils. Bien que ce soit peut-être un hommage au thème déclaré de la conférence - les outils. Par conséquent, la grande majorité des rapports proposaient précisément une approche instrumentale. L'un des organisateurs de la conférence ISP RAS est spécialisé dans le développement d'outils d'analyse de code statique et dynamique. En fait, le FAI RAS a donné le ton avec un discours d' Alexander Gerasimov avec un rapport «Utilisation des outils d'analyse automatique des programmes dans le cycle de développement de logiciels sûrs».

Sur le thème du développement d'analyseurs statiques, il y a eu un rapport de Vladimir Kozyrev de la société Advalange «Développement d'outils pour collecter et analyser la couverture des logiciels embarqués». La boîte à outils présentée a été développée dans le but de vérifier les logiciels embarqués selon la norme DO-178C , mais la même boîte à outils peut être utilisée non seulement dans les logiciels embarqués, car le code analysé pour la couverture est un C. ordinaire.

En plus des rapports sur le développement d'outils, il y avait plusieurs rapports sur l'expérience d'utilisation d'outils similaires (ou identiques). Par exemple, un rapport de Pyotr Devyanin de RusBITech -Astra avec le titre long «Expérience avec l'utilisation d'outils pour accroître la confiance dans les mécanismes de sécurité de l'OSRA Astra Linux Special Edition» a parlé de l'expérience de l'application de ces outils à un module de sécurité pour leur système d'exploitation.

Naturellement, non seulement des outils d'analyse de logiciels ont été présentés lors de la conférence, mais aussi d'autres, à l'aide desquels il est possible d'augmenter la fiabilité des logiciels. Il était très intéressant d'écouter Dmitry Dagaev avec le rapport «Les technologies Oberon évolutives comme moyen de sécuriser les logiciels sécurisés pour les systèmes critiques». L'auteur du rapport est le concepteur en chef du SCADA QMS pour les centrales nucléaires. Par conséquent, une expérience de première main avec des systèmes avec «des exigences accrues en termes de sécurité fonctionnelle et de protection contre les cybermenaces» (citation de l'annotation à son rapport). Pour augmenter la sécurité des logiciels, l'auteur suggère d'utiliser la technologie Oberon . L'auteur de la langue Oberon, Nikolaus Wirth , a émis l'idée d'introduire des restrictions, ce qui réduit considérablement le risque d'écrire des logiciels dangereux. Dans le même temps, avec l'aide du raffinement du compilateur, l'auteur du rapport suggère de créer des images destinées à diverses tâches et plates-formes. Le rapport était très proche de moi, car nous, à Embox , avons eu des idées similaires sur les limitations. Mais ils ont suggéré que des restrictions soient introduites en utilisant le langage de description du module (un langage déclaratif de sa propre composition destiné à une tâche spécifique). Et pour générer des artefacts qui vous permettent de créer des images pour une tâche spécifique, à notre avis, il est également plus facile d'utiliser un langage distinct pour décrire ces artefacts.

En conséquence, les organisateurs de la conférence ont résumé dans une section les rapports sur les différentes approches du logiciel sécurisé, principalement sur la sécurité fonctionnelle. La première approche consiste à utiliser des outils d'analyse de code, la seconde à utiliser des langages de niveau supérieur et, enfin, l'approche du Kaspersky Lab, qui est plutôt organisationnelle ou méthodologique. Il y avait également un rapport sur le débogueur, mais je ferais mieux de le mettre dans une section distincte, bien que, bien sûr, le débogage puisse réduire le nombre d'erreurs et, par conséquent, augmente également la fiabilité du logiciel.

Outils de débogage

La conférence a présenté plusieurs outils de débogage et de profilage des logiciels système.
Valery Egorov de la société NTP "Cryptosoft" (créateur du QP OS ) a parlé du débogueur PathFinder, qui est utilisé dans leur hyperviseur QP VMM. Naturellement, tous les leurs, avec tous les avantages et inconvénients qui en découlent.

Denis Silakov , architecte principal des systèmes, Virtuozzo
Il a parlé de l'expérience de trouver des erreurs sur la base de l'ABRT (Automatic Bug Reporting Tool). Création d'un journal de tout ce qui peut être utile pour l'analyse, envoi d'un rapport en cas d'urgence au serveur et analyse supplémentaire déjà sur le serveur.

Fedor Chemerev de NIISI RAS a parlé des installations de traçage dans le système d'exploitation du VR de la famille Baget. Étant donné que le Baget RTOS se concentre sur les systèmes embarqués, dans le cas de Virtuozzo, les informations sont également collectées sur la machine instrumentale et l'analyse est effectuée sur le serveur. Les informations sont collectées en écrivant dans le journal des événements, tandis que le journal peut être analysé sans situations d'urgence.

Approche modulaire

Le premier exposé sur les outils qui favorisent la modularité des logiciels et les avantages de la modularité a été le discours déjà mentionné sur la technologie Oberon .

En outre, il y avait trois autres rapports, chacun proposant sa propre approche du problème de la modularité. Dmitry Alekseev d'Eremeks LLC a présenté le rapport «Injection de dépendances dans les logiciels orientés composants sur C / C ++». Dans ce document, l'auteur a parlé de la commutation de la configuration de divers modules du noyau du système d'exploitation FX-RTOS et également de diverses interfaces. Un projet basé sur des macros a été mis en œuvre. En savoir plus dans l' article sur Habr .

Moi, Anton Bondarev , en tant que participant au projet Embox, j'ai présenté un rapport «Expérience dans le développement et l'utilisation d'un système d'assemblage basé sur un langage de programmation spécialisé», dans lequel j'ai parlé de notre expérience dans le développement du langage Mybuild, qui a été partiellement écrit sur le hub . Dans notre cas, la modularité et l'implémentation des dépendances sont fournies à l'aide de fichiers séparés, qui décrivent les modules dans un langage déclaratif.

Et le troisième est un rapport de Mullachiev Kurbanmagomed du FAI RAS «Sur l'utilisation d'une approche modulaire dans les systèmes d'exploitation embarqués». Cet outil a été utilisé dans un autre système d'exploitation JetOS. Pour la description des modules, le langage YAML est utilisé. Malheureusement, aucun exemple n'a été donné, mais l'idée exprimée était très intéressante et nous l'envisageons dans notre projet. L'idée est d'exporter (déclarer) une interface et les objets peuvent être connectés via cette interface. L'idée a été exprimée que les auteurs ont réinventé l' IDL . Mais ce n'est certainement pas le cas, juste des idées proches.

Un tel nombre de rapports sur une approche modulaire ou composante indique probablement l'importance du modèle de composant pour créer un logiciel fiable. Après tout, personne ne doute qu'une approche modulaire puisse réduire la complexité du logiciel, et donc sa fiabilité; que la structure (architecture) correcte du logiciel donne des résultats étonnants; que l'API correcte (essentiellement un contrat de logiciel) rend le logiciel plus pris en charge. Mais il est plus facile de dire que vous devez créer la bonne interface que de l'implémenter. Par exemple, un rapport sur Oberon suggère d'utiliser des modules sans état. Naturellement, cela résout le problème, mais personnellement, je n'ai jamais vu de véritable système sans état.

Revenons à la discussion sur le C obsolète

Les problèmes d'utilisation du langage C sont évidents, par conséquent, toutes sortes de façons de les résoudre sont utilisées, et des analyseurs statiques, et divers types de tests, et bien plus encore. Une question raisonnable se pose: pourquoi dépenser autant d'efforts?
Étant donné que la discussion était ouverte et qu'un microphone était fourni à tout le monde, il était clair que certains des participants à la conférence soutenaient pleinement cette idée et certains doutaient que le langage C appartienne au passé, du moins dans le domaine de la programmation système dans un avenir proche.

Je vais d'abord donner les arguments de la partie des participants qui ont soutenu l'idée. De toute évidence, l'idée a été soutenue par Dmitry Dagaev, auteur du rapport sur Oberon. Comme argument, il a cité une photographie de l'endroit où, dans la photo avec Nikolaus Wirth, il tient une affiche avec l'inscription dont vous avez besoin pour enseigner la programmation uniquement sur Oberon. D'autres participants à la discussion ont avancé la thèse selon laquelle l' architecture de von Neumann était quelque peu dépassée, eh bien, au moins vous pouvez utiliser la mémoire balisée, comme dans l'architecture Elbrus. Et il ne s'agissait pas de l'architecture Elbrus, mais des tendances modernes de l'architecture ARM, et Alexander Popov, déjà mentionné, l'a dit. Naturellement, il y avait immédiatement ceux qui voulaient écrire un OS, dont certaines des fonctions seront implémentées dans le matériel. Toute une série de participants, développant le sujet de l'utilisation d'un autre langage, a naturellement suggéré d'utiliser des langages de programmation fonctionnels. En développant le thème du langage, nous sommes arrivés à la conclusion que dans notre pays il n'y a pas d'outils de développement certifiés, par exemple, un compilateur pour ARM, et les compilateurs autorisés à utiliser peuvent contenir des signets. Par conséquent, il est évident que vous devez d'abord créer un compilateur, puis seulement écrire des logiciels basés sur celui-ci, y compris les systèmes d'exploitation.

Les arguments de la deuxième partie des participants à la discussion n'étaient pas tellement en faveur de l'utilisation du langage C, ils expliquaient plutôt pourquoi ce langage est toujours la norme pour la création de noyaux OS. De tels arguments ont retenti. La syntaxe du langage C implique un contrôle complet et explicite par le programmeur de tout dans le programme, y compris l'allocation de mémoire, ce qui vous permet de créer des algorithmes très économes en ressources. Le langage C est en effet supporté par des outils de développement, par exemple, gcc. La syntaxe du langage est très simple et familière à un très grand nombre de personnes.

J'ai vraiment aimé l'allégorie avec les vaisseaux spatiaux et les vieilles routes. À partir de là, on utilise maintenant des voitures ordinaires, qui ne sont probablement pas très bonnes, polluent l'environnement et ont un taux d'accidents important. Mais pour passer à certaines supercars sans pilote, vous devez probablement les développer, construire un réseau de routes de qualité appropriée, faire le plein, développer des algorithmes, etc. Des travaux sont en cours dans ces domaines, mais il est peu probable que prendre et interdire de vieilles voitures comme celle-ci réussisse.

Je suis absolument d'accord, vous devez d'abord développer l'industrie et former des spécialistes, et ce sont des processus très longs, pour l'instant vous devez utiliser un tas de logiciels déjà développés en C, car il est beaucoup plus fiable et plus débogué que le nouveau, bien qu'avec des technologies avancées. En effet, bien que n'étant pas à cette discussion, de tels avertissements ont retenti lors de la conférence. Par exemple, l'auteur du rapport d'hébergement de logiciels de cryptographie, Dmitry Belyavsky, lorsqu'on lui a demandé ce que le développeur de sécurité doit savoir, a répondu: «N'écrivez jamais vous-même la cryptographie». Et Dmitry Shevtsov de FSTEC, m'a demandé de prendre davantage soin de soutenir le logiciel développé.

À propos de la formation de spécialistes, c'est probablement la question la plus importante: que pensent les experts - le logiciel sera développé là-dessus, il est fort possible que le langage C soit devenu la norme de facto pour le système d'exploitation, car il avait UNIX et Minix (et c'est peut-être pour cela que conçu pour le développement UNIX). Par conséquent, le projet d'enseigner aux écoliers et aux étudiants à programmer dans la langue d'Oberon Informatics 21 peut porter ses fruits, cependant, beaucoup de temps doit passer.

Conclusion

Comme je l'ai dit dans l'introduction, cette conférence vous permet de partager des idées, de discuter et de discuter. Plusieurs approches ont été présentées sur de nombreuses questions, par exemple sur les logiciels modulaires et les logiciels sécurisés. De plus, les organisateurs de la conférence appellent sciemment des intervenants avec différentes approches, ce qui rend la conférence encore plus intéressante. Et bien sûr, la conférence est très ouverte, comme l'a dit Dmitry Zavalishin lors de la discussion sur le langage C, "Cinq minutes de gloire pour tout le monde".

PS

Je viens de lire un article sur un hub appelé "Technical Media as a Bazaar" . Il explique à quel point il est important d'avoir plusieurs opinions différentes. Je propose de poursuivre la discussion sur le langage C sur Habré. Par exemple, il est très intéressant de savoir s'il existe des solutions industrielles multiplateformes sur la rouille ou disparaître?