Discussion :

[floyer]

En gros,des tableaux sécurisés avec une notion système?

Qu’appelle tu une notion système ?

En tout cas, il y a une vérification des bornes du tableau. Soit à la compilation lorsque c’est possible, soit à l’exécution.

Par ailleurs pour des tableaux de taille variable, la taille du tableau est passé en paramètres implicite (si passé en référence).

Cela permet d’écrire

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
fn affiche(t : &[int32])
{
  for a in t.iter() {
    println("{}",a);
  }
}

Dans la mesure où Rust t'impose de savoir ce qu'il se passe avec la mémoire et que cela est une forte contrainte dans l'écriture d'un programme, je dirai plutôt que Rust est bas niveau, à l'inverse de Python qui est très permissif sur l'écriture et masque la gestion de la mémoire.

Oui, en Rust on sait assez bien comment c’est stocké en mémoire et le choix stockage sur pile, vs sur le tas est explicite. Mais il n’y a pas de malloc, memcpy… où l’on doit indiquer une taille en octets. Par exemple.

La gestion de la mémoire impose des contraintes mais garantit l’absence de déréférencement invalide. Et si on ne respecte pas les contraintes, le compilateur le dit voire propose des corrections ! Avec le C il faut s’imposer des contraintes sous peine d’avoir un programme buggué. Le compilateur laissant passer beaucoup plus de choses.

Rust est globalement de plus haut niveau, sans vraiment sacrifier les performances.

[NotABread]

Oui, en Rust on sait assez bien comment c’est stocké en mémoire et le choix stockage sur pile, vs sur le tas est explicite. Mais il n’y a pas de malloc, memcpy… où l’on doit indiquer une taille en octets. Par exemple.

La gestion de la mémoire impose des contraintes mais garantit l’absence de déréférencement invalide. Et si on ne respecte pas les contraintes, le compilateur le dit voire propose des corrections ! Avec le C il faut s’imposer des contraintes sous peine d’avoir un programme buggué. Le compilateur laissant passer beaucoup plus de choses.

Rust est globalement de plus haut niveau, sans vraiment sacrifier les performances.

Ça n'est pas tout à fait exact, il y a bien des fonction pour la gestion manuelle de la mémoire, elles sont en unsafe. Cela ne fait pas parti du code idéal Rust et je ne sais pas dans quelles circonstance on se retrouve forcé à les utiliser (surtout que pour l’interopérabilité avec le C, on utilise libc)

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
use std::alloc::{alloc, dealloc, Layout};
 
fn main() {
    unsafe {
        let layout = Layout::new::<u16>();
        let ptr = alloc(layout);
 
        *(ptr as *mut u16) = 42;
        assert_eq!(*(ptr as *mut u16), 42);
 
        dealloc(ptr, layout);
    }
}

[Uther]

Comme pour a peu prêt tout ce qu'on dit a propos de Rust, il y a une petite astérisque implicite qui dit indique "* sauf si on utilise du code unsafe".

En l’occurrence, ces fonctions ne sont normalement pas utilisées directement. Elles sont utilisées en interne par les types de base de la bibliothèque qui font des allocations sur le tas comme Vec, Box, Rc, ... A moins de vouloir remplacer ces types par des implémentations maison, on en a pas besoin.

[fdecode]

Le multithread est assez simple en Rust. Tu peux utiliser tokio pour te faciliter la vie, sinon tu as des thread que tu peux créer assez simplement, ou utiliser des coroutines (fonction marquée async).
J'ai l'impression que les coroutines restent privilégiée car la répartition de leur exécution sir les threads est faite efficacement de base.

Je ne comprends pourquoi utiliser tokio pour du multithread.
tokio te fournit un runtime pour faire de la programmation concurrente, et dans ce cadre de gérer plus de threads que n'autorise l'OS.
Mais la programmation multithread (non asynchrone) est directement accessible depuis la librairie standard.
Le fait d'être asynchrone complexifie sensiblement la programmation comparé au multithread. Et le multithread sans runtime est plus performant pour paralléliser des sections de calcul courtes:

https://stackoverflow.com/questions/...nchronous-code
Async/await does not give you any parallelism, only concurrency. That means that any sync operation using async/await to divide the work will just run one part after the other, not faster than without async/await and in fact slower because it adds overhead.

You can only get parallelism via threads, and you are limited to the number of cores you have in your system.

Some async runtimes do run the code in parallel, using multiple threads, so you will get some parallelism (and therefore speed) if you'll use them correctly; but this just adds overhead over using threads directly, or using a library such as rayon that avoids async/await and parallelizes the code using threads only.

If you're not I/O bound, don't use async/await. You have nothing to gain.

Par exemple, j'aurais plutôt tendance à utiliser rayon pour paralléliser un calcul sur une collection.

Le plus dur, c'est de satisfaire le borrow checker qui demandera que le thread/la coroutine possède ce qu'il veut modifier ou que les potentiels data race soient protégés par des types sûrs (et attention, le compilo ne protège pas du dead lock ni des goulots d'étranglement).

Au passage, les scopes permettent de faire du multithread (sans runtime) avec des références (non mutables tout au moins). Pour faire la même chose avec tokio, ... il me semblait que pour l'instant, il fallait transmuter du lifetime.

Oui en Rust les références sont de simple pointeurs bas niveau. La différence et que le compilateur surveille la façon dont ils sont utilisés et leve une erreur si leur usage est susceptible de commettre une erreur mémoire.
Rust a aussi des pointeur simples, mais ils ne sont déréférençables que sans les blocs unsafe

Pour compléter cette réponse, une référence est un pointeur avec en plus de l'information abstraite apportée par le typage pour permettre au compilateur de contrôler l'usage de la mémoire.
En C on a un exemple d'information porté par le typage, avec le mot clef restrict. En terme d'optimisation à la compilation, il produit des résultats similaires aux références de Rust.

En revanche, les pointeurs/references Rust sont des fat pointers pour les slices et les trait objects.

[Gugelhupf]

La question de ce qu'est un langage de haut niveau reste en effet nébuleuse, il n'y a pas de définition officielle

Oui il suffit de regarder les documentaires sur la création du langage C, ils le qualifient de haut niveau parce qu'ils le comparent avec l'assembleur qui est couramment utilisé à l'époque. Pour moi c'est très simple, la notion de haut niveau/bas niveau n'a rien à voir avec la complexité d'écriture ou de compréhension du code : Ton langage produit un binaire qui requiert une VM avec un système de garbage collector/ramasse-miettes ? Alors c'est un langage de haut-niveau, pour qu'un langage soit de bas niveau il doit être prédictible, on doit connaitre toutes les instructions CPU du programme à l'avance et donc sans interférence de garbage collector/ramasse-miettes

[Uther]

Oui il suffit de regarder les documentaires sur la création du langage C, ils le qualifient de haut niveau parce qu'ils le comparent avec l'assembleur qui est couramment utilisé à l'époque. Pour moi c'est très simple, la notion de haut niveau/bas niveau n'a rien à voir avec la complexité d'écriture ou de compréhension du code : Ton langage produit un binaire qui requiert une VM avec un système de garbage collector/ramasse-miettes ? Alors c'est un langage de haut-niveau, pour qu'un langage soit de bas niveau il doit être prédictible, on doit connaitre toutes les instructions CPU du programme à l'avance et donc sans interférence de garbage collector/ramasse-miettes

Le langage dont on connaît toutes les instruction, ça n'existe plus depuis au moins 30 ans, les optimiseurs moderne sont fabuleux, mais parfois sont surprenant.
Ce qu'on a de plus prédictible après l'assembleur, c'est ce qu'on appelle les langages système, dont on a une bonne idée de la façon dont est allouée la mémoire. Pas la peine d'utiliser le termes de haut et bas niveau, qui sont floue pour cela alors qu'on en a une plus précise (quoique pas parfaite non plus).

[Patrick Ruiz]

Linus Torvalds explique pourquoi la longévité des développeurs Linux est une bonne chose : « C’est un bon signe »
Lance-t-il sans répondre à la question du passage à la future génération de mainteneurs

Les principaux mainteneurs du noyau Linux sont des quinquagénaires. Certains se rapprochent même de la soixantaine. Ce sont des âges pour lesquels on est considéré dans certains pays comme étant trop vieux pour exercer dans la filière du développement de logiciels. C’est donc sans surprise que la question du passage à la future génération de mainteneurs du noyau Linux revient constamment sur la table. Très évasif sur cet aspect, Linus Torvalds signe que « c’est une bonne chose que les vieux continuent à être à la manœuvre » tout en soulignant la difficulté le potentiel impact de cet état de choses sur l’intégration des jeunes mainteneurs.

« Il peut sembler difficile d’intégrer l’équipe de mainteneurs en tant que jeune qui voit tous ces séniors encore aux commandes », reconnaît-il. C’est en toile de fond le débat sur le choix entre le langace C et le Rust pour le futur du développement du noyau qui prend un coup de neuf. En effet, les principaux mainteneurs du noyau Linux sont des habitués du langage C dont l’âge commence par le chiffre 5. Certains se rapprochent même de la soixantaine. La nouvelle génération de mainteneurs du noyau Linux semble plutôt constituée d’utilisateurs du langage Rust dont certains se plaignent déjà du traitement que leur infligent les habitués du langage C.

Les habitués du langage C n’entendent pas se laisser embarquer dans ce qu’ils appellent la nouvelle religion du Rust

Les rapports font en effet état de ce qu’un sous-ensemble de contributeurs au noyau en langage C sont déterminés à rendre la vie dure aux mainteneurs Rust. Motif : Ils considèrent que Rust n’apporte pas de plus-value significative et préfèrent donc que ce langage de programmation soit mis de côté dans le cadre du développement du kernel.

Les mainteneurs du noyau réfractaires à la mise à jour des bases de code du noyau Linux vers le langage Rust ont fait savoir quelle est leur position lors d’une présentation des systèmes de fichiers Linux et des besoins en termes de migration des bases de code vers le Rust. Il était question pour ces derniers de créer des passerelles permettant de faciliter l’atteinte de cet objectif. L'un des membres de l'auditoire a exprimé son désaccord en disant : « Vous essayez de convaincre tout le monde de passer à la religion du Rust, mais cela n’arrivera pas. »

Ces derniers multiplient donc des attitudes qui frustrent certains mainteneurs Rust qui choisissent de quitter le navire : « Ce type de traitement est exactement la raison pour laquelle j'ai entamé le projet @redox_os en partant de zéro et en l'écrivant principalement en Rust. Il y a beaucoup de résistance aux changements bénéfiques, même mineurs, dans Linux et les projets connexes. C’est la raison pour laquelle je n'essaie même plus de contribuer au noyau Linux. Il y a des projets pour lesquels vous devrez inévitablement faire passer vos changements devant des mégalomanes pédants et condescendants, et si le noyau Linux n'est pas seulement développé par ce type de personnalité, il est aussi contrôlé par lui de manière écrasante. »

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 : Linus Torvalds

Et vous ?

Quel impact le comportement des habitués du langage C est-il susceptible d’avoir sur le futur du développement du noyau Linux ?

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

[vVDB.fr]

On assiste à une rupture du même ordre de linux quand Linus c'est lancé...
Donc aujourd'hui, Linus doit suffisamment segmenter linux pour que les pans définis puissent s'écrire et fonctionner en Rust et en C et que le meilleur gagne... Il doit y avoir émulation.
Les gens ont participé à linux avec cet esprit de compétition, de faire mieux qu'un Unix propriétaire...

[floyer]

Voilà une partie très intéressante. Je reprend les chiffres donnés: 2288 en 20 ans. 2288/20 = 144,4. 15,9% de ces vulnérabilités à des problèmes lié au C (gestion mémoire, dépassement de tampons, allocation non libérées, accà des zones mémoire invalide ou libérée, etc)

15,9% de 144,4, c'est en arrondissant [B]30[/], soit 1,5 vulnéralité par an. Comparée à l'immense base de code du noyau linux, c'est particulièrement faible. Et ça n'implique certainement de changer le langage utilisé pour ce noyau.

1,5 par an cela fait peu… mais regarde :

https://www.cvedetails.com/product/4...l?vendor_id=33

645 vulnérabilité en 2024 (pas encore terminée) pour des corruptions de mémoire.

Même si cette année semble catastrophique, on est bien au delà des 1,5 par ans. (17 mini… 70 ou plus dans la plupart des années). On n’a pas les mêmes sources.

645 qui pourraient en grande partie être évité par une language plus sûr, cela fait réfléchir.

[Minato Sensei]

Les principaux mainteneurs du noyau Linux sont des quinquagénaires. Certains se rapprochent même de la soixantaine. Ce sont des âges pour lesquels on est considéré dans certains pays comme étant trop vieux pour exercer dans la filière du développement de logiciels. C’est donc sans surprise que la question du passage à la future génération de mainteneurs du noyau Linux revient constamment sur la table. Très évasif sur cet aspect, Linus Torvalds signe que « c’est une bonne chose que les vieux continuent à être à la manœuvre » tout en soulignant la difficulté le potentiel impact de cet état de choses sur l’intégration des jeunes mainteneurs

Oui mais non. En quoi ce serait une bonne chose que les « vieux continuent à être à la manœuvre » ? Avec cette philosophie on n'aurait jamais ce gamin à la tête de l'Etat (encore moins cet ancien premier ministre, tient), on se contenterait d'un « vieux à la manœuvre ». À mon avis, il serait plus logique de susciter l'intérêt des jeunes mainteneurs pour le C. Après avec l'arrivée du C++, qui lui aussi voit désormais plusieurs recommandations en faveur d'autres langages comme le Rust, est-ce qu'intéresser les jeunes au C pourrait être une chose aisée / réalisable ? À voir

[dlandelle]

Avant de se précipiter dans l'innovation il serait bon de ne pas dégrader l'existant. Les problèmes actuels de linux ne proviennent pas de là. Quand on voit passer des corrections de bug oracle dans le noyau ... Pour compenser des bugs qui le sont pas dans le noyau, c'est juste du sabotage.
Microsoft aussi "contribue" sur Linux.

[Jipété]

Et voilà comment on embrouille les gens :

Je reprend les chiffres donnés: 2288 en 20 ans. 2288/20 = 144,4.

2288 / 20 = 114,4 ! ! !
Ahurissant de constater que personne n'a remarqué ça...

Et sinon, pour tout le reste, TL;NR
Faut pas déc au nez.

[vVDB.fr]

Pourquoi n'y aurait il pas une relecture du code en C par une IA qui dirait votre code est merdeux, incompréhensible ?
Les problèmes du C sont-ils suffisamment documentés ? Documentation nécessaire pour entraîner une IA qui n'est qu'un bon automate probabiliste... On n'oublie pas qu'une IA est un truc instruit avec des biais et pas intelligent. C'est suffisant pour pas mal de contrôles.

[Uther]

Et voilà comment on embrouille les gens :

2288 / 20 = 114,4 ! ! !
Ahurissant de constater que personne n'a remarqué ça...

En même temps c'est pas bien grave, on reste dans le même ordre de grandeur.
Il y a d'autres approximations bien plus embêtantes, comme le fait que ces erreurs ne représentent qu'un partie des erreurs que peut prévenir le Rust et qu'une bonne partie de la période remonte à une époque ou les vulnérabilités mémoire étaient peu surveillées.

Ces deux dernières années le nombre de CVE remonté est énormément plus élevé et c'est en très grosse majorité des erreurs mémoire qui viennent des drivers, preuve s'il en fallait que le choix de permettre de faire des drivers en Rust est pertinent.

Pourquoi n'y aurait il pas une relecture du code en C par une IA qui dirait votre code est merdeux, incompréhensible ?
Les problèmes du C sont-ils suffisamment documentés ? Documentation nécessaire pour entraîner une IA qui n'est qu'un bon automate probabiliste... On n'oublie pas qu'une IA est un truc instruit avec des biais et pas intelligent. C'est suffisant pour pas mal de contrôles.

Il y a depuis longtemps pas mal de contrôles de plus en plus fins, par des outils divers (fuzzer, analyseurs statiques, ...) beaucoup plus efficaces que des IA de type LLM, qui ne sont absolument pas adaptées. C'est très bien pour améliorer la sécurité mais ça n'est pas une aussi bonne garantie qu'un langage qui interdit complètement les erreurs mémoires..

[floyer]

Oui, on sais depuis 1936 grâce à Alan Turing que des problèmes informatiques sont non démontrables… plus le language contraint (dans une certaine limite), plus certaines exigences de fiabilité peuvent être démontrées nativement par le compilateur.

[Jipété]

Oui, on sait depuis 1936 grâce à Alan Turing que des problèmes informatiques sont non démontrables…

J'aimerais bien voir un exemple, histoire de me coucher moins bête.

Merci,

[OuftiBoy]

1,5 par an cela fait peu… mais regarde :

https://www.cvedetails.com/product/4...l?vendor_id=33

645 vulnérabilité en 2024 (pas encore terminée) pour des corruptions de mémoire.

Même si cette année semble catastrophique, on est bien au delà des 1,5 par ans. (17 mini… 70 ou plus dans la plupart des années). On n’a pas les mêmes sources.

645 qui pourraient en grande partie être évité par une language plus sûr, cela fait réfléchir.

Oui, je suis bien d'accord. Je me suis penché un peu plus sur Rust. Mis à part la syntax (question d'habitude, rien d'insurmontable), il a incontestablement de quoi "remplacer" le "C". Pour du nouveau code, pas de soucis. Si la plus jeune génération préfère Rust, le chiffre qui m'interpelle ici, c'est pourquoi cette année est beaucoup plus "catastrophique" que les années précédentes ? Quelqu'un a-t-il une explication ?

BàT. et Peace & Love.

Et voilà comment on embrouille les gens :


2288 / 20 = 114,4 ! ! !
Ahurissant de constater que personne n'a remarqué ça...

Et sinon, pour tout le reste, TL;NR
Faut pas déc au nez.

Oui, oui, j'ai fais une erreur de calcul (faute de frappe en fait). Heureusement que tu étais là, je ne sais pas comment le monde s'en serait remit. Mais comme l'a dit Uther, ça reste dans le même ordre de grandeur.

Sauf les 2 dernières années, où sa "part" en flêche. Si tu a une explication, je serais ravi de l'entendre.

BàT et Peace & Love.

[OuftiBoy]

Il y a d'autres approximations bien plus embêtantes, comme le fait que ces erreurs ne représentent qu'un partie des erreurs que peut prévenir le Rust et qu'une bonne partie de la période remonte à une époque ou les vulnérabilités mémoire étaient peu surveillées.

Je ne parlais que de ces problèmes, car c'était le sujet. Qu'il y en ait d'autres, que Rust interdirait de faire, c'est très bien. Rust a des atouts, c'est certains, je ne le nie pas.

Ces deux dernières années le nombre de CVE remonté est énormément plus élevé et c'est en très grosse majorité des erreurs mémoire qui viennent des drivers, preuve s'il en fallait que le choix de permettre de faire des drivers en Rust est pertinent.

Sait-on pourquoi il y'a énormément plus d'erreurs qu'avant ?

BàT et Peace & Love.

[floyer]

J'aimerais bien voir un exemple, histoire de me coucher moins bête.

Merci,

En l’occurrence, il s’agit de la condition d’arrêt. Il est impossible de réaliser un programme qui vérifie si un autre s’arrête.

Un exemple simple est la conjoncture de Syracuse:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
def f(n):
   while n != 1:
      if n % 2 == 0:
         n = n/2
      else:
         n = 3*n+1

On suppose que cela s’arrête (cela s’arrête pour tous les cas testés à présent), mais on n’en sait rien.

Le programme d’Alan Turing est celui là:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
def indécidable():
  if arrêt(indécidable):
     while true:
         pass

On suppose une fonction arrêt qui analyse une autre fonction et indique si elle s’arrête ou non.

Si le programme est analysé comme s’arrêtant… il boucle sans fin (l’analyse est mauvaise), sinon il s’arrête aussitôt (l’analyse est donc aussi mauvaise).

[Uther]

Je ne parlais que de ces problèmes, car c'était le sujet. Qu'il y en ait d'autres, que Rust interdirait de faire, c'est très bien. Rust a des atouts, c'est certains, je ne le nie pas.

Le sujet général c'est l'utilisation de Rust dans le noyau pour prévenir les erreur de sûreté mémoire. Sans même parler des autres types d'erreurs que Rust peut aider à prévenir, les erreurs de dépassement tampon ne constituent qu'un cas d'erreur de sûreté mémoire. Parmi cette famille, on compte aussi les utilisations avant ou après allocation, les doubles libérations et les data race.
Ne voyez pas ça comme une accusation en malhonnêteté envers vous, le problème de base vient du texte que vous citez qui est plus un recueil désordonné de citations mal contextualisées qu'un article bien construit.

Sait-on pourquoi il y'a énormément plus d'erreurs qu'avant ?

Difficile a dire, il peu probable que Linux se soit mis a avoir plus d'erreur d'un coup, ils ont juste du changer la manière de les rapporter. On peut supposer qu'ils ont fait le choix de déclarer systématiquement des CVE pour les erreurs à risque, alors qu'auparavant ils ne le faisaient que quand ils avaient une preuve d'exploitabilité.

Les CVE ne sont pas a prendre comme un indice direct de fiabilité d'une application. Si leur existence indique manière certaine la présence de bugs, leur absence n'indique pas que le logiciel en est exempt. Certaines sociétés sont connues pour avoir très peu de CVE ce qui n'est clairement pas une marque de qualité, au contraire. C'est juste qu'elles ne déclarent rien pour les problèmes détectés en interne.