49 jours, les amis, c'est la durée de vie d'un Mac avant que son réseau TCP ne s'effondre dans un silence assourdissant. Il suffit d'un overflow d'entier 32 bits dans le kernel XNU, une horloge interne qui se bloque, et hop, plus moyen d'ouvrir la moindre connexion. Le ping marche toujours, parce qu'ICMP se fout du TCP, mais pour le reste... c'est reboot obligatoire ou rien.

Pour savoir combien de temps il vous reste, tapez uptime dans le Terminal. Si votre Mac sous macOS Sequoia, Sonoma ou même Ventura tourne depuis plus de 7 semaines sans redémarrage, c'est le moment d'y remédier car le bug touche toutes les versions.

C'est l'équipe de Photon qui a révélé le problème. Celui-ci est apparu sur une flotte de Macs dédiée à la télémétrie iMessage. Pile 49,7 jours après le dernier redémarrage, plusieurs machines ont lâché en même temps. Plus de nouvelles connexions réseau, mais le ping répondait toujours.

En fouillant le code du noyau XNU d'Apple (qui est open source, faut le rappeler), ils sont tombé sur une variable tcp_now, qui est un compteur 32 bits qui s'incrémente chaque milliseconde. En gros, imaginez un compteur kilométrique qui arrivé au max (environ 4,3 milliards), repasse à zéro.

Sauf que le code contient un garde fou censé empêcher l'horloge de reculer du genre "si la nouvelle valeur est plus petite que l'ancienne, on ne met pas à jour". Ça a l'air malin mais en fait, au moment du rebouclage, patatras : la nouvelle valeur (proche de zéro) est forcément plus petite que l'ancienne (proche du max), du coup le garde fou bloque tout et l'horloge TCP se fige.

Et ensuite, ça part en cascade. Les connexions fermées restent normalement en TIME_WAIT durant 30 secondes sur macOS, avant d'être nettoyées par tcp_gc() mais avec l'horloge gelée, ce nettoyage ne se fait plus. Un netstat -an | grep TIME_WAIT montre alors la catastrophe en temps réel avec des connexions mortes qui s'empilent, et finissent par bouffer les 16 384 ports éphémères (range 49152-65535 sur macOS) restant... Et au bout de quelques heures, plus rien ne passe !

Photon a laissé tourner deux machines après l'overflow pour voir. Neuf heures plus tard, l'une affichait 8 000 connexions zombies et un load average de 49. La machine ne faisait plus que scanner sa propre file d'attente de connexions mortes.

Si ça vous rappelle quelque chose, c'est normal car j'sais pas si vous vous souvenais mais Windows 95 plantait au bout du même délai pour la même raison (le fameux GetTickCount() en 32 bits). Le Boeing 787 avait également un souci similaire au bout de 51 jours sur ses switches réseau, sans oublier le bug de l'an 2038 sous Unix, qui est la version signée du même phénomène. 30 ans séparent certains de ces bugs qui pourtant appartiennent à la même catégorie !

Après flippez pas car des devs avec des Macs à plus de 600 jours d'uptime disent n'avoir jamais eu le souci. À vrai dire, le bug ne se déclencherait que si votre Mac n'a aucun trafic TCP pile au moment de l'overflow. Si votre machine cause au réseau en permanence (et c'est le cas de 99% des Macs), l'horloge passe le cap sans broncher.

Les machines les plus exposées sont en fait les serveurs CI/CD sous macOS, les Mac mini en ferme de build Jenkins ou GitHub Actions, les Mac Pro dédiés au rendu 3D avec Blender ou Cinema 4D. Le MacBook qui passe en veille tous les soirs n'est pas vraiment concerné (le compteur tcp_now ne tourne pas pendant la veille, donc le délai de 49 jours ne concerne que le temps d'activité réel).

Maintenant pour vérifier votre compte à rebours personnel, ouvrez un Terminal et collez y ceci :

boot_sec=$(sysctl kern.boottime | grep -o 'sec = [0-9]*' | head -1 | awk '{print $3}')
now_sec=$(date +%s)
remain=$(( 4294967 - (now_sec - boot_sec) ))
echo "Temps restant avant overflow : $((remain/3600))h $((remain%3600/60))m"

Vous vous souvenez de BadUSB ? Mais siiii, c'est ce truc dévoilé en 2014 à la Black Hat qui avait foutu la trouille à tout le monde. Ça montrait qu'un simple périphérique USB pouvait se faire passer pour un clavier et balancer des commandes à votre place. Hé bien depuis, les attaques se sont bien raffinées et c'est pourquoi un dev vient de proposer un module kernel Linux capable de détecter ces saloperies.

Enfin !

Ce module s'appelle hid-omg-detect et c'est signé Zubeyr Almaho. Le patch (déjà en v2) a été soumis le 4 avril dernier sur la LKML. Alors je pense que vous allez vous dire que c'est encore un truc qui va bloquer par défaut vos périphériques USB sauf que non, ça ne bloque rien. En fait, il surveille passivement les périphériques HID (claviers, souris...) et leur attribue un score de suspicion basé sur trois critères.

D'abord, l'entropie des frappes clavier. Un humain tape de manière irrégulière, avec des pauses, des hésitations, des fautes (perso je fais au moins 3 fautes de frappe par phrase ^^). Un câble trafiqué, lui, balance ses commandes avec une régularité de métronome, genre 500 caractères en 2 secondes sans une seule erreur. Ensuite, y'a la latence entre le branchement et la première frappe. Si votre "clavier" commence à taper immédiatement après avoir été branché... y'a comme un souci. Et enfin, le fingerprinting des descripteurs USB pour repérer les vendor/product IDs suspects ou les anomalies dans les descripteurs HID.

Pas con hein ? Et si le score dépasse un certain seuil (configurable), hop, le module balance un warning dans dmesg et vous oriente vers USBGuard pour bloquer le périphérique. Parce que hid-omg-detect ne touche à rien lui-même. Il sonne juste l'alarme, et c'est à vous d'agir !

Mais alors pourquoi lancer ça maintenant ?

Hé bien parce que les outils d'attaque USB sont devenus légion ! Les câbles O.MG (créés par le chercheur MG et distribués via Hak5), par exemple, ça ressemble à un câble USB lambda que vous emprunteriez sans réfléchir pour charger votre téléphone. Sauf que dedans y'a un implant WiFi capable d'injecter des frappes, de les logger, de spoofer les identifiants USB, le tout contrôlable à distance. Quand je pense qu'il y a quelques mois, des chercheurs montraient qu'une simple webcam Lenovo pouvait être transformée en dispositif BadUSB ... Sa fé grav réchéflir 🤓 comme dirait les citoyens souverains ^^.

Maintenant, en attendant que le patch soit accepté, vous n'êtes pas totalement démunis non plus. Des outils comme USBRip (un script Python, pip3 install usbrip) permettent déjà de tracer les connexions et déconnexions USB en parsant /var/log/syslog. Y'a pas ce scoring d'anomalies, mais au moins vous avez un historique pour savoir qui a branché quoi et quand. Et si vous êtes vraiment parano (et franchement, vous avez raison de l'être), USBGuard peut carrément whitelister vos périphériques de confiance et bloquer tout le reste. Mais le problème d'une telle solution c'est que ça demande de maintenir une liste blanche à jour, ce qui n'est pas toujours pratique quand on branche 15 trucs par jour.

On verra si les mainteneurs du kernel l'accepte... Après ça ne protégera pas contre tous les scénarios non plus. Un périphérique qui attend 30 secondes avant de commencer son injection pourrait passer sous le radar. Et si un attaquant injecte du jitter aléatoire dans ses frappes pour simuler un humain, là ce sera plus compliqué. Mais combiné avec USBGuard, ça donnera enfin une vraie ligne de défense native contre les attaques par périphériques USB piégés . Et c'est quand même mieux que de boucher ses ports au plâtre et ciment (Mais pleure pas au dessus du mortier...) !

Bref, va falloir garder un œil là-dessus.

Source

Google rebuilt Android’s kernel using AutoFDO and real app data, boosting performance, speeding system calls, and improving app launches.

The post Android Performance Boost Could Soon Reach Billions of Devices appeared first on TechRepublic.

Linus Torvalds vient de donner son avis sur l’IA et le vibe coding et ça ne va pas plaire à tout le monde, ahahaha.

Hé oui car pendant que le monde tech se déchire entre les évangélistes de l’IA qui veulent tout automatiser et les énervés qui refusent l’IA par principe idéologique, Linus débarque dans le game avec un avis… de complet normie.

Lors de l’Open Source Summit à Séoul qui vient d’avoir lieu, Linus a partagé sa vision sur l’IA générative et le fameux “vibe coding”. Et son avis, c’est que l’IA c’est juste un outil de plus !

Ah putain, ça fait plaisir de lire ça ! ( Tout comme cet article d’ailleurs )

Le vibe coding, pour ceux qui débarquent, c’est ce terme inventé par Andrej Karpathy d’OpenAI qui consiste à décrire ce que vous voulez coder à un LLM. Ce dernière génère alors le code, et vous testez si ça marche ou si ça marche pas. Et ensuite vous demandez des ajustements et ainsi de suite !

Autant dire que c’est devenu un sujet chaud pour pleiiiins de raisons.

Bref, Linus se déclare “plutôt positif” sur le vibe coding mais uniquement comme point d’entrée en informatique. Pour des petits projets, des prototypes rapides…etc c’est top car ça permet à des gens qui ne savent pas coder de faire des trucs super ! Mais après pour du code critique en production, il est cash en expliquant que ça risque d’être “horrible, horrible d’un point de vue maintenance”. Et je ne peux pas lui donner tort.

Linus n’utilise pas personnellement d’IA pour coder mais il voit bien que des gens testent l’IA pour travailler sur du code critique dans le noyau Linux et ça il s’en méfie à raison car les mainteneurs du kernel se prennent régulièrement des bugs reports et des security notices complètement bidons générés par des gens qui utilisent mal les IA.

Les crawlers IA posent aussi des problèmes techniques sur kernel.org car ces bots qui aspirent tout le code pour nourrir leurs modèles font ramer les serveurs. Quoiqu’il en soit, Linus est plutôt modéré sur le sujet de l’IA générative pour coder et attend avec impatience le jour où l’IA sera un truc moins hype. En gros, qu’on arrête d’en parler H24 et qu’on l’utilise juste quand c’est pertinent…

C’est vrai que d’un côté, vous avez ces fifous pro-IA à toutes les sauces qui pensent qu’on va tous devenir des prompt engineers et que les devs vont disparaître (spoiler : non). Et de l’autre, les donneurs de leçons en pureté technologique qui refusent l’IA en bloc sans jamais se poser la moindre question.

Du coup, je vous avoue que je suis content de voir qu’au milieu de tout ce bordel, y’a ce bon vieux Linus qui nous explique que c’est juste un stupide outil et qu’il faut simplement apprendre à l’utiliser intelligemment.

Créer un système d’exploitation complet from scratch pour s’amuser, c’est le genre de projet un peu foufou qu’on ne voit plus tellement aujourd’hui. Pourtant SkiftOS existe !

SkiftOS c’est un OS écrit entièrement depuis zéro, et pas un n-ième fork de Linux ou d’une distribution BSD. Non, c’est un vrai OS avec son propre kernel, son interface graphique et même les bases d’un moteur de navigateur web.

J’ai découvert ce projet en me baladant sur les Top GitHub et ça m’a rappelé cette époque d’avant ma naissance où créer son OS était un genre de rite de passage pour tous les développeurs passionnés. Sauf qu’ici, on n’est plus dans les années 70 et le projet utilise du C++20 moderne avec une architecture microkernel très propre.

Et malgré son statut de projet “hobby”, il fonctionne réellement. Il tourne pour le moment sur du hardware x86_64 et l’équipe travaille sur le support RISC-V.

L’architecture modulaire du projet est d’ailleurs particulièrement bien pensée. Chaque module a son petit nom, c’est rigolo. Hjert gère le microkernel avec les fonctions essentielles telles que la gestion mémoire, l’ordonnancement et l’IPC (Inter-Process Communication). Karm fournit la bibliothèque C++ de base sans dépendre de la STL (Standard Template Library) . KarmUI propose un framework d’interface réactive. Hideo s’occupe du bureau et de l’environnement graphique. Et Vaev ambitionne de devenir un moteur de navigateur web complet.

Pour compiler tout ça, l’équipe a également développé CuteKit, leur propre système de build qui gère les dépendances et la cross-compilation. Bah oui, quand on réinvente un OS, autant réinventer aussi tous les outils pour le construire.

Cette approche “tout fait maison” rend en tout cas le projet fascinant d’un point de vue pédagogique. Car oui le code source est disponible sur GitHub donc si vous voulez comprendre comment fonctionne un OS moderne sans vous perdre dans les millions de lignes de code de Linux ou de Windows (pour les vieilles versions qui ont leakée), c’est une excellente opportunité pour apprendre. Pas besoin donc d’être Microsoft ou Apple pour développer un système d’exploitation fonctionnel.

Faut “juste” de la motivation, du temps, des compétences en C++ moderne, et surtout l’envie de construire quelque chose de différent.

Vous l’aurez compris, SkiftOS ne remplacera probablement jamais votre OS principal, c’est clair mais pour les développeurs curieux qui veulent comprendre les entrailles d’un système d’exploitation, ou pour ceux qui cherchent un projet open source technique sympa où contribuer, c’est une sacrée mine d’or.

Et qui sait, peut-être que dans quelques années on parlera de SkiftOS comme on parle aujourd’hui des débuts de Linux…