Linux est prêt pour « la fin des temps » : un correctif du bogue de l'an 2038 vient d'être intégré à Linux 5.6

La RC1 de noyau Linux 5.6 a été publiée avec un prise en charge de WireGuard,
Linux 5.6 apporte une solution au problème de l’an 2038 et s'annoncerait comme le plus intéressant depuis des années

Après la publication de la version 5.5 du noyau Linux vers la fin du mois de janvier, Linus Torvalds a publié ce dimanche la première version admissible (première release candidate ou rc1) de Linux 5.6. Il s’agit d’une grosse mise à jour du noyau, car cette version apporte un grand nombre de nouvelles fonctionnalités. Linux 5.6 apporte WireGuard, la norme USB4, le nouveau système de fichiers Zonefs, des améliorations de la sécurité et bien d'autres choses encore. Cette version sera stable dès la fin du mois de mars ou au début du mois d’avril.

La version 5.5 du noyau Linux a été publiée il y a peu de temps, et les développeurs du noyau ont déjà fait un grand travail pour finir la rc1 de la version 5.6. Pour beaucoup dans la communauté, c’est un travail très important qui a été abattu et il est probable que Linux 5.6 soit la version la plus intéressante depuis Linux 5.0. Il y a plein de nouvelles fonctionnalités et d'améliorations dans cette version du noyau et d’autres pourraient venir avant sa version stable prévue dans environ deux mois. Voici un aperçu de ce qu’il y a dans Linux 5.6-rc1.

Prise en charge de WireGuard

David Muller, le mainteneur de la pile réseau de Linux a abordé cette prise en charge depuis le début du mois de décembre dernier. Aujourd’hui, c’est chose faite, WireGuard est officiellement prise en charge par Linux 5.6-rc1. WireGuard est une application logicielle et un nouveau protocole de communication gratuite et open source. C’est un VPN extrêmement simple, mais rapide et moderne qui utilise un chiffrement de pointe. Il est plus rapide, plus simple, plus léger et plus utile qu'IPsec. Il est vu par beaucoup comme un remplaçant potentiel d’OpenVPN.

Pièce jointe 537341

L’ajout des interfaces de chiffrement Zinc nécessaires au réseau privé virtuel WireGuard a commencé depuis Linux 5.5. Pour aller plus loin, WireGuard utilise Curve25519 pour l'échange de clés, ChaCha20 pour le chiffrement, Poly1305 pour l'authentification des données, SipHash pour les clés de la table de hachage et BLAKE2s pour le hachage. Il prend en charge la couche 3 pour IPv4 et IPv6 et peut encapsuler v4-in-v6 et vice versa. WireGuard a déjà été adopté par certains fournisseurs de services VPN comme Mullvad VPN, AzireVPN, IVPN et cryptostorm.

Prise en charge de la norme USB4

La norme USB4 est une technologie qui s’appuie sur la spécification Thunderbolt la plus récente (version 3) et promet des débits maximaux similaires (jusqu’à 40 Gb/s). Elle exploite le connecteur classique USB-C et est rétrocompatible avec les normes USB antérieures, y compris l’USB 3.2 qui double la vitesse maximale d’une connexion USB (de 10 Gb/s à 20 Gb/s), l’USB 2.0 et le Thunderbolt 3 lui-même. L’USB4 permet de brancher des écrans 4K ou 8K en USB. Elle permet de connecter à la chaîne une série de périphériques USB variés sur le même port.
En outre, elle prend en charge l’alimentation de dispositifs affichant une puissance maximale de 100 watts via la fonctionnalité USB Power Delivery.

Résolution du problème de l’an 2038 pour les processeurs 32 bits

Unix et Linux stockent la valeur du temps dans un format d'entier signé de 32 bits qui a la valeur maximale de 2147483647. Au-delà de ce nombre, en raison d'un dépassement d'entier, les valeurs seront stockées sous forme de nombre négatif. Cela signifie que pour un système 32 bits, la valeur du temps ne peut pas dépasser 2147483647 secondes après le 1er janvier 1970. En termes plus simples, après 03:14:07 UTC le 19 janvier 2038, en raison d'un dépassement de nombre entier, l'heure se lira comme étant le 13 décembre 1901 au lieu du 19 janvier 2038.
Le noyau Linux 5.6 a une solution à ce problème pour que les systèmes 32 bits puissent fonctionner au-delà de l'année 2038.

Amélioration du support matériel

Avec la version 5.6 de Linux, le support matériel a également été amélioré. Le plan de prise en charge des nouveaux périphériques sans fil représente une priorité. Le nouveau noyau ajoute déjà la prise en charge de la souris MX Master 3 et d'autres produits Logitech sans fil. Il y a beaucoup d’autres nouvelles fonctionnalités dans Linux 5.6-rc1 qu’on peut classer par catégorie. Voici de quoi il s’agit.

Performance

• mise à jour des plateformes Intel Jasper Lake, Tiger Lake et Elkhart Lake, ainsi que des PCI ID Comet Lake manquantes dans différents pilotes ;
• un nouveau pilote thermique générique pour le refroidissement au ralenti des processeurs ;
• Linux 5.6 prend en charge la version principale d'Amazon Echo ;
• prise en charge de nouveaux SoC et cartes ARM ;
• activation du SoC Intel Gateway ;
• prise en charge du SoC Ingenic X1000 ;
• suppression complète du support de MPX d'Intel ;
• les ordinateurs portables ASUS équipés de processeurs AMD Ryzen cesseront de surchauffer et de tomber en panne ;
• accélération de memmove() pour Intel Ice Lake ;
• diverses améliorations du code x86 ;
• etc.

Graphiques

• NVIDIA GeForce RTX 2000 Turing prend en charge le nouveau pilote open source qui peut offrir une accélération matérielle, mais qui repose toujours sur le micrologiciel binaire. Des modifications doivent encore être apportées au NVC0 Gallium3D pour la prise en charge de l'OpenGL ;
• prise en charge d'AMD Pollock ;
• prise en charge de la réinitialisation AMDGPU pour Renoir et Navi ;
• des améliorations graphiques Intel Gen11 et Gen12 ;
• de nombreuses autres modifications des pilotes DRM ;
• amélioration des pilotes média pour les SoCs Rockchip ;
• etc.

Systèmes de fichiers / Stockage

• support de DISCARD asynchrone pour les Btrfs pour une meilleure efficacité/performance ;
• support de la compression expérimentale pour F2FS ;
• corrections de performance EXT4 ;
• le système de fichiers Zonefs pour les périphériques avec des blocs zonés est un nouveau système de fichiers avec Linux 5.6 ;
• NFSD prend désormais en charge les copies de serveur à serveur en s'appuyant sur le support client NFS précédemment fusionné pour SSC ;
• le client NFS peut désormais utiliser un cache si la connexion au serveur NFS est perdue ;
• corrections pour NVMe et BFQ ;
• amélioration des performances pour FS-VERITY ;
• etc.

Source : Linus Torvalds

Et vous ?

:fleche: Que pensez-vous des nouveautés de la rc1 de la version 5.6 du noyau Linux ?
:fleche: Selon vous, cette version s'annonce-t-elle comme la plus intéressante depuis la version 5.0 ? Pourquoi ?

Voir aussi

:fleche: WireGuard, une application VPN et un nouveau protocole de communication gratuit et open source, a été fusionné dans net-next et est en passe d'être inclus dans la version 5.6 du noyau Linux

:fleche: La version 5.5 du noyau Linux est disponible avec un support pour les stations de travail SGI Octane et Octane II alimentées par MIPS

:fleche: Les spécifications de la norme USB4 viennent enfin d'être publiées par l'USB-IF. Tour d'horizon des nouveautés qu'elle introduit

:fleche: Le «bug de l'an 2000» se reproduira en 2038 dans le monde Linux, mais c'est maintenant qu'il faut s'inquiéter selon Jon Corbet

:fleche: Sortie de la version 5.4 du noyau Linux avec l'ajout d'un mode de verrouillage du noyau, d'une couche de sécurité pour détecter les modifications de fichiers et plusieurs autres améliorations

Bien traduit, et sujet bon, bravo!

Je suis vraiment désolé pour les gens de la communauté de la cryptographie mais les noms des technologies utilisées m'ont donné l'impression d'être sur un chat IRC de "rencontres" et j'arrive pas à m'en défaire :ptdr:.

Par contre, je serais bien curieux de connaître la solution adopté pour le timestamp, ils ont juste changé un entier 32 bit sur 64 bits ou ils ont fait autre chose ?

Citation:

---

Envoyé par Bill Fassinou

Résolution du problème de l’an 2038 pour les processeurs 32 bits
(...) la valeur du temps dans un format d'entier signé de 32 bits qui a la valeur maximale de 2147483647. Au-delà de ce nombre, en raison d'un dépassement d'entier, les valeurs seront stockées sous forme de nombre négatif.

Graphiques
- NVIDIA GeForce RTX 2000 Turing prend en charge le nouveau pilote open source qui peut offrir une accélération matérielle, mais qui repose toujours sur le micrologiciel binaire.

---

Il n'y a que moi que ça fait tilter l'usage de "pilote open-source" avec "repose sur un binaire" ?

J'ai eu un doute sur l'explication opaque du problème de 2038, tantôt signé, tantôt entier... voici mon explication d'électronicien, qui je pense sera plus claire.
Pour interpréter un "entier signé", on interprète chaque bit comme ceux d'un "entier non signé", à l'exception du dernier bit, celui de plus gros poids, a qui l'on assigne en plis de sa valeur entière, le signe "moins".
Un entier signé de 32 bits possède donc une valeur "entière non signé" sur ses 31 premiers bits. Le dépassement 2'147'483'647, qui correspond à 31 bits à "un", fait donc nécessairement usage du 32ième bit, qui est négatif, et représente la "poids" le plus important dans la valeur que cet entier peut prendre.
--> un entier signé avec tout les bits à "1" vaut toujours "-1", car le bit suivant vaut la somme de tous les précédant +1, et le MSB est négatif dans un entier signé. Puisque c'est un mécanisme par incrémentation binaire, le passage à l'usage du 32e bits correspond à la valeur la plus basse -[2'147'483'647 +1], puis tant vers 0.


Ma grande incompréhension est : pourquoi y a t-il nécessiter de faire usage à des entiers signés pour les valeurs calendaires ? est-ce un maque de rigueur ou la conséquence d'une contrainte technique ?

Linux est prêt pour « la fin des temps » : un correctif du bogue de l'an 2038 vient d'être intégré à Linux 5.6 qui doit sortir et permettra aux systèmes 32 bits de fonctionner après 2038,
mais les travaux ne sont pas encore achevés

Voici maintenant plusieurs années qu’un bug a été détecté dans l’encodage du temps sur les systèmes de type Unix, notamment Linux, Mac OS, et autres systèmes d’exploitation compatibles POSIX. Sur Unix et les systèmes dérivés, le calcul du temps est effectué en fonction des secondes écoulées à partir du 1er janvier 1970 à 00:00:00 UTC (nommée également epoch). Un jour donnera par exemple 86 400 secondes et une année 31 536 000 — secondes. Et plus les années passeront, plus il faudra de nombres pour représenter les dates. Pour effectuer le décompte sur ces systèmes, lorsque la fonction time() est appelée, elle retourne un entier signé de type "time_t​". Si le système est 32 bits, la valeur retournée est un entier signé 32 bits et si le système est 64 bits, la valeur retournée est 64 bits.

Sur une machine 64 bits, les limites du type de données sont supérieures à 292 milliards d’années. À ce niveau donc, le monde technologique n’a pas de soucis à se faire (ce sera beaucoup plus que l'âge de notre planète ou l'estimation de son espérance de vie). Mais sur les systèmes 32 bits, le nombre de secondes total que la fonction peut retourner est 2³¹ – 1, c’est-à-dire environ 68 ans. La date de référence étant le 1er janvier 1970 à 00:00:00 UTC, la date minimale représentable est le vendredi 13 décembre 1901 et la date maximale représentable est le mardi 19 janvier 2038 à 3 h 14 min 8 s. Lorsqu’il sera 3 h 14 min 8 s le 19 janvier 2038, le système passera au 13 décembre 1901 à la seconde suivante (également appelé le bug de l’an 2038 abrégé en anglais Y2038). Bien évidemment, ce ne sera pas la fin du monde, mais les systèmes 32 bits de la famille UNIX qui seront encore basés sur cet encodage seront fortement perturbés au point de ne plus pouvoir fonctionner correctement dans la mesure où un des éléments très importants sur les ordinateurs est le temps.

Pièce jointe 539761

Voyant que 2038 approche et aucune solution n’a été publiée, Jon Corbet, chroniqueur de longue date du noyau Linux, a exprimé en 2015 son inquiétude par rapport à ce problème. Il déclara lors du sommet de collaboration de la fondation Linux à Santa Rosa en Californie qu’« il est temps de commencer à s’inquiéter ». Pour mieux se faire comprendre, il expliqua que « les systèmes basés sur Linux sont implémentés dans des voitures, dans la construction de systèmes de contrôle, dans les centrales électriques, et dans, qui sait combien, plusieurs autres endroits où ils y seront tout simplement placés et feront leur travail jusqu’à ce time_t vienne à manquer de bits. Et alors ils ne fonctionneront plus ».

L’équipe de Linux a pris depuis longtemps ce problème très au sérieux et vient d’intégrer un correctif dans la version 5.6 de Linux qui sera mis à la disposition du public. Dans son message de présentation des changements, Arnd Bergmann, qui fait partie de l’équipe de développement Linux rassure qu’il a parcouru toutes les instances de time_t et confirme qu’elles ont été remplacées par des alternatives sures. En conséquence, déclare-t-il, « Linux-5.6, ou mon backporting des correctifs vers 5,4 [1], devrait être la première version pouvant servir de base à un système 32 bits conçu pour fonctionner au-delà de l’année 2038 ». Toutefois, certains changements doivent être apportés à plusieurs niveaux :

• Tout l’espace utilisateur doit être compilé avec un time_t 64 bits, qui sera pris en charge dans les prochaines versions de musl-1.2 et glibc-2.32, ainsi que les entêtes de noyau installés de linux-5.6 ou supérieur ;
• les applications qui utilisent directement les interfaces d’appel système doivent être portées pour utiliser les appels système time64 ajoutés dans linux-5.1 à la place des appels système existants. Cela affecte la plupart des utilisateurs de futex () et seccomp () ainsi que les langages de programmation qui ont leur propre environnement d’exécution non basé sur libc ;
• les applications qui utilisent une copie privée des fichiers d’entête uapi du noyau ou de leur contenu peuvent nécessiter une mise à jour vers la version linux-5.6, en particulier pour sound/asound.h, xfs/xfs_fs.h, linux/input.h, linux/elfcore.h, linux/sockios.h, linux/timex.h et linux/ can / bcm.h ;
• quelques interfaces restantes ne peuvent pas être modifiées pour faire passer un time_t 64 bits de manière compatible. Elles doivent donc être configurées pour utiliser des heures CLOCK_MONOTONIC ou (avec un problème y2106) des horodatages 32 bits non signés. Plus important encore, cela affecte tous les utilisateurs de 'struct input_event' ;
• tous les problèmes y2038 qui sont présents sur les machines 64 bits s’appliquent également aux machines 32 bits. En particulier, cela affecte les systèmes de fichiers avec des horodatages sur disque utilisant des secondes 32 bits signés : ext4 avec de petits inodes de style ext3, ext2, xfs (à corriger bientôt) et ufs.

Source : LKML

Et vous ?

:fleche: Comment accueillez-vous cette nouvelle ?

:fleche: Pensez-vous que certains systèmes de la famille n'arriveront pas à corriger ce problème jusqu'en 2038 ?

:fleche: Le « bug de l’an 2000 » se reproduira en 2038 dans le monde Linux, mais c’est maintenant qu’il faut s’inquiéter selon Jon Corbet
:fleche:Apple sort iOS 11.2.6 pour corriger un bogue lié à un caractère indien qui fait planter l’OS et les applications de messagerie
:fleche:Un bogue dans un code Python pourrait avoir causé des erreurs de calcul dans plus d’une centaine d’études scientifiques publiées depuis 2014
:fleche:Apple, Microsoft et Orange victimes d’un bogue de l’an 2011, avez-vous constaté d’autres dysfonctionnements du même type ?
:fleche:Après le passage au Nouvel An, plusieurs entreprises connaissent le bogue de l'année 2020 nommé Y2K20, à cause d'une solution paresseuse utilisée pour corriger le bogue du millénaire

Ça a l'air un peu laborieux :

• Déjà il faut upgrader vers 5.6
• En plus il faut faire quelques règlages de builds

Autrement dit :

• Cela est utile que pour ceux qui feront leur travaux aujourd'hui du 32 bits
• Cela peut-être utiliser que pour ceux qui pensent à 2038 et qui persistent aujourd'hui à rester sur du 32 bits
  
  

N'étant pas du domaine, je pense quand même que dans l'embarqué cela peut être justifié, et on peut espérer qu'ils s'en soucieront. Pour ceux qui font des développements plus classiques, s'ils prennent encore du 32 bits aujourd'hui, je suis très sceptique sur le fait qu'ils pensent à gérer le problème de l'an 2038.


Par contre :

Citation:

---

Sur une machine 64 bits, les limites du type de données sont supérieures à 292 milliards d’années. À ce niveau donc, le monde technologique n’a pas de soucis à se faire.

•tous les problèmes y2038 qui sont présents sur les machines 64 bits s’appliquent également aux machines 32 bits. En particulier, cela affecte les systèmes de fichiers avec des horodatages sur disque utilisant des secondes 32 bits signés : ext4 avec de petits inodes de style ext3, ext2, xfs (à corriger bientôt) et ufs.

---

Cela se contredit un peu tout de même, je pensais vraiment qu'on était tranquille avec le 64 bits, mais en fait non.

Citation:

---

Envoyé par walfrat

Cela se contredit un peu tout de même, je pensais vraiment qu'on était tranquille avec le 64 bits, mais en fait non.

---

Un OS 64 bits signifie simplement que tes adresses ont une taille de 64 bits, je ne vois pas ce que cela à avoir avoir avec la taille de stockage d'une donnée?

Li'dée c'est que tel que c'est dit, on peut avoir l'impression que tant qu'on a une machine 64 bits on aura pas de problème, au sens global.

C'est vrai dans le cas d'un appel au timestamp du système, mais on voit que certains composant Linux restent concernés.

espérons qu'entre le réchauffement climatique , l'émergence de nouveaux virus (biologiques) et les effets de la réforme des retraites, nous ayons tout de même le luxe de nous préoccuper des bugs de dates en 2038

Citation:

---

Envoyé par walfrat

Cela se contredit un peu tout de même, je pensais vraiment qu'on était tranquille avec le 64 bits, mais en fait non.

---

Citation:

---

Envoyé par Andarus

Un OS 64 bits signifie simplement que tes adresses ont une taille de 64 bits, je ne vois pas ce que cela à avoir avoir avec la taille de stockage d'une donnée?

---

Vous avez mal compris, ce qu'il faut comprendre est que les "architectures" 64bit sont concernés si elles utilisent des "formats" de données sur 32bit.
De la même manière qu'un PC 64bit faisant tourner un Windows 32bit, hérite de toutes les limitations découlant du fonctionnement sur 32bit. Au passage, beaucoup de PC dans les TPE étaient installés en 32bit, car cela permettait une économie d'usage de RAM jusqu'à 20% par rapport au même matériel sous 64bit. Cela permettait certaines économies avant de renouveler le matériel (ex: ne pas remplacer les barrettes RAM afin d'augmenter la capacité pour fonctionner sans heurts).

Un ordinateur 64bit, avec un linux 64bit est donc également concerné dès lors qu'il utilise des données sur 32bit. Le problème est logiciel.

Citation:

---

Envoyé par Steinvikel

Vous avez mal compris, ce qu'il faut comprendre est que les "architectures" 64bit sont concernés si elles utilisent des "formats" de données sur 32bit.
De la même manière qu'un PC 64bit faisant tourner un Windows 32bit, hérite de toutes les limitations découlant du fonctionnement sur 32bit. Au passage, beaucoup de PC dans les TPE étaient installés en 32bit, car cela permettait une économie d'usage de RAM jusqu'à 20% par rapport au même matériel sous 64bit. Cela permettait certaines économies avant de renouveler le matériel (ex: ne pas remplacer les barrettes RAM afin d'augmenter la capacité pour fonctionner sans heurts).

Un ordinateur 64bit, avec un linux 64bit est donc également concerné dès lors qu'il utilise des données sur 32bit. Le problème est logiciel.

---

Je suis d'accord avec ce que tu dis, cependant mes propos ne visaient que ce qui concerne directement Linux, je ne parlais évidemment pas des logiciels que des entreprises ont développés et ont laissé en 32 bits dessus. Cela bien qu'étant un problème est le problème du développeur du dit logiciel et pas de ceux qui contribue à Linux.

Citation:

---

lorsque la fonction time() est appelée, elle retourne un entier signé de type "time_t​". Si le système est 32 bits, la valeur retournée est un entier signé 32 bits et si le système est 64 bits, la valeur retournée est 64 bits.
(...)
les systèmes 32 bits de la famille UNIX qui seront encore basés sur cet encodage seront fortement perturbés au point de ne plus pouvoir fonctionner correctement dans la mesure où un des éléments très importants sur les ordinateurs est le temps.

---

Le contournement :
- forcer l'usage d'une variable sur 64bit pour time_t
- utiliser des horodatages 32 bits non signés (avec une limite en l'an 2106, en place de 2038)
NB : tous les problèmes y2038 qui sont présents sur les machines 64 bits s’appliquent également aux machines 32 bits. (cette affirmation est étrange, on dirait que 64 et 32 ont été inversé)
En particulier, cela affecte les systèmes de fichiers avec des horodatages sur disque utilisant des secondes 32 bits signés : ext4 avec de petits inodes de style ext3, ext2, xfs (à corriger bientôt) et ufs.

Je trouve plutôt surprenant qu'une variable destiné à contenir des entiers strictement positifs ai été implémenté par un entier "signé". De plus, même avec du matos 64bit, si le FS (système de fichier) utilise un horodatage sur 32bit, le problème persiste. C'est sur ces propos que mon affirmation porte : "Le problème est logiciel."
A mon sens, le problème porte donc sur les contributeurs de Linux pour avoir utilisé un entier signé, ainsi que les système de fichier 64bit comportant un horodatage de 32bit.

Néanmoins, je doute que ces aspects soient de simples étourderies... il est certainement question de concession. Je ne suis pas suffisamment familier avec se domaine précis pour apporter plus de réponse. ^^'

Citation:

---

Je trouve plutôt surprenant qu'une variable destiné à contenir des entiers strictement positifs ai été implémenté par un entier "signé"

---

Peut-être tout simplement pour gérer des dates antérieures à EPOCH, représentées par des valeurs négatives donc nécessité d'arithmétique signé.

Si c'est la raison, c'est dommage d'avoir retenu cette solution. =/
...parmi toutes celles qui existent (mais qui demandent plus de travail).

bien sur ça surprend de penser à des environnements en 32 bits en 2038, quoique j'ai revendu pour un petit prix il y a 2 ans une rare carte avec 2 sorties paralelles ou série je me souviens plus pour une très vieille machine de gravure fonctionnant encore en dos et visiblement en 16 bits, un port correspondant au logiciel avec son mot de passe l'autre à la machine, une machine devenue introuvable et la dame aurait du fermer boutique.
Ces vieilles machines ou lignes de production mécaniquement et électroniquement bien faites (automates, surveillance) risquent de perdurer au dela de 2038.
Bien sur ce qu'on fabrique maintenant si on atteint 2030 c'est un miracle!