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 !

La RC1 du noyau Linux 5.6 a été publiée avec une 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

Le , par Bill Fassinou

43PARTAGES

24  1 
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.


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 ?

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

Voir aussi

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

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

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

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

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

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

Avatar de MaximeCh
Membre éprouvé https://www.developpez.com
Le 10/02/2020 à 16:57
Bien traduit, et sujet bon, bravo!
4  0 
Avatar de walfrat
Membre confirmé 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 confirmé 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 confirmé https://www.developpez.com
Le 11/02/2020 à 10:25
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 .

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 ?
1  1 
Avatar de Steinvikel
Membre émérite https://www.developpez.com
Le 12/02/2020 à 4:31
Citation Envoyé par Bill Fassinou Voir le message
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 ?
0  0