Sortie de Linux 3.15

Pause Café
#1

Bonjour à tous

La version 3.15 de Linux est sortie il y a quelques jours.

On peut noter les améliorations suivantes :

[ul][li]la gestion des EFI (= les nouveaux BIOS) 32 bits sur les architectures 64 bits : il était compliqué de faire démarrer une machine sous Linux 64 bits lorsque l’EFI était en 32 bits. Voilà qui devrait nous simplifier la vie sur certaines machines ;

[/li]
[li]l’amélioration de la prise en charge du changement de luminosité sur les ordinateurs portables : il y avait pas mal de bugs à ce sujet ;

[/li]
[li]pilote libre “radeon” pour les cartes graphiques AMD/ATI : l’encodage vidéo matériel est maintenant supporté, ce qui accélèrera la conversion des vidéos au format H.264 ;

[/li]
[li]pilote libre “i915” pour les cartes graphiques Intel : amélioration de la gestion de l’affichage sans clignotement au démarrage de la machine : cette fonctionnalité n’est pas activée par défaut car il reste des bugs. On peut passer l’option “i915.fastboot=1” au démarrage du noyau si l’on souhaite la tester ;

[/li]
[li]pilote libre “nouveau” pour les cartes graphiques Nvidia : début de la prise en charge des cartes “Maxwell” + élimination de beaucoup de bugs dans la gestion automatique de la ventilation. On notera qu’un salarié de Nvidia (français, cocorico !) a contribué à ce patch. S’il n’y a donc toujours aucune volonté de Nvidia d’écrire des pilotes libres pour Linux (et ce n’est apparemment pas près d’arriver), on peut au moins compter sur certains de leurs salariés pour contribuer au code libre de “nouveau” ;

[/li]
[li]une bien meilleure protection contre les dénis de service : une amélioration de la gestion des verrous a permis de multiplier par presque 3 le nombre connexions par seconde qu’un serveur peut gérer !! Autant dire que les administrateurs réseau devraient se dépêcher d’utiliser cette nouvelle version !

[/li]
[li]une forte accélération de la sortie de veille pour les machines qui utilisent du SATA : plutôt que d’attendre que le contrôleur SATA soit réveillé pour s’occuper de réveiller le reste du système, on fait les deux en parallèle. Ce patch a permis de diviser par 7 à 12 fois le temps de réveil d’une machine !! Je me souviens qu’une version 2.6.3x avait déjà considérablement réduit le temps de réveil, donc le temps de sortie de veille devrait maintenant être quasiment instantané ! (les tests montrent qu’on passé allègrement de 5 secondes à 0,4 secondes par exemple) D’ailleurs je serais intéressé de savoir ce qu’il en est pour vous lorsque ce kernel sera disponible dans les backports. J’imagine que si on a des SSD on ne voit pas trop la différence, mais avec des disques durs le temps de réveil est souvent assez long (plusieurs secondes). Pour ma part, j’ai 2 disques durs en RAID 0, ce qui oblige le système à les réveiller les 2 pour pouvoir sortir de la veille. Je devrais donc sentir un vrai gain de ce côté là (je vous dirai ce qu’il en est en pratique) ;

[/li]
[li]le système de fichiers du futur, Btrfs, tend à se stabiliser avec beaucoup de corrections de bugs. Cela fait 7 ans qu’il est en développement. Il a été récemment déployé dans une ferme de serveurs de test chez Facebook, ce qui a permis d’éliminer tous ces bugs.[/li][/ul]

Comme d’habitude, vous pouvez retrouver plus de détails ici : linuxfr.org/news/sortie-du-noyau-linux-3-15

#2

Salut,

L’amélioration de la sortie de veille est sans doute très sensible, mais à condition de pouvoir passer en mode veille !

L’écran s’éteint puis se rallume (en gris presque noir) pendant une quinzaine de secondes, puis recommence. Il ne me reste plus qu’a couper le courant et ainsi avoir de jolis messages au boot suivant.
C’est vrai que je ne suis pas sous Gnome :laughing:

#3

bonjour,
la 3.15 est disponible pour toutes les architectures comme la 3.14,
c’est volumineux
salutations
A+
JB1

#4

[quote=“jb1”]bonjour,
la 3.15 est disponible pour toutes les architectures comme la 3.14,
c’est volumineux
salutations
A+
JB1[/quote]
Pas dans les rétroportages de Debian en tout cas ?

packages.debian.org/wheezy-backports/kernel/

#5

bonjour,
j’enlève toutes les versions ne concernant pas mon processeur,
et je manipule en faisant référence au wiki
A+
JB1

#6

C’est bien de faire référence au wiki, aurais-tu un lien pour moi ?

#7

bonjour,

http://www.isalo.org/wiki.debian-fr/Noyau_%28Kernel%29

attention au ln -s vers /usr/src/linux
A+
JB1
:030

#8

Je pense que tu te trompes, de même que l’article sur linuxfr se trompe :

[quote]
Les dénis de service, consistant à surcharger un serveur par un nombre impressionnant de connexions, sont très courants sur Internet. Parmi ceux-ci, un grand classique est le bon vieux SYN flood. Sur un pare-feu à états, chaque paquet ajoutera une connexion à suivre, et il faut être capable de les gérer.

Chez Linux, ce suivi est effectué par la table conntrack. Cette table était protégée par un verrou central pour les insertions et les suppressions. Et ce verrou devenait avec le temps un énorme frein (un peu comme le Big Kernel Lock, à échelle très réduite).

Le nouveau noyau introduit donc un verrouillage plus fin, avec 1 024 verrous et une table de hachage pour savoir quel verrou utiliser. L’amélioration de performance est spectaculaire, si vous avez le matériel qui va avec. Avec un bon processeur et un réseau à 10 Gbit/s, le testeur est passé d’une gestion de 810 405 connexions par seconde à 2 233 876, soit une amélioration d’un facteur de presque trois.[/quote]

La solution est de ne pas utiliser ce genre de parefeu sans savoir l’utiliser :slightly_smiling:
Par exemple, mettre du conntrack sur un port sans serveur est contre-productif;

#9

Quel est le rapport ? Tu peut faire un DOS en attaquant un service existant (même si aujourd’hui c’est pas mal les firewall eux-même qui se font attaquer).

Le paragraphe présente peut être les choses de manière un peu orienté et ça s’explique bien par le message de commit.

#10

Ben, donc si tu te fait ddos un service, c’est généralement le service qui va prendre cher avant le firewall, non ?
810 405 connexions par seconde, je me demande si y’a beaucoup de service qui peuvent endurer cette charge;

#11

Haleth, il est tout à fait possible que je me trompe, mais est-ce que tu peux nous expliquer en quoi exactement ? Je ne comprends pas. Merci

#12

Ben dans ma tête, conntrack n’a rien à voir avec une quelconque protection contre les dos

#13

La conntrack est une table de suivi des connexions. Même s’il n’y a pas de règles iptables l’utilisant, elle est tout de même utilisée pour gérer entre autres la poignée de main TCP. À chaque fois que la machine reçoit un SYN, elle garde dans la table le numéro de séquence pour pouvoir continuer la poignée de mains.
L’attaque consiste à envoyer un flot de paquets SYN, pour remplir la table (de taille /proc/sys/net/ipv4/netfilter/ip_conntrack_max). Étant seulement sur la couche TCP, l’attaque ne charge pas le service qui écouterait sur le port attaqué, mais empêche l’établissement de connexions légitimes au dit service, en remplissant la table du suivi de connexions.

Ce que je comprends de l’article de linuxfr, c’est qu’il n’est pas nécessaire de remplir totalement la conntack pour faire un DOS, car elle utilise un système de verrou qui va faire saturer les insertions/suppressions dans la table. Le kernel 3.15 impose alors un système de vérrou optimisé, permettant d’encaisser beaucoup plus de paquets dans le cas d’une attaque par SYN flood. Mais si l’attaquant dispose d’assez de ressources, il peut tout de même arriver à remplir la table.

#14

Comment fonctionne Linux pour faire du TCP sans le module conntrack ?

#15

Le suivi de connexion de netfilter (conntrack) n’intervient pas dans la gestion des connexions par la pile TCP/IP. Il ne sert que pour les règles iptables. Ce sont deux choses complètement différentes.

kna : une attaque de conntrack peut se faire sur un autre protocole que TCP. Conntrack suit tous les protocoles, pas seulement TCP.

#16

Tout ce qui est utilisé lors d’une connexion d’un point à A un point B peut être attaqué. C’est le point le plus faible qui défini la force de l’ensemble. On a commencé en parlant surtout du service destinataire, mais on voit de plus en plus d’attaques sur les éléments du réseau que ce soit les routeurs ou les parfeux. On peut faire un DOS en faisant exploser un réseau ethernet ou wifi par exemple.

Donc tout ce qui permet d’améliorer la performance de ces éléments permet de réduire le risque d’attaque.

#17

Bonjour,
le petit dernier en 3.15

root@alpha30:~# uname -a
Linux alpha30.bohain.org 3.15.0-rc8-20140615 #1 SMP Sun Jun 15 18:43:26 CEST 2014 x86_64 GNU/Linux
root@alpha30:~#

je n’ai pas trouvé de changement dans la vitesse avec speedtest
bonne journée
A+
JB1
:041 pour les changeurs de palier

#18

[quote=“jb1”]
je n’ai pas trouvé de changement dans la vitesse avec speedtest[/quote]
Pourquoi, t’as mis ton ordi sur des roulettes ?

#19

bonjour,
pour écluser 2.3M messages par second, il faut du répondant.
avec IN, ils vont être content

je pensais malgré tout voir une petite variation

dommage je n’ai pas de carte Ip 10G/s
A+
JB1

#20

“une amélioration de la gestion des verrous a permis de multiplier par presque 3 le nombre connexions par seconde qu’un serveur peut gérer”.

Question de newbie mais plutôt que d’augmenter le nombre de “requêtes” que conntrack peut encaisser, ne faudrait-il pas mieux améliorer l’interprétation d’un déni de service?

Car passer de 810 405 connexions par seconde à 2 233 876, c’est juste repousser la limite, mais quelle difficulté empêchera une attaque d’atteindre 2 233 876 connexions?

Ne serait-il pas plus simple que les équipements pistent mieux les symptômes d’un déni de service pour le bloquer en amont?