Cybersécurité et open source : l’électrochoc Heartbleed « n’a pas changé grand chose »

Cybersécurité et open source : l’électrochoc Heartbleed « n’a pas changé grand chose »

Sept ans plus tard, les mêmes travers

Avatar de l'auteur
Sébastien Gavois

Publié dans

Internet

20/10/2021 10 minutes
38

Cybersécurité et open source : l’électrochoc Heartbleed « n’a pas changé grand chose »

Pendant le salon B.Boost de La Rochelle – consacré aux logiciels libres et à l’open source –, plusieurs conférences parlaient de cybersécurité. Plus de sept ans après le douloureux épisode Heartbleed d’OpenSSL, nous avons cherché à savoir si les mentalités avaient changé.

Dans le monde actuel, les cyberattaques se multiplient à vitesse grand V ; toutes les entreprises et les institutions sont concernées ou le seront un jour, ce n’est qu’une question de temps. Pour Henri Verdier, ambassadeur pour les affaires numériques, « la prochaine guerre mondiale commencera par une attaque cyber ».

Il faut évidemment espérer que l’on n’en arrivera jamais là, mais il faut tout de même prendre cette menace au sérieux. L’open source est une approche intéressante, car « les failles sont plus faciles à détecter quand vous ouvrez le code : tout le monde peut regarder, alors que si vous avez un code fermé il n’y a en gros que les méchants qui peuvent regarder », expliquait un intervenant. Ce n’est malgré tout pas un gage de sécurité absolu, loin de là.

Surveiller les tiers de confiance

Olivier Grall, délégué sécurité numérique de l’ANSSI dans la région Nouvelle-Aquitaine, commence par quelques rappels salutaires : « vos données vous les stockez chez des tiers de confiance et vous partez du principe qu’ils en assurent la sécurité »… Mais est-ce toujours le cas ? Non, d’autant qu’il y a la notion de confidentialité et celle de pérennité comme certains l’ont découvert avec perte et fracas suite à l’incendie d’OVHcloud au début de l’année.

Ainsi, « vous n’avez pas de visibilité sur qui opère les données et ce qu’ils en font, qu’ils soient français ou étrangers ». Olivier Grall cite l’exemple d’un responsable financier d’une très grande société « qui a mis en vente la base de données intégrale de ses clients sur le darkweb pour se faire un peu d’argent (20 000 euros) ». Il n’y a donc pas besoin d’une cyberattaque ou de passer par un service étranger pour mettre en danger ses données.

Heartbleed : un gros coup de tonnerre… pour rien ?

Lancelot Pecquet, maître de conférences à l’université de Poitiers, est revenu sur la faille Heartbleed d’OpenSSL qui a tant fait parler d’elle en avril 2014, car elle permettait de récupérer des données telles que des mots de passe et des numéros de cartes bancaires. L’histoire derrière cette brèche, les questions qu’elle soulève et les leçons qui en ont été tirées sont intéressantes à analyser.

Comme nous avons déjà eu l’occasion de le rappeler à maintes reprises, « ce n’est pas parce que c’est open source et qu’on peut voir le code qu’on peut voir la faille ». Parfois elle est compliquée à trouver, alors que dans d’autres cas elle est cachée intentionnellement. Avec Heartbleed, se pose la question de la découverte de la faille, faite simultanément par deux organismes : Google et la société finlandaise Codenomicon.

Pour que cette dualité existe, c’est soit le fruit du hasard, soit des experts des deux entités ont repéré un élément suspect quelque part sur Internet et ils ont creusé. Cette thèse, évoquée par plusieurs personnes sur le salon, apporte de l’eau au moulin de ceux qui pensent que la NSA était au courant et exploitait cette vulnérabilité.

B.Boost

Une autre question est de savoir si cette faille a été ajoutée par « malchance » ou malveillance. Il y a eu « de forts soupçons sur le fait que Robin Seggelmann et le code reviewer Stephen Henson auraient été de mèche et influencés par des agences pour permettre que ce code soit diffusé ».

Néanmoins, « ce qui ressort de l’enquête c’est que c’est une erreur et que ça arrive ». Nous demandons à Lancelot Pecquet si cet « électrochoc » Heartbleed a fait bouger les choses dans la durée : « mon impression et mon observation : ça n’a pas changé grand-chose […] car les gens sont très pressés de sortir la nouvelle fonctionnalité ».

Il y a bien eu la Core Infrastructure Initiative (CII) de la Linux Foundation pour financer les projets libres et open-sources (lancée suite à Heartbleed), mais cela ne change finalement pas le problème de fond et ne semble pas avoir franchement fait évoluer la situation. Il regrette que, bien souvent, il n’y ait « pas de vision architecture et stratégique de l’ensemble des composants ». De plus : « vu la pression sur les calendriers, je ne vois pas très bien ce qui aurait pu changer cela, à moins d‘avoir une vision stratégique ».

On serait ainsi « toujours dans quelque chose d’assez opportuniste [et] on va copier-coller le truc qui marche ». Le problème étant que cette technique du copier-coller est « aussi un truc qui marche chez les étudiants » dont ils usent (et abusent ?) durant leur apprentissage. Ils peuvent donc avoir tendance à le reproduire. 

« Réinventer sa crypto c’est le meilleur moyen de se planter »

Nous avons profité d’une autre table ronde pour poser cette même question de l’électrochoc Heartbleed à plusieurs experts. Nous espérions une réponse du représentant de l’ANSSI, mais il a préféré botter en touche et passer le relai à Thierry Leblond, cofondateur et président de Scille, une société spécialisée dans le développement de progiciels qui propose des solutions zero trust pour le stockage des données.

Celui-ci reconnait que, bien évidemment, son entreprise signalera (et corrigera) des failles identifiées dans des solutions open source qu’elle utilise, mais qu’elle ne « fait pas la revue complète » des bibliothèques. Il vante néanmoins les louanges de l’open source :

« Si on va réinventer sa crypto, c’est le meilleur moyen de se planter parce que la crypto c’est la confiance qui s’est construite au fil du temps . Aujourd’hui il y a d’excellentes bibliothèques crypto qui font le taf. »

Les faces sombres de l’open source

Il n’en reste pas moins que, selon Pecquet, l'affaire Heartbleed relance la question « de l’instrumentalisation de l’open source […] Au-delà d’erreurs, il y a clairement des tentatives de manipulation du code source », affirme-t-il. Des développeurs sont ainsi approchés… plus ou moins discrètement et sur un timing plus ou moins long. 

Sur des solutions open source très utilisées, ces tentatives peuvent commencer par des contributions de développeurs, qui peuvent ensuite dériver doucement vers un comportement suspect à un moment donné, en essayant de pousser des modifications qui les arrangent. N’allez pas croire que c’est ponctuel : « on peut observer que ça existe régulièrement », affirme le professeur.

La question qu’il soulève est de savoir « quelles sont les intentions des personnes qui font ça ?  » Si dans certains cas elles peuvent paraitre obscures (la cible est peut-être une autre application qui utilise cette brique technologique), dans d’autres cas c’est évident. Il donne un exemple qui n’était pas des plus discrets : la « tentative de piratage du compte de Gentoo sur lequel est basé CLIP OS, le système développé par l’ANSSI ».

Le principe même de l’open source est de proposer du code qui peut être utilisé et réutilisé, mais il faut prendre en compte qu’il n’est pas forcément toujours maintenu avec rigueur. 

B.Boost

Une étude est mise en avant durant la conférence : « on a annoncé à des développeurs de 117 projets GitHub qu’il y avait un problème dans leur code public ». Résultat des courses : « il n’y en a que 15 qui ont répondu. La plupart ont dit "oui tant pis c’est pas grave je bouge pas", ou "ce n’est pas très grave" ».

« Ça pose cette question de la conscience que peut avoir cette communauté de développeurs et de l’enjeu que peut avoir la mise à disposition de code qui possède des vulnérabilités et de ne pas agir face à cette découverte ». De l’autre côté du spectre, les développeurs qui réutilisent ces codes doivent aussi être conscients des risques.

Un autre problème tient parfois au fait que ce ne sont pas les bibliothèques qui sont utilisées, mais juste des copier-coller. Même si le développeur met à jour son dépôt, il faut alors récupérer les lignes de codes. Ces sujets sont évidemment connus depuis longtemps, mais pas suffisamment pris en compte par certains acteurs et les choses ne bougent pas vraiment, explique Lancelot Pecquet. 

Les attaques sur les solutions open source peuvent aussi passer par les réseaux sociaux, qui sont largement utilisés par les services de renseignements pour cibler des utilisateurs à « haute valeur ». Cela peut passer par de faux comptes – par exemple une jeune et belle personne – qui approchent des cibles afin de récupérer des informations pour préparer une cyberattaque.

Le but peut aussi être de les « tamponner ». Pour le professeur cette notion renvoie à « la capacité qu’un service peut avoir de vous faire faire ce qu’il a envie ». Ces problématiques seraient « souvent pas connu, parfois abordé avec un sourire comme une légende », alors que « c’est typiquement le genre d’attaque qui pourrait avoir des conséquences significatives sur la vie d’un projet open source ».

Autre exemple : un nombre significatif de développeurs de haut niveau participent à un projet open source avec « comme objectif de créer la discorde au sein de la communauté, de telle sorte que le projet forke et qu’on se retrouve à recréer un produit à côté ». Les « frondeurs » en profitent alors pour avoir davantage la mainmise sur le projet et les changements à y apporter. De loin cela apparaitrait comme une énième dispute au sein d’un projet open source, comme il en arrive régulièrement, et permettrait de cacher les intentions réelles.

Les motivations pourraient être d’introduire une porte dérobée, d’affaiblir le chiffrement, etc. « Peut être que ce type d’attaque a eu lieu ou pourrait avoir lieu, mais je ne suis pas sur que les gens soient sensibilisés ».

B.Boost B.Boost

WSL : Linux devient une « feature » dans Windows

Il donne enfin l’exemple d’une « manœuvre efficace dans la communauté open source » : Microsoft avec son WSL (Windows Subsystem for Linux). Libriste dans l’âme, Lancelot Pecquet ne voit pas cela d’un bon œil et dépeint « une opération stratégique d’encerclement qui consiste à faire entrer Linux dans Windows comme une '"feature"  ».

Suite au lancement de cette fonctionnalité, il affirme avoir déjà eu des questions du genre : « Pourquoi veux-tu booter sous Linux puisque maintenant on a WSL ? ». « Des gens ont été convaincus par le discours idéologique de Microsoft […] Ils veulent qu‘on croie qu’ils aiment Linux… et ça marche ».

Ce mouvement visible de Microsoft ne serait que la face visible de l’iceberg. D’autres « manœuvres » du genre pourraient se produire à d’autre niveau sur de petites briques qui sont ensuite réutilisées par de grands systèmes, sans forcément saisir tous les enjeux. Là encore, xkcd à un dessin qui résume bien la situation et les risques :

xkcd dependency
Crédits : xkcd
38

Écrit par Sébastien Gavois

Tiens, en parlant de ça :

Sommaire de l'article

Introduction

Surveiller les tiers de confiance

Heartbleed : un gros coup de tonnerre… pour rien ?

« Réinventer sa crypto c’est le meilleur moyen de se planter »

Les faces sombres de l’open source

WSL : Linux devient une « feature » dans Windows

Le brief de ce matin n'est pas encore là

Partez acheter vos croissants
Et faites chauffer votre bouilloire,
Le brief arrive dans un instant,
Tout frais du matin, gardez espoir.

Commentaires (38)



Un autre problème tient parfois au fait que ce ne sont pas les bibliothèques qui sont utilisées, mais juste des copier-coller.




Et ne parlons pas des applications snaps, Appimage dont c’est le principe de faire une copie de toutes les bibliothèques utilisées.


C’est vraiment passionnant tous ces échanges, merci à l’équipe pour l’article!



Soriatane a dit:


Et ne parlons pas des applications snaps, Appimage dont c’est le principe de faire une copie de toutes les bibliothèques utilisées.




oui ou les très gros projet “tousse” Discord “tousse” qui utilise des librairie a plusieurs version de retard pour évité les mises a jours qui nécessite une version de node plus récente etc qui fini par se retrouvé dépassé et qui échoue a sortie une version ARM une année après la sortie des pc ARM d’apple.



Si on commençais par formé / punir les entreprises qui subissent une bêche dans leur système lorsqu’elle est du a un défaut de mises a jours, ca pousserai déjà la sécurité vers le haut.



Ca plus assisté les projet open source (au lieu d’injecté des gigatone de pognon dans des projet mort #Qwant), ca ferait avancer le schmilblick.


+2000



Les entreprises et dirigeants ont l’air de croire que l’oss se maintient par l’opération du saint esprit… mais c’est oublier le temps perso passé dessus.


Les SNAP permettent plus de sécurité grâce à l’isolement (avec comme inconvénient de prendre plus de place)



Soriatane a dit:


Et ne parlons pas des applications snaps, Appimage dont c’est le principe de faire une copie de toutes les bibliothèques utilisées.




T’as oublié ce cher Docker…



Isolation ne veut pas dire être à l’abri des failles et une appli plombée a quand même souvent accès à des choses (données perso), et cela fait aussi un point d’entrée pour attaquer le système “hôte” : faille Docker, Kubernetes, vSphere…


quand je vois que stackoverflow, c’est typiquement un site dont les threads les plus influents comportent tjs en tête de gondole, la solution la plus pertinentée considérée comme le choix le plus efficace.
Et ce choix qu’on accepte d’une manière un peu «hypnopédique» (j’entend par là sous le niveau de conscience à cause de son pedigree impeccable que les pouces verts ne tendent qu’a renforcer) va être copier/coller dans des SI diverses et constituer des failles en nombre



Je réagis de cette façon et en citant Stackoverflow à cause de son rachat chinois assez récent : https://www.blogdumoderateur.com/stack-overflow-rachat-prosus/
Et les potentialités décuplées que pourront en faire les usines à troll


Prosus c’est néerlandais il me semble. :D
Et je crois qu’ils possèdent 29% de Tencent, mais sans droit de vote.


Selon moi, ça n’a pas beaucoup changé pour la simple raison que les décideurs ne sont pas, en majorité, des gens du milieu info/sécu. Prenez un décisionnaire (administratif, financier…) et demander lui de parler d’HeartBleed, Spectre/Meltdown ou autre ? Vous allez rigoler, promis.



Leur boulot est de faire tourner une entreprise. La sécurité a toujours un coût négatif à court et long terme pour eux. En outre, les compétences qu’ils faut pour bien coder nécessite du temps, des gens qualifiés et de l’argent… Bref, c’est pas rentable. (Qui veut payer pour OpenSSL quand c’est gratuit ?)



Pour changer les mentalités il faudrait que la sécurité ne soit plus vu comme un coût négatif mais un investissement à court et long terme, et des lois punissant (et appliqué) sans vergogne les plus graves manquement à la sécurité.
Une autre solution serait d’avoir un fond national (ou UE) qui investit des moyens (argent, personnel) sur des projets jugés “vitaux” pour celle-ci et qui viserait à entrenir/maintenir/évoluer les projets Open-Sources sélectionnés.


Quelqu’un a-t-il été ou peut-il être condamné pour tentative (réussie ou non) de sabotage, d’introduction de faille etc. dans un projet open-source ? En gros que risque-t-on à tenter ?



SIaelrod a dit:


oui ou les très gros projet “tousse” Discord “tousse” qui utilise des librairie a plusieurs version de retard pour évité les mises a jours qui nécessite une version de node plus récente etc qui fini par se retrouvé dépassé et qui échoue a sortie une version ARM une année après la sortie des pc ARM d’apple.



Si on commençais par formé / punir les entreprises qui subissent une bêche dans leur système lorsqu’elle est du a un défaut de mises a jours, ca pousserai déjà la sécurité vers le haut.



Ca plus assisté les projet open source (au lieu d’injecté des gigatone de pognon dans des projet mort #Qwant), ca ferait avancer le schmilblick.




Node est une purge à faire évoluer. Mon projet est tjs en 12.16. La moindre tentative de mettre à jour une des bibliothèques casse le code, le schéma dans l’article est représentatif, pour une bibliothèque que l’on importe, des dizaines sont ajoutées et mises à jour, aucun développeur de bibliothèque open source ne respecte le “save exact”.
Sur un sprint de 3 semaines, on n’a pas le temps, et de ttes façon, le client s’en bats les brouettes, l’important c’est que ça fonctionne. On a une superbe chaine CI, avec du Node scan, du sonar, du trivy et au final, on a désactivé tout ça, sinon on passe le sprint à ne faire que de la gestion de màj.



spidermoon a dit:


Node est une purge à faire évoluer. Mon projet est tjs en 12.16. La moindre tentative de mettre à jour une des bibliothèques casse le code, le schéma dans l’article est représentatif, pour une bibliothèque que l’on importe, des dizaines sont ajoutées et mises à jour, aucun développeur de bibliothèque open source ne respecte le “save exact”. Sur un sprint de 3 semaines, on n’a pas le temps, et de ttes façon, le client s’en bats les brouettes, l’important c’est que ça fonctionne. On a une superbe chaine CI, avec du Node scan, du sonar, du trivy et au final, on a désactivé tout ça, sinon on passe le sprint à ne faire que de la gestion de màj.




Je veux bien que les dev petit et moyen on du mal, mais la on parle de discord, les grosse infra c’est inadmissible.



Dans mon cas a la ou j’ai fait mon stage y’a des années ils ont commencé la migration vers node, vu que ca cassait tous a chaque version et sont revenu a du code en natif pour chaque OS.



gg40 a dit:


Ultra flippant …




Ce qui est surtout flippant c’est que j’ai pu trouver un exploit de cette faille en moins de 2 minutes de recherche sur google. Et que 5 minutes plus tard je pouvais l’exploiter alors que je n’avais jamais touché le langage python.



Quand j’y repense… Maintenant que je gère en python j’aurais pu me coder un ui + gros script en quelques heures et pomper non stop de la data sur tout un tas de site pour y trouver des informations croustillantes.



Je pense que mettre à jours des choses c’est plus simple quant tu est petit.



J’ai un pote qui bossait dans une énorme boite, il était content si il arrivait à pondre 20 lignes de code par semaines. Et pour ces 20 lignes de code c’était 200 lignes de documentation et 30 demande d’autorisation.



A contrario moi j’étais en solo et je pondrais des centaines de ligne de code par jours. Quasiment zéro documentation à part quelques commentaires dans le code. Petit fichier .rar puis des test de débiles mentaux et restauration du petit .rar.



SIaelrod a dit:


oui ou les très gros projet “tousse” Discord “tousse” qui utilise des librairie a plusieurs version de retard pour évité les mises a jours




Un jour Minecraft a mis à jour la librairie graphique (genre de la version 1.9999 à la 2.01).
-> Ca a apporté plein de nouveautés pour les shaders
-> Ca a monté le niveau d’exigence OpenGL de plusieurs crans, mettant de côté tous les PC tournant sur des intel IGP un peu trop vieux (alors qu’il tournait correctement dessus).



Le problème, c’est que mettre à jour peut casser ton soft, et les softs sont rarement faits pour une mise à jour “partielle”.



Par ailleurs, tu peux avoir des références croisées: une lib A qui dépend de B en 2.0 et une lib C qui en dépend aussi.
lib B est passé en 3.0, cassant quelques petites choses.
lib C évolue et prend en compte la 3.0, pas lib A…



C’est pas pour rien si à la gendarmerie il ont des plans de fou pour tout retester et qualifier en permanence!



Perso j’ai déjà vécu des situations de daube:




  • Disparition d’un pilote du noyau linux empêchant de passer au kernel suivant (merci IBM) et du coup impossible d’upgrader les Redhat, et du coup impossible d’upgrader les PHP en mettant à jour les paquets

  • Tentative manuelle: recompiler PHP (ok) recompiler les plugins (pas ok, il fallait upgrader gcc car le plugin de bdd nouvelle version en avait besoin). Tentative d’upgrade gcc: nécessite de recompiler glibc car version non dispo pour le Linux … bref, abandon, trop risqué… 2 mois de travail pour un dead-end.



vivienfr a dit:


Les SNAP permettent plus de sécurité grâce à l’isolement (avec comme inconvénient de prendre plus de place)




Bah non, au lieu d’avoir une bibliothèque à jour de manière centralisée tu te retrouves avec des dixaines d’app dont tu ignores le fonctionnement… C’est l’opposé de l’opensource !


L’opposé de GNU j’aurai dit.



Est-ce que isoler une bibliothèque renforce la sécurité en plus de l’isolation des binaires et les fichiers associés au binaire ?


Merci pour cet article 😊


Merci beaucoup pour cet article très intéressant et accessible.



Ultra flippant …



Avec Heartbleed, se pose la question de la découverte de la faille, faite simultanément par deux organismes : Google et la société finlandaise Codenomicon.



Pour que cette dualité existe, c’est soit le fruit du hasard, soit des experts des deux entités ont repérés un élément suspect quelque part sur Internet et ils ont creusé. Cette thèse, évoquée par plusieurs personnes sur le salon, apporte de l’eau au moulin de ceux qui pensent que la NSA était au courant et exploitait cette vulnérabilité.




J’ai beau retourner dans tous les sens, je vois pas le rapport avec la NSA. Soit il manque un bout de phrase, soit on tombe dans le complotisme chez Nextinpact aussi? :D


Je parlais gros niveau main-d’oeuvre / finances demande a une boite qui n’a que un dev de tous update et tu verra sa tete



(quote:1908869:brice.wernet)
Un jour Minecraft a mis à jour la librairie graphique (genre de la version 1.9999 à la 2.01). -> Ca a apporté plein de nouveautés pour les shaders -> Ca a monté le niveau d’exigence OpenGL de plusieurs crans, mettant de côté tous les PC tournant sur des intel IGP un peu trop vieux (alors qu’il tournait correctement dessus).




Ça me surprend un peu, ou alors c’est la dite bibliothèque qui est mal fichue et force à utiliser des versions trop avancées d’OpenGL et de GLSL sans proposer des versions dégradées, ce qui est assez débile pour une bibliothèque…



deathscythe0666 a dit:


Ça me surprend un peu, ou alors c’est la dite bibliothèque qui est mal fichue et force à utiliser des versions trop avancées d’OpenGL et de GLSL sans proposer des versions dégradées, ce qui est assez débile pour une bibliothèque…




C’était LWJGL. J’ai retrouvé un patch: https://www.planetminecraft.com/mod/mod-opengl-fixer/



Mais les premiers mois: aucune solution, sauf changer d’ordi. Le chagement de version faisait passer la version minimale d’OpenGL en 4.6, avant même d’utiliser les nouveaux shaders.
Ca a mis à la corbeille les intel HD 4600 et tout ce qui était en-dessous.



thotor a dit:


J’ai beau retourner dans tous les sens, je vois pas le rapport avec la NSA. Soit il manque un bout de phrase, soit on tombe dans le complotisme chez Nextinpact aussi? :D




La faille a été introduite via un complot de la NSA, qui a manipulé ou payé le dev & le reviewer. Elle est restée inconnue pendant 2 ans, sauf de la NSA. Et c’est hasard ou des signaux faibles qui ont fait que 2 chevaliers ont trouvé un truc suspect, peut-être avec un lien suspecté fortement avec la NSA. et ont découvert le pot aux roses. Genre du trafic suspect qui atterrissait sur un serveur suspecté d’être contrôlé par la NSA.
Au final, impossible de prouver que la NSA est pour quelque chose, mais si ce n’est pas le cas, c’est une coïncidence troublante.



Au final, on ne saura pas la vérité.



(quote:1909255:brice.wernet)
C’était LWJGL. J’ai retrouvé un patch: https://www.planetminecraft.com/mod/mod-opengl-fixer/



Mais les premiers mois: aucune solution, sauf changer d’ordi. Le chagement de version faisait passer la version minimale d’OpenGL en 4.6, avant même d’utiliser les nouveaux shaders. Ca a mis à la corbeille les intel HD 4600 et tout ce qui était en-dessous.




Ah oui, donc le gars a un produit vendu 4 milliards de dollars à MS, et il utilise une lib maintenue en gros par un gars tout seul (en tout cas si on regarde les commits du dernier mois) qui s’amuse à péter la rétrocompatibilité quand il fait une montée de version (et surtout qui se met sur la dernière version OpenGL qui vient à peine de sortir, donc a priori pas supportée trop partout).



Ça me rappelle le module npm enlevé par son développeur et qui avait pété des milliers de projets…


D’un autre coté, la base du jeu à été créé par une seule personne en quelques mois (je crois que l’on parle de 3 mois pour la première Alpha).



A coté de ça, tu as Minecraft Bedrock Edition qui est la réécriture complète en C++ tournant sur PC, consoles et portable et développée en parallèle à la Java Edition.



tazvld a dit:


D’un autre coté, la base du jeu à été créé par une seule personne en quelques mois (je crois que l’on parle de 3 mois pour la première Alpha).




Raison de plus pour ne pas utiliser des libs à l’avenir incertain ? :D




A coté de ça, tu as Minecraft Bedrock Edition qui est la réécriture complète en C++ tournant sur PC, consoles et portable et développée en parallèle à la Java Edition.




Du coup, ça change concrètement bcp les performances ? (je ne connais pas suffisamment Minecraft).
En tout cas, le concept de réécrire en C++ pour supporter plein de plateformes alors que la version d’origine est en Java est … amusant.


Je pense que c’est surtout parce que Notch maitrisait cette bibliothèque et qu’il n’avait pas le temps/budget/besoin d’en utiliser une autre.



Niveau perf, c’est simple, c’est un no-match.



La Java Edition a toujours été lourde et souffre d’instabilité de performance. Cela viens certes d’une optimisation pas folichonne et beaucoup de Mods permettent de vraiment booster le jeu en tirant plus profit du matos (Optifine étant le plus connus) mais casse parfois certains éléments en privilégiant l’économie au respect de la compatibilité (surtout pour les serveurs non officiel). Mais le problème vient aussi de Java. Ce langage n’est pas adapté au jeu vidéo, lourd (à l’époque je lancer avec 2Go de préservé), peu performant (c’est du langage interprété, avec beaucoup d’indirection et aucune optimisation), avec une performance non garantie (instable). Par exemple, l’un des gros problème est le Garbage Collector qui peut ralentir l’exécution voir carrément la mettre en pause pour faire son boulot. Il était même courant à l’époque de Mojang que les MaJ plombaient les perfs (à l’heure actuel, ça bouge pas mal pour améliorer ça sans pour autant tout casser).



A coté de ça, la Bedrock Edition, bien c’est déjà pas mal de code compilé, donc directement lu par la machine (et pas par une VM). Il y a une meilleurs optimisation du code de base et là où il est galère d’afficher parfois le monde à plus de 16chunks (des colonnes de 16*16block, donc là ça fait une sorte de carrés de 256 block de coté avec au centre le joueurs) avec du gros cliping en Java, la Bedrock Edition permet sans trop de soucis à charger 24 chunks et ça se charge quasi instantanément.



Il a existait avant ça d’autre éditions écrites par Mojang (avant le rachat par MS). La première, la Pocket Edition était déjà écrite en C++ car il était inconcevable de faire tourner la Java Edition sur un smartphone. C’était la même chose pour la version qui s’appelle maintenant Legacy Console Edition (pour la XBox 360, One, PS3, PS4, PS Vita WiiU Switch). Mais ces 2 éditions n’était pas du tout “compatible” à la version Java (c’était des versions réduite et au mécanisme parfois différent).



A l’heure actuelle, la Java reste cependant la préférée sur PC surtout pour des raisons historiques. C’est celle avec laquelle plupart des personnes ont commencé et celle qui possède la plus grosse communauté et le plus grand nombre d’outils. Parce que certaine tutos utilisent des propriétés très “précises” (disons que c’est des “features” pas officielles) dans l’exécution du jeu, il ne sont pas forcément compatible d’une édition à l’autre (et même il est courant qu’une maj casse les “machines”).



tazvld a dit:


Ce langage n’est pas adapté au jeu vidéo, lourd (à l’époque je lancer avec 2Go de préservé), peu performant (c’est du langage interprété, avec beaucoup d’indirection et aucune optimisation), avec une performance non garantie (instable). Par exemple, l’un des gros problème est le Garbage Collector qui peut ralentir l’exécution voir carrément la mettre en pause pour faire son boulot.




Oui et non (je précise, je ne suis absolument pas un fan de Java et je développe principalement en C et en C++ selon les contextes). Un programme bien écrit en C ou en C++ est généralement plus performant qu’en Java. En revanche, un programme C ou C++ (sur un OS) qui passe par exempel son temps à allouer et désallouer de la mémoire va être bien plus lent que le même en Java (l’alloc/désalloc est bien plus rapide, c’est la JVM qui a déjà une mémoire prête pour ça alors que C/C++ font des appels au systèmes)



Et Java n’est pas un langage interprété, il passe par une JVM mais c’est le bytecode compilé pour la JVM qui est exécuté, pas le code lui même qui est interprété (a contrario de PHP ou Python par exemple). Encore que pour python… :-P


Ceci ce fait au prix d’un gerbage collector qui rend instable les performances. Et dans un jeu vidéo surtout type FPS, une framerate instable n’est pas terrible. En C et C++, c’est quand même globalement largement plus performant que Java et bien plus prévisible. Dans le cas de Minecraft, ça saute aux yeux (on parle au minimum d’un facteur 2-3 dans le cadre du nombre de chunk).



Oui, c’est un abus de langage, il faut dans tous les cas lancer un programme qui fait l’intermédiaire entre la machine et le code à exécuter. Et pour pyhton, oui, il y a bien ces fichier .pyc, mais je ne sais pas trop exactement ce qu’est vraiment ce “bytecode” dans ce cas (et pour python, une nombre important de bibliothèque ne sont que des interfaces à des bibliothèque compilé). Mais on peut aussi parler de Javascript qui est aujourd’hui compile à la volé par les naviagateurs.



tazvld a dit:


Ceci ce fait au prix d’un gerbage collector




Sur quelle hauteur, le gerbage? :francais:



tazvld a dit:


Ceci ce fait au prix d’un gerbage collector […]




Je crains que cette fonction ne mène à de sérieuses fuites de mémoire. :D



tazvld a dit:


Ceci ce fait au prix d’un gerbage collector qui rend instable les performances.




Le ramasse-miettes est un paradigme différent de celui de l’allocation/libération de la mémoire que l’on retrouve en C/C++.



Quand un programme est mal ficelé en C/C++, tu as des fuites de mémoires. Quand un programme est mal ficelé en Java (ou .Net, puisque le principe est exactement le même), tu as des problèmes de performance.



Ce qui rend instable les performances, c’est les erreurs de conceptions et les bugs.



En C/C++, la libération de la mémoire est en O(1) tandis que l’allocation est en O(quelque chose) qui dépend fortement de l’algorithme d’allocation et du contexte d’appel.



En Java, l’allocation est en O(1), et il n’y a pas de libération. Bon, l’allocation est en O(1) si le ramasse-miettes ne s’exécute pas. Ce qui est le cas lorsque la pression sur la mémoire devient trop importante.



L’inconvénient du ramasse-miettes, c’est que son lancement est non déterministe. On ne sait pas exactement quand il se lance. Mais cela ne veut pas dire qu’on ne peut rien faire. On peut indiquer des points où il devrait se lancer (ou en tout cas, vérifier s’il doit se lancer) parce qu’on sait que c’est pertinent (chargement d’une map, suppression d’une quantité importante de ressources utilisées, etc…). C’est tout un art ! A contrario, le faire au mauvais moment peut bien sûr aggraver la situation !



Et dans le cadre d’un jeu, où le FPS est important, un bon programme est un programme qui ne fait pas d’allocation (ou très peu), car c’est un facteur d’indéterminisme, que cela soit en C/C++ ou en Java.



Dire que Java n’est pas adapté pour le jeu car le ramasse-miettes ralenti le jeu de manière aléatoire c’est en réalité mettre en cause la conception même du jeu.



Un autre point du ramasse-miettes, c’est que lorsqu’il se lance, il “compacte” la mémoire, c’est à dire qu’il va déplacer la mémoire allouée afin de combler les trous des objets qui ont été libérés. Cela permet de continuer d’offrir des performances d’allocation en O(1), tout en participant au principe de localité (des objets utilisés en même temps sont souvent créés en même temps, ce qui peut diminuer la pression sur les bus mémoires).



Donc en gros, il n’y a pas forcément une méthode qui est meilleure qu’une autre. Ce sont deux paradigmes de gestion de la mémoire qui sont différents, chacun avec ses avantages et ses inconvénients.


Java et C++ sont 2 langages différents aux usages différents. Développer un truc en C++ prendra surement beaucoup plus de temps que faire la même chose en Java (même si C++ commence à avoir quelques facilité) mais les performances sont largement meilleurs. Oui, il faut penser dès la conception à la vie d’un objet, quand le créer, quand le détruire et tout ces trucs d’optimisation que finalement Java va faire plus ou moins bien automatiquement.



tazvld a dit:


Java et C++ sont 2 langages différents aux usages différents.




Pas tant que ça. Hormis pour des trucs très spécifique, le choix de l’un ou de l’autre résulte plus d’une préférence que d’une contrainte technique.




Développer un truc en C++ prendra surement beaucoup plus de temps que faire la même chose en Java (même si C++ commence à avoir quelques facilité)




Sauf qu’aujourd’hui, c’est le temps de dev qui coute le plus ! Le C++ nécessite plus de temps pour deux raisons principales : c’est plus long à écrire (plus de fichiers, notamment à cause des entêtes absent en java) et c’est plus long à compiler (et je ne parle même pas de la métaprogrammation qui peut faire exploser de manière exponentielle les temps de compilation).




mais les performances sont largement meilleurs.




Il faut voir ce que l’on appel performance largement meilleure. Aujourd’hui, le même algo écrit en C++ ou en java on des performances quasi-identiques à quelques % près (avantage pour l’un ou l’autre, cela dépend des cas).



Là où il me semble que Java est le plus pénalisé par rapport au C/C++, c’est sur les calculs flottants. Si je ne dis pas de bêtise, la JVM travaille forcément sur une représentation 64 bits, là où les processeurs x86/x64 peuvent travailler sur 80 bits par exemple. C’est malheureusement une contrainte nécessaire pour garantir un fonctionnement identique indépendamment de la plateforme (car le passage 64 -> 80 bits et 80 -> 64 amènent à des arrondis qui peuvent modifier légèrement les calculs pour un même algorithme en fonction de sa traduction en code machine). Du coup, je ne suis pas certains que la JVM puisse utiliser directement les instructions à calculs flottant, en tout cas, pas sans prendre quelques précautions.




Oui, il faut penser dès la conception à la vie d’un objet, quand le créer, quand le détruire et tout ces trucs d’optimisation que finalement Java va faire plus ou moins bien automatiquement.




Hormis la destruction explicite objets, le programmeur a toujours la main sur ce qu’il fait, comme en C++. Rien à voir avec le langage Java en particulier.


C++ permet certain paradigme de programmation très efficace (justement le template metaprogramming et tout ce qui est template specialization par exemple). Oui, des algos basiques sont peut peut-être similaire mais à priori, même là, C++ semble avoir toujours un avantage indéniable (même un reverse-complement qui est pourtant une opération simple de manipulation de vector)



Comme il a été dit, souvent, l’une des problèmes c’est les allocutions mémoires dans le tas. Or, il peut être intéressant de plutôt privilégier l’allocution dans la pile (qui est “gratuite”) lorsque l’on sait que l’objet n’a pas a exister en dehors du bloc. C’est possible assez explicitement en C++ en n’utilisant des “new” uniquement lorsque c’est nécessaire, cela parfois implique d’instancier des objet en amont (par exemple, tu passes par référence où il faut stocker le résultat d’une function). D’où pourquoi je dis qu’il faut savoir quand créer un objet. En Java, je ne sais pas si les objet qui n’existe que dans une méthode sont crées dans la pile.



Sinon, pour le temps, c’est bien souvent plus rentable de coder en Java qu’en C++, C ou ASM. C’est justement l’un des avantages de java. Et ce n’est pas pour rien que Java et C# on autant de succès. Ce sont des langages qui sont parfaitement adapté aux entreprises et au gros projets. Personnellement, je bosse actuellement en python car c’est ce qu’il y a de plus efficace pour faire des expérimentations : il faut mieux ne passer qu’une journée à coder mais avoir un code qui demande 1h d’exécution pour avoir un résultat que passer 1 semaine pour un code qui s’exécute en 1min.



Mais si on revient sur Minecraft, les moteurs de jeux demandent des performances élevés. Mais comme ça demande de gros investissement, ce n’est pas pour rien que ce travail est mutualisé par des boites qui vendent justement des moteurs de jeux (qui s’interface souvent avec d’autre langage). Et selon moi, Minecraft est l’exemple comme quoi Java montre très vite ses limites dans le cadre d’un jeu-vidéo lorsqu’on le compare avec sa contrepartie en C++.



Au final, chaque langage a une raison d’exister. Ils ont chacun leurs avantages, leurs défauts, leurs usages.



fdorin a dit:


Sauf qu’aujourd’hui, c’est le temps de dev qui coute le plus ! Le C++ nécessite plus de temps pour deux raisons principales : c’est plus long à écrire (plus de fichiers, notamment à cause des entêtes absent en java) et c’est plus long à compiler (et je ne parle même pas de la métaprogrammation qui peut faire exploser de manière exponentielle les temps de compilation).




Pas vraiment : avoir un fichier d’entête et un fichier de définition, c’est un overhead très limité par rapport à tout mettre dans le même fichier (en C++, ça va t’éviter de recompiler le code à chaque fois qu’il est inclus aussi). Écrire une signature de méthode et cliquer dessus pour choisir “Implémenter”, ça te fait perdre 12 seconde, ce n’est pas ça qui va fondamentalement changer ton temps de développement.



Pour ce qui est de la durée de compilation, il y a un certain nombre de techniques qui permettent de la réduire (Pimpl notamment) et évitent accessoirement de péter ton ABI quand tu fais une modification sur une bibliothèque.




Il faut voir ce que l’on appel performance largement meilleure. Aujourd’hui, le même algo écrit en C++ ou en java on des performances quasi-identiques à quelques % près (avantage pour l’un ou l’autre, cela dépend des cas).




Il y a un tas de cas où tu peux faire du C++ et pas du Java, notamment l’embarqué (quand tu as qql centaines de KB de RAM et/ou de flash, tu peux oublier Java). Et des cas où faire du C++ va être bien plus difficile que du Java (serveurs d’applications notamment où Java est assez incontesté).



tazvld a dit:


C++ permet certain paradigme de programmation très efficace (justement le template metaprogramming et tout ce qui est template specialization par exemple). Oui, des algos basiques sont peut peut-être similaire mais à priori, même là, C++ semble avoir toujours un avantage indéniable (même un reverse-complement qui est pourtant une opération simple de manipulation de vector)




Il suffit de bien choisir ses benchmarks pour avoir des résultats différents ;)



Le lien que je donne est d’ailleurs intéressant à plus d’un titre, puisqu’il essaie d’expliquer parfois des bizarreries, comme le même algo, qui est 2x plus rapide ou 2x plus lent en fonction de la taille des données (lié à la notion de localité dont je parlais précédemment).



Il faut se méfier des benchmarks. En faire un juste et sans biais, c’est très difficile. Un biais classique, c’est sur la gestion des tableaux. Utiliser un vector en C++ et utiliser l’opérateur d’indexation induit un biais invisible pour l’oeil non averti, car en C++, l’opérateur d’indexation ne fait aucune vérification quant à la taille du tableau, contrairement au java. Pour avoir moins de biais, il faut utiliser la méthode at().



Il faut également s’assurer que l’algorithme utilisé dans un cas comme dans l’autre est implémenté exactement de la même manière, ce qui ne semble pas être le cas pour le reverse-complément que tu cites par exemple.




Comme il a été dit, souvent, l’une des problèmes c’est les allocutions mémoires dans le tas. Or, il peut être intéressant de plutôt privilégier l’allocution dans la pile (qui est “gratuite”) lorsque l’on sait que l’objet n’a pas a exister en dehors du bloc. C’est possible assez explicitement en C++ en n’utilisant des “new” uniquement lorsque c’est nécessaire, cela parfois implique d’instancier des objet en amont (par exemple, tu passes par référence où il faut stocker le résultat d’une function). D’où pourquoi je dis qu’il faut savoir quand créer un objet. En Java, je ne sais pas si les objet qui n’existe que dans une méthode sont crées dans la pile.




On est tout à fait d’accord. Pour java je ne sais pas (je suis plutôt C# ;) ). En C#, c’est possible en tout cas pour certains types (pas tous).




Sinon, pour le temps, c’est bien souvent plus rentable de coder en Java qu’en C++, C ou ASM. C’est justement l’un des avantages de java. Et ce n’est pas pour rien que Java et C# on autant de succès. Ce sont des langages qui sont parfaitement adapté aux entreprises et au gros projets.




Je ne peux qu’être d’accord. Ayant “bouffé” du C++ et de l’assembleur par le passé, j’ai bien vu le gain de temps en terme de codage depuis que j’utilise du C# !




Et selon moi, Minecraft est l’exemple comme quoi Java montre très vite ses limites dans le cadre d’un jeu-vidéo lorsqu’on le compare avec sa contrepartie en C++.




Pas tout à fait d’accord. La première version était en Java. D’autres ont suivi en C++. Pour des questions de performance peut être, mais à mon avis, c’était plus la portabilité qui était en vue, notamment pour les smartphones/tablettes. Et comme tout est question de coût aussi, il fallait pouvoir mutualiser le maximum de code, quelque soit la plateforme cible.



Et tu le disais toi même plus haut, certains mods arrivaient à accroitre les performances de l’implémentation en Java. C’est donc bien que c’est l’implémentation qui était bancale plus que le langage lui-même.



Surtout qu’aujourd’hui, le compilateur JIT, qui permet de traduire un bytecode en langage machine, est vraiment très performant et fourni parfois de bien meilleures optimisations qu’un gcc -O3, pour la simple et bonne raison que le compilateur JIT peut traduire plusieurs fois le même code, en fonction du nombre d’appels d’une méthode par exemple, et bénéficier de statistiques sur les branchements à l’exécution (est-ce le if ou le else qui est le plus fréquemment rencontré ? etc…).




Au final, chaque langage a une raison d’exister. Ils ont chacun leurs avantages, leurs défauts, leurs usages.




Yep, je n’aurais pas dit mieux :)



deathscythe0666 a dit:


Pas vraiment : avoir un fichier d’entête et un fichier de définition, c’est un overhead très limité par rapport à tout mettre dans le même fichier (en C++, ça va t’éviter de recompiler le code à chaque fois qu’il est inclus aussi). Écrire une signature de méthode et cliquer dessus pour choisir “Implémenter”, ça te fait perdre 12 seconde, ce n’est pas ça qui va fondamentalement changer ton temps de développement.




Ca c’est quand tu as un bon IDE. Rajoute le temps pour passer d’un fichier à l’autre, maintenir des versions cohérentes entre la signature et une implémentation, etc… Et tu verras que cela n’est pas négligeable.



Et quand tu n’as pas un bon IDE, ben c’est encore pire :)




Pour ce qui est de la durée de compilation, il y a un certain nombre de techniques qui permettent de la réduire (Pimpl notamment) et évitent accessoirement de péter ton ABI quand tu fais une modification sur une bibliothèque.




Utiliser des techniques pour réduire le temps de compilation, c’est pour moi, une mauvaise pratique. Ecrire ton code en vue de minimiser le temps de compilation, c’est le meilleur moyen d’avoir un code de mauvaise qualité.



Pour ma part, la technique Pimpl, c’est plutôt pour fournir une ABI stable. Que cela réduise ou pas les temps de compilation, c’est du bonus :)



Et si tu veux réduire les temps de compilation, tu oublies la métaprogrammation et tu fais du C objet (par exemple, gtk fait cela très bien).




Il y a un tas de cas où tu peux faire du C++ et pas du Java, notamment l’embarqué (quand tu as qql centaines de KB de RAM et/ou de flash, tu peux oublier Java).




Je n’ai jamais dis le contraire. J’ai juste dit que dans la majorité des cas, le choix relevait plus d’une préférence que d’une contrainte, et que dans ce cas, les deux sont généralement interchangeables.