Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

  1. #1
    Chroniqueur Actualités
    Avatar de Patrick Ruiz
    Homme Profil pro
    Redacteur web
    Inscrit en
    février 2017
    Messages
    820
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Cameroun

    Informations professionnelles :
    Activité : Redacteur web
    Secteur : Communication - Médias

    Informations forums :
    Inscription : février 2017
    Messages : 820
    Points : 28 080
    Points
    28 080
    Par défaut Linux : un framework pour la mise au point de drivers en langage Rust pourrait faire son entrée dans le noyau
    Linux : un framework pour la mise au point de drivers en langage Rust pourrait faire son entrée dans le noyau
    De l’OS

    Il s’agit d’une proposition d’un contributeur faite à Greg Kroah-Hartman – l’un des mainteneurs du noyau Linux engagé sur cet axe. Rien de concret pour le moment, mais il se dit qu’il est possible qu’un framework dédié à la mise au point de drivers en langage Rust soit accepté dans le noyau de l’OS open source. Pour cela, Greg Kroah-Hartman formule deux conditions : primo, ledit framework ne sera pas activé par défaut dans le cas de son intégration, ce, pour éviter que l’on n’ait besoin de Rust pour compiler le noyau ; secundo, que l’approche proposée présente de réels avantages en comparaison à ceux qui découlent de l’utilisation du langage C.

    C’est connu, le noyau Linux est le produit de développements en langages C et assembleur. Dans la filière de la mise au point de drivers pour le système d’exploitation open source, c’est encore ce tandem qui règne en maître. Les développeurs engagés sur cet axe le plébiscitent pour les énormes possibilités qu’il offre en matière de manipulation des ressources matérielles d’un système informatique. Dans le jargon du milieu, on parle de « proximité avec le hardware. » Seulement, de plus en plus de voix s’élèvent pour appeler au passage au langage Rust – l’un de ceux pressentis comme remplaçant du C sur le terrain du contrôle du matériel.

    Il y a seulement que lors du dernier Linux Security Summit, des chercheurs en sécurité ont, à côté d’autres, mis le doigt sur l’une des plus grosses tares que le langage C traîne : les problèmes liés à la gestion de la mémoire – dépassements de mémoire tampon, allocations non libérées, accès à des zones mémoire invalides ou libérées, etc. D’après les chiffres rapportés par le duo de chercheurs, 65 % des vulnérabilités du noyau Linux recensées sur les 6 derniers mois en résultent. Les chiffres du dictionnaire Common Vulnerabilities and Exposure (CVE) abordent dans le même sens : 15,9 % des 2288 vulnérabilités qui ont affecté le noyau Linux en 20 ans sont liées à des dépassements de mémoire tampon. À contrario, l’équipe de chercheurs est d’avis qu’à côté d’autres atouts, Rust offre de meilleures garanties en matière de gestion de la mémoire que le langage C.

    Nom : 1.png
Affichages : 111919
Taille : 85,5 Ko

    L’équipe de chercheurs ne s’est pas limitée à parler des avantages que le langage Rust offre en comparaison au C. Elle en a profité pour présenter une initiative relative au développement d’un framework dédié à la mise au point de drivers Linux en langage Rust. De façon brossée, l’effort consiste en la mise sur pied de wrappers vers des API du noyau Linux. Les développements visent les architectures x86, arm/arm64, mips, POWERPC, RISC-V, s390 et SPARC.

    Mais, il y a seulement que Linus Torvalds est d’avis qu’il n’y a rien de mieux que le langage C pour la programmation système.

    « 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 », a-t-il déclaré il y a 7 ans lors d’une de ses interventions à l’Intel Open source Technology Center.

    Auparavant, il a balayé d’un revers de la main des propositions similaires visant à introduire le C++ dans le cercle des langages dédiés au développement de drivers pour Linux. Il avait notamment mis en avant la possibilité de faire de l’orienté objet de façon plus propre avec le C qu’avec le C++.

    L’initiative d’Alex Gaynor & Geoffrey Thomas reste un énorme chantier sur de nombreux axes. Par exemple, l’équipe de chercheurs souligne la nécessité de poursuivre avec le développement de pilotes pour des systèmes de fichiers et pour des types d’appareils spécifiques. Faudra ensuite voir si les contenus arrivent à convaincre les mainteneurs Linux.

    Source : lwn, lss, GitHub

    Et vous ?

    Qu’en pensez-vous ?

    Êtes-vous d’accord avec cette proposition d’ouverture du noyau Linux au langage Rust pour la programmation système ?

    Le Rust peut-il remplacer le C pour la programmation système ? Est-il meilleur ?

    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
    Contribuez au club : Corrections, suggestions, critiques, ... : Contactez le service news et Rédigez des actualités

  2. #2
    Expert éminent sénior Avatar de Uther
    Homme Profil pro
    Tourneur Fraiseur
    Inscrit en
    avril 2002
    Messages
    3 885
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Pyrénées Orientales (Languedoc Roussillon)

    Informations professionnelles :
    Activité : Tourneur Fraiseur

    Informations forums :
    Inscription : avril 2002
    Messages : 3 885
    Points : 11 232
    Points
    11 232
    Par défaut
    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 »
    Cette affirmation est de moins en moins vraie avec les optimisations des compilateurs C récents (ça vaut aussi pour le Rust) qui peuvent se permetre de faire des optimisations toujours plus poussées, mais aussi plus surprenantes.

  3. #3
    Membre éprouvé
    Homme Profil pro
    Développeur
    Inscrit en
    juillet 2009
    Messages
    346
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Hauts de Seine (Île de France)

    Informations professionnelles :
    Activité : Développeur

    Informations forums :
    Inscription : juillet 2009
    Messages : 346
    Points : 1 123
    Points
    1 123
    Par défaut
    Il y a seulement que lors du dernier Linux Security Summit, des chercheurs en sécurité ont, à côté d’autres, mis le doigt sur l’une des plus grosses tares que le langage C traîne : les problèmes liés à la gestion de la mémoire – dépassements de mémoire tampon, allocations non libérées, accès à des zones mémoire invalides ou libérées, etc. D’après les chiffres rapportés par le duo de chercheurs, 65 % des vulnérabilités du noyau Linux recensées sur les 6 derniers mois en résultent. Les chiffres du dictionnaire Common Vulnerabilities and Exposure (CVE) abordent dans le même sens : 15,9 % des 2288 vulnérabilités qui ont affecté le noyau Linux en 20 ans sont liées à des dépassements de mémoire tampon. À contrario, l’équipe de chercheurs est d’avis qu’à côté d’autres atouts, Rust offre de meilleures garanties en matière de gestion de la mémoire que le langage C.
    Ça ressemble plus à une tare des programmeurs incompétents qu'à une tare du langage C. Si les mêmes programmeurs abusent des blocs "unsafe" en Rust, il y aura les mêmes problèmes.

    Perso j'aime bien Rust, à part son système de build (cargo), même si le langage a déjà aussi des défauts, mais ça me fait plaisir de le voir de plus en plus mis en avant Après je ne peux pas m'exprimer plus que ça, je ne connais pas grand chose au milieu de la programmation de drivers sous Linux.

  4. #4
    Expert éminent sénior Avatar de Uther
    Homme Profil pro
    Tourneur Fraiseur
    Inscrit en
    avril 2002
    Messages
    3 885
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Pyrénées Orientales (Languedoc Roussillon)

    Informations professionnelles :
    Activité : Tourneur Fraiseur

    Informations forums :
    Inscription : avril 2002
    Messages : 3 885
    Points : 11 232
    Points
    11 232
    Par défaut
    Ces chiffres ne viennent pas de dépot github choisis au hasard, mais de sociétés qui ont une vraie politique de sécurité et dont le code est forcément relu.
    La pratique a clairement montré que, sur des base de code un minimum complexe, on peut être certains que même les meilleurs développeurs C finiront par faire des erreurs. A partir de là dire que c'est seulement un problème des développeur incompétents, c'est se voiler la face.

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo