Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

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 et permettra aux systèmes 32 bits de marcher après 2038
Les travaux sont encore en cours

Le , par Olivier Famien

589PARTAGES

18  0 
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 231 – 1, c’est-à-dire environ 136 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.


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 ?

Comment accueillez-vous cette nouvelle ?

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

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
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
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
Apple, Microsoft et Orange victimes d’un bogue de l’an 2011, avez-vous constaté d’autres dysfonctionnements du même type ;?
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

Une erreur dans cette actualité ? Signalez-le nous !

Avatar de walfrat
Membre éprouvé https://www.developpez.com
Le 19/02/2020 à 13:03
Ç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 :


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.
2  0 
Avatar de Aspartame
Membre averti https://www.developpez.com
Le 19/02/2020 à 22:46
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
2  0 
Avatar de Andarus
Membre averti https://www.developpez.com
Le 19/02/2020 à 13:48
Citation Envoyé par walfrat Voir le message

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?
1  0 
Avatar de walfrat
Membre éprouvé https://www.developpez.com
Le 19/02/2020 à 15:54
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.
1  0 
Avatar de Steinvikel
Membre émérite https://www.developpez.com
Le 20/02/2020 à 0:01
Citation Envoyé par walfrat Voir le message
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 Voir le message
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.
2  1 
Avatar de Steinvikel
Membre émérite https://www.developpez.com
Le 22/02/2020 à 12:29
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. ^^'
1  0 
Avatar de chrtophe
Responsable Systèmes https://www.developpez.com
Le 23/02/2020 à 10:00
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é.
1  0 
Avatar de walfrat
Membre éprouvé https://www.developpez.com
Le 20/02/2020 à 13:24
Citation Envoyé par Steinvikel Voir le message
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.
0  0 
Avatar de Steinvikel
Membre émérite https://www.developpez.com
Le 25/02/2020 à 18:42
Si c'est la raison, c'est dommage d'avoir retenu cette solution. =/
...parmi toutes celles qui existent (mais qui demandent plus de travail).
0  0 
Avatar de pemmore
Membre régulier https://www.developpez.com
Le 29/02/2020 à 11:19
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!
0  0