Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

  1. #1
    Chroniqueur Actualités

    Linux 5.10-rc1 se sépare enfin d'une fonctionnalité vieille de plusieurs décennies qui a causé des bogues
    Linux 5.10 fera du problème de l'an 2038 le problème de l’an 2486,
    le réglage de l'horodatage XFS prolonge le temps des systèmes Unix de quelques siècles

    Linux 5.9 a été publié la semaine dernière et l’équipe de développement a déjà démarré les travaux sur la prochaine version du noyau, Linux 5.10. L’équipe continue toujours d’étudier des alternatives pour résoudre le problème de l’an 2038, censé ramener les systèmes Unix en 1901. Pour ce faire, Darrick J. Wong, le responsable du système de fichiers XFS, a soumis des correctifs pour XFS pour Linux 5.10 qui devraient retarder le problème de l'an 2038 pour XFS de 448 années supplémentaires. Cela devrait être suffisant pour trouver une véritable solution à long terme.

    C’est depuis la version 5.6 du noyau, publié en mars dernier, que l’équipe a commencé à proposer des correctifs pour résoudre le problème de l’année 2038. Il s’agit en effet d’un bogue détecté il y a longtemps dans l’encodage du temps sur les systèmes de type Unix, dont Linux, Mac OS, et d’autres systèmes d’exploitation compatibles POSIX. Sur ces systèmes, 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 un système 64 bits, les limites sont supérieures à 292 milliards d’années. Il n’y a donc pas de soucis à se faire ici (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 bogue de l’an 2038 abrégé en anglais Y2038). Bien évidemment, ce ne sera pas la fin du monde.

    Toutefois, 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 puisque le temps est l’un des éléments les plus importants sur les ordinateurs. Avec la version 5.6 du noyau, l’équipe s’est assurée que les systèmes Linux de 32 bits puissent passer l’année 2038 sans ramener l’utilisateur en 1901, mais avec la prochaine version, Linux 5.10, les choses pourraient évoluer encore plus. Mercredi, Wong a envoyé à Linus Torvalds une “grosse pile de nouveaux correctifs pour 5.10”.

    Les correctifs pour XFS pour le noyau Linux 5.10 soumis Wong sont prévus pour retarder le bogue de l'an 2038 de 448 années supplémentaires. « Les changements les plus importants sont deux nouvelles fonctionnalités pour les métadonnées sur le disque : une pour enregistrer les tailles des brèves inodes dans l'AG pour augmenter les contrôles de redondance, mais aussi pour améliorer les temps de montage ; et une seconde fonctionnalité pour prendre en charge les horodatages jusqu'en 2486 », a écrit Darrick Wong dans le mail qu’il a adressé à Torvalds mercredi.

    Les 448 années supplémentaires devraient être suffisantes pour trouver une solution à long terme pour ce problème concernant le système de fichiers XFS. Il existe deux nouvelles fonctionnalités de métadonnées sur disque pour XFS avec Linux 5.10 dans les correctifs soumis par Wong, que voici :

    • la taille des brèves inodes dans le groupe d'allocation est désormais enregistrée. Cela permet d'augmenter les contrôles de redondance et d'accélérer les temps de montage ;
    • prise en charge des horodatages jusqu'en 2486. Cette fonctionnalité de “gros horodatage” consiste à remanier leurs fonctions d'encodage de l'horodatage et des inodes pour traiter les horodatages comme un compteur de nanosecondes de 64 bits et un décalage de bits pour augmenter la taille effective. Cela permet maintenant à XFS de dépasser largement le bogue de l'an 2038 pour passer maintenant à l'année 2486. La mise en place d'un nouveau système de fichiers XFS avec bigtime activé permet d'obtenir une plage d'horodatage allant de décembre 1901 à juillet 2486 plutôt que de décembre 1901 à janvier 2038. Afin de préserver la rétrocompatibilité, la fonction d'horodatage n'est pas activée par défaut.


    Il n'est pas confirmé que les correctifs seront intégrés dans Linux 5.10, mais cela semble très probable. La fenêtre de fusion est ouverte et Darrick J. Wong, employé par Oracle, est le mainteneur XFS, si bien que les correctifs XFS de sa part sont fusionnés par routine.

    Source : Darrick J. Wong

    Et vous ?

    Qu'en pensez-vous ?

    Voir aussi

    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 «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

    Linux 5.6 est disponible avec l'implémentation du VPN WireGuard et la prise en charge d'Arm EOPD

    Linux 5.9 est disponible. Cette version augmente les performances du processeur avec la prise en charge de FSGSBASE, et comporte diverses nouvelles fonctionnalités et améliorations
    Contribuez au club : Corrections, suggestions, critiques, ... : Contactez le service news et Rédigez des actualités

  2. #2
    Membre régulier
    32 bits ? toutes les machines en 2038 ne seront pas 64 bits ?
    Je ne comprends pas bien les enjeux de cet article, puisque la plupart des machines ont des processeurs 64 bits.
    Quels systèmes utilisent encore l'OS en 32 bits ?
    Merci d'avance.

  3. #3
    Expert éminent sénior
    Il y a pas mal de gens qui font tourner Linux sur des machines 32 bits y compris sur des applications pro.
    Ne prenez pas la vie au sérieux, vous n'en sortirez pas vivant ...

  4. #4
    Membre éprouvé
    Linux 32 bits.
    Citation Envoyé par Golfy Voir le message
    Je ne comprends pas bien les enjeux de cet article, puisque la plupart des machines ont des processeurs 64 bits.
    Quels systèmes utilisent encore l'OS en 32 bits ?
    Merci d'avance.
    Je suis sur un projet de maintien en conditions opérationnelles d'un système de traitement de messages (pas plus de détails). Le système a été développé et mis en production en 2008. Ce produit utilise du perl et des bibliothèques compilées dont le code source a été perdu. Les serveurs d'hébergement étant arrivés en fin de vie, il a fallu les remplacer. Ce n'est pas si simple, on ne peut pas prendre ce vieux logiciel avec ses vieilles librairies et l'installer sur un linux récent comme ça. Le logiciel tourne dans des containers Docker, qui en quelque sorte émulent l'ancienne version 32 bits de l'OS d'origine sur une version 64 bits récente de Linux. Mais ce n'est pas tout : tout le traitement des messages est basé sur leur horodatage, qui utilise le Linux Epoch en 32 bits... Le produit a été laissé sans maintenance pendant 10 ans (c'est costaud Linux) mais à un moment donné il faut se poser des questions. Donc j'ai signalé au CDP et au manager que ce système ne passera pas l'an 2038. Ils m'ont répondu, ça va, c'est loin... N'empêche que la précédente période sans maintenance a duré 10 ans...
    Ne crois pas que parce que maintenant tous les CPU sont en 64 bits, que tous les projets peuvent fonctionner comme ça en 64 bits.

  5. #5
    Membre habitué
    Citation Envoyé par Golfy Voir le message
    Je ne comprends pas bien les enjeux de cet article, puisque la plupart des machines ont des processeurs 64 bits.
    Quels systèmes utilisent encore l'OS en 32 bits ?
    Merci d'avance.
    On peut avoir un traitement en 64bits, mais un stockage en 32bits. Les systèmes de fichiers précise la taille des champs stockés sur disque, ce qui fait que l’on peut récupérer un disque formaté sur un système 32bits sur un système 64bits.

    C’est pareil en réseau. Si les équipements ont des champs de taille fixe, une valeur doit être fixée afin que des systèmes différents puissent communiquer (ex : adresses TCP/IP sur 32bits).

  6. #6
    Membre averti
    Citation Envoyé par Pierre Louis Chevalier Voir le message
    Il y a pas mal de gens qui font tourner Linux sur des machines 32 bits y compris sur des applications pro.
    Il y a quelques gens qui utilisent bizarrement des OS 32 Bits sur des machines 64 Bits. Quand aux machines pure 32 Bits, il y en a bien dans des musées, mais j'ai des doutes quand au fait qu'il y en aie encore vraiment en fonction, sauf dans des automates peut-être.

    Les applis 32 Bits quand à elles tournent sur des OS 64 Bits, encore heureux !!

    Quoi qu'il en soit il serait peut-être temps de migrer !! Dans la vie il y a ceux qui prennent les devants et ceux qui traînent des pieds...

  7. #7
    Membre à l'essai
    Il y'a plein de systèmes linux 32 bits dans les systèmes embarqués. Et du coup avec peu de mise a jour.
    ( Routeur, serveur d'impression, etc..)

  8. #8
    Membre actif
    Passage de patate chaude
    En deux mots, ça revient à refiler le bébé avec l'eau du bain aux générations futures lointaines.

    Reste à savoir si l'humanité existera encore dans 4 siècles.
    Et que sera devenu Linux ? Une attraction qu'on trouve dans les musées ?
    Le souci du Timestamp sera devenu une histoire drôle pour se moquer des être primitifs que nous étions, à nous taper des lignes de code interminables...

  9. #9
    Responsable 2D/3D/Jeux

    Je ne pense pas que ce soit de refiler le problème aux générations futures. Vous pourriez utiliser un stockage plus important pour la date (64 bits -> 128 bits, ou plus), mais cela voudrait dire qu'une grande partie de vos programmes vont devoir manipuler des données plus grandes et vont être ralenti. Il faut donc faire un compromis.
    De plus, même si vous utilisez une taille plus grande, il y a toujours un moment où vous avez une taille finie avec une limite. Certes, la limite sera toujours plus loin, mais il y a toujours un développeur dans le futur qui devra faire un nouveau changement.
    En bref, 2486, cela me semble rassurant. Pas de problème à venir. Le problème de 2038 a été pris en charge plutôt très tôt (18 ans avant le possible bug) et l'impact stockage/performances est réduit.
    Vous souhaitez participer à la rubrique 2D/3D/Jeux ? Contactez-moi

    Ma page sur DVP
    Mon Portfolio

    Qui connaît l'erreur, connaît la solution.

  10. #10
    Chroniqueur Actualités

    Linux 5.10-rc1 se sépare enfin d'une fonctionnalité vieille de plusieurs décennies qui a causé des bogues
    Linux 5.10-rc1 se sépare enfin d'une fonctionnalité vieille de plusieurs décennies qui a causé des bogues de sécurité
    et repousse le problème de l'an 2038 à l'an 2486 via un réglage de l'horodatage XFS

    Linus Torvalds a lancé un autre cycle de développement pour le noyau Linux, annonçant la sortie de Linux 5.10-rc1, et cette fois avec une tournure historique. La nouvelle version du noyau marque en fait la fin d'une fonctionnalité vieille de quelques décennies qui a longtemps été rendue redondante après que des développeurs ont découvert qu’elle était à l'origine de bogues de sécurité.

    Il s’agit de set_fs() qui permet au noyau Linux de remplacer les espaces d'adressage, ce qui était une chose pratique à faire avec les processeurs 286 et 386 d'Intel.

    Comme Torvalds l'a expliqué dans sa mise à jour hebdomadaire du noyau, set_fs() contrôle « si une copie de l'espace utilisateur va réellement dans l'espace utilisateur ou dans l'espace noyau ». Cela est important car, comme cela a été détaillé en 2010 dans CVE-2010-4258, il pourrait être utilisé pour « écraser des emplacements de mémoire du noyau arbitraires et obtenir des privilèges ».

    Le bogue a été corrigé, encore une fois en 2010, et au fil du temps, les concepteurs de puces sont passés à des techniques améliorées de gestion de la mémoire. Torvalds a écrit que ce genre de surcharge d'espace mémoire a été banni des architectures x86, powerpc, s390 et RISC-V.

    Mais set_fs(), qui « remonte à peu près à la version originale de Linux » selon Torvalds, a persisté… jusqu'à maintenant.

    « Ce n'est pas un énorme changement, mais c'est intéressant », a écrit Torvalds, ajoutant que « Pour la plupart des gens, cela ne devrait pas avoir d'importance du tout, et c'est principalement une petite note de bas de page historique que 5.10 ne repose plus sur l'ensemble du modèle set_fs (). » Torvalds a estimé que le reste de la version était « assez normal ».

    Avec la fermeture de la fenêtre de fusion de deux semaines, qui précède la sortie de chaque nouvelle itération du noyau Linux, Torvalds a partagé ses réflexions sur la liste de diffusion du noyau Linux, affirmant que « les choses semblent s'être assez bien déroulées » :

    « Le changement le plus intéressant - pour moi - ici est la suppression de setf_fs() de Christoph (il a été fusionné via Al Viro, comme vous pouvez le voir dans mon mergelog ci-dessous). Ce n'est pas un changement énorme, mais c'est intéressant car tout le modèle de set_fs() pour spécifier si une copie de l'espace utilisateur va réellement dans l'espace utilisateur ou l'espace noyau remonte à peu près à la version originale de Linux, et bien que le nom soit entièrement historique ( il n'a pas utilisé le registre de segment %fs depuis longtemps), le concept est resté. Jusqu'à maintenant.

    « Nous avons toujours "set_fs()", et toutes les architectures n'ont pas été converties dans la nouvelle norme, mais ce genre de surcharge d'espace mémoire a été banni des architectures x86, powerpc, s390 et RISC-V et tout le travail de base a été fait dans ce sens. J'espère que d'autres architectures vont également s’éloigner de ce modèle très historique, même si cela pourrait prendre un certain temps pour qu’elles s’en débarrassent.

    « Quoi qu'il en soit, pour la plupart des gens, cela ne devrait pas avoir d'importance du tout, et c'est principalement une petite note de bas de page historique dans laquelle il sera marqué que 5.10 ne repose plus sur l'ensemble du modèle set_fs() ».

    Selon des rapports, cette version apporte environ 704 000 nouvelles lignes de code et a entraîné la suppression de 419 000 lignes, ce qui rend Linux 5.10-rc1 comparable en taille au plus gros noyau de Linux jamais créé (Linux 5.8). « Cela semble être une version plus grande que ce à quoi je m'attendais, et bien que la fenêtre de fusion soit plus petite que celle de la version 5.8, elle n'est pas beaucoup plus petite », a déclaré Torvalds. « Et 5.8 était la plus grosse publication que nous ayons jamais faite ».


    Selon le calendrier typique de Linux, 5.10-rc1 sera suivi de plusieurs semaines de correctifs de résolution de problèmes, avec plusieurs Release Candidate publiées avant la sortie de la version stable du noyau prévue en décembre.

    Les grands changements dans cette version du noyau incluent la fin du support des processeurs PowerPC 601, le support des SOC Orin de Nvidia destiné à être utilisé dans les voitures autonomes et les robots, un meilleur support du pilote graphique dans le processeur Broadcom utilisé dans le Raspberry Pi 4, une atténuation de Spectre pour les processeurs Arm, des ajustements de virtualisation et la résolution du bogue de l'année 2038.

    Depuis la version 5.6 du noyau, publié en mars dernier, l’équipe a commencé à proposer des correctifs pour résoudre le problème de l’année 2038. Il s’agit d’un bogue détecté il y a longtemps dans l’encodage du temps sur les systèmes de type Unix, dont Linux, macOS, et d’autres systèmes d’exploitation compatibles POSIX. Sur ces systèmes, 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 un système 64 bits, les limites sont supérieures à 292 milliards d’années. Il n’y a donc pas de soucis à se faire ici (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 bogue de l’an 2038 abrégé en anglais Y2038). Bien évidemment, ce ne sera pas la fin du monde.

    Toutefois, 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 puisque le temps est l’un des éléments les plus importants sur les ordinateurs. Avec la version 5.6 du noyau, l’équipe s’est assurée que les systèmes Linux de 32 bits puissent passer l’année 2038 sans ramener l’utilisateur en 1901, mais avec la prochaine version, Linux 5.10, les choses pourraient évoluer encore plus. Wong a envoyé à Linus Torvalds une « grosse pile de nouveaux correctifs pour 5.10 ».

    Les correctifs pour XFS pour le noyau Linux 5.10 soumis Wong sont prévus pour retarder le bogue de l'an 2038 de 448 années supplémentaires. « Les changements les plus importants sont deux nouvelles fonctionnalités pour les métadonnées sur le disque : une pour enregistrer les tailles des brèves inodes dans l'AG pour augmenter les contrôles de redondance, mais aussi pour améliorer les temps de montage ; et une seconde fonctionnalité pour prendre en charge les horodatages jusqu'en 2486 », a écrit Darrick Wong dans le mail qu’il a adressé à Torvalds.

    Les 448 années supplémentaires devraient être suffisantes pour trouver une solution à long terme pour ce problème concernant le système de fichiers XFS. Comme l’a noté Linus Torvalds, les correctifs ont été intégrés.

    Source : Linus Torvalds, CVE-2010-4258

    Voir aussi :

    Ubuntu 20.10 « Groovy Gorilla » est disponible avec des images optimisées pour Raspberry Pi, GNOME 3.38, Linux kernel 5.8 et des logiciels préinstallés comme Firefox 81 et LibreOffice 7.0.2
    Quatre packages npm trouvés en train d'ouvrir des shells sur des systèmes Linux et Windows. Tout ordinateur avec l'un de ces packages installés « doit être considéré comme totalement compromis »
    Google et Intel mettent en garde contre un bogue de sécurité sous Linux qui permet d'exécuter un code malveillant via Bluetooth, Intel recommande une mise à jour vers la version 5.9 du noyau
    Le sous-système Windows pour Linux WSL 2 s'accompagne du support des interfaces graphiques d'applications et apporte l'accès aux systèmes de fichiers Linux non pris en charge nativement par Windows
    Contribuez au club : Corrections, suggestions, critiques, ... : Contactez le service news et Rédigez des actualités

  11. #11
    Membre à l'essai
    2^31 secondes font 136 ans ?

  12. #12
    Membre habitué
    Citation Envoyé par thanjuzo Voir le message
    2^31 secondes font 136 ans ?
    Je compte 68 (2^31/3600/24/365,25)

  13. #13
    Membre averti
    Citation Envoyé par floyer Voir le message
    Je compte 68 (2^31/3600/24/365,25)
    En effet, il semble qu'on raisonne sur des nombres signés. Cela conduit à représenter les dates antérieures à 1970 comme des dates négatives, ce qui n'a pas grand sens mais ne change pas grand chose en pratique.

    Par ailleurs la discussion sur le fait de savoir si 64 bits suffiraient est une plaisanterie. L'article rappelle que cela permet 292 milliards d’années (toujours avec des nombres signés, soit 2^31 s après 1970). Très important pour qui sait voir loin !
    La limitation à 2486 tient à une autre raison qui n'est pas expliquée.

    J'aime bien l'euphémisme énoncé avec le plus grand sérieux :
    Les 448 années supplémentaires devraient être suffisantes pour trouver une solution à long terme pour ce problème concernant le système de fichiers XFS.
    D'ici là, s'il y a encore des systèmes informatiques, je pense qu'ils auront un peu changé, comme le note alexetgus.
    Linux Mint 20 Mate.
    1984 est passé, les émules de Big Brother nous surveillent.

  14. #14
    Responsable Systèmes

    c'est bien 68. comme on compte à partir de 1970 1970+68=2038. Si on est en arithmétique signée, le bit de poids fort sert au signe
    Ma page sur developpez.com : http://chrtophe.developpez.com/ (avec mes articles)
    Mon article sur la création d'un système : http://chrtophe.developpez.com/tutor...s/minisysteme/
    Mon article sur le P2V : http://chrtophe.developpez.com/tutoriels/p2v/
    Consultez nos FAQ : Windows, Linux, Virtualisation

  15. #15
    Expert éminent sénior
    Salut,
    Citation Envoyé par Christian_B Voir le message
    En effet, il semble qu'on raisonne sur des nombres signés. Cela conduit à représenter les dates antérieures à 1970 comme des dates négatives, ce qui n'a pas grand sens mais ne change pas grand chose en pratique.

    Par ailleurs la discussion sur le fait de savoir si 64 bits suffiraient est une plaisanterie. L'article rappelle que cela permet 292 milliards d’années (toujours avec des nombres signés, soit 2^31 s après 1970). Très important pour qui sait voir loin !
    La limitation à 2486 tient à une autre raison qui n'est pas expliquée.
    Heu, je présumes que, comme on parle de 64 bits, tu voulais écrire (2^63-1)

    Car il n'y a qu'un seul bit de signe, ce qui ne divise pas les 64 par deux, mais qui y soustrait tout simplement un
    A méditer: La solution la plus simple est toujours la moins compliquée
    Ce qui se conçoit bien s'énonce clairement, et les mots pour le dire vous viennent aisément. Nicolas Boileau
    Compiler Gcc sous windows avec MinGW
    Coder efficacement en C++ : dans les bacs le 17 février 2014
    mon tout nouveau blog

  16. #16
    Membre averti
    Citation Envoyé par koala01 Voir le message
    Salut,
    Heu, je présumes que, comme on parle de 64 bits, tu voulais écrire (2^63-1)
    Car il n'y a qu'un seul bit de signe, ce qui ne divise pas les 64 par deux, mais qui y soustrait tout simplement un
    Oh là là oui, énorme erreur de ma part. Comme je le savais, je préfère attribuer ça à la distraction qu'à d'inquiétants courts-circuits dans mes neurones.
    Linux Mint 20 Mate.
    1984 est passé, les émules de Big Brother nous surveillent.

###raw>template_hook.ano_emploi###