IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

Les détracteurs du Rust s'unissent autour de l'initiative Fil-C : Une implémentation sécurisée des langages C et C++
Destinée à redonner au langage C sa grandeur

Le , par Patrick Ruiz

65PARTAGES

8  0 
Le langage C est de plus en plus sujet à controverse comme en témoigne la situation tendue dans la communauté de développement du noyau Linux : les principaux mainteneurs sont des habitués du langage C et refusent de porter le code existant en C ou de passer du temps pour aider d’autres contributeurs à le porter en Rust. En toile de fond, c’est la question de savoir si le langage C a besoin d’un remplaçant dans la filière de la programmation système qui est au centre des débats. C’est la raison de l’apparition d’implémentation dites sécurisées du langage C comme Fil-C.

« Les langages de programmation C et C++ sont merveilleux. Il existe une tonne de codes écrits dans ces deux langages. Mais le C et le C++ sont des langages peu sûrs. De simples erreurs de logique peuvent amener un attaquant à contrôler la zone mémoire un pointeur et ce qui y est écrit, ce qui ouvre la voie à une exploitation facile. Beaucoup d'autres langages (Rust, Java, etc.) n'ont pas ce problème ! Mais j'aime le C. Et j'aime presque autant le C++. J'ai grandi avec eux. C'est une telle joie pour moi de d'utiliser les deux ! C'est pourquoi, pendant mon temps libre, j'ai décidé de créer mes propres langages C et C++ à mémoire sécurisée. Il s'agit d'un projet personnel et d'une expression de mon amour pour le C. Fil-C introduit la sécurité de la mémoire au cœur du C et du C++ », souligne Filip Pizlo de Epic Games.

« Le projet vise une compatibilité à 100 % avec C et C++. Il suffit de compiler son code avec le compilateur pour obtenir du code sécurisé », d’après Pizlo. Ce dernier reconnaît néanmoins que « le principal obstacle à l'utilisation de Fil-C en production est la vitesse. Fil-C est actuellement environ 1,5 à 5 fois plus lent que le C traditionnel. »


L’initiative fait surface dans un contexte de multiplications des appels au passage à des langages de programmation dits sécurisés et Rust s’impose au point d’être adopté pour lé développement du noyau Linux

Linus Torvalds lui-même est pourtant d’avis que le langage Rust est une solution d’avenir pour le développement du noyau. Il considère la prise en charge de Rust pour le développement du noyau Linux comme une « une étape importante vers la capacité d'écrire les pilotes dans un langage plus sûr. » Rust de Mozilla Research est le type de langage de programmation auquel ceux qui écrivent du code pour des systèmes d’entrée/sortie de base (BIOS), des chargeurs d’amorce, des systèmes d’exploitation, etc. portent un intérêt. D’avis d’observateurs avertis, c’est le futur de la programmation système en lieu et place du langage C. En effet, des experts sont d’avis qu’il offre de meilleures garanties de sécurisation des logiciels que le couple C/C++. Chez AWS on précise que choisir Rust pour ses projets de développement c’est ajouter l’efficacité énergétique et la performance d’exécution du C à l’atout sécurité.

En effet, il y a une liste de griefs qui reviennent à l’encontre du langage C : 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 du dictionnaire Common Vulnerabilities and Exposure (CVE), 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.

De plus, certains benchmarks suggèrent que les applications Rust sont plus rapides que leurs équivalents en langage C. Et c’est justement pour ces atouts que sont la parité en termes de vitesse d’exécution en comparaison avec le C, mais surtout pour la sécurisation et la fiabilité que de plus en plus d’acteurs de la filière du développement informatique recommandent le Rust plutôt que le C ou le C++.

Ainsi, en adoptant Rust, la communauté autour du noyau Linux devrait mettre à profit ces atouts du langage sur le C. Et elle devrait faire d’une pierre deux coups étant donné que Rust peut faciliter l’arrivée de nouveaux contributeurs. C’est en tout cas ce que laisse entrevoir une étude de l’université de Waterloo.

Source : GitHub du projet

Et vous ?

Que pensez-vous de cette multiplication d’implémentations dites sécurisées du langage C ?
Pourquoi le langage C pourrait encore avoir de longues années devant lui ? Simple résistance au changement ?
Le C a-t-il vraiment besoin d’un remplaçant en matière de programmation système ?
Le problème avec le C n’est-il pas plutôt le mauvais usage que certains développeurs en font ?

Voir aussi :

Programmation : une étude révèle les langages les plus voraces en énergie, Perl, Python et Ruby en tête, C, Rust et C++, les langages les plus verts

Linus Torvalds souligne une bonne avancée du langage Rust dans le développement du noyau Linux, et aurait qualifié le C++ de « langage de m... », après le message de Google

Microsoft, Google, AWS, Huawei et Mozilla s'associent pour créer la Fondation Rust, une organisation à but non lucratif chargée de gérer le langage de programmation

Facebook rejoint AWS, Huawei, Google, Microsoft et Mozilla dans la Fondation Rust, et renforce son équipe Rust par des nouveaux talents

Une erreur dans cette actualité ? Signalez-nous-la !

Avatar de NotABread
Membre actif https://www.developpez.com
Le 18/11/2024 à 17:23
Citation Envoyé par vivid Voir le message
A toujours être assister on perd en compétence ! çà c'est un paradigme
[Troll]
Tu as raison, les IDE avec leurs suggestions automatiques et leur autres fioritures, les smart pointer, les class, les struct, les bibliothèques, les compilateurs et les éditeurs de lien... Que d'éléments qui nous obscurcissent de la vrai connaissance de la programmation ! Les vrais dev, eux ils font tout en assembleur et leur programmes marchent sans problème quelque soit l'ordinateur ou le temps
[/Troll]

Il faut savoir où mettre son cheval de bataille. Le temps passer à s'assurer que toutes les possibilités soient correctement traiter est de la productivité de perdu. Si l'on peut gagner en productivité et en stabilité tout en conservant les performances, pourquoi devrions refuser d'être assister ? Pour la beauté du geste ?
Attention, je ne dis pas qu'il ne faut pas savoir comment ça marche derrière, rien n'est magique et l'obscurantisme mènent à la dépendance. Je dis juste que rejeter toute assistance est idiot. Si le borrow checker de Rust me dit qu'il y a un risque d'un double emprunt, c'est pas lui qui à mal compris mon code, c'est moi qui n'a pas vu le cas où ça pourrait si produire. L'humain aussi assidu puisse t-il être ne sera jamais infaillible. Avoir l'assistance d'un programme l'aide à éviter des erreurs
8  1 
Avatar de vivid
Membre habitué https://www.developpez.com
Le 18/11/2024 à 11:13
A toujours être assister on perd en compétence ! çà c'est un paradigme
7  4 
Avatar de floyer
Membre éclairé https://www.developpez.com
Le 18/11/2024 à 22:29
Citation Envoyé par vivid Voir le message
A toujours être assister on perd en compétence ! çà c'est un paradigme
Rassure toi, les règles d'emprunt, et les manières de faire avec de Rust nécessitent des compétences. Même si le compilateur est assez didactique dans son assistance.

Citation Envoyé par NotABread Voir le message
Je ne suis pas contre, on a plusieurs idée explorée tel que "rustiser" C++ (je n'ai plus le nom du projet), ici ajouter un GC et des bound check ou encore (je ne suis pas vraiment sûr de ça) ajouter une notion d'ownership avec Zig. Peut-être que qu'une idée novatrice s'imposera, ou peut être que l'on aura un énième langage. La plus grosse contrainte est la compatibilité avec l'existant et je ne pense pas qu'il y a de solution miracle.
Mais est-ce vraiment nécessaire de multiplier à outrance les langages ? L'intérêt d'un langage est aujourd'hui autant dans les qualités intrinsèques que dans l'écosystème autour (à commencer pour le côté batteries included). Le côté révélateur est marqué par les gestionnaires de packages qui permettent une fluidité dans l'accès à cet écosystème (Pip pour Python, Maven pour Java, Nuget pour C#, Cargo pour Rust, vcpkg pour C/C++/MSVC, Opam pour OCaml, Alire pour Ada, etc...).

Actuellement, on a des langages évolués, mais néanmoins avec des implémentations proches du matériels (Rust, Ada, Zig, D...). Ada est peut-être un des rares langages avec des types entiers bornés (comme range 1..10). L'avantage est que si une variable a ce type, inutile de tester les limites d'un tableaux de type array (range 1..10) of Integer. Un for I in Tableau'Range loop Tableau(I) := Tableau(I)*2; end loop; peut être compilé sans aucune vérification de bornes (sauf le *2... si on dépasse la capacité des Integer !! NB: Il y a des types sans vérifications de bornes), mais aussi sans aucun risque de sécurité. Par ailleurs, il existe des langages moins proches du matériels utilisés aussi dans des applications similaires (le projet MirageOS vise à proposer un Unikernel en OCaml).

Quand à ajouter à C/C++ un GC et des bound check, c'est peut-être ce qui est fait avec C# dans une certaine mesure. (Même si l'arithmétique des pointeurs y est autorisé uniquement pour des blocs unsafe).
1  0 
Avatar de floyer
Membre éclairé https://www.developpez.com
Le 26/11/2024 à 4:43
Pourquoi parler d’obsession alors que le problème des accès mémoire est une cause importante de CVE ? (Cf https://www.cvedetails.com/product/47/Linux-Linux-Kernel.html?vendor_id=33)

Et si, cela a voir avec le langage. En Rust accéder au 10ème éléments d’un tableau de 5 cause une exception alors qu’en C, tu auras des effets de bord (en lecture, l’attaquant peut obtenir des informations confidentielles, en écriture, provoquer un comportement inattendu). Le dernier bug de Crowdstrike est un exemple.
Je ne vois pas où tu veux en venir avec l’OS et la mémoire physique. La question n’est pas de savoir si on accède à de la mémoire physique in fine (forcément…) mais si on accède aux zones prévues. Si tu as un tampon de 64 caractères pour un mot de passe, une implémentation naïve écrasera de manière inattendue les variables après dès que tu envoies un mot de passe plus long.

Et oui, comme la plupart des programmes complexe Python n’est pas exempt de bug, mais ce logiciel est plus éprouvé que beaucoup de projet (plus de contributeurs). Si bien que tu peux tout de même gagner à utiliser Python là où il est adéquat. Nb : en Python, range(10) compte aussi de 0 à 9… ce sont plutôt des langage comme Ada ou Pascal où tu comptes jusqu’à la borne sup incluse… (le mieux étant les langages fonctionnels où des fonctions comme map te dispensent de compter. Python permet d’écrire [x*2 for x in l], ce qui dispense d’expliciter une boucle sur les indices de la liste l. En Ada, on écrirait la boucle comme for i in Table’Range loop … ce qui laisse peu de risque d’erreur. Pareil en Rust : for &x in tableau.iter() { …}).

Et sinon, Rust est aussi conçu pour limiter les bug liés à la programmation concurrente (race condition…)
1  0 
Avatar de Fagus
Membre expert https://www.developpez.com
Le 18/11/2024 à 10:50
C'est une compilation avec des bound checks et un garbage collector. Ça va pas plaire à tout le monde. En plus il faut modifier un peu les sources.
0  0 
Avatar de NotABread
Membre actif https://www.developpez.com
Le 18/11/2024 à 11:46
Que pensez-vous de cette multiplication d’implémentations dites sécurisées du langage C ?
Je ne suis pas contre, on a plusieurs idée explorée tel que "rustiser" C++ (je n'ai plus le nom du projet), ici ajouter un GC et des bound check ou encore (je ne suis pas vraiment sûr de ça) ajouter une notion d'ownership avec Zig. Peut-être que qu'une idée novatrice s'imposera, ou peut être que l'on aura un énième langage. La plus grosse contrainte est la compatibilité avec l'existant et je ne pense pas qu'il y a de solution miracle.

Pourquoi le langage C pourrait encore avoir de longues années devant lui ? Simple résistance au changement ?
Tout simplement parce qu'il y a une énorme base de code en C, tout transcripter en un langage à mémoire sûre demandera beaucoup de temps donc d'argent. Ajoutons aussi que la simplicité de C permet aussi d'écrire "facilement" un compilateur pour une plateforme personnalisée. C ne nous quittera pas de sitôt n'en déplaise à ses détracteurs.

Le C a-t-il vraiment besoin d’un remplaçant en matière de programmation système ?
Je dirai que oui, les cyberattaques sont de plus en plus sophistiquées, une petite erreur simple peut permettre un contrôle à distance et garantir qu'une énorme base de code sera 100% safe demande un temps monstrueux (amusez à faire de la preuve formelle avec coq sur absolument tout un programme, je suis presque sûr que ça sera plus long que de réécrire le code en un langage à mémoire sûre). On peut aussi compter le temps perdu pour débugguer un problème mémoire.
Ce n'est que mon avis, mais il faut un langage à mémoire sûr qui ne sacrifie pas significativement les performances. D'une part, cela garanti une absence de type de faille de facto, d'autre part, cela améliorera la productivité et permettra de se focaliser plus sur les aspects de logique et moins sur de la technique.

Le problème avec le C n’est-il pas plutôt le mauvais usage que certains développeurs en font ?
Est-ce de la faute du développeur de ne pas avoir prévu tous les cas possible et impossible ? Est-ce de la faute du manager d'avoir mit une deadline qui a réduit les campagnes de test ? Est-ce la faute de ces grandes entreprises qui font des bénéfices énormes sur les communautés libre et open source sans pour autant investir dans celle-ci pour améliorer le code ? Est-ce la faute du langage qui permet de se tire une balle dans le pied ?
La réponse est: un langage, c'est un choix technique et comme tout choix technique il y a des avantages et des inconvénients. Choisir le C c'est avoir de très bonne performance au prix de devoir gérer la mémoire soit même et les risque accrus d'un plantage ou de faille de sécurité. Je ne blâmerais ni les dev, ni le langage si leur programme plante tous les vendredi 13, soir de pleine lune lorsque tous les astres du systèmes solaires sont alignés.
0  0 
Avatar de NotABread
Membre actif https://www.developpez.com
Le 19/11/2024 à 14:56
Citation Envoyé par floyer Voir le message
Mais est-ce vraiment nécessaire de multiplier à outrance les langages ? L'intérêt d'un langage est aujourd'hui autant dans les qualités intrinsèques que dans l'écosystème autour (à commencer pour le côté batteries included). Le côté révélateur est marqué par les gestionnaires de packages qui permettent une fluidité dans l'accès à cet écosystème (Pip pour Python, Maven pour Java, Nuget pour C#, Cargo pour Rust, vcpkg pour C/C++/MSVC, Opam pour OCaml, Alire pour Ada, etc...).
J'ai envie de dire oui et non. Non car multiplier le nombre de langage disperse des ressources qui pourrait être mutualiser pour faire un bon langage plutôt que 20 moyen ou expérimentale. Oui car ces nouveaux langages ou extensions de langage cherche à répondre à un problème qui n'a pas de solution satisfaisante (ou pas totalement), et c'est source d'innovation. Certaines initiatives cherchent même à conserver l'accès à l'écosystème déjà établi (il me semble que les travaux visant à faire un C++ sûr ont toujours garder une compatibilité avec le C++ standard).
0  0 
Avatar de floyer
Membre éclairé https://www.developpez.com
Le 19/11/2024 à 22:55
Oui… quand je vois que Java a mis 8 ans (1996-2004) pour intégrer les génériques. Avec C# c’est arrivé plus tard encore (2005 mais leur V1 date de 2003)… fonctionnalités de ML (typage Hindley-Milner en 1978), reprise dans Ada (1983)… ainsi, je veux bien croire et espérer que chaque language essaye de se démarquer en ajoutant un truc en plus, mais à réinventer la roue, on peine parfois à se mettre à l’état de l’art pour lequel la barre est de plus en plus haute. Sauf à avoir une bonne expertise (ce qui me semble le cas de ceux qui ont fait Rust).

Ça dépend aussi de la portée du langage. Haskell avec son côté purement fonctionnel et paresseux se démarque franchement et ouvre une voie de recherche.

Après, il y a des langages (et implémentations) construites pour utiliser leur écosystème (Ada avec C qui a des pragma dédiés et standards, les langages des VM .Net et JVM…). D’autres nécessitent des bindings en C (JNI avec JVM…).

Pour C++, une bibliothèque STL alternative est peut-être le plus simple (de mémoire, Stroutstrup semblait dans un de ses livres mettre en avant les vecteurs que les tableaux).

Par ailleurs, supprimer l’arithmétique des pointeurs au C++, mettre un GC et cela commence à ressembler à C#.
0  0 
Avatar de floyer
Membre éclairé https://www.developpez.com
Le 26/11/2024 à 0:07
Le Pascal a tout de même beaucoup de limitations qui sont compensés dans l’implémentation de Delphi qui supporte entre autres l’objet et les génériques. On est alors assez loin du langage de Niklaus Wirth. C’est presque un Ada avec une autre syntaxe un peu proche, même s’il reste beaucoup de différences.

Ada est très novateur avec les tâches/rendez-vous et génériques dès 1983, puis l’objet en 1995. D’ailleurs les tableaux Delphi ressemblent aux tableaux Ada en ce sens qu’il incluent leurs bornes (on peut écrire High(Array) pour obtenir la borne max, comme un Array’Last en Ada. C’est une différence majeure avec C/C++ (les tableaux passés en paramètre sont de simples pointeurs qui obligent à passer en plus des tailles comme avec strncmp, strncpy… évidemment en C++, on pourrait préférer les vector)

Le côté embêtant en Ada est la gestion des caractères… pour avoir un tableau de chaînes de caractères de tailles différentes, il faut les convertir en Unbounded_String ce qui alourdi les choses. C’est plus pratique en Delphi.

Là où Rust se distingue de Delphi et Ada est l’introduction de la programmation fonctionnelle. Typiquement : words.iter().map(|&s| s.to_uppercase()).collect() cela peut être assez puissant. C’est le genre de chose introduite avec les stream Java 8. Bon Delphi supporte les fonctions anonymes (lambda fonctions) mais c’est plus lourd et il ne me semble pas qu’il y ait les fonctions usuelles (map, filter…) même si on peut les réimplémenter. Rust désalloue automatiquement les objets du tas, là où c’est manuel en Delphi et Ada. Rust et probablement Delphi supportent les closures, pas Ada.
0  0 
Avatar de djm44
Membre régulier https://www.developpez.com
Le 25/11/2024 à 23:17
J'ai écrit plusieurs applications en C et en C++ qui ont passé tous les test de vérifications avec succès. Aucune fuite et toute la salade avancées par les amateurs de Rust. Mais comme ces applications sont écrites en C et C++ et non en Rust elles sont donc dangereuses quoi qu'elles fassent. L'aspect sécuritaire du Rust n'est qu'un détail qui ne peut pas remplacer le C ou le C++. D'ailleurs pourquoi pas Ada ou Pascal ? Là aussi ce sont des langages pourris comme le C et le C++ ?
0  1