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 5.10-rc1 se sépare 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

Le , par Stéphane le calme

145PARTAGES

12  0 
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

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

Avatar de thanjuzo
Membre à l'essai https://www.developpez.com
Le 01/11/2020 à 11:24
2^31 secondes font 136 ans ?
0  0 
Avatar de floyer
Membre habitué https://www.developpez.com
Le 01/11/2020 à 13:04
Citation Envoyé par thanjuzo Voir le message
2^31 secondes font 136 ans ?
Je compte 68 (2^31/3600/24/365,25)
0  0 
Avatar de Christian_B
Membre averti https://www.developpez.com
Le 09/11/2020 à 13:20
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.
0  0 
Avatar de chrtophe
Responsable Systèmes https://www.developpez.com
Le 09/11/2020 à 13:57
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
0  0 
Avatar de koala01
Expert éminent sénior https://www.developpez.com
Le 18/11/2020 à 9:24
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
0  0 
Avatar de Christian_B
Membre averti https://www.developpez.com
Le 19/11/2020 à 11:20
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.
0  0