Auteur/autrice : Regulus Page 2 of 4

Le jeu d’instructions AVX-512 va fêter ses 10 ans cette année. Toutefois, il existe une immense fragmentation dans ce jeu d’instructions puisqu’il existe de nombreuses évolutions telles que F, CD, VL, DQ, BW, IFMA, VBMI, VBMI2, VPOPCNTDQ, BITALG, VNNI, VPCLMULQDQ, GFNI, qui sont supportées par un petit nombre de processeurs.

Ce jeu d’instructions AVX-512 succède au jeu d’instruction AVX2 déjà ardu à implémenter. Même les précédents jeux d’instructions SSE et AVX ne sont pas simples à appréhender comme on peut le voir sur ce tutoriel « SSE & AVX vectorization ».

De plus, ces jeux d’instructions occupent une place non négligeable dans les processeurs modernes, ainsi qu’une complexité là aussi importante. Avec tous ces inconvénients, les développeurs de logiciels peuvent être excédés et préfèreraient à la place davantage de cœurs pour distribuer la charge.

Alors que les processeurs grand public chez AMD et Intel commençaient à inclure tout ou partie des jeux d’instruction AVX-512, Intel a finalement fait machine arrière et supprime maintenant le support de l’AVX-512 dans ses derniers processeurs grand public, la déclinaison Alder Lake. Il faut dire que les processeurs Intel supportent maintenant 2 types de cœurs : les performants et par opposition les « non performants » qui excluaient de fait l’AVX-512. Quant-à AMD, la dernière génération Zen 4 continue d’avoir un support de l’AVX-512. Reste à voir si ce support se maintiendra avec les générations futures.

Coup de théâtre : Intel vient de publier en open source son code source permettant un tri rapide à l’aide du jeu d’instructions AVX-512, ce tri rapide étant basé sur l’algorithme de tri bitonic. Cet algorithme de tri n’est pas le plus efficace puisque qu’il est en O(n(log(n))²). Mais pour certains cas particuliers, grâce à l’AVX-512, il permet de paralléliser une partie de travail et au final peut être plus rapide que les meilleurs algorithmes de tri. L’abandon de l’AVX-512 est donc malvenu pour ce cas particulier.

Enfin, on peut se demander si l’AVX-1024 verra le jour dans ces conditions.

Peut-on confier à ChatGPT l’analyse sécurité d’une application ? Notamment, ChatGPT peut-il détecter efficacement des injections SQL par exemple dans du code java ?

Pour cela, testons le en utilisant le célèbre OWASP Benchmark (https://github.com/OWASP-Benchmark/BenchmarkJava) qui a l’avantage de fournir des exemples d’injection SQL, avec en prime une mention s’il existe un problème ou pas pour chaque cas de test.

Essayons d’abord le premier cas de test de type SQL injection (CWE-89). Le code source est en ligne : https://github.com/OWASP-Benchmark/BenchmarkJava/blob/master/src/main/java/org/owasp/benchmark/testcode/BenchmarkTest00008.java. Le fichier XML associé (https://github.com/OWASP-Benchmark/BenchmarkJava/blob/master/src/main/java/org/owasp/benchmark/testcode/BenchmarkTest00008.xml) mentionne bien qu’il existe une injection SQL dedans.

Posons la question à ChatGPT : Is there a SQL injection in the following java code: et en fournissant le code source complet.
La réponse arrive instantanément, et est correcte :

The code you provided is vulnerable to SQL injection. The variable « param » is being obtained from the request header « BenchmarkTest00008 » and is being appended to a SQL query without proper validation or escaping. An attacker could manipulate the value of this header to include malicious SQL code, potentially allowing them to access or modify sensitive data in the database.

Par ailleurs ChatGPT fournit en plus des conseils pertinents :
It is recommended that you use prepared statements with parameterized queries, or use an ORM framework that will handle escaping data for you, to protect against SQL injection.

Essayons maintenant un cas de test de type SQL injection (CWE-89) bien plus subtil. Le code source est en ligne : https://github.com/OWASP-Benchmark/BenchmarkJava/blob/master/src/main/java/org/owasp/benchmark/testcode/BenchmarkTest00104.java. Le fichier XML associé (https://github.com/OWASP-Benchmark/BenchmarkJava/blob/master/src/main/java/org/owasp/benchmark/testcode/BenchmarkTest00104.xml) mentionne qu’il n’existe pas d’injection SQL dedans. En raison bien sûr de la condition complexe dans le « if » de la ligne 69.

Posons la même question à ChatGPT.

Voici la réponse :

ChatGPT voit quand même une injection SQL car il n’a pas vu l’astuce pour ce cas complexe. Il n’obtiendra donc pas 100% au OWASP Benchmark. Seuls quelques rares outils spécialisés à base d’analyse dynamique de code sont capables de réussir ce genre de test difficile.

Au tour de l’excellente application K9 (servant à la lecture de mails sur téléphone mobile) de se conformer avec les nouveaux réglages de Gmail, via l’authentification OAuth2.

Dans les réglages, il faut cocher l’authentification OAuth2 :

Ensuite, lors de la synchronisation des messages, une boîte de dialogue demande les paramètres (adresse et mot de passe) :

C’est simple.

Google a mis sa menace à exécution : « À partir du 30 mai, vous ne pourrez peut-être plus accéder aux applis qui utilisent une technologie de connexion moins sécurisée ». De fait, début juin 2022, impossible de recevoir ou d’envoyer des mails depuis thunderbird au moyen de compte Gmail :

Hélas, le support de Mozilla est pauvre en solution : https://support.mozilla.org/fr/kb/thunderbird-et-gmail et https://support.mozilla.org/fr/kb/conversion-automatique-comptes-google-mail-oauth20.

Voici comment faire, capture d’écran à l’appui.

Cas POP :

Cas SMTP :

Ce quatrième opus de la franchise « Men in Black » fut un échec cuisant. Dans ce billet, il ne sera toutefois question que de programmation informatique utilisée dans ce film.

En effet, au début du film, l’héroïne montre un de ses écrans. Elle recherche des extra-terrestres et a manifestement écrit un programme pour les débusquer :

On reconnaît évidemment du langage COBOL du fait des numéros de lignes et de la syntaxe truffée de SQL. D’ailleurs, il est très facile de retrouver le code source d’origine. Il s’agit d’un simple programme d’exemple présenté sur le site IBM.

À nouveau on ne peut que s’interroger sur ce décalage existant entre la programmation informatique présentée au cinéma et le monde réel de la programmation. Manifestement Hollywood vit dans un monde déconnecté.

Cette série en quatre épisodes est présentée dans un article du site Développez.

Un point intéressant dans le premier épisode, est la présentation d’un code source illustrant le travail de codage du principal informaticien :

On reconnaît évidemment du code en langage C++, qui contient même un lien vers le site MSDN. Ce code est facile à retrouver sur GitHub : il s’agit d’un extrait du fichier keylogger.cpp du projet FTPKeyLogger.

On peut noter 2 points concernant ce choix :

1/ Ce programme a été écrit bien après les événements du film (l’action du film se situant entre la fin des années 90 et au début des années 2000). Or, le lien MSDN du programme date de 2011 selon toute vraisemblance selon Internet Archive.

2/ Pour une fois, le code source présenté n’est pas trop éloigné du film qui le présente, mais quand même, présenter un outil qui automatise la saisie de tout ce qui est tapé au clavier et qui envoie ensuite le résultat sur un serveur FTP, c’est quand même limite. Même si après tout ce genre de programme est en accès libre.

Bien que Windows 10 soit une belle amélioration par rapport à ses prédécesseurs, et en attendant Windows 11, il reste pas mal de composants inutiles qui consomment des ressources. Tels les widgets et autres applications faciles à retirer. Il reste pourtant au cœur du système d’autres composants nuisibles. Par exemple le service « Expériences des utilisateurs connectés et télémétrie ». Ce service qui se permet de consommer 100% de CPU sur 1 thread pendant longtemps ne sert qu’aux besoins de Microsoft (sans qu’on sache très bien ce qui est envoyé d’ailleurs), pas à l’utilisateur. Du coup, il suffit de l’arrêter définitivement.

Il y a seulement 4 ans, le machine learning apparaissait encore comme une utopie pour les compétitions de programmation. Pour preuve, cette remarque d’un compétiteur sérieux (à 34’40 ») :

La phrase qui nous intéresse : « En pratique, sur un challenge comme ça, je n’ai jamais vu quelqu’un gagner grâce au machine learning ».

On peut noter que le niveau en compétition de programmation a bien progressé sur ce genre de compétition. Du fait de l’utilisation croissante d’algorithmes qui ont fait leur preuves (Minimax, algorithme génétique, recuit simulé, algorithme de recherche en faisceau, Monte Carlo Tree Search et ses nombreuses variantes, etc.) on assiste à des résultats remarquables.

Certains compétiteurs ont réussi à appliquer avec succès le machine learning dès 2019 sur certains problèmes issus de précédentes compétitions. Les résultats étaient variables et dans certains cas très remarquables, battant largement tous les algorithmes mis en œuvre jusqu’à présent.

Lors de la très sérieuse compétition de programmation organisée par CodinGame en ce mois de mai 2021, plusieurs candidats se sont essayés au machine learning. L’un de ces candidats a particulièrement frappé les esprits en réussissant à sortir une solution qui a littéralement écrasé tous les autres participants (près de 7000).

On remarque donc que le machine learning, s’il n’est toujours pas une solution magique instantanée, engrange toutefois toujours plus de succès. Inévitablement, on va assister à une accélération de son utilisation, tout comme on a vu se répandre l’usage de certains algorithmes performants il y a quelques années.

À plusieurs reprises il m’est arrivé d’atteindre des limites peu connues en utilisant le .NET framework.

Récemment encore, en travaillant sur un problème d’optimisation, j’avais mis en place un algorithme de type BFS afin de chercher la solution la plus efficace à un problème. Du fait de l’explosion combinatoire du problème, mon pauvre programme pourtant en mode 64 bits tombait sur une exception de type « mémoire insuffisante« . Le souci est qu’au moment de l’exception, mon programme consommait à peine 10 Go de mémoire et qu’il me restait 16 Go de libre sur ma machine de 32 Go. Rageant.

Comme je travaille de plus en plus avec le .NET core, aussi bien sous Windows que sous Linux, j’ai voulu tester mon programme en le basculant pour .NET core 5 et voir s’il y avait des différences en terme de performance et d’occupation mémoire. Je n’ai pas spécialement noté de différence sur ces 2 aspects là, mais j’ai découvert une différence majeure : plus d’exception. J’ai même pu laisser filer mon programme au-delà de la mémoire disponible (process testé à 44 Go avec 32 Go de RAM), Windows restant imperturbable.

En conclusion, tout nouveau développement en C# devrait cibler sans hésiter .NET Core au lieu de .NET framework, vu l’ensemble des avantages (notamment l’aspect multi-plateforme) et l’absence de perte.

Le terme que je veux mettre en avant est éphémère.

On ne s’en rend pas compte parce que l’informatique est ancrée dans le quotidien et que les améliorations et nouveautés s’enchaînent dans ce monde. Mais l’obsolescence est de plus en plus présente dans de nombreux domaines de l’informatique.

Quelques exemples pour étayer cette remarque.

Flash a disparu début 2021 après une longue période pendant laquelle ce composant était indispensable à nombre de sites internet et même des logiciels. Cette disparition entraîne de fait nombre de pages internet à ne plus fonctionner (sauf si évolution), nombre de logiciels à ne plus pouvoir fonctionner (sans alternative), et nombre de vidéos à ne plus pouvoir être lues.

Les langages de programmation évoluent de nos jour à un rythme inquiétant (et sans compter les nouveaux langages qui fleurissent chaque année). Ainsi, nombre de langages se sont lancés dans une course folle à enchaîner soit des nouveautés non négligeables sur un rythme semestriel, soit des nouveautés significatives sur un rythme triennal. En conséquence, relire un code source écrit il y a une dizaine d’année peut faire mal aux yeux. Également, le travail d’actualisation des connaissances pour les développeurs devient de plus en plus compliqué (sans compter les nouveaux frameworks qui apparaissent ou qui évoluent, ainsi que les nouveaux outils et les nouvelles pratiques). Et là encore, arriver à recompiler un ancien code source peut s’avérer difficile voire impossible de nos jours tant les évolutions sont rapides et brutales. On peut penser au langage python 2 qui n’a plus de support depuis 2020, certaines anciennes version de Swift.

On peut aussi penser aux célèbres applets java qui étaient tant présentes au début du web : elles vont être définitivement retirées de la version 17 de java (cf. https://openjdk.java.net/jeps/398).

Les logiciels suivent le même chemin : certains disparaissent (Outlook Express, Internet Explorer, etc.). On peut aussi évoquer une liste impressionnante de projets abandonnés par Google : https://killedbygoogle.com.

Toutes ces évolutions conduisent inévitablement à devoir migrer sans cesse les données, changer les logiciels et les habitudes. Et même parfois, ça conduit à des pertes de données/fonctionnalités définitives. Une forme d’obsolescence à marche forcée. Et pourtant cette tendance ne devrait pas s’inverser, bien au contraire.