Sortie du noyau Linux 4.9

92
8
fév.
2017
Linux

La sortie de la version stable 4.9 du noyau Linux a été annoncée le dimanche 11 décembre 2016 par Linus Torvalds. Le nouveau noyau est, comme d’habitude, téléchargeable sur les serveurs du site kernel.org.

Le détail des évolutions, nouveautés et prévisions est dans la seconde partie de la dépêche (qui est sous licence CC BY-SA).

Les deux filles nerds implémentent BBR, un nouvel algorithme d’évitement de congestion TCP pour remplacer les douze autres algorithmes. Mais, à la fin, l’algorithme BBR, intégré dans Linux 4.9, n’est pas le meilleur dans tous les cas. Et les filles se rendent compte que maintenant elles font face à treize algorithmes et aucun pour remplacer les autres dans tous les cas !

Sommaire

Annonces des versions candidates par Linus Torvalds

RC-1

La version RC-1 est sortie le samedi 15 octobre 2016 :

Habituellement, je fais mes publications le dimanche après‐midi, mais de temps en temps, je raccourcis la fenêtre d’intégration d’un jour, pour garder les gens en alerte et m’assurer qu’ils ne se mettent pas à envoyer leurs demandes d’intégration [N. D. T. : pull requests] à la dernière minute. Ce n’est pas le dernier jour qu’on s’amuse à jouer avec la fenêtre d’intégration. Idem pour celle‐ci.

Pour être honnête, la raison qui m’a poussé à la sortir un jour plus tôt pour cette fois‐ci est moins d’empêcher les gens de jouer contre la montre avec leurs contributions, mais bien plus parce que cette fenêtre d’intégration était plutôt imposante et pas particulièrement réjouissante. J’ai dû arrêter la fusion par deux fois pendant cette fenêtre d’intégration, uniquement parce que je traquais divers problèmes. C’est ce qui a tendance à faire passer ma période d’activité sur la fenêtre de fusion du mode « occupé » à « légèrement stressant ».

Mais, bon, tout va bien maintenant. Et, même si la 4.9 semble être une grosse version et que nous avons eu quelques couacs, dans l’ensemble, les choses semblent normales. La grande nouveauté est l’ajout de Greybus, dont Greg jure qu’il est vraiment utilisé. Mais, sous le capot, le plus gros des modifications est, en réalité, tout un tas de petits détails, comme d’habitude.

Dans les « petits détails de dessous le capot », il se trouve que mon préféré concerne les nouvelles allocations de piles virtuelles du noyau par Andy Lutomirski. Elles simplifient la découverte et la récupération des débordements de la pile. L’effort a également permis de nettoyer du code et d’ajouter un cache de correspondance à la pile du noyau pour éviter des baisses de performance. Al a aussi travaillé sur quelques nettoyages de VFS et uaccess que j’ai suivis (en particulier un truc puant dans un modèle de liaison). Mais soyons réalistes : ce que je considère comme des petits détails sympas sont juste mes propres marottes, il y en a un peu partout.

Il se fait que le système de pile virtuelle signifie aussi qu’il est grand temps pour ceux qui ont la sale manie de faire des accès directs en mémoire (DMA) à l’aide de variables temporaires allouées sur la pile (« Ne faites pas ça ! ») de changer leurs habitudes. Cela aura des retombées et je m’attends à ce qu’il y ait quelques pilotes à corriger çà et là. Mais tout ceci est pour une bonne cause, vraiment (et ce n’est pas un usage très répandu, parce que faire un accès direct à la mémoire depuis la pile n’a jamais été une bonne idée et, de manière générale, même pas envisageable dans la plupart des situations).

Mais il y a vraiment beaucoup d’autres choses en cours et le sommaire des modifications, tel que je le fais pour les autres versions, est bien trop long pour la RC-1. Donc, comme d’habitude, j’adjoins mon « journal de fusion » à la place, ce qui donne une vue de très haut niveau de ce que j’ai fusionné et de qui cela provient. Et, comme d’habitude, je tiens à souligner que les personnes dont proviennent les contributions que je fusionne ne sont pas nécessairement celles qui ont fait le travail : nous avons eu 1 500 personnes impliquées dans cette version, seuls les mainteneurs de haut niveau sont cités dans mon journal de fusion.

Allez‐y et testez,

Linus

RC-2

La version RC-2 est sortie le dimanche 23 octobre 2016 :

Je suis de retour sur mon agenda de publication habituel le dimanche après‐midi et Linux 4.9-rc2 est disponible.

Ma nouvelle fonctionnalité préférée, telle que je l’avais nommée dans l’annonce de la RC-1 (les piles virtuelles) est peut‐être impliquée dans des plantages que Dave Jones a essayé de comprendre. Donc, si vous voulez vous rendre utile et voir si vous pouvez fournir plus de données, s’il vous plaît, assurez‐vous d’avoir activé la variable CONFIG_VMAP_STACK.

… d’un autre côté, si tout ce que vous voulez est d’éviter les tracas engendrés par ce problème particulier, désactivez les piles virtuelles pour l’instant ; mais, s’il vous plaît, aidez‐nous à tester.

Parce que la 4.9 est clairement en phase d’être une grosse version (je n’ai pas encore fait de véritables statistiques, mais je pense que c’est la plus importante version que nous ayons jamais eue en nombre de modifications enregistrées [N. D. T. : commits]) et je pense que Greg prévoit aussi d’en faire une version LTS. Il se peut que les deux soient liés, avec tous ceux qui insistent pour que leurs trucs soient prêts. Bref, plus il y en a qui testent, plus tôt ils commencent à tester dans la série des RC, plus tôt nous en aurons fini. Un indice ! Un indice !

OK, sujet clos. La RC-2 elle‐même n’est pas énorme, mais c’est un cas fréquent : soit les gens prennent une pause après la fenêtre de fusion, soit c’est juste qu’il leur faut un moment avant de découvrir les retombées du nouveau code source ; donc, comme d’habitude, la RC-2 est dans le lot des petites versions.

En revanche, nous avons des modifications un peu partout : les pilotes dominent (les pilotes graphiques sortent du lot, mais il y a [aussi] IPMI, clocksource, MMC, pinctrl, HID, SCSI, NVMe… En veux‐tu, en voilà). Ajoutez à cela quelques mises à jour d’architectures (x86 et ARM64), un peu de nettoyage sur les systèmes de fichiers (ext4, NFS, Ceph, F2FS), les machines virtuelles, plus un gros correctif et vous en avez à peu près fait le tour.

Le sommaire des modifications ci‐joint donne quelques détails et, pour encore plus de détails, vous pouvez toujours parcourir l’arborescence Git en question.

Linus

RC-3

La version RC-3 est sortie le samedi 29 octobre 2016 :

Je publie la RC-3 un samedi, non pas pour attraper tous ceux qui s’amuseraient à m’envoyer des trucs à la dernière minute, mais simplement parce que, demain, je pars en voyage pour le Kernel Summit.

Il s’avère que le bogue que nous pensions dû aux nouvelles piles virtuelles pendant les tests de la RC-2 n’avait rien à voir avec ça ; il s’agit d’un problème d'accès concurrents à la file d’attente des requêtes de blocs. Donc, ceux qui avaient désactivé la nouvelle fonctionnalité n’y échappaient pas du tout, alors que les personnes touchées étaient probablement, tout comme DaveJ, ceux qui effectuent des tests de montée en charge. Mais tout ça est corrigé maintenant et nous devrions être parés.

Il y a également un tas d’autres corrections un peu partout. Les statistiques des modifications ont l’air un peu bizarres, avec les corrections sur XFS qui prennent quasiment autant de place que celles portant sur les pilotes ; mais ce sont principalement des corrections du nouveau code de reflink incorporé durant cette version. De toute façon, vous ne devriez pas avoir été touché, à moins que vous n’utilisiez les derniers trucs à la mode.

À part ça ? Tous les divers correctifs habituels de pilotes, mises à jour d’architectures, etc. Le sommaire des modifications ci‐joint n’est vraiment pas petit (comme on pouvait s’y attendre, la RC-3 était plus grosse que la RC-2), mais il est assez facile à parcourir pour avoir ne fût‐ce qu’une idée de ce qui s’est passé.

Donc, allez‐y, testez.

Linus

RC-4

La version RC-4 est sortie le samedi 5 novembre 2016 :

C’est de nouveau un samedi après‐midi plutôt qu’un dimanche. Cette fois, c’est parce que je sentais que cette RC était déjà suffisamment grosse.

Une part de cette taille vient probablement du seul fait que la 4.9 est énorme, avec quelques changements en profondeur : nous avons un certain nombre d’améliorations apportées aux pilotes et systèmes de fichiers qui ont provoqué une avalanche de problèmes du genre « la pile est actuellement virtuellement mise en correspondance et les adresses physiques ne fonctionnent pas ».

Mais une plus grande part est tout simplement due aux premières corrections réseaux venant juste d’arriver après la RC-3, ce qui représente une large portion de celle‐ci (environ un tiers en vrac, légèrement plus en nombre de modifications enregistrées [N. D. T. : commits] — réparti à la fois sur les pilotes et l’architecture réseau).

Je ne vais pas mentir : ce n’est pas une petite RC, et j’aurais été plus heureux si elle l’avait été. Mais ce n’est pas déraisonnablement grand pour cette (grosse) version, donc ce n’est pas comme si je devais m’en inquiéter. J’envisage toujours de sortir cette version au bout de sept [versions] candidates, pour autant que les choses commencent à se calmer. Nous verrons ce que ça donne à mesure que nous nous rapprocherons de la date de sortie.

Quoi qu’il en soit, environ la moitié des changements sont imputés aux pilotes (le réseau en étant une partie non négligeable, mais aussi les pilotes média, graphiques et autre bric‐à‐brac). Environ un tiers sont des mises à jour d’architecture (SPARC et MIPS se démarquent, mais il y a aussi x86 et PA-RISC, plus quelques petites mises à jour sur ARM). Pour le reste, on a essentiellement l’architecture réseau et une poignée d’autres changements (systèmes de fichiers, tests). Et Arnd est toujours en train d’éliminer ses erreurs de variables non initialisées, de sorte que nous espérons pouvoir réactiver cet avertissement pour la 4.9 finale. On verra bien.

Le sommaire des modifications ci‐joint n’est pas petit, mais vous pouvez, genre, le parcourir et avoir un aperçu de ce qui s’est passé la semaine dernière.

Linus

RC-5

La version RC-5 est sortie le samedi 13 novembre 2016 :

De retour à mon agenda du dimanche, tout a l’air plutôt normal. Calme au début, avec la plupart des corrections qui tombent en fin de semaine. J’ai l’habitude, maintenant.

Aucun doute là-dessus, tout a franchement diminué et, malgré l’embonpoint de la 4.9, un agenda de sortie habituel semble encore possible (avec la rc7 en dernier). Mais voyons comment les choses évoluent au cours des prochaines semaines. En attendant, il y a beaucoup de corrections ordinaires ici et il nous faut encore plus de tests.

Les statistiques de cette RC-5 sont franchement barbantes (ce qui est une bonne chose). Deux tiers de mises à jour des pilotes, 10 % de mises à jour d’architectures, 10 % sur les systèmes de fichiers, le reste en « divers ». Rien de frappant, sauf peut‐être à la prochaine réactivation [N. D. T. : l’option de compilation] de -Wmaybe-uninitialized dès que Arnd aura tout corrigé.

Donc, allez‐y, testez.

Linus

RC-6

La version RC-6 est sortie le dimanche 20 novembre 2016 :

On avance dans la série des RC et, même si tout a été plutôt calme, je ne suis pas certain qu’on soit près du but. Il reste encore à corriger quelques problèmes qui n’ont rien à faire dans une RC-6, alors on va garder un œil là‐dessus. Il se pourrait qu’on ait une de ces sorties incluant une RC-8, ce qui, compte tenu de la taille de la 4.9, n’est peut‐être pas si inhabituel que ça.

Cela dit, il n’y a rien de particulier qui ne me dérange vraiment. En revanche, nous avons des corrections de VMALLOC_STACK qui continuent d’arriver au compte‐gouttes et j’ai peur qu’on ne soit pas encore près d’en voir la fin. Aussi, attendons de voir à quoi la liste des régressions de Thorsten ressemblera la semaine prochaine. Donc, je n’ai pris encore aucune décision, d’un côté ou de l’autre, ça ira quand‐même.

Que la RC-6 soit plus grosse que la RC-5 n’est pas particulièrement bon signe, en revanche. Mais, apparemment, tout ceci n’est que le reflet des fluctuations habituelles sur le rythme des sorties : la RC-6 avait des mises à jour réseau, mais pas la RC-5, par exemple. Il y a aussi quelques mises à jour de RDMA qui se démarquent. Rien de bien inquiétant.

À part le réseau susmentionné et le RDMA, il y a des corrections au niveau des pilotes graphiques, un peu de corrections sur les outils et l’assemblage, plusieurs mises à jour sur les architectures (x86, PowerPC, ARM et Xtensa). Plus quelques corrections un peu partout (I²C, son, FUSE, KVM…).

Allez‐y, testez.

Linus

RC-7

La version RC-7 est sortie le dimanche 27 novembre 2016 :

Toujours dans le cadre de l’agenda des sorties dominicales, voici la RC-7.

Je pense que nous avons fait corriger tous les bêtes problèmes dont j’avais connaissance et, dans l’ensemble, les choses ont l’air d’aller plutôt bien. En fait, si la semaine prochaine se termine bien tranquillement, il se pourrait que cela soit la dernière RC, même si, honnêtement, je soupçonne fortement d’avoir à finir par une RC-8. C’est une grosse version et la RC-7 aurait pu être plus calme. On verra.

Je me réserve le droit de me décider le week‐end prochain.

Dans la RC-7, ce sont principalement les pilotes, l’architecture et le réseau qui ont été modifiés. En réalité, la plupart des mises à jour de pilotes concernent le réseau, je crois donc pouvoir dire « surtout des mises à jour de pilotes réseau et d’architectures, avec une poignée de mises à jour d’autres pilotes » (dans ces autres catégories de pilotes, on a notamment USB, pilotes graphiques, HID, I²C et IOMMU). Et l’on a toujours les trucs habituels un peu partout (le noyau, une correction eBPF, quelques corrections sur les systèmes de fichiers, etc.).

Le sommaire des modifications ci‐joint donne une assez bonne vue sur ce qui a été fait.

Linus

RC-8

La version RC-8 est sortie le dimanche 4 décembre 2016 :

Alors, pour ceux qui auront suivi l’arborescence Git, ça ne devrait pas être une surprise si j’ai fini par faire une RC-8, en définitive : non pas que les choses aient mal tourné, mais ça n’a pas non plus été le calme plat qui m’aurait fait dire « pas de quoi se taper encore une semaine ».

Et les félicitations du jury pour Arnd, qui a fini par trouver la véritable cause de ces messages incroyablement pénibles « modversions ne fonctionnent pas avec les nouvelles versions de binutils », en décortiquant les traces jusqu’à une modification bien précise dans la manière dont binutils gère les symboles, puis en ajoutant un petit correctif d’une ligne au noyau pour contourner le problème. Nous avions déjà d’autres solutions en place, mais il est toujours bon de savoir exactement ce qui a changé dans la chaîne d’outils pour provoquer ce genre de chose.

Cependant, cette ligne unique n’était qu’une des 163 petites corrections (sans compter les fusions) apportées à la RC-8. C’est assez petit (pour le noyau), mais pas complètement insignifiant. Tous les détails sur les modifications figurent au sommaire des modifications, mais c’est en majorité dans les pilotes réseau (des fuites dans la gestion des retours d’erreurs subsistent, mais la liste est disparate) et autres par‐ci, par‐là, avec en plus de petites corrections de trucs liés au noyau (mémoire virtuelle, systèmes de fichiers et noyau).

Linus

Version finale

La version finale est sortie le dimanche 11 décembre 2016 :

Ainsi, Linux 4.9 est sorti et, par conséquent, la fenêtre de fusion pour la 4.10 est ouverte.

Avec la semaine supplémentaire prise par la 4.9, le calendrier de la période de fusion est évidemment un peu gênant et devrait techniquement se clôturer dans deux semaines, autrement dit le jour de Noël. Mais c’est une pure question de technique, parce que je vais certainement arrêter l’intégration le 23 au plus tard ; et, si je suis enrôlé dans les préparatifs du repas de Noël, même cette date pourrait être remise en question.

Je pourrais étendre la fenêtre de fusion plutôt que de la raccourcir, mais je ne vais pas le faire. Je suppute que nous voulons tous une gentille pause d’hiver en paix ; donc, si vos affaires ne sont pas prêtes pour la fusion suffisamment tôt, la solution est bel et bien de ne pas les fusionner du tout et d’attendre la 4.11. Ceci pour que vous soyez tous au parfum (j’ai déjà averti la semaine dernière en message privé ceux que je suspecte de vouloir utiliser la fenêtre de fusion principale ; je me répète ici afin d’éviter la confusion à propos de l’agenda).

Quoi qu’il en soit, revenons à la 4.9.

Je suis sûr que c’est la plus grosse sortie que nous ayons jamais eue, au moins dans le nombre de modifications inscrites [N. D. T. : commits]. Si vous jetez un œil au nombre de lignes modifiées, nous avons eu des versions plus importantes dans le passé, mais elles avaient tendance à être dues à des problèmes spécifiques (par exemple, la version 4.2 a pris pas mal de lignes dans les fichiers de définition des registres des processeurs graphiques d’AMD et il y a eu de grosses restructurations ayant engendré un grand nombre de lignes par le passé : la version 3.2 était de grande taille en raison de la zone d’attente [N. D. T. : staging], la version 3.7 avait la désintégration automatisée du fichier d’en‐tête uAPI, etc.). À côté, la 4.9 est juste énorme.

Certes, la nouvelle prise en charge de Greybus est un bon morceau, mais ce n’est vraiment pas le plus gros — c’est juste un autre petit détail dans l’ensemble « oui, la version 4.9 est une version importante ».

En dehors de sa taille, la 4.9 semble plutôt normale. Un peu plus de deux tiers des pilotes (en gros la branche staging, les pilotes graphiques et réseau, mais il y en a partout), le reste aussi est plutôt normal : mises à jour d’architectures, documentation, infrastructure réseau générale, systèmes de fichiers…

Le sommaire (plus de 16 000 modifications inscrites, ainsi qu’un autre lot de 1 100 fusions, pour arrondir le tout) est évidemment beaucoup trop volumineux pour être écrit ici ; ce serait illisible de toute façon. Donc, comme à mon habitude, j’ajouterai seulement le journal de mes fusions.

Linus

Sécurité

Pas de changement majeur du côté de la génération des nombres pseudo‐aléatoires

Contrairement à ce que laisse penser Phoronix, les contributions de Stephan Müller concernant son « Linux Random Number Generator » (LRNG) n’ont toujours pas été intégrées au noyau. Les rédacteurs de vos dépêches favorites vérifient scrupuleusement l’historique des changements et ne se font pas avoir.

Profitons‐en quand même pour présenter cette partie du noyau. :-)

Réservoir d’entropie

Afin d’obtenir le plus d’aléa (le plus d’entropie), le noyau collecte toutes les sources de bruit à sa disposition, généralement les variations infimes (le bit de poids faible) de différentes mesures. Voici quelques exemples : température (processeur, disque dur), heure d’arrivée des paquets réseau, défaut de cache (cache miss), temps d’accès à la mémoire, ticks. Le noyau a aussi à sa disposition des instructions spéciales du processeur. En revanche, ces instructions ne sont pas auditables (par un organisme indépendant) car les conception et fabrication des processeurs sont rarement accessibles. Et le noyau prend surtout en compte les sources d’entropie de confiance.

Les fichiers /dev/urandom et /dev/random

La lecture du fichier /dev/urandom génère un nombre pseudo‐aléatoire (uniform random) à partir du réservoir d’entropie. La lecture du fichier /dev/random génère aussi un nombre pseudo‐aléatoire, mais sa lecture reste bloquée tant que le noyau n’a pas collecté suffisamment de bruit. Un démon s’initialisant au démarrage du noyau va plutôt opter pour /dev/urandom pour éviter de se bloquer. Une application ayant besoin d’une garantie d’entropie sur un nombre aléatoire utilisera plutôt /dev/random. La fonction getrandom() (en langage C) propose exactement ces mêmes services.

Améliorations

Stephan Müller avait proposé de rajouter 1 800 lignes de code source C pour changer la collecte d’entropie, dont les détails de conception et ses tests sont disponibles en HTML et en PDF. Ses principaux objectifs sont :

  • exploiter les SSD dans cette collecte d’entropie (on ne peut pas exploiter le réseau, car il n’est pas encore disponible) ;
  • exploiter les fonctions matérielles de génération pseudo-aléatoire ;
  • limiter par défaut les sources non auditables à un trente-deuxième du réservoir d’entropie ;
  • augmenter davantage l’entropie dès le démarrage et permettre la lecture du fichier /dev/random le plus tôt possible ;
  • améliorer l’entropie même dans une machine virtuelle ;
  • améliorer la performance sur les systèmes massivement multi‐cœurs et évitant les collectes d’entropie inutiles ;
  • permettre de tester de façon déterministe chacune des étapes ;
  • proposer une option (switch) de construction du noyau CONFIG_CRYPTO_LRNG pour choisir entre l’ancien et le nouveau fonctionnement (important pour les environnements avec peu de mémoire).

Refus

Ce sont surtout les agences nationales de sécurité informatique, comme l’ANSSI française, le BSI allemand ou le NIST aux États‐Unis, qui sont intéressées par de telles améliorations. Mais elles n’apprécient pas les changements non audités…

Allouer les piles d’exécution du noyau en mémoire virtuelle

Les contributions (correctifs) d’Andy Lutomirski concernant les fils d’exécution (threads) du noyau sont certainement celles que Linus a le plus appréciées, d’après son message de la RC-1. Il faut dire qu’Andy vient de loin et a travaillé avec acharnement pour trouver des solutions radicales à tous les problèmes rencontrés et, au final, a joliment nettoyé les tréfonds du code source du noyau.

Ce chapitre retrace cette aventure tumultueuse et se base sur les excellents articles de LWN.net rédigés par Jonathan Corbet (juin 2016) et sous licence CC BY-SA 4.0 :

Problème de conception

Andy s’est attaqué au vieux problème de conception du noyau Linux des piles d’exécution (call stacks). Ces piles étaient toujours allouées directement en mémoire physique, avec des inconvénients ennuyeux.

1. Fragmentation

Toute la pile doit tenir en un seul bloc de mémoire physique contigüe. Mais les grands blocs contigus sont de plus en plus difficiles à trouver au fur à mesure de la fragmentation de la mémoire. Ce qui met en péril un noyau Linux qui réalise de nombreuses opérations critiques depuis longtemps, surtout quand une attaque titille le noyau en le forçant à fragmenter sa mémoire.

2. Petite taille

Pour réduire les risques de fragmentation, la taille des piles d’exécution est limitée généralement à 8 192 petits octets. Ce qui impose des contraintes strictes comme l’interdiction des appels récursifs, pas de structure passée par valeur et l’obligation d’analyser en détail les possibles enchaînements des appels de fonctions. Et de nombreuses personnes préféraient plutôt en avoir une plus grosse !
Même si parler de code récursif dans un noyau, cela fait froid dans le dos, car cela veut dire un risque de « stack overflow » selon la taille des données traitées (et c’est mal) !

3. Dépassement

Malgré toute l’attention sur les arbres d’appel, les dépassements de pile (stack overflow) sont possibles. Une attaque peut trouver des combinaisons pour provoquer un dépassement et écraser des informations et même introduire son code exécutable. D’ailleurs, la taille a dû être doublée à 16 Kio sur les architectures x64.

4. Contournements contre‐performants

Pour détecter un dépassement, une solution consiste à positionner un canari à l’extrémité de la pile d’exécution. Ce canari correspond à une valeur magique qui est vérifiée régulièrement afin de détecter son écrasement par une autre valeur et donc un dépassement de la pile d’exécution. Non seulement, cela oblige à réaliser des opérations supplémentaires (vérifier plus ou moins fréquemment), mais en plus, ce dépassement n’est détecté qu’a posteriori et c’est souvent trop tard.

Une seconde solution pour détecter un dépassement en mémoire physique consiste à rajouter une page mémoire en accès interdit. Mais cela gâche de la mémoire qui n’est pas utilisée et augmente le risque de fragmentation (le bloc de mémoire contigu doit être plus grand).

Et que faire si le dépassement est détecté ? Tuer le fil d’exécution ou ré‐allouer une pile plus grande ? Avec la mémoire physique, tuer est plus facile que ré‐allouer. De plus, il faut utiliser une fonction realloc() différente, car la pile s’exécute de la fin vers le début, donc il faut ajouter de la mémoire avant et non après. Sans parler des risques d’augmentation de la fragmentation.

Mémoire virtuelle

L’idée initiale d’Andy était de proposer un agrandissement automatique de la taille de la pile d’exécution au fur et à mesure que son dépassement est détecté en allouant cette pile en mémoire virtuelle. La gestion de la mémoire virtuelle a été un des tous premiers objectifs du noyau Linux avec le processeur i386. C’est le MMU du processeur qui donne l’impression au fil d’exécution que la plage d’adresses est contigüe, mais les pages de la mémoire physique (des blocs généralement de 4 Kio) peuvent être dispersées, réduisant considérablement les problèmes de fragmentation.

Pour atteindre ce but ultime, Andy a remanié ses contributions à de très nombreuses reprises et son acharnement a abouti à des résultats spectaculaires non attendus.

Trop lent

Au tout début, le seul inconvénient de sa première proposition était une lenteur de 1,5 µs lors de la création d’un nouveau fil d'exécution du noyau. Ce temps d’exécution plus long est imputable à la fonction vmalloc() utilisée pour allouer de la mémoire à la pile d’exécution (virtual memory allocation — allocation de mémoire virtuelle). Cette fonction prend plus de temps, car elle réalise des opérations supplémentaires et n’a pas bénéficié du même effort d’optimisation que les autres fonctions d’allocation. Mais, pour Linus, cette régression de performance est irrecevable.

Mémoire tampon

Alors, voyons comment éviter d’appeler la fonction vmalloc(). Pour cela, Linus a demandé à Andy de recycler les piles d’exécution des derniers fils s’étant terminés. On les conserve temporairement dans une petite mémoire tampon et on les fournit dès qu’il faut créer un nouveau fil d’exécution. Cela devrait nous permettre d’appeler vmalloc() moins souvent.

Incompatibilité avec le Read‐Copy‐Update

Mais, c’est oublier le fonctionnement fourbe du Read‐Copy‐Update (RCU) qui libère les ressources d’un fil d’exécution (dont sa pile d’exécution) par saccade. Le RCU accumule les ressources de tous les fils d’exécution qui se terminent, puis les libère tous en même temps. Notre petit cache de piles d’exécution se retrouve donc à devoir absorber plus de piles d’exécution qu’il ne peut en contenir. Et, en attendant le prochain cycle du RCU, nous nous retrouvons rapidement avec un cache vide et donc la nécessité d’appeler la fonction vmalloc().

Contournement du Read-Copy-Update

Au lieu d’augmenter la capacité de notre cache (pensons aux systèmes avec peu de mémoire), essayons de décorréler la pile d’exécution du mécanisme RCU. En récupérant nous‐même la pile d’exécution d’un fil qui se termine, nous évitons les pics de piles d’exécution fournis par le RCU. En revanche, le RCU libère les autres ressources du fil d’exécution à son rythme.

Interdépendance entre la mémoire de la pile et le Read‐Copy‐Update

Mais, nous avons un autre problème : la pile d’exécution et les autres ressources du fil d’exécution ne sont pas complètement décorrélées. En fait, les informations du fil d’exécution sont dispersées à deux endroits :

  1. dans la structure task_struct, qui est allouée indépendamment de la pile d’exécution (ouf) ;
  2. dans la structure thread_info, qui fait partie du même bloc mémoire que la pile d’exécution (zut).

C’est là que les choses se compliquent : les différentes parties du noyau ne vont pas immédiatement être au courant qu’un fil d’exécution vient de se terminer, cela prend un certain temps pendant lequel la structure thread_info ne peut être utilisée par un nouveau fil d’exécution. On en revient au même : attendre la fin du cycle du RCU !

Se débarrasser du thread_info

Et si nous déplacions le thread_info ailleurs ? Eh bien, c’était comme cela au début du noyau, tout était dans task_struct. Mais avoir quelques informations directement dans le même bloc mémoire que la pile d’exécution permet justement d’éviter une indirection. D’ailleurs, c’est l’essence même de l’existence de task_struct : permettre un accès direct en appliquant un masque sur le pointeur d’exécution ($sp).

Avec le temps, la structure task_struct contient les champs génériques, indépendants de la plate‐forme (architecture‐independent). Et la structure thread_info contient les champs spécifiques à la plate‐forme (architecture‐specific).

Pourtant, ces dernières années, la structure thread_info a fondu. Quelques champs de cette structure ont été déplacés dans une structure de données spécifique à chaque cœur (unité de calcul). Mais, ce n’est pas là non plus que nous pouvons déplacer des champs de thread_info, car seul le code s’exécutant sur ce cœur a le droit d’accéder à sa structure de données spécifique, afin d’éviter que le processeur perde du temps à synchroniser les caches mémoire de niveau 2.

C’est là que Linus a donné un coup de main à Andy. D’abord, en réduisant la dépendance entre les différentes parties du noyau vis‐à‐vis de la structure thread_info. Puis, en déplaçant certains champs vers task_struct. Andy a poursuivi ce travail pour chaque champ. Et le dernier champ contenant les drapeaux (flags) a également été déplacé vers task_struct. Mais cela demande tellement d’investissement sur chaque plate‐forme spécifique, qu’Andy a mené à bien ce travail uniquement pour la plate‐forme x86.

C’est gagné !

Maintenant, nous avons enfin la mémoire de la pile d’exécution qui peut être directement libérée dès la fin du fil d’exécution, sans avoir besoin d’attendre la fin du cycle RCU. Et nous pouvons donc mettre en cache cette pile d’exécution dans la structure de données spécifique à chaque cœur.

Les avantages de la contribution d’Andy sont nombreux :

1. Gain en performance

En faisant des tests avec un petit cache pour deux piles d’appel, la latence de 1,5 µs se transforme en un gain de performance entre ½ et 1 µs.

2. Détection immédiate du dépassement de la pile d’exécution

En plus de ce gain de performance, nous avons aussi un dépassement de la pile (stack overflow) qui est immédiatement détecté. Avant, le dépassement de la pile commençait par écraser la structure thread_info, ce qui ne pouvait pas être détecté (car cela ne dépassait pas le bloc mémoire). D’ailleurs, c’était une faille de sécurité importante. En faisant exécuter par le noyau un long enchaînement de fonctions, on pouvait changer les valeurs dans thread_info.

3. Meilleur diagnostic

Et, comme en cas de dépassement de pile, les informations de thread_info ne sont plus écrasées, il est plus facile de diagnostiquer le problème et ce, sans planter le noyau. Le dépassement est détecté, le noyau arrête le fil d’exécution et fournit un rapport d’erreur complet et précis.

Plébiscite

Devant l’avalanche de tels avantages, dont le nettoyage/regroupement des informations des fils d’exécution, les autres architectures sont en train d’être adaptées afin de ne plus avoir le thread_info dans le même bloc mémoire que la pile d’exécution.

En conclusion, cette épopée dans les entrailles du code source du noyau a permis de belles réalisations et Andy va pouvoir reprendre son idée initiale d’agrandir automatiquement la taille de la pile d’exécution en détectant son dépassement mémoire. Le noyau pourrait avoir à l’avenir des petites piles d’exécution pour la grande majorité des cas. Et pour une minorité de cas, la taille de la pile s’adaptera dynamiquement sans avoir à tuer le fil d’exécution. C’est un très bon compromis entre économie de mémoire et sécurité accrue.

Merci Andy Lutomirski et bonne continuation dans ton formidable travail. Visage d’Andy Lutomirski

Clefs de protection de la mémoire (memory protection keys)

Cette nouvelle fonctionnalité abrégée pkeys permet d’empêcher que d’autres processus accèdent à des plages d’adresses. C’est le rêve des cryptographes : cacher ses secrets.

Cette technologie existait déjà sur les bons vieux ordinateurs centraux — mainframes — (Key‐controlled memory protection). Et voilà qu’Intel l’intègre depuis le Skylake pour serveur (commercialisé depuis un an).

Dave Hansen (Intel) avait proposé une prise en charge, mais elle a été refusée pour la version 4.6. Puis améliorée, mais encore refusée pour la 4.7. Et, rebelote pour la 4.8. La contribution de Dave Hansen a enfin été acceptée pour la 4.9, au bout de la sixième révision.

API

Nous avons maintenant ces nouvelles fonctions dans l’API du noyau :

int pkey_alloc(unsigned long flags, unsigned long init_access_rights)
int pkey_free(int pkey);
int pkey_mprotect(unsigned long start, size_t len, unsigned long prot, int pkey);

Dans les précédentes révisions de cette contribution, il y avait deux autres fonctions. Nous les signalons pour éviter que nos lecteurs se trompent en se basant sur des documentations obsolètes. Dave Hansen a récemment nettoyé leurs traces du noyau :

/* Fonctions supprimées */
unsigned long pkey_get(int pkey);
int pkey_set(int pkey, unsigned long access_rights);

Ces nouvelles fonctions permettent donc de protéger en écriture seulement ou en lecture et écriture des adresses mémoire. Attention, l’implémentation sous‐jacente d’Intel peut être contournée, car les nouvelles instructions ajoutées, RDPKRU et WRPKRU, peuvent être utilisées par d’autres fils d’exécution.

Voir aussi

Toutes ces documentations sont en langue anglaise. Si les lectrices et lecteurs de LinuxFr.org souhaitent lire une dépêche en français sur ce sujet, merci de nous le signaler dans les commentaires.

Les excellents articles de Jonathan Corbet (CC BY-SA 4.0) publiés sur LWN.net :

Manuel de l’API Linux :

Couches bas niveau :

Pilotes graphiques libres

AMD

Logo AMD
Le nouveau pilote graphique libre amdgpu pour les cartes graphiques AMD GCN a été mis à jour et introduit la prise en charge de l’affichage virtuel. Son contenu est ensuite accessible via un logiciel de bureau à distance.

Autre changement apporté par ce pilote, la prise en charge de la technologie de réduction de consommation énergétique AMD PowerPlay pour les cartes graphiques équipées d’un processeur graphique de génération Iceland (2014).

L’amélioration de la réinitialisation des unités de calcul accéléré (APU) de génération Carrizo (2015), ainsi que de son remplaçant Stoney Ridge (2016).

La prise en charge des circuits intégrés spécialisés (ASIC) AMD UVD (Unified Video Decoder), permettant le décodage vidéo, et AMD VCE (Video Coding Engine), qui permet le codage des normes vidéo de type H.264, MPEG-2, MPEG-4 et VC-1, a été ajoutée pour les puces plus récentes.

Prise en charge également de la pré‐initialisation de la mémoire tampon de la VRAM, par exemple, la remise à zéro.

Et de nombreuses autres corrections de bogues en tout genre.

Voir aussi :

Nouveau

Aucun changement pour le pilote nouveau n’a été intégré à cette version du noyau.

Réseau

BBR

Le protocole TCP est l’un des plus utilisés sur Internet. Il est, entre autres, utilisé par HTTP et SSH. L’un des atouts de ce protocole est sa capacité à gérer la congestion, c’est‐à‐dire, sa capacité à continuer de fonctionner quand le réseau commence à être saturé par les connexions. En effet, lorsque l’on augmente le trafic sur un réseau, le temps d’attente dû à des interblocages augmente (sur Ethernet, il n’y a qu’une seule trame à la fois, par exemple). TCP est capable de réduire son débit automatiquement pour réduire cette congestion.

Depuis la création de TCP, différents algorithmes ont vu le jour pour améliorer le débit, car les premières versions ne pouvaient pas atteindre les 100 Mbit/s, par exemple. Le BBR (pour Bottleneck Bandwidth and RTT) fait donc suite aux douze autres protocoles permettant à TCP de réduire son débit lorsque le réseau est congestionné tout en maximisant les débits (dans les cas sans congestion et lors de la congestion). Il faut comprendre que ces algorithmes ont différentes propriétés. D’une part, on cherche à ce qu’ils soient le plus efficace possible pour améliorer le débit utile par rapport à l’ensemble du débit consommé, ensuite, il y a différentes façons de se comporter lors de la congestion. Par exemple, le débit peut augmenter plus ou moins vite une fois la congestion passée. La meilleure solution dépendra (entre autres) des couches inférieures du réseau (comme le lien physique) et des autres équipements. C’est ce qui explique qu’il y ait encore tant d’algorithmes différents pour répondre à la même problématique.

Ce nouvel algorithme a été proposé par une équipe de Google. Ces derniers expliquent que BBR, contrairement aux autres algorithmes, ne se base pas sur des pertes de paquets, mais sur des mesures faites au fur et à mesure. Ainsi, il n’attend pas d’être dans les pires cas pour ajuster son débit. Ils expliquent aussi que cet algorithme est déjà utilisé dans les infrastructures de YouTube et de Google Search (excusez du peu). Un des premiers tests publics qui compare l’algorithme TCP Reno, TCP CUBIC et TCP BBR semble montrer de bons résultats.

Systèmes de fichiers

FUSE

FUSE (pour Filesystem in Userspace) a été mis à jour. Il permet à un utilisateur sans privilèges particuliers d’accéder à un système de fichiers, sans qu’il soit nécessaire de modifier les sources du noyau. Il est utilisé dans GNOME (GVfs), pour écrire sur des partitions NTFS (NTFS-3G), par VeraCrypt, ou encore Flatpak.

Le correctif de FUSE apporte enfin la vérification des permissions (ACL) POSIX, ainsi que diverses corrections de bogues. Ceux qui souhaitent découvrir ce que sont les listes de contrôle d’accès POSIX sous Linux peuvent lire l’article (en anglais) qui leur est dédié. Lire aussi la version française sur Wikipédia de leur mise en œuvre sous UNIX.

UBIFS

Un correctif proposé par Bean Huo introduit la gestion d’OverlayFS. Pour ceux qui se servent d’UBIFS sur de la mémoire Flash brute, il n’existe pas, en ce moment, de prise en charge d’OverlayFS. Néanmoins le travail est en préparation pour les mémoires Flash de type MLC NAND (mémoires Flash NAND à cellules multi‐niveaux).

ext4

Corrections et nettoyages, notamment dans la gestion des attributs étendus.

Btrfs

Correction de bogues et diverses optimisations. Rien d’excitant pour le moment. Chris Mason signale d’ailleurs que des modifications plus importantes sont en préparation pour la version 4.10.

F2FS

F2FS, le système de fichiers de Samsung dédié à la mémoire Flash, a reçu plusieurs améliorations :

XFS

XFS, le système de fichiers hérité d’IRIX, l’UNIX de SGI, s’est vu ajouter un nombre important de fonctionnalités, notamment à son infrastructure, mais aussi au format des données. Suite aux contributions soumises par Dave Chinner, un espace disque peut désormais avoir plusieurs propriétaires (XFS Shared Extents ou zones disque partagées), ceci grâce à l’adjonction, dans chaque groupe d’allocation, d’un nouvel arbre B (B‐tree) répondant au doux nom de refcount.

Prise en charge des plates‐formes

Raspberry Pi Zero

La gestion du Raspberry Pi Zero a été ajoutée en même temps que d’autres systèmes mono‐puces de Broadcom.

Amlogic S905

La prise en charge de l’Amlogic S905 a été améliorée. La gestion des systèmes mono‐puces ARM 64 bits d’Amlogic fait l’objet d’un gros travail depuis Linux 4.7. On a en plus grâce à Linux 4.9, notamment :

  • PWM (modulation en largeur d’impulsions), pierre angulaire de la gestion du Wi‐Fi sur les cartes Amlogic ;
  • la Mailbox, utilisée pour la communication SCPI qui gère le DVFS (adaptation dynamique de la tension d’alimentation et de la fréquence d’un micro‐processeur) ;
  • l’I²C et le SPI ;
  • des améliorations de l’Ethernet 10, 100 et 1000 Mbit/s.

La gestion de MMC/SD/SDIO, SCPI et de l’USB est malheureusement repoussée pour Linux 4.10. Cette dernière intégrera le Wi‐Fi (si les pilotes SDIO sont dans Linux) et les variantes S905D, S905X et S912.

Autres

On voit également débarquer la prise en charge de diverses plates‐formes et composants :

  • ZTE ZX296718, SoC ARM 64-bit ;
  • les systèmes mono‐puces Broadcom BCM47189 et BCM53573, premiers systèmes mono‐puces ARM à se conformer au standard Wi‐Fi 802.11ac. ;
  • Renesas r8a7796 (R-Car M3-W), système mono‐puce pour l’automobile ;
  • le NextThing GR8, très proche de celle du A13/R8 ;
  • la platine de développement Marvell Armada 8040 avec son Cortex-A72 à quatre cœurs et ses trois interfaces Ethernet 10 Gbit ;
  • la carte Qualcomm DragonBoard 820c 96Boards ;
  • TVBox Tronsmart Orion r86, une carte pour boîtiers décodeurs avec un système mono‐puce octocœur Rockchip RK3368 ;
  • Qualcomm External Bus Interface 2 (EBI2), utilisé sur les téléphones pour connecter la mémoire Flash, les écrans LCD et d’autres périphériques ;
  • les cartes Allwinner, incluant l’Empire Electronix M712 et la tablette iNet D978 rev2, ainsi que l’Orange Pi PC Plus, Orange Pi 2, Orange Pi Plus 2E, Orange Pi Lite, Olimex A33-Olinuxino et le Nano Pi Neo ;
  • les cartes Broadcom incluant les cartes de références BCM958525er, BCM958522er, BCM988312hr, BCM958623hr et BCM958622hr ;
  • le routeur NETGEAR WNR854T ;
  • le LG Nexus 5 ;
  • la Beagleboard-x15 rev B1 ;
  • la conversion vers l’arborescence matérielle DeviceTree pour mach-omap2 est complète, incluant une gestion complète du vénérable Nokia N900.

Autres nouveautés

Pilote de test EFI

Ce pilote, soumis par Ingo Molnar, mais dont Canonical assure la maintenance, est désormais inclus dans le noyau dans le but d’aider les développeurs de micrologiciels (firmwares). Il exporte en espace utilisateur les interfaces du service d’exécution UEFI et est utilisé par la suite de test de micrologiciels (FTWS).

Plate‐forme Mellanox

Un correctif, également proposé par Ingo Molnar, marque le début de la prise en charge de la plate‐forme Mellanox, utilisée principalement dans les domaines du calcul à haute performance et les centres de traitement de données (data centers). Ces plates‐formes ne sont pas données, par exemple, le commutateur réseau MSX6710 à 36 ports coûte la bagatelle de 11 900 US$. Mellanox est un fournisseur de matériel haut de gamme InfiniBand et Ethernet pour serveurs et plates‐formes de stockage en masse.

MD RAID

Le code de MD RAID ajoute la prise en charge de AXV512 pour accélérer le RAID 6 et d’autres améliorations pour la création d’un volume.

NVDIMM

Le code NVDIMM ajoute plus de flexibilité dans la prise en charge de ces zones de mémoire non volatile exportées par ACPI. Michael Larabel en écrit un bref récapitulatif sur son site, Phoronix.

Intel Integrated Sensor Hub (ISH)

Linux 4.9 prend également en charge le module ISH (Integrated Sensor Hub) d’Intel, un capteur intégré en remplacement de capteurs externes. Ces capteurs détectent, par exemple, le changement de position de l’appareil, contribuent à l’ajustement automatique de la luminosité et interviennent également dans la gestion de l’énergie sur les ordinateurs portables. Ce correctif est destiné à la famille de processeurs Cherry Trail et suivantes.

Intel Atom

Un nouvel algorithme de gestion du P-state (une collection de niveaux prédéfinis pour la gestion de l’énergie) a été soumis par Rafael J. Wysocki. En outre, il améliore les performances des processeurs Intel Atom en baissant moins fortement le niveau d’énergie. L’idée est d’ajouter 50 % à l’objectif de performance calculé pour diminuer le coût de migration d’un processus vers un autre cœur.

Projet ARA de Google

Le pilote qui gère Greybus, conçu sur les bases du protocole UniPro, a été ajouté au noyau Linux.

Unipro ?

UniPro est un protocole de communication, comme I²C, destiné à l’interconnexion de divers circuits intégrés. Il est destiné à être utilisé dans le monde des ordiphones.
UniPro

Il est notamment utilisé par Google pour son projet ARA qui vise à créer un ordiphone modulaire. On peut le retrouver dans un produit grand public commercialisé : le téléphone Lenovo Moto Z utilise ce bus pour ses Moto Mods.

Les différentes versions du protocole UniPro ont été créées par la MIPI Alliance (Mobile Industry Processor Interface Alliance) composée de 250 entreprises. Le protocole a été créé en 2006.

Unipro est un protocole de transmission à haute vitesse et de faible consommation électrique. Il prend en charge jusqu’à 128 périphériques. Il respecte les standards de l’OSI.

 Greybus ?

Greybus est une couche applicative pour UniPro ce qui correspond à la septième couche du modèle OSI. C’est un bus générique initialement transporté sur USB, avec des notions de « cports » et de liens logiques correspondants aux liens UniPro, mais il a été conçu pour ne pas être dépendant du lien physique.

L’implémentation dans Linux suppose une communication avec un « SVC » qui, dans le téléphone ARA, est un microcontrôleur utilisé pour gérer le routage des liens logiques vers les cports des périphériques UniPro.

Il y a par exemple des implémentations 100 % USB avec un démultiplexage des cports dans un micrologiciel sur un STM32F4 ou, plus récemment, une implémentation d’un routage Greybus en espace utilisateur via Netlink, et une communication par Bluetooth avec des modules. Cela donne en pratique des interfaces virtuelles locales vers des périphériques distants. Par exemple, GreyBus permettait d’exposer le bus I²C ou SPI des modules et de les contrôler avec les API I²C ou SPI de Linux, ou même d’y associer des pilotes classiques.

UniPro, quant à lui, se situe au niveau de la couche physique, soit la première couche du modèle OSI.

Ci‐dessous la mise en œuvre de Greybus dans le noyau Linux :
Intégration de Greybus dans le noyau Linux

Voir aussi :

Commande perf

Parmi les améliorations apportées à l’outil en ligne de commande perf, on peut lister la gestion de fichiers JSON pour décrire les évènements de l’unité de supervision des performances (PMU — Performance Monitor Unit), un nouvel ensemble d’astuces et le début du travail pour la gestion de Clang/LLVM demande d’intégration.

KThread

L’API KThread a reçu un gros coup de nettoyage.

Clef de protection mémoire

Attendue depuis un moment, la nouvelle interface MPK (Memory Protection Keys ou clefs de protection de la mémoire) est maintenant terminée et intégrée à Linux 4.9, d’après le correctif envoyé par Thomas Gleixner. Ce système définit un ensemble d’interfaces en espace utilisateur (lire des appels système) et offre aux applications un mécanisme de protection des données par page, à l’aide de clefs de chiffrement. Cette protection sera mise en application dans les futurs processeurs de la firme Intel. On peut lire, sur le site Phoronix, comment la mettre en œuvre en langage C.

Virtualisation Xen et KVM

La plate‐forme de virtualisation Xen a reçu un correctif qui introduit une fonctionnalité fort intéressante : les connexion et déconnexion à chaud du processeur (c.‐à‐d. pendant que la machine fonctionne) — sur les cartes‐mères qui en possèdent plus d’un, bien entendu. Quant à KVM, autre plate‐forme de virtualisation, ce sont des améliorations sur l’architecture ARM qui ont été apportées. À noter également un travail préparatoire sur l’adressage virtuel étendu (EVA) pour les processeurs MIPS.

Virtual mapped stack

Andy Lutomirski a introduit un nouveau mécanisme de gestion des piles noyau, qui a pour effet secondaire d’optimiser la création de tâches par la mise en cache de deux piles de fil d’exécution par processeur. Initialement, ce correctif a pour but de faciliter le diagnostic et de sécuriser l’interception des débordements de pile, ce qui devrait aussi rendre leur exploitation (exploit) plus difficile. Une pile virtuelle est encadrée par des pages de garde et les débordements sont interceptés immédiatement par le noyau, au lieu de provoquer des corruptions mémoire extrêmement difficiles à diagnostiquer. Ce genre de fonctionnalités était fourni par les correctifs de grsecurity.

Lire également les articles sur les sites Phoronix et LWN.net.

Statistiques

Entreprises ayant participé à cette version

En nombre de lignes changées

AMD sort en première position avec 105 820 lignes modifiées soit 11,1 % du total de lignes modifiées, suivie de très près par Red Hat avec 104 492 lignes, soit 10,9 %. Intel s’en sort en troisième positon avec 89 456 lignes, soit 9,4 % du total (cf. l’article de Jonathan Corbet Development statistics for 4.9 sur LWN.net).

Aller plus loin

  • # L'original ...

    Posté par  . Évalué à 10.

    est chez xkcd

    • [^] # Re: L'original ...

      Posté par  . Évalué à 10.

      Je pense qu'on se fout un peu de notre gueule. C'est du vol et du plagiat.

      • [^] # Re: L'original ...

        Posté par  . Évalué à -10.

        Moi je trouve l'illustration sexiste : elle laisse sous-entendre que les femmes sont moins douées que les hommes …

        • [^] # Re: L'original ...

          Posté par  (Mastodon) . Évalué à -2. Dernière modification le 08 février 2017 à 15:44.

          Moi je les trouve juste moche et inutiles ces illustrations, m'enfin bon ce n'est que moi. Ce serait d'ailleurs bien de pouvoir désactiver les images dans les préférences de son compte comme on peut le faire pour les avatars avec juste une mention du champ description, ou à défaut du nom du fichier pour qu'on puisse optionnellement les consulter.

          Yakafokon je dois envoyer un patch faire une pull request c'est ça ?

          • [^] # Re: L'original ...

            Posté par  . Évalué à 10.

            C'est quand même violent de dire que c'est moche et pas drôle, on reste un site convivial où tout le monde peut participer. Après tout, il y a aussi des journaux pas drôles et pas très intéressants, et on passe juste à autre chose.

            Ça me rappelle quand même un truc que j'ai vécu au moment où je m'intéressais un peu aux communautés autour des jeux libres. La pluralité des besoins (code, média, images, sons, ergonomie, interface…) fait que quand la taille de la communauté est petite, les arbitrages sont très compliqués, à la fois humainement et même techniquement. Par exemple, dès qu'on tape un peu dans le côté artistique (dessin des sprites ou musique d'ambiance), il faut non seulement prendre en compte la qualité objective (résolution, qualité du son…) des contributions, mais aussi leur qualité subjective (c'est beau/c'est moche), et surtout leur intégration dans l'existant (c'est beau mais ça jure avec l'ambiance du jeu). En gros, il faudrait que la même personne dessine l'ensemble des sprites du jeu, parce que la collaboration sur ce genre de choses, c'est très très compliqué. Et comme les gens qui jouent un peu dans le domaine artistique ont tendance à être quand même assez susceptibles (c'est certainement lié à la nature subjective de la critique dans ces domaines, hein…), c'est très compliqué à gérer. Quand c'est du code, on a quand même des arguments techniques à opposer pour un rejet de patch, quand c'est des dessins ou une bande son, à part que le chef de projet trouve ça moche, il n'y a pas beaucoup de discussions ou d'améliorations possibles.

            Tout ça pour dire que ce n'est pas comme si on avait plusieurs propositions pour illustrer les dépêches du kernel : soit on met l'image proposée bénévolement par quelqu'un qui a pris du temps pour le faire, soit on lui dit que ça ne nous intéresse pas. Je comprends très bien pourquoi on a l'image, même si je partage ta critique artistique.

            • [^] # Re: L'original ...

              Posté par  (site web personnel, Mastodon) . Évalué à 5.

              Je ne sais pas pour un jeu, mais on a un peu ce genre de problèmes quand il s'agit de faire des icônes ou d'autres éléments graphiques dans une application.

              Haiku a des règles sur la façon de dessiner les icônes (https://www.haiku-os.org/development/icon-guidelines) et plusieurs personnes ont pu participer, tout en gardant la cohérence. ça dépend aussi des outils utilisés, et du fait que les artistes partagent non seulement le résultat de leur travail, mais aussi les "sources": fichiers vectoriels, palettes de couleurs, méthode utilisée pour réaliser tel ou tel effet, etc. Ce qui permet de prendre un icône et de le dériver pour en faire un autre, par exemple.

            • [^] # Re: L'original ...

              Posté par  . Évalué à 3.

              C'est quand même violent de dire que c'est moche et pas drôle,

              Mouais… Sur Linuxfr, la critique est rarement à fleurets mouchetés. Pour le coup, c'est réellement mal dessiné et d'un humour inexistant. Même la typo des phylactères est laide.

              Le minimum serait de les afficher dans une taille deux à quatre fois plus petite, histoire que ces images ne bouffent pas la moitié de l'espace vertical. Ceci d'autant plus que la dépêche est par ailleurs excellente (merci aux rédacteurs).

              Tout ça pour dire que ce n'est pas comme si on avait plusieurs propositions pour illustrer les dépêches du kernel

              Je ne vois pas trop le rapport, en fait. Une illustration n'est pas nécessaire, et si elle n'apporte rien au message de l'article, elle est même superflue. Ça me fait penser aux magasins ou aux bars qui insistent pour passer une musique pénible en fond sonore.

              • [^] # Re: L'original ...

                Posté par  . Évalué à 4.

                Je ne vois pas trop le rapport, en fait. Une illustration n'est pas nécessaire, et si elle n'apporte rien au message de l'article, elle est même superflue. Ça me fait penser aux magasins ou aux bars qui insistent pour passer une musique pénible en fond sonore.

                Roooh, t'es dur là. Moi ça me fait penser aux ilustrations du regretté magazine Dream (rebaptisé LOGIN). Celà dit je te rejoins sur la taille de l'image qui est réellement trop grande ( les illustrations de Login étaient beaucoup plus petites en général).

                • [^] # Re: L'original ...

                  Posté par  . Évalué à 3.

                  j'aime bien ce genre d'illustration, du léger pour commencer et du lourd ensuite.
                  il faut du temps pour tout lire …
                  jean francois

      • [^] # Re: L'original ...

        Posté par  (site web personnel, Mastodon) . Évalué à 3.

        xkcd est sous licence CC BY-SA: https://xkcd.com/license.html . Mais en effet, je ne vois pas Randall Munroe dans la liste des contributeurs à la dépêche…

        • [^] # Re: L'original ...

          Posté par  . Évalué à 5.

          À côté du droit d'auteur, il y a aussi les considérations "bassement" morales ou éthiques, qui consistent à expliciter les clins d'œil (les clins d'œils? les clins de z-yeux? les clins d'yeux? «Il a fait deux clins d'œil» vs «Ils se sont fait des clins d'yeux»? Le mec qui a écrit les specs du français était vraiment bourré).

          … à expliciter les références, reformulerais-je. Autrement, ça donne vraiment l'impression que ça donne à tout le monde : les auteurs du dessins essayent de faire passer pour leur blagounette quelque chose qu'ils ont pompé, alors qu'ils essayaient probablement de faire un clin d'… une référence à une blague connue de la culture geek, mais probablement pas assez connue pour qu'il soit évident que ça n'est pas une tentative de plagiat.

          Au passage, c'était quand même plus drôle sur xkcd, et les geekscottes me manquent…

          • [^] # Re: L'original ...

            Posté par  . Évalué à 3. Dernière modification le 10 février 2017 à 11:49.

            Digression, Mais ce n'est pas moi qui ai commencé ! Et le vendredi c'est permis !

            les clins d'œil (les clins d'œils? les clins de z-yeux? les clins d'yeux? «Il a fait deux clins d'œil» vs «Ils se sont fait des clins d'yeux»? Le mec qui a écrit les specs du français était vraiment bourré).

            Je ne sais quel est l'usage moderne, mais ma référence personnelle reste l'excellent dictionnaire de M. Littré. Je le cite donc :

            Au plur. Des clins d'œil, mais on peut dire aussi, si l'on considère les deux yeux, des clins d'yeux.
            A prix de faux clins d'yeux et d'élans affectés, [Molière, Tartuffe. I, 6]

            Très correct pour des specs élaborées au fil du temps, sans planification. L'alcool a sûrement joué un rôle1 dans l'évolution de la langue française, mais peut-être pas plus que dans l'évolution d'autres langages naturels2 comme PHP ;-)


            1. Je constate simplement l'importance traditionnelle de l'alcool et notamment du vin. J'aime beaucoup ce proverbe, toujours extrait du Littré, et que la sécurité routière devrait recycler : « après bon vin, bon cheval, quand on a bu un coup, on fait aller son cheval plus vite. » 

            2. Le sens moderne de l'expression Langage naturel est précis, mais on peut lui redonner sa souplesse d'antan. 

            • [^] # Commentaire supprimé

              Posté par  . Évalué à 4.

              Ce commentaire a été supprimé par l’équipe de modération.

              • [^] # Re: L'original ...

                Posté par  . Évalué à 7.

                D'après l'académie Française 1835, «Après bon vin, bon cheval, Quand on a un peu bu, on fait aller son cheval meilleur train; et, plus figurément, Quand on a un peu bu, on est plus hardi.»

                D'après l'internaute.com (vla la référence), «Ce proverbe signifie qu'après un bon repas on poursuit agréablement son chemin.»

                M. Quitard, 1842 écrit : «Le Duchat explique ainsi ce proverbe: Quand on a bu de bon vin on s'en ressent, et comme alors on ménage moins le cheval, il parait meilleur parce qu'il va plus vite.» Mais il poursuit par «Il me semble qu'on a du dire "après bon vin, bon cheval" pour signifier que lorsqu'on a bien bu, on a besoin d'un cheval qui ne bronche pas, et ne jette pas son cavalier à terre.»

                En gros, même en 1842, on avait déja perdu la signification du proverbe. C'est d'ailleurs assez incroyable qu'il ressorte encore en 2017, puisqu'il semble que ça fait environ 200 ans qu'on ne sait pas ce qu'il voulait dire.

            • [^] # Re: L'original ...

              Posté par  . Évalué à 3.

              Bah, pas si illogique que ça : tout dépend du nombre d'oeil que tu fais cligner … si tu clignes toujours le même, ce sont des clins d'oeil, si tu fais cligner les deux ce sont des clins d'yeux. JE ne vois pas ou est le problème, pas de trace de personne bourrée dedans.

      • [^] # Re: L'original ...

        Posté par  . Évalué à -1.

        Je pense qu'on se fout un peu de notre gueule. C'est du vol et du plagiat.

        Mais…. Tu te permets d'interrompre ce flime ?

      • [^] # Re: L'original ...

        Posté par  . Évalué à -2.

        J'aime pas les voleurs et les fils de p***

        La classe !

  • # diff

    Posté par  (site web personnel) . Évalué à 4.

    - quand le réseau commence à être saturer
    + quand le réseau commence à être saturé

    ce commentaire est sous licence cc by 4 et précédentes

  • # Micro-kernel

    Posté par  . Évalué à 10.

    Super la description du travail d'Andy. En le lisant je n'ai pas pu m'empêcher de me dire que c'est un problème qui doit être inexistant dans les micro-noyaux, non ?

    Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

    • [^] # Re: Micro-kernel

      Posté par  . Évalué à 8.

      En effet, cette chronique du travail d'Andy est véritablement passionnante !

      De ce que j'ai compris de la problématique, je pense que ce problème pourrait se poser dans un système à micro-noyau.
      En effet, les responsabilités du noyau sont certes limitées et dispersées dans des processus utilisateurs de l'espace utilisateur/non privilégié. Néanmoins, le micro-noyau lui même pourrait avoir le même type de problème si la pile noyau n'est pas mappée virtuellement à la mémoire. Cela dépend des choix d'implémentation.

      La solution présentée dans cet article ne peut être mise en oeuvre que sur des architecture possédant une MMU. Les systèmes à noyau monolithique ou même à micro-noyau tournant sur des architectures sans MMU devront toujours faire face à ce problème, et procéder à l'ancienne pour détecter l'overflow (canaris, peinturer la pile, …, ou dans le meilleur des cas utiliser une MPU si disponible, avec l'inconvénient de gâcher une page pour la garde).

    • [^] # Re: Micro-kernel

      Posté par  (site web personnel) . Évalué à 8.

      J'en déduis surtout qu'il y a un GC dans le noyau Linux (et un très basique par rapport aux langages modernes, en plus) :

      libère les ressources d’un fil (dont sa pile d’exécution) par saccade. Le RCU accumule les ressources de tous les fils qui se terminent, puis les libère tous en même temps.

      en attendant le prochain cycle du RCU

      les pics de piles d’exécution fournis par le RCU [ah tiens un GC bloquant ?]

      cela prend un certain temps pendant lequel la structure thread_info ne peut être utilisée par un nouveau fil. On en revient au même : attendre la fin du cycle du RCU !

      Du caviar pour les prochains trolls sur les GC et comment Linux ne peut pas se permettre de ne pas être écrit en C.

  • # Enlarge your stack

    Posté par  (site web personnel) . Évalué à 4.

    Et de nombreuses personnes préféraient plutôt en avoir une plus grosse !

    Excusez moi je meurs de honte et je reviens :-D

    kentoc'h mervel eget bezan saotred

    • [^] # Re: Enlarge your stack

      Posté par  . Évalué à -1.

      Alors qu'ils en ont déjà plus de 8000!

      Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

  • # Contournement des Clés de protection de la mémoire

    Posté par  . Évalué à 10.

    Bonjour,

    Un grand merci pour cet article de grande qualité.

    Je n'ai pas compris le passage sur les "Clés de protection de la mémoire" où il est fait mention d'un contournement possible de la solution d'Intel. Est-ce que ça va dire que la solution n'est pas exploitable en tant que tel pour le moment, ou il est nécessaire de mettre en place d'autres mesures existantes pour avoir une solution 100% fonctionnelle ?

    Est-ce que vous avez des précisions là-dessus, s'il vous plait ?
    Un grand merci d'avance !

    • [^] # Re: Contournement des Clés de protection de la mémoire

      Posté par  (site web personnel) . Évalué à 8. Dernière modification le 08 février 2017 à 11:43.

      Salut et merci pour cette remarque pertinente.
      C'était prévu que j'éclaircisse cet aspect et j'ai zappé :-/

      Vaut mieux tard que jamais, alors voici l'explication :

      Le risque zéro n'existe pas, même dans le domaine de la Sécurité. Alors pour mettre des bâtons dans les roues des attaques, on cherche à rajouter des barrières complémentaires (l'image souvent utilisée est celle des pelures d’oignon).

      Donc, oui, les clés de protection sont à utiliser avec les autres protections complémentaire.

      Néanmoins, on peut imaginer une attaque qui consiste à exploiter des failles pour casser chacune des sécurités, et malgré l'accumulation de mesures complémentaires, la solution ne sera jamais 100% fonctionnelle. Je préfère dire que la sûre ne sera jamais 100% sûre (sauf bien sûr, à implémenter une solution inutilisable).

      Commentaire sous licence Creative Commons Zero CC0 1.0 Universal (Public Domain Dedication)

      • [^] # Re: Contournement des Clés de protection de la mémoire

        Posté par  . Évalué à 1.

        OK, merci.

      • [^] # Re: Contournement des Clés de protection de la mémoire

        Posté par  . Évalué à 3.

        Il y a une coquille qui est resté dans ce paragraphe

        Ce système définit un ensemble d’interfaces en espace utilisateur (lire des appels système) et offre aux applications un mécanisme de protection des données par page à l’aide de clés de chiffrement.

        Les clef de protection n'ont rien a voir avec du chiffrement. Ce sont plus des clefs d’accès au sein d'un même espace adresse.

        Sur mainframe IBM, c'est utilisé, par exemple, pour isoler le code utilisateur du code noyau d'un moniteur transactionnel.

  • # Erreurs d'attribution

    Posté par  (site web personnel) . Évalué à 4.

    Pour "EFI Test Driver" et "Mellanox Platform", ça n'est pas du tout Ingo qui a proposé les patches c'est respectivement Ivan Hu (http://www.spinics.net/lists/linux-efi/msg08921.html) et Vadim Pasternak (https://lkml.org/lkml/2016/9/22/958)

    • [^] # Re: Erreurs d'attribution

      Posté par  (site web personnel) . Évalué à 7.

      Ingo Molnar est le mainteneur donc celui qui a poussé le patch final contenant des multiples contributions ?

      Il y mentionne :

      lex Thorlton (1):
      Ard Biesheuvel (5):
      Colin Ian King (1):
      Ivan Hu (1):
      Lukas Wunner (4):
      Markus Elfring (2):
      Matt Fleming (13):
      Ricardo Neri (1):
      Sylvain Chouleur (2):

      et

      Andrew Banman (10):
      Andy Shevchenko (7):
      Vadim Pasternak (1):
      Wei Yongjun (1):

  • # Merci pour la dépêche !

    Posté par  . Évalué à 6.

    Merci pour cette dépêche bien détaillée !

    Donation Bitcoin : 1N8QGrhJGWdZNQNSspm3rSGjtXaXv9Ngat

  • # À propos de /dev/urandom

    Posté par  . Évalué à 0.

    Myths about /dev/urandom explique bien les différences (où plutôt l’absence de différence) entre /dev/random et /dev/urandom.

    • [^] # Re: À propos de /dev/urandom

      Posté par  . Évalué à 10.

      Il y a bien une différence : /dev/random/ garantit de renvoyer des bits réellement aléatoires (et non pseudo-aléatoires), tandis que /dev/urandom peut retomber sur un comportement prédictible s'il est utilisé avant que le pool d'entropie soit suffisamment plein. Cela pose problème pour les programmes lancés pendant le démarrage d'un système, qui font alors face à un dilemme :

      • soit lire depuis /dev/urandom, qui est non-bloquant mais risque dans certains cas de fournir une entropie insuffisante (et donc rendre ces programmes potentiellement vulnérables, s'ils utilisent ces bits aléatoires pour des fonctions de sécurité)

      • soit lire depuis /dev/random et risquer de bloquer pendant de longues secondes, le temps que le pool d'entropie soit initialisé

      C'est très bien expliqué dans le document de proposition du nouveau RNG, avec des mesures concrètes assez édifiantes : le pool d'entropie actuel peut ainsi prendre 30 secondes pour collecter suffisamment d'entropie (notamment sur une VM, qui dispose de sources d'entropie limitées), ce qui est beaucoup trop long pour les besoins des programmes lancés au démarrage. Avec la proposition de nouveau RNG, ce délai descend à une seconde ou moins, ce qui est beaucoup plus supportable.

      Pour un exemple concret, Python utilise désormais la version bloquante de l'appel système getrandom(), ce qui offre des garanties plus fortes que de lire depuis /dev/urandom:
      https://www.python.org/dev/peps/pep-0524/

      • [^] # Re: À propos de /dev/urandom

        Posté par  . Évalué à 1.

        Il y a bien une différence : /dev/random/ garantit de renvoyer des bits réellement aléatoires (et non pseudo-aléatoires),

        Justement non. L’article que j’ai cité explique bien comment fonctionne /dev/random et /dev/urandom (ils utilisent le même PRNG).

        Et puisque tu parles de getrandom, voilà ce que dit l’auteur de l’article : “In the meantime, Linux has implemented a new syscall, originally introduced by OpenBSD as getentropy(2): getrandom(2)”.

        • [^] # Re: À propos de /dev/urandom

          Posté par  . Évalué à 10.

          L’article que j’ai cité explique bien comment fonctionne /dev/random et /dev/urandom (ils utilisent le même PRNG).

          La différence n'est pas là. La différence est dans le fait que /dev/random est bloquant jusqu'à ce qu'il y ait assez d'entropie (garantissant ainsi que les bits renvoyés ne peuvent être prédits), alors que /dev/urandom peut renvoyer des bits uniquement pseudo-aléatoires (donc théoriquement prédictibles) s'il n'y a pas assez d'entropie.

          L'auteur de l'article prétend que ce n'est pas un problème. Mais ce n'est pas ce que pense l'auteur de la proposition de nouveau RNG, qui considère que la sécurité actuelle est insuffisante. La question n'est pas aussi tranchée que l'article semble le dire.

          Ce qui est vrai, c'est que pour la plupart des applications, /dev/urandom est largement suffisant. Mais il y a des usages, minoritaires mais importants, où la possibilité de retomber sur une génération uniquement pseudo-aléatoire (typiquement, au démarrage du système) peut poser de réels problèmes de sécurité.

          Et puisque tu parles de getrandom, voilà ce que dit l’auteur de l’article

          Oui, et je ne vois pas en quoi cela contredit ce que j'ai dit. getrandom() a un comportement différent de /dev/urandom/ pendant le démarrage du système.

          Ainsi (page de manuel de getrandom()) :

          By default, when reading from /dev/random, getrandom() blocks if no random bytes are available, and when reading from /dev/urandom, it blocks if the entropy pool has not yet been initialized.

          => au démarrage du système, getrandom() bloque jusqu'à ce que le pool d'entropie soit initialisé (i.e. rempli une première fois)

          Tandis que (page de manuel de /dev/urandom):

          A read from the /dev/urandom device will not block waiting for more entropy. If there is not sufficient entropy, a pseudorandom number generator is used to create the requested bytes. As a result, in this case the returned values are theoretically vulnerable to a cryptographic attack on the algorithms used by the driver.

          => au démarrage du système, il est possible que /dev/urandom renvoie des bits théoriquement prédictibles.

          Encore une fois, l'article pense que cette différence n'a pas d'importance, l'auteur de la proposition de nouveau RNG (et aussi l'auteur des pages de manuel Linux) pense que si.

          • [^] # Re: À propos de /dev/urandom

            Posté par  (site web personnel) . Évalué à 2.

            l'article pense que cette différence n'a pas d'importance,

            En fait, ce n'est pas vraiment le sujet : l'auteur du commentaire initial pense qu'il n'y a pas de différence, alors qu'il y en a une (qu'elle soit importante ou pas n'a pas d'importance, l'auteur n'a pas dit que la différence n'est pas importante, il a dit qu'il y a une absence de différence ce qui et factuellement faux).

            Bon, peut-être qu'il commence à comprendre, il ne va pas jusqu'à dire qu'il a dit une connerie au début mais change discrètement sa formulation pour parler du PRNG (absence de différence) à la place de l'algo entier (différence).

          • [^] # Re: À propos de /dev/urandom

            Posté par  . Évalué à 7.

            Encore une fois, l'article pense que cette différence n'a pas d'importance, l'auteur de la proposition de nouveau RNG (et aussi l'auteur des pages de manuel Linux) pense que si.

            De ce que j'ai compris, Stephan Müller dit que cette propriété de garantir d'avoir assez d'entropie est importante, mais son patch permet que /dev/urandom puisse être seedé avec assez d'entropie au boot, contrairement à l'ancien, et recommande toujours l'utilisation de /dev/urandom comme source d'entropie pour la plupart des usages, même cryptographiques ! Il n'est écrit nulle part dans sa proposition de préférer /dev/random, bien au contraire : il n'a fait que pérenniser ce que préconisent les promoteurs de urandom, comme Arcaik, et de permettre de continuer à se baser dessus, même au boot.

            • [^] # Re: À propos de /dev/urandom

              Posté par  . Évalué à 8. Dernière modification le 10 février 2017 à 15:22.

              La discussion est un peu compliquée par le fait que parler de /dev/urandom peut désigner deux choses:

              • l'API /dev/urandom elle-même, c'est-à-dire le fait de lire depuis ce fichier, a le problème de renvoyer des octets théoriquement prédictibles au démarrage ; cette API devient progressivement obsolète (sous Linux) au profit de getrandom() qui résoud ce problème précis ;

              • le RNG sous-jacent, souvent désigné par raccourci de la même manière, mais qui est aussi utilisé par getrandom() avec des garanties différentes

              La proposition de Stephan Müller corrige certains problèmes du RNG sous-jacent, pas de l'API qui, elle, reste toujours problématique pour des usages nécessitant un degré élevé de sécurité (par exemple pour générer une clé privée utilisée pendant tout l'uptime dans d'un démon). Ainsi la proposition de Stephan Müller raccourcit le temps pendant lequel l'API /dev/urandom peut renvoyer des octets prédictibles, elle ne l'élimine pas.

              • [^] # Re: À propos de /dev/urandom

                Posté par  . Évalué à 4.

                a le problème de renvoyer des octets théoriquement prédictibles au démarrage

                Même avec le « hack » décrit dans l’article de Thomas Hühn ?

                On Linux it isn't too bad, because Linux distributions save some random numbers when booting up the system […] into a seed file that is read next time the machine is booting. So you carry over the randomness from the last running of the machine. 
                

                Question subsidiaire, il parle également du cas FreeBSD (juste au dessus) :

                FreeBSD does the right thing: they don't have the distinction between /dev/random and /dev/urandom, both are the same device. At startup /dev/random blocks once until enough starting entropy has been gathered. Then it won't block ever again.
                

                Pourquoi est-ce que c’est pas implémenté de la même manière sous Linux plutôt que d’avoir 3 API (les deux devices et un syscall) ?

                Merci pour tes réponses en tout cas :)

                • [^] # Re: À propos de /dev/urandom

                  Posté par  . Évalué à 4.

                  Même avec le « hack » décrit dans l’article de Thomas Hühn ?

                  Imagine que tu démarres toujours ta VM depuis le même instantané (dans un usage « stateless » façon Docker). Alors tu initialiseras toujours ton PRNG avec les mêmes valeurs « aléatoires ».

                  Pourquoi est-ce que c’est pas implémenté de la même manière sous Linux plutôt que d’avoir 3 API (les deux devices et un syscall) ?

                  Honnêtement, je n'en sais rien. L'avantage d'un syscall, c'est qu'on n'a pas besoin d'ouvrir un descripteur de fichier, et on peut tailler la sémantique sur mesure. Mais je ne connais pas l'historique.

                  • [^] # Re: À propos de /dev/urandom

                    Posté par  . Évalué à 6.

                    Imagine que tu démarres toujours ta VM depuis le même instantané

                    Ou tout simplement depuis un système de fichiers en lecture seule, comme c'est le cas dans des millions de « box », de routeurs, etc.

    • [^] # Re: À propos de /dev/urandom

      Posté par  (site web personnel) . Évalué à -10.

      (où plutôt l’absence de différence)

      Il y a des gens qui prennent le temps d'expliquer l'unique (mais importante) différence entre les deux mais non, il faut une personne qui ne lit pas vraiment la dépêche mais croit tout savoir et balance une phrase qu'on lui aurait dite par une source "sûre", et aussi sans volonté de réfléchir : une démonstration claire et nette qu'elle n'a pas lu la dépêche.
      Sans doute un fan de Trump, amateur de faits alternatifs…

  • # Coquilles

    Posté par  (site web personnel) . Évalué à 5.

    D’ailleurs c’est l’essence même de l’existence de task_struct : permettre un accès direct en appliquant un masque sur le pointeur d’exécution

    Si j'ai bien compris, il s'agit dans cette phrase de thread_info et non de task_struct.

    Sinon le paragraphe "Virtual mapped stack" de la fin est devenu inutile avec l'explication très détaillée de la même fonctionnalité au début de la dépêche (si ce n'est la phrase sur GrSecurity qui pourrait être récupérée).

    Et merci pour cette bien belle dépêche !

  • # AMDGPU

    Posté par  . Évalué à 2.

    Y en a t-il parmis vous qui on une AMD récente et qui peut parler de la 3d?

    J'ai toujours des bonnes expériences avec AMD par le passé hors jeux - bureaux fluides, video, veilles, 3d sans trop de shaders… Mais je voudrais savoir ce que cela vaut à présent. A t-on enfin le niveau de perf que ces cartes sont supposées fournir et ce en libre?

    • [^] # Re: AMDGPU

      Posté par  . Évalué à 1. Dernière modification le 09 février 2017 à 14:02.

      Depuis le noyau 4.8 au moins, je suis très satisfait des performances de mes cartes AMD : VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Trinity [Radeon HD 7480D].
      glsgears donne 2700 à 3000 fps.

      • [^] # Re: AMDGPU

        Posté par  . Évalué à 3.

        Une carte récente, la Radeon HD 7480D ? Il ne me semble pas.
        Moi j'ai une Radeon HD 5850, mais elle date de 2010 ! Marche très bien encore sur quelques jeux récents (counter-strike global offensive, XCOM2, Pillars of eternity, rocket league…) en 1920 x 1080, avec le pilote propriétaire !
        Je n'ai jamais testé le pilote libre, mais je n'ai pas complètement honte, jouer sur linux c'est déjà être une exception !

      • [^] # Re: AMDGPU

        Posté par  . Évalué à 2.

        Merci pour vos retours mais GLXgears n'est en rien un indicateur de performance.
        J'avais aussi du temps de ma radeon 3450 une expérience satisfaisante avec le pilote libre sous Linux hors jeux.

        • [^] # Re: AMDGPU

          Posté par  . Évalué à 2. Dernière modification le 10 février 2017 à 01:06.

          Non, effectivement.
          Pour avoir des informations plus pertinentes, il faut consulter les comparatifs sur Phoronix.
          Mon avis pour faire court, c'est que windows reste une meilleure plateforme pour les jeux que linux, vu que les jeux commerciaux sophistiqués sont d'abord développés pour windows.
          Puisque de toute façon Direct X11 et 12 n'existent pas sous linux, les jeux qui utilisent ces API sous windows sont donc "portés" sur linux, parfois en utilisant SDL, parfois en utilisant simplement wine, avec les conséquences que cela peut avoir sur les performances. Les jeux qui utilisent nativement OpenGL s'en sortent généralement mieux lors du portage de linux vers windows.
          Donc, dans le meilleur des cas, on a des performances similaires sur les jeux sous linux par rapport à windows, mais je n'ai jamais entendu parler de performances meilleures.
          Ensuite, les pilotes propriétaires gardent une longueur d'avance concernant les fonctionnalités 3D avancées.
          Enfin, Nvidia reste supérieur à AMD, pour la bonne raison que les développeurs y consacrent plus de temps. Certains jeux fonctionnent bien mieux ou uniquement avec une carte graphique Nvidia : Counter strike Global Offensive est parait-il 2 fois plus rapide sur Nvidia que sur AMD, Borderlands 2 ne fonctionne que sur Nvidia.

          Cela étant, il y a de plus en plus de jeux AAA (commerciaux à gros budget) disponibles sous linux.
          En tout cas j'ai commandé récemment une AMD RX 480 !

        • [^] # Re: AMDGPU

          Posté par  . Évalué à 1. Dernière modification le 10 février 2017 à 10:38.

          Merci pour vos retours mais GLXgears n'est en rien un indicateur de performance.

          C'est vrai mais faute de mieux, c'est un indicateur de bon fonctionnement de base. C'est avec ça que j'ai trouvé des problèmes importants sur le pilote Intel de Xorg et que j'ai pu amélioré sa configuration en fonction de la puce que j'utilisais.

          Il faut combiner glxgears avec la variable vblank_mode.

          Si vous connaissez des outils simples et meilleurs que glxgears de mesure de rendu, je suis preneur.

          PS : Je n'utilise que des pilotes libres avec des microcodes euh… moins libres.

          • [^] # Re: AMDGPU

            Posté par  . Évalué à 2.

            Si vous connaissez des outils simples et meilleurs que glxgears de mesure de rendu, je suis preneur.

            Team Fortress II (free2play) ou Doom 3 ( de 2004 quand même :/) dans la résolution native de ton écran. :)

  • # Un bogue

    Posté par  . Évalué à 2.

    Autant le noyau 4.8 fonctionnait très bien sur mes systèmes (MSI AMD x64 et Intel x86) et même mieux que le 4.7 et précédents, autant j'ai des problèmes avec le 4.9 sur Debian.

    Le plus grave c'est l'impossibilité d'arrêter les machines qui redémarrent au lieu de se mettre hors tension avec la commande poweroff ou équivalente.

    Le chien de garde (informatique) pourrait en être la cause, je suppose.

    • [^] # Re: Un bogue

      Posté par  (site web personnel) . Évalué à 1.

      Le chien de garde (+ connu sous le terme watchdog) n'est présent matériellement que sur les serveurs et nécessite une activation dans le BIOS + une initialisation par le système d'exploitation. Ce dernier doit derrière régulièrement ré-initailiser un compteur pour éviter un reboot.

      • [^] # Re: Un bogue

        Posté par  (site web personnel) . Évalué à 3.

        Le chien de garde (+ connu sous le terme watchdog) n'est présent matériellement que sur les serveurs et nécessite une activation dans le BIOS + une initialisation par le système d'exploitation.

        Bah non, tout ordinateur ayant un processeur un minimum évolué a un watchdog. IL est d'ailleurs probable que ton OS ait un processus noyau nommé wathdog/X pour gérer ça.

        Dans les systèmes embarqués c’est également très courants, et tous les x86 en ont un aussi.

        • [^] # Re: Un bogue

          Posté par  . Évalué à 4.

          tous les x86 en ont un aussi.

          Ça existe depuis le i386, plus de 20 ans.
          Par contre ça ne correspond pas à ma définition d'un chien de garde (avis perso, etc). Par exemple si le noyau est bien planté, le chien de garde des x86 ne fera rien. Idem avec un chipset qui bloque la machine de temps en temps.
          Un vrai chien de garde redémarre la machine lorsqu'il n'est pas réactivé au bout de x secondes.

          • [^] # Re: Un bogue

            Posté par  . Évalué à 3.

            Du coup, à quoi sert ce watchdog, s'il ne redémarre pas la machine quand elle est gauffrée ?

            • [^] # Re: Un bogue

              Posté par  . Évalué à 2.

              Ben justement, ce n'est pas ce que j'appelle un chien de garde :-)

              Ça fonctionne probablement dans beaucoup de cas. Mais certainement pas pour un truc un peu critique.

    • [^] # Re: Un bogue

      Posté par  . Évalué à 2.

      Qu'entends tu par "fonctionner moins bien" et par "problèmes" ?

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.