Discussion :

[Patrick Ruiz]

Il n’y a rien de mieux que le langage de programmation C pour le développement de systèmes d’exploitation
D’après Linus Torvalds

La déclaration est de Linus Torvalds – le créateur du système d’exploitation open source Linux – lors d’une de ses interventions à l’Intel Open source Technology Center en 2012. Il répondait à la question de savoir s’il voit un autre langage de programmation à part le C qui soit taillé sur mesure pour le développement de systèmes d’exploitation. Quelques extraits de sa réponse …

Je dois dire que je suis assez vieux jeu sur des sujets comme celui-là. La raison pour laquelle je me suis lancé dans Linux et les systèmes d’exploitation en général est que j’aime vraiment le hardware ; j’aime explorer l’aspect matériel. Je ne le dis pas pour souligner que je suis un expert en hard parce que me tendre un fer à souder serait une mauvaise idée. Ce que je veux dire c’est que j’aime interagir avec le matériel à partir du logiciel. Vu sous cet angle, je n’ai pas encore vu un langage de programmation qui approche seulement le langage C. Cette affirmation ne tient pas uniquement à ce que le C soit utile pour générer du bon code pour piloter le matériel. Ce qu’il faut dire en plus c’est que l’usage du C fait sens pour des personnes qui pensent comme un ordinateur. Je crois que la raison pour laquelle il en est ainsi est que les personnes qui ont conçu le langage C l’ont fait à un moment où les compilateurs devaient être simples ; à un moment où le langage devait être adapté à la sortie ou au résultat attendu. Donc lorsque je lis du code en langage C, je sais à quoi va ressembler le code assembleur et c’est ce qui m’intéresse.

Certes, la déclaration de Linus Torvalds date, mais 7 années plus tard, des avis récoltés sur la toile lui donnent un coup de neuf.

Le C est à bien des égards un langage ingénieux. C'est une très bonne abstraction du matériel sous-jacent. Assez transparent pour "voir" ce qui se passe à un niveau inférieur et juste assez haut niveau pour fournir quelques constructions utiles et éviter la peine de faire usage de l'assembleur.

Bon nombre de ses "défauts" sont en fait la conséquence directe de cette conception. Si vous comprenez le processeur et la mémoire, vous trouverez le C naturel. D'autres langages qui sont vantés comme modernes, plus faciles et tout le reste, font tellement abstraction de l'aspect matériel qu'une grande partie du contrôle fin est perdue. C'est un compromis.

C a certainement des défauts. Il porte en lui un héritage dont il est difficile de se débarrasser, mais la façon dont il garde le programmeur près du matériel n'est pas un défaut, c'est une caractéristique dont il faut dire qu'elle est de plus en plus difficile à trouver.

La sortie de Linus Torvalds est antérieure à la publication de la première version stable de Rust – l’un des langages de programmation pressentis comme remplaçant du C sur le terrain du contrôle du hardware. En fait, au moment où Linus s’exprime, Rust n’en est qu’au stade de l’enfance.

De nos jours, Rust est une véritable alternative et offre des caractéristiques qui le rendent tout simplement plus polyvalent. Nous avons d'abord besoin d'un code sûr et donner des garanties de sécurité élevées est l'un des aspects les plus importants d'un système d'exploitation ou d'un programme. Je suis absolument sûr que quelque chose de similaire à Rust sera utilisé pour écrire le système d'exploitation qui remplacera Linux sur le long terme.

Ce qu’il faut en effet souligner à propos de Rust est que le langage garde une vision proche de la machine. Il est clairement prévu pour être utilisable pour des applications de très bas niveau comme un noyau, des pilotes de périphériques ou de l'embarqué temps réel. Il permet aussi d'éviter certains points complexes du C++, mais n'est pas aussi radical. Il s’appuie pour cela sur des génériques et un système de macros plus propre que celui de C++. Il est par contre plus complexe sur un point particulier : il surveille à la compilation la durée de chaque variable ; il vient qu'une utilisation des pointeurs qu'il ne peut garantir sûre refusera de compiler. Pour éviter cela le développeur doit bien assimiler les notions de propriété et de durée de vie d'un pointeur qui permettent de garantir que le code est sûr. Cela permet d'avoir une garantie absolue qu'il n'y aura aucune erreur de sécurité mémoire.

Dans la liste des systèmes d’exploitation créés à partir de Rust on compte Redox. L’équipe de développeurs derrière cet OS le présente comme un « système d’exploitation open source qui vise l’intégration des innovations au sein de Rust à un microkernel et un ensemble complet d’applications. » Le système d’exploitation est publié sous licence MIT.

Le GUI Orbital sous Redox

De façon générale, l’intervention de Linus Torvalds relance le débat sur la question de savoir quel langage pourrait remplacer le C. Il y a 4 ans, l’architecte logiciel Andrei Alexandrescu a dressé un comparatif de Go, Rust et D. De façon brossée, il en resssortait que pour ses caractéristiques d’introspection statique, son temps de compilation rapide ajouté à d’autres atouts uniques, le langage D est le remplaçant idéal du C.

Sources : YouTube, Redox

Et vous ?

Que pensez-vous de la déclaration de Linus Torvalds ?

Depuis 2012, quel langage de programmation s’est d’après vous positionné en véritable remplaçant du C ?

Pourquoi le langage C pourrait encore avoir de longues années devant lui ?

Voir aussi :

Programmation : un « Pony » peut cacher un langage, l'outil adéquat, d'avis d'utilisateurs, pour le développement d'applications concurrentes

C2 : un langage qui se présente comme une évolution de C, plus rapide, sans fichiers d'en-tête, avec système de build intégré et d'autres changements

Quel avenir pour le langage C ? Un développeur expérimenté fait ses adieux au langage et livre ses inquiétudes quant à son avenir

[KsassPeuk]

Le gros soucis ça reste qu'atteindre un haut niveau de fiabilité dans un composant aussi critique d'un OS nécessite un boulot de dingue. Et à l'échelle d'un truc qui fait plusieurs millions de lignes de code, c'est juste infaisable d'obtenir des vraies garanties de fiabilité avec un effort raisonnable. Et C est définitivement l'un des langages où c'est le plus difficile. Ce n'est pas parce qu'un langage est de plus haut niveau que nécessairement il occulte tous les détails de bas niveau (et on pourrait aussi arguer que C occulte lui aussi énormément de détails selon comment on l'utilise). Mais si on prend des retours d'expérience comme HACL* (F-Star) ou Pip protokernel (Coq), on peut voir que l'utilisation d'un langage de haut niveau n'implique pas de cacher les détails nécessaires au bas niveau, simplement de devoir effectivement les prendre complètement en compte et pas juste de tester un ensemble restreint de scénarios.

[redcurve]

Le top reste le combo C/C++/C#, j'arrive la lire de l'object-c sans problème mais je n'aime pas trop la syntaxe quoique le délire de considérer que tout est un dictionnaire est assez funky

[KsassPeuk]

Le top reste le combo C/C++/C#

Ça dépend des objectifs, encore une fois. Faire du code sûr en C, c'est pas simple. Il y a qu'à voir comment des projets comme seL4 en ont chié pour arrivé à un niveau EAL7 de sûreté (25 personnes-année pour 10K lignes de C - sachant que c'est la preuve qui a été hardcore, pas le process de certif en lui même). Et honnêtement, pour des composants aussi critiques qu'un OS, avoir des vraies garanties de sécurité et sûreté, ça serait pas un mal.

[hotcryx]

Je me demande si à l'époque de Torvalds, il y avait des pattern de programmation comme actuellement.

Bien découper le code ça aide

[Invité]

Je me demande si à l'époque de Torvalds, il y avait des pattern de programmation comme actuellement.

Bien découper le code ça aide

Non non. A l'époque de Torvalds (paix à son âme), on faisait marcher un chaton sur le clavier et quand ça compilait on sortait une nouvelle release. https://en.wikipedia.org/wiki/Design_Patterns

[Se7h22]

La déclaration est de Linus Torvalds – le créateur du système d’exploitation open source Linux – […]

Pour rappel, Linus Torvalds est le créateur du noyau Linux, et non du système d'exploitation GNU/Linux ;-)

Sinon, je n'ai pas vraiment d'avis sur la question, même si j'imagine qu'il a plus ou moins raison vu que le langage C à fait ses preuves, je pense. Mais il n'est pas inimaginable qu'il soit remplacé un jour pour réaliser des systèmes d'exploitation.

[kilroyFR]

Personnellement en 30 ans de dev, j'ai toujours decoupé mes softs en couches (regle d'or) et jamais eu aucun probleme de conception, quel que soit le langage.
Le principe des micros services on en faisait deja a l'epoque sous Linux - c'etait meme un principe elementaire, combiner des applications/utiltaires faisant individuellement des choses tres simples. Tu peux batir un OS avec ce simple principe.
Alors oui on a inventé C# parce que C/C++ etait considéré comme trop compliqué (oui avoir de la rigueur c'est pas donné a tout le monde). Du coup maintenant on code en C# sans se poser des questions (sauf que nombre de devs ne comprennent meme plus pourquoi des fois y a des problemes de GC et autres). C# a permis de democratiser la programmation et mettre le C au niveau du visual basic - n'importe qui peut faire du C#, c'est sa force.
C'est la base de tout. Les patterns on les suivait sans le savoir; tout comme je me rends compte qu'on a toujours ete agile dans les devs. Cycle en vie etant plus theorique car dans la pratique c'etait une forme d'agilité qui prevalait.

[Médinoc]

Pour un truc bas niveau comme ça, je tendrais à privilégier le C++, qui permet de descendre exactement à aussi bas niveau que le C quand on en a besoin, avec l'ajout de la sécurité sur la manipulation des ressources.

[chrtophe]

Je reste septique sur l'utilisation d'autre chose que le C pour un OS, (du moins pour le noyau et les pilotes). L'intérêt qu'autre chose que le C reste à prouver.

[Invité]

Je reste septique sur l'utilisation d'autre chose que le C pour un OS, (du moins pour le noyau et les pilotes). L'intérêt qu'autre chose que le C reste à prouver.

Entre les bugs de gestion mémoire ou de concurrence, les failles de sécurité à la buffer overflow et autres, les codes inmaintenables, etc, l'intérêt du C reste également à prouver.

Concernant les alternatives au C, Rust semble quand même avoir des vrais intérêts.
https://www.rust-lang.org/what/embedded
https://www.redox-os.org/

[chrtophe]

Entre les bugs de gestion mémoire ou de concurrence, les failles de sécurité à la buffer overflow et autres, les codes inmaintenables, etc,

Il s'agit souvent d'un problème d'interface chaise clavier, de mauvaise programmation. C'est sûr que ce type de problèmes est masqué par le langage quand tu utilises du C++ ou autre.

l'intérêt du C reste également à prouver.

Tous les OS du marché sont à ma connaissance basé sur le C.

Je vais jeter un œil sur Redux, Même si ça perce pas, l'alternative reste intéressante à étudier.

[KsassPeuk]

Il s'agit souvent d'un problème d'interface chaise clavier, de mauvaise programmation. C'est sûr que ce type de problèmes est masqué par le langage quand tu utilises du C++ ou autre.

Oui c'est précisément le point : il est très facile de faire du code buggé en C, bien plus facile que dans beaucoup d'autres langages, et dans le même temps les dites erreurs peuvent être beaucoup plus difficile à détecter. On sait bien que les problèmes sont avant tout dus à de la mauvaise programmation, mais justement la question est là : qu'est ce qu'on devrait utiliser pour qu'il soit plus difficile de faire de la mauvaise programmation. Et pour ça, C n'est pas un cadeau.

Tous les OS du marché sont à ma connaissance basé sur le C.

Et une nouvelle fois ce n'est pas parce que c'est ce qui est fait partout que c'est une bonne chose. C'est pour une bonne part dû à l'histoire, et à la formation des développeurs qui font généralement ces systèmes qui n'ont pour leur vaste majorité jamais vraiment autre chose que C. Faire du soft blindé en C c'est extrêmement coûteux. Et si tu prends un domaine comme les systèmes formellement vérifiés quand tu as un soft qui est composé que 10 000 lignes de C et 200 000 lignes de code dans un langage de vérification, finalement c'est peut être plus tout à fait exact de dire que la base de confiance c'est C.

[Invité]

Il s'agit souvent d'un problème d'interface chaise clavier, de mauvaise programmation. C'est sûr que ce type de problèmes est masqué par le langage quand tu utilises du C++ ou autre.

C'est aussi ce que disaient les programmeurs assembleur des programmeurs C il y a quelques décénnies...

Tous les OS du marché sont à ma connaissance basé sur le C.

Je vais jeter un œil sur Redux, Même si ça perce pas, l'alternative reste intéressante à étudier.

Haiku OS -> C++ https://fr.wikipedia.org/wiki/Haiku_...7exploitation)
MaRTE OS -> Ada https://fr.wikipedia.org/wiki/MaRTE_OS
MirageOS -> OCaml https://mirage.io/
Mezzano -> Common Lisp https://github.com/froggey/Mezzano
...

Evidemment, ce ne sont pas des OS mainstream mais ça prouve qu'il est parfaitement possible de programmer un OS dans d'autres langages. La prédominance du C dans les OS, c'est essentiellement parce qu'il est simple, supporté par tous les fabricants de matériel et connu par tous les programmeurs.

[chrtophe]

Voici ce que j'ai dit :

Je reste septique sur l'utilisation d'autre chose que le C pour un OS, (du moins pour le noyau et les pilotes). L'intérêt qu'autre chose que le C reste à prouver.

Je n'ai pas dit que ce n'était pas faisable.

ça prouve qu'il est parfaitement possible de programmer un OS dans d'autres langages.

Et quel est l’intérêt ?

La prédominance du C dans les OS, c'est essentiellement parce qu'il est simple, supporté par tous les fabricants de matériel et connu par tous les programmeurs.

Là je suis d'accord avec toi. Et c'est quand même des éléments majeurs.

Il est à noter qu'à l'origine Unix (origine de Linux, de MacOS via freeBSD) n'était pas programmé en C, mais a été entièrement réécrit en C. Cela date des années 70. Depuis, bien d'autres langages ont été créés, Unix n'a pas été réécrit dessus. Microsoft, qui à la base créait des compilateurs, n'a pas utilisé autre chose que le C/C++ (C++ étant un sur-ensemble de C) pour écrire Wiindows.

Pour tes exemples :

- Haiku : démarré en 2001, en beta depuis septembre 2018 : inexploitable vu la lenteur (j'ai testé). Juste un navigateur : mais qui semble à peu près fonctionnel. Libreoffice a été porté dessus semble t'il. J'ai arrêté là.
- Marte OS : c'est un système temps réel, comme QNX ou windows CE, fourni sous forme de tar.gz : contenant des fichiers .c ??? .Pour un système embarqué, j'utiliserais plutôt de l'Arduino, qu'on programme plutôt ... en C. Par ailleurs il boote via Grub, le noyau se présente sous forme d'un fichier ELF. Il te faut donc Linux pour le compiler.
- MirageOS : système basé sur le principe d'unikernel, en gros c'est de la virtualisation, il te faut un hyperviseur. Je ne sais pas si on peut vraiment considérer ça comme un OS.
- Mezzano : On peut lancer Doom ou Quake : super. Rien d'autre d'utile, et pareil : lenteur extrème.
Pour rester objectif, la lenteur est quand-même à pondérer par le fait que j'ai testé en VM. Mais avec l'UEFI maintenant, même pas sûr qu'oin puisse booter en réel (sauf dans le cas d'utilisation de Grub, bootloader de linux).

Tous ces trucs sont des proofs of concepts de possibilité de coder un OS avec autre chose que le C, mais en quoi est-ce mieux, ou moins bien ?
Il existe aussi des Os en js (OS.js), en VB.net (Flux OS) : ça n'en fait pas des langages adaptés au remplacement du C pour coder un OS.

Quant à Redox, Super lent et impossible d'aller sur le net, impossible de saisir un eURL dans le browser (j'ai peut-être pas compris comment ça marche)

ReactOS, projet d'OS alternatif compatible Windows est compatibles avec les pilotes windows, fait tourner AbiWorld, Nero, firefox, liste non exaustive. Il est écrit en C et toujours en version Alpha. Pourquoi je le cite ? Car grâce au projet Haiku, dont le test ne m'a que très moyennement convaincu, ReactOS dispose d'un pilote USB de stockage de masse .ReactOS et Wine, connu pour permettre de lancer des executables Windows sous Linux sont des projets qui s'apportent mutuellement des choses.

Je n'ai donc vu aucun des OS sités non écrit en C exploitable (ça veut pas forcément dire qu'il n'y en a pas). Je reconnais le gros travail fait, mais il reste encore beaucoup à faire.

[Invité]

Et quel est l’intérêt ?

Alors, sans ordre particulier :
- empêcher les buffer overflow
- empêcher les data race condition
- empêcher les allocations non libérées
- empêcher les accès à des zones mémoires invalides ou libérées
- avoir un vrai système de type et non des "void *" + cast
- avoir des vrais types génériques
- avoir un langage plus expressif, qui rend le code plus court et plus lisible
- ...

Maintenant c'est sûr qu'avec des programmeurs parfaits qui ne font pas d'erreur, tout cela est inutile mais dans ce cas je me demande pourquoi il y a eu 2000 CVE en 20 ans (https://www.cvedetails.com/product/4...l?vendor_id=33) et pourquoi les programmeurs linux ne codent pas directement en binaire plutôt que de s'embêter avec des compilateurs....

[chrtophe]

empêcher les buffer overflow

Dans ce cas je t'invite à lire :
How Rust’s standard library was vulnerable for years and nobody noticed

seg fault pushing on either side of a VecDeque
https://github.com/rust-lang/rust/issues/44800

This is a buffer overflow bug in the standard library’s implementation of a double-ended queue. The data written out of bounds is controlled by the attacker. This makes it a good candidate for a remote code execution exploit.

The bug affects Rust versions 1.3 to 1.21 inclusive. It is causing a crash that is relatively easy to observe, yet it has gone unnoticed for two years. In the release that fixed it it did not even get a changelog entry. No CVE was filed about this vulnerability.

Mais rassure-toi, il n'y a a pas de CVE.

Il ne faut pas croire qu'un langage plus récent/évolué qu'un autre n'engendrera pas de problèmes, ni qu'il n'y aura pas de vecteurs d'attaques identiques à ceux connus voire de nouveaux.

Après dans cet exemple, un segfault kille le processus, le problème est donc en théorie circonscrit mis à part la perte éventuelle de données dans l'appli crashée.

[Invité]

Dans ce cas je t'invite à lire :
How Rust’s standard library was vulnerable for years and nobody noticed
...

Merci pour l'article. Je t'invite à le relire également car visiblement tu l'as mal compris ou les choses ont évoluées.

L'article vante principalement les méthodes de travail qui mettent en avant la sécurité, comme les CVE. Le bug que tu mentionnes a un CVE, c'est même écrit dans l'article (https://cve.mitre.org/cgi-bin/cvenam...E-2018-1000657).

L'article parle effectivement de ce bug de la lib rust mais il parle aussi d'une faille dans libjpeg qui, pendant 10 ans, permettait de récupérer les mots de passe du navigateur !

Il parle aussi de python : "Python runtime gets at about 5 remote code execution vulnerabilities per year"

Il parle aussi des buffer overflow dans une bibliothèque utilisée par tous les navigateurs web : "When I asked the maintainers to file a CVE, they said that if they filed one for every such bug they fixed they’d never get any actual work done."

du langage C en général : "it is evident that humans are unable to write secure C code, unless they swear off dynamic memory allocation altogether"

et du langage rust en général : "There is a mathematical proof of correctness for a practical subset of safe Rust and even some inherently unsafe standard library primitives, and ongoing work on expanding it to cover even more of the language."

Bref, si ton avis est que le langage C convient et que le problème vient des développeurs, l'article dit à peu près exactement le contraire.

[Vincent PETIT]

Salut,
Il y a quelques choses que je ne comprends pas ci après, j'ai l'impression que tout ceci est un faux problème.

- empêcher les buffer overflow
- empêcher les data race condition
- empêcher les allocations non libérées
- empêcher les accès à des zones mémoires invalides ou libérées
- avoir un vrai système de type et non des "void *" + cast
- avoir des vrais types génériques
- avoir un langage plus expressif, qui rend le code plus court et plus lisible
- ...

Je travaille souvent en C sur des microcontrôleurs sans aucun OS et sans ce dernier il n'y a aucune gestion des overflow, si on en fait un il ne se passe rien du tout, pas plus que de mécanisme de violation des zones mémoires. On peut se balader n'importe où dans la mémoire sans aucun problème. Sans OS, pas question de faire des try catch en espérant attraper un événement puisque rien n'est implémenté. Sans OS ça ne "try"era rien, pas plus que ça "catch"era quelque chose. Un langage prenant en charge le garbage collector va se trouver dans de beaux draps si on l'utilise pour faire un OS car lors de l'écriture de celui-ci, le mécanisme sous-jacent n'est pas encore implémenté. Un langage qui a un vrai système de type ne peut pas les mettre en oeuvre pendant l'écriture de l'OS car idem, tout reste à implémenter.

Les langages plus récents et plus performants le sont parce qu'ils tournent sur un OS mais sans OS, directement face au processeur, les langages aussi récent soient ils se retrouvent littéralement à poils comme le langage C.

Je ne sais pas si vous voyez ce que je veux dire ?

Je pense personnellement qu'il peut y avoir pleins d'autres langages pour faire un OS mais directement face au processeur tous ces autres langages ne seront pas (ou pas beaucoup) plus armés que le C. En revanche, une fois qu'il y a un OS, il y a pléthore de langages bien plus préformant dans leur interaction avec l'OS.

[Invité]

Je ne sais pas si vous voyez ce que je veux dire ? [/I]

Pour être honnête non :
- Un langage n'a pas besoin d'un OS mais d'un "runtime system". Même le C en a un (https://en.wikipedia.org/wiki/Runtime_system#Examples).
- Il est tout à fait possible de faire un OS avec un langage à exception et à garbage collector. Il faut "juste" que ce soit dans le runtime system. Au passage, il me semble que Rust n'a pas de garbage collector ni d'exception à la try/catch.
- Rust fait du typage statique : les types sont vérifiés à la compilation. Il n'y a pas besoin de système de typage dans le runtime system.

Pour info, Redox OS fonctionne directement sur le matériel, sans passer par un OS support.
https://discourse.redox-os.org/t/run...hardware/146/8
https://doc.redox-os.org/book/overvi..._redox_is.html