Nos confrères de chez Phoronix ont publié un comparatif des performances du tout nouveau Ryzen 9 9950X3D2 d'AMD sous deux systèmes : Windows 11 et Ubuntu 26.04 LTS. Le verdict est sans appel, Linux prend une avance très nette sur Windows sur la majorité des charges de travail testées.

Petit point pour ceux qui décrochent dès qu'on parle de processeur. Le 9950X3D2, c'est une variante Dual Edition du processeur haut de gamme d'AMD pour le grand public. Elle embarque 16 cœurs, 32 threads, et surtout une particularité plutôt rare : une mémoire cache 3D (le V-Cache, une couche de mémoire ultra-rapide empilée physiquement sur la puce) présente sur les deux blocs de cœurs, là où les versions précédentes n'en avaient que sur un seul.

En pratique, les deux moitiés du processeur peuvent piocher dans une grosse réserve de mémoire rapide, ce qui accélère pas mal de calculs gourmands.

Phoronix a fait tourner ses batteries de benchmarks habituelles : compilation de code, encodage vidéo, calcul scientifique, rendu 3D, base de données. Sur la majorité de ces tests, Ubuntu 26.04 arrive devant Windows 11, parfois de quelques pourcents, parfois beaucoup plus selon la charge. Quand on additionne tout, ça donne une moyenne nettement à l'avantage du pingouin.

C'est un constat qui revient quasi à chaque test du genre depuis plusieurs années. Linux fait souvent mieux tourner les processeurs serveur ou les CPU multi-cœurs musclés que Windows, notamment parce que son ordonnanceur (le bout du système qui décide quel programme tourne sur quel cœur et à quel moment) est plus malin avec les architectures complexes.

AMD, avec son design en deux blocs séparés et son cache 3D asymétrique, est typiquement le genre de processeur où ça compte vraiment.

Côté Windows, c'est un peu toujours la même histoire. Microsoft a fait des efforts ces dernières années pour mieux gérer les Ryzen, mais le système traîne encore quelques inefficacités et un fond plus lourd. Pour un gamer pur, ça n'a probablement pas grand impact. Mais pour un développeur, un créateur de contenu ou quelqu'un qui compile son propre code, l'écart commence vraiment à avoir du sens.

On peut d'ailleurs se demander si AMD finira par sortir une version officiellement labellisée Linux. Pour l'instant, rien d'annoncé. Mais bon, qu'un constructeur grand public reconnaisse explicitement que son matos tourne mieux sous Linux serait déjà une petite révolution culturelle.

Source : Phoronix

Le chercheur en sécu Hyunwoo Kim vient de lâcher dans la nature Dirty Frag, un nouvel exploit kernel Linux qui enchaîne 2 vulnérabilités pour obtenir un accès root sur n'importe quelle distro majeure, avec un taux de réussite proche de 100%.

L'embargo devait tenir encore quelques semaines. Il n'a pas tenu.

Et problème (et c'est pour ça que je vous en parle) c'est que ça marche du feu de dieu, et que personne n'a encore de patch disponible !! Alerte rouge donc !!

La lignée "Dirty" a donc maintenant quatre membres. Dirty COW en 2016, avec ses 9 ans de présence silencieuse dans le kernel avant d'être découvert, Dirty Pipe en 2022, Copy Fail dont je vous parlais il y a tout juste 8 jours, découvert par une IA. Et maintenant Dirty Frag, qui s'appuie sur le même principe que Copy Fail tout en contournant sa mitigation connue.

Alors comment ça marche ?

Le concept du truc c'est l'abus d'un mécanisme tout à fait légitime du kernel Linux : splice(). Cette fonction permet de faire circuler des données entre deux descripteurs de fichiers sans les copier en mémoire. C'est très utile, très performant, mais dans certaines configurations, c'est surtout très catastrophique.

Dirty Frag exploite les modules réseau d'IPsec (ESP) et du protocole RxRPC, ainsi quand un attaquant utilise splice() pour faire passer une page du cache mémoire (disons, /usr/bin/su) dans un buffer réseau, le kernel effectue son chiffrement directement sur cette page en RAM et sans faire de copie.

Résultat, les premiers octets de /usr/bin/su en mémoire sont remplacés par du code malveillant qui ouvre un shell root. Un simple appel à su ensuite, et l'attaquant est root.

Deux CVE sont impliqués dans la chaîne. CVE-2026-43284 qui concerne les modules esp4 et esp6 et qui a été patchée depuis hier et CVE-2026-43500 qui concerne rxrpc et pour celle-ci, y'a aucun patch actuellement à l'heure où j'écris ces lignes.

Le fait de chainer les 2 exploits permet à chacun de combler les angles morts de l'autre. C'est un peu technique mais en gros, la variante ESP requiert les droits de créer un namespace utilisateur, ce qu'Ubuntu peut bloquer via AppArmor. Alors que de son côté, la variante RxRPC ne nécessite pas ce privilège, mais le module rxrpc.ko n'est chargé par défaut que sur... Ubuntu. Du coup, une fois combinés, ils couvrent toutes les distros majeures sans exception.

Hyunwoo Kim a reporté la faille aux mainteneurs des distribs le 30 avril dernier, avec un accord de divulgation coordonnée via [email protected]. Mais un tiers extérieur (appelons le "connard" ^^) a brisé l'embargo hier, d'où la publication immédiate du PoC, avec l'accord des maintainers, pour éviter qu'un exploit silencieux circule sans que personne soit prévenu.

Les versions testées et confirmées vulnérables sont donc Ubuntu 24.04.4, RHEL 10.1, openSUSE Tumbleweed, CentOS Stream 10, AlmaLinux 10, Fedora 44.

En gros, si vous avez un kernel compilé depuis début 2017, vous êtes dans le scope.

Tester avec Lima sur macOS

Si vous voulez reproduire ça dans un environnement contrôlé, l'idée c'est de lancer une Ubuntu 24.04 avec le kernel non patché et de faire comme ceci :

# Cloner, compiler, et lancer
git clone https://github.com/V4bel/dirtyfrag.git
cd dirtyfrag
sudo apt install gcc -y && gcc -O0 -Wall -o exp exp.c -lutil && ./exp

Et si tout se passe bien, vous obtenez alors un shell root sans faire paniquer le kernel comme chez moi ici :

Après le test, le page cache est contaminé donc avant de faire quoi que ce soit d'autre, faut le nettoyer. :

echo 3 > /proc/sys/vm/drop_caches

Ou plus simple, redémarrez la machine car la modification est uniquement en RAM, donc un reboot permet de repartir de zéro.

Alors que faire ?

Hé bien, comme aucun patch n'est disponible pour la plupart des distros à l'heure où j'écris ces lignes, vous pouvez vous mettre en boule et pleurer. Sauf si vous êtes sous AlmaLinux car eux ont déjà poussé des kernels corrigés. Après vous pouvez aussi sécher vos larmes si vous êtes sur une autre distro, et suivre cette remédiation qui vous prendra trente secondes :

sh -c "printf 'install esp4 /bin/false\ninstall esp6 /bin/false\ninstall rxrpc /bin/false\n' > /etc/modprobe.d/dirtyfrag.conf; rmmod esp4 esp6 rxrpc 2>/dev/null; echo 3 > /proc/sys/vm/drop_caches; true"

Cette commande fait trois choses : elle blackliste les modules vulnérables pour qu'ils ne se rechargent pas au prochain boot, elle les décharge s'ils sont actifs, et elle nettoie le page cache au cas où il serait déjà corrompu.

Après c'est tranquille à faire car esp4, esp6 et rxrpc ne sont pas des modules que la plupart des machines desktop utilisent au quotidien. Les désactiver n'a donc aucun impact visible sur 99% des setups. Mais un serveur qui fait du VPN IPsec en mode transport ESP, lui, sera affecté...

En tout cas, surveillez ça de près car une fois que votre distro sortira le patch, faudra mettre à jour et rebooter.

Source : https://github.com/V4bel/dirtyfrag

Si vous utilisez Ubuntu 26.04, vous avez peut-être remarqué un truc bizarre dernièrement en tapant votre mot de passe sudo... Ouiiiiii, y'a des petites étoiles qui apparaissent !! Pas de panique, c'est "normal". Enfin, c'est nouveau...

En effet, sudo-rs, la réécriture en Rust de la bonne vieille commande sudo, a décidé d'activer pwfeedback par défaut. En gros, quand vous faites un sudo apt install bidule, au lieu du trou noir habituel, vous voyez maintenant des ***** défiler pendant la saisie du mot de passe. C'est un changement qui casse une convention vieille de 40 ans... et ça, forcément, ça fait du bruit !

Pour rappel, Ubuntu a basculé sur sudo-rs (le remplaçant en Rust du bon vieux sudo en C) depuis la version 25.10. Ça fait partie du même mouvement de réécriture des outils système en Rust, comme les coreutils dont je vous avais parlé. Et la 26.04 vient de "cherry-picker" comme on dit, un patch upstream qui active le feedback visuel par défaut.

Un bug report sur Launchpad ( #2142721 ) est bien sûr arrivé direct, en mode vénère genre "*ÇA FAIT DES DÉCENNIES qu'on n'affiche pas la longueur du mot de passe pour empêcher le shoulder surfing ! C'est quoi ce bordel !!?? *"

Et la réponse des devs : Won't Fix. Circulez les relous !

En fait, leur argument c'est que le bénéfice sécurité est "infinitésimal". Parce que bon, votre mot de passe sudo c'est le même que celui de votre session (celui que vous tapez à l'écran de login, devant tout le monde). Et le bruit des touches trahit déjà la longueur de toute façon. Du coup, ils ont préféré régler le problème UX qui paume les débutants depuis le début des années 80.

D'ailleurs, en 2013 je vous expliquais comment activer ces étoiles manuellement avec sudo visudo (ça date de fou !!) et maintenant c'est l'inverse, faut expliquer comment les virer ! Linux Mint avait d'ailleurs déjà sauté le pas de son côté depuis un moment.

Perso, le truc qui me gonfle c'est pour les tutos vidéo. Quand vous faites un screencast, les astérisques révèlent la longueur de votre mot de passe à tous vos spectateurs. Du coup faut aller reparamétrer chaque machine avant de filmer ou faire du masquage en post prod. C'est pas la fin du monde, mais bon, la flemme...

Alors pour désactiver ces jolies zétoiles :

sudo visudo

Defaults !pwfeedback

Vous êtes un warrior ! Normal, vous utilisez Linux depuis des années. Et vous aimez beaucoup toutes vos petites commandes du quotidien, ls, cat, base64… Vous le savez, tout ça fonctionne avec du bon vieux code C aussi vénérable que solide. Du code robuste, certes, mais qui pourrait bien se faire dépasser par plus moderne. Hé oui, parce qu’une bande de développeurs a décidé de refaire tout uutils Coreutils en Rust, et en prime, leurs nouvelles versions sont largement plus rapides que les originales.

Les benchmarks parlent d’eux-mêmes : l’utilitaire base64 mouline maintenant en 3,146 secondes là où GNU Coreutils prend 4,901 secondes. La version Rust est donc clairement plus rapide, mais le plus fou, c’est que la version précédente de Rust Coreutils mettait encore 5,998 secondes. En gros, ils ont pratiquement doublé la vitesse entre leurs deux versions mineures.

Alors comment ils ont fait ça ? Et bien en intégrant la bibliothèque base64-simd qui exploite les instructions SIMD des processeurs modernes. Pour faire simple, au lieu de traiter les données octet par octet comme un escargot asthmatique, le nouveau code traite plusieurs octets en parallèle, comme un guépard qui serait abonné à la chaine de Tibo Inshape. SSE4.1, AVX2, AVX-512 pour les processeurs Intel et AMD, et ARM NEON pour les puces ARM comme les Apple Silicon… ce sont toutes ces architectures qui profitent de l’accélération.

D’ailleurs, ce n’est pas qu’une histoire de performance brute. Ubuntu prévoit d’intégrer ces outils Rust dans sa version 25.10. Et Canonical ne fait pas ça pour suivre la mode du Rust… Non, ils voient un vrai intérêt qui est la sécurité mémoire garantie par Rust. Cela élimine toute une catégorie de bugs qui hantent le code C depuis des décennies, à savoir les buffer overflows, les use-after-free…etc, tout ce folklore de développeur devient impossible avec Rust.

Et Sylvestre Ledru , le développeur principal du projet uutils, n’a pas juste optimisé base64. Par exemple, la commande tr qui était 9,8 fois plus lente que GNU dans les anciennes versions est maintenant 1,58 fois plus rapide par rapport à sa propre version précédente !

Bon après, je vais faire plaisir aux grincheux qui n’aiment pas le changment, oui, tout n’est pas rose non plus. Sur les 600 tests de la suite GNU, Rust Coreutils n’en passe que 500 environ. Il reste donc un peu de boulot pour avoir une compatibilité parfaite. Mais avec l’attention que le projet reçoit en ce moment et le soutien d’Ubuntu, ça devrait s’améliorer rapidement.

Ça fait plaisir de voir ce bon vieux code C qui fait tourner nos systèmes depuis des millénaires est en train d’être challengé par du Rust. Et non pas parce que c’est à la mode, mais parce que dans certains cas, c’est objectivement meilleur : plus rapide, plus sûr, plus maintenable.

Pour les dev parmi vous qui veulent tester, la nouvelle release 0.2.2 est disponible sur GitHub . Et pour ceux qui se demandent si c’est vraiment utile d’optimiser des commandes qui s’exécutent en quelques secondes, rappelez-vous que ces outils sont appelés des milliers de fois par jour dans des scripts, des pipelines CI/CD, des conteneurs Docker… Chaque milliseconde gagnée, c’est donc un gros paquet d’énergie économisée et du temps machine libéré !

Alors, prêts à voir vos vieilles commandes Linux carburer au Rust ?

Source

Ce serait quand même bien quand on réinstalle Linux from scratch pour la énième fois, qu’il y ait un moyen rapide de résinstaller tous nos outils préférés sans avoir à se retaper toutes les commandes d’installation une par une.

Et bien, si vous avez le même rêve que moi, vous allez adore Nixite , un petit outil qui va faire plaisir aux linuxiens.

Le principe est simple. Vous cochez les logiciels que vous voulez installer sur une interface web , et Nixite vous génère un script bash prêt à l’emploi. Ce script gère automatiquement l’installation de tous vos programmes, que vous soyez sur Ubuntu ou Arch Linux.

Ce qui est vraiment cool, c’est que Nixite ne se contente pas d’enchaîner bêtement des commandes apt ou pacman. L’outil choisit intelligemment la meilleure méthode d’installation pour chaque logiciel. Si un programme est mieux maintenu sur Flatpak, il utilisera Flatpak. Si c’est un snap qui est plus à jour, il partira sur snap. Et pour les cas particuliers, il peut même exécuter des commandes bash personnalisées.

L’interface web propose déjà une belle collection de logiciels organisés par catégories : navigateurs web, outils de communication, développement, gaming, productivité… Vous avez Discord, Zoom, VS Code, Steam, GIMP, VLC et des dizaines d’autres. En gros, tout ce dont vous avez besoin pour transformer une installation Linux toute fraîche en un système fonctionnel pour votre boulot.

Chaque logiciel est défini dans un simple fichier TOML dans le dépôt GitHub et vous pouvez spécifier des instructions communes pour toutes les distributions ou des commandes spécifiques pour Ubuntu et Arch. Par exemple :

install_system = "firefox" # Utilisera apt sur Ubuntu, pacman sur Arch

[ubuntu]
install_system = "firefox-esr" # Version spécifique pour Ubuntu

[arch]
install_system = "firefox-developer-edition" # Version pour Arch