Le noyau Linux 3.2 est disponible

117
5
jan.
2012
Noyau

La sortie de la version stable 3.2 du noyau Linux vient d'être annoncée par Linus Torvalds sur la liste de diffusion et sur Google+. 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.

P.‐S. : Merci à toutes les personnes qui ont aidé à traduire les courriels de RC quand cette dépêche était dans l'espace de rédaction. Merci également à Laurent Wandrebeck (low) pour sa contribution sur la brève concernant DVFS.

Sommaire

La phase de test

RC-1

La version RC-1 a été annoncée le 7 novembre dernier par Linus :

Cela fait donc deux semaines depuis la 3.1, et vous connaissez le fonctionnement maintenant.
Je dois dire que cela n'a pas été ma fenêtre d'intégration favorite. J'aurais vraiment voulu prendre uniquement les choses qui se trouvaient dans -next, mais vérifier tout ça a été très douloureux, surtout que de nombreuses branches ont été réunifiées, et celles qui ne l'ont pas été contenaient souvent de nouveaux correctifs qui étaient toujours visibles quand je faisais un « git log linux-next..FETCH_HEAD ».
Dans l'ensemble, la plupart des trucs étaient corrects et je n'ai pas vraiment protesté auprès des gens. Je suis à peu près sûr qu'il y a des branches que je n'aurais pas dû laisser passer mais la majorité était vraiment dans -next.
L'autre point d'irritation est qu'il y a des nouveaux patchs qui sont arrivés hier et qui, en gros, ont pris la fenêtre d'intégration pour une sorte de dance Limbo high-tech. S'il ne s'agissait pas de quelques branches que je voulais intégrer, j'aurais en fait planifié la sortie de -rc1 dimanche après-midi, juste pour couper court à ces demandes d'intégration de dernière minute.
D'ailleurs certaines branches n'ont pas été intégrées. Vous vous reconnaîtrez, et vous pouvez essayer de faire appel à mon côté gentil si vous pensez que c'est injuste. Bien sûr, si vous réussissez à le faire, merci d'informer ma femme et mes enfants, ils seront ravis de l'apprendre.
En fait la raison principale de la non-intégration de ces branches est qu'elles ont généré de longues flame-wars. Je ne voulais pas aggraver les choses ces temps-ci, surtout en sachant qu'il y avait plein d'autres branches à intégrer.
Qu'ai-je intégré ? Beaucoup de choses. Les statistiques sur les différences sont énormes, et remplies de renommages. Les pilotes réseau ont été réorganisés, ce qui est un gros morceau de renommage, mais il y a les architectures qui ont été, elles aussi, nettoyées et réorganisées (UML et quelques sous-architectures arm, par exemple) ajoutant leur propre lot de renommages. À cela s'ajoutent des pilotes de la branche -staging qui sont passés dans la branche principale, etc.
Mis à part les réorganisations, il y a vraiment beaucoup de changements un peu partout. À peu près 75 % pour les pilotes (et cela sans compter les renommages), 15 % architecture, et 10 % « le reste » (principalement système de fichiers et réseau - avec les fichiers d'en-tête s'affichant aussi dans les statistiques).
Ce qui n'apparaît même pas dans les statistiques, ce sont les changements sur la mémoire virtuelle, bien que ceux-ci soient les plus remarquables au coeur du système. C'est peut-être proportionnellement petit, mais c'est un peu fondamental, et cela a le potentiel de toucher tout le monde. Les gens ont travaillé sur le writeback, et tout ce qui concerne la gestion fine de l'écriture de pages dirty. Ainsi, maintenant les problèmes de writeback devraient faire partie du passé. Voyons comment tout cela fonctionne.
Amusez-vous, testez le bien. Il ne devrait rien avoir d'énormément effrayant là-dedans, mais il y a beaucoup de choses. Le fait que 3.1 ait traîné signifie que cela fut une des plus grosses fenêtres d'intégration, mais je ne me sens pas trop nerveux à ce propos.

RC-2

La version RC-2 est sortie le 15 novembre :

Linux 3.2-rc2 est maintenant disponible. En fait, les dépôts git sont là (kernel.org et github), et les fichiers tar devraient être bons, mais le patch est toujours en cours de transfert.
Une chose qui vaut la peine d'être remarquée : j'ai corrigé mes nouveaux scripts de publication, ainsi maintenant les fichiers de -rc2 se trouvent à la place qui leur revient de droit « v3.x/testing », contrairement à -rc1 où les fichiers étaient directement dans « v3.x ». Je corrigerai l'emplacement de cette -rc1 quand je serai dans un endroit ayant un meilleur réseau.
Et pour une version -rc2 venant après une fenêtre d'intégration aussi longue, elle semble avoir une taille assez raisonnable. En fait, bien que ce soit le plus gros linux-next au cours d'une publication dans toute l'histoire de linux-next (je pense), -rc2 a exactement le même nombre de commits depuis -rc1 que c'était le cas avec le noyau 3.1.
Environ la moitié des changements concerne des corrections d'architectures (m68k et arm, avec un peu de powerpc et une poignée d'autres). Pour le reste, environ la moitié concerne les pilotes (la plupart concernent DRM), et le reste est « système de fichiers et diverses mises-à-jour ».

RC-3 - Juste à temps pour Thanksgiving

La version RC-3 a été annoncée par Linus le 23 novembre, veille de la fête de Thanksgiving aux USA :

Hey, puisque la majeure partie des États-Unis sera dans le coma demain, suite aux indigestions, je sais que publier une nouvelle version candidate est une bonne idée.
Un quart de mises à jour d'architectures, 2 quarts de pilotes, et un autre quart de changements aléatoires. Secouez vigoureusement et servez froid…
Et peut-être que le reste du monde peut essayer de compenser la probable absence de participation des États-Unis ? Hmm ?
Peu importe, que vous vous gaviez de dinde ou non demain, une nouvelle -rc est sortie. J'aurais aimé vous dire que les choses se sont calmées, et que le nombre de commits se réduit, mais je mentirais. -rc3 est en fait plus gros que -rc2, principalement à cause de mises à jour réseau (rien dans -rc2) et avec Greg faisant son truc 'usb/driver-core/tty/staging' habituel.
Nous avons aussi eu des mises-à-jour sur DRM.
Ceci étant dit, la plupart des commits sont assez petits et raisonnables. Bon, il y a certainement plus de trucs que ce que j'aurais souhaité, mais ce n'est pas comme s'il s'agissait d'un tas de gros changements.

RC-4

Une fois que le « food-induced coma » de la version précédente a été surmonté, c'est le premier décembre que Linus a fait paraître la version RC-4 du noyau 3.2 :

Cela ne semble pas énormément plus petit que la -rc2 ou la -rc3 mais ça l'est vraiment.
Oui, il y a bien quelques modifications sur ARM, des corrections dans le nouveau code DRI Exonys et une mise à niveau tardive d'ocfs2, mais si vous ignorez ces trois secteurs (et la plupart d'entre-vous le font avec joie), les choses se sont joliment calmées.
Il y a quelques petites mises à jour sur la partie son, et btrfs reçoit encore des correctifs (mais bien moins que pour la -rc2), mais en dehors de cela, tout a été inhabituellement calme.
Je m'attends à une seconde vague. Il est possible que Davem et GregKH se retiennent - leur silence est très suspect, et j'ai le sentiment d'entendre des petits rires démoniaques. Mais, c'est peut-être tout simplement l'heure de prendre mes médicaments.

RC-5

Une semaine plus tard, le 9 décembre au moment de la RC-5, Linus a confirmé que ses craintes étaient fondées :

Cela fait un peu plus d'une semaine, et je suis désolé de constater que la -rc5 est plus grosse (au moins en nombre de commits - la plupart d'entre eux sont assez petits, il est donc possible que le fichier des différences soit plus petit, mais je n'ai pas vérifié) que la -rc2 et la -rc4 l'ont été.
Tant pis pour « les choses se sont joliment calmées ».
Bon, cela est probablement dû en partie au retour d'Ingo et de ses commits en retard (principalement x86 et perf). Mais franchement, cela n'est pas suffisant pour expliquer tout ça - nous avons des modifications sur xfs et btrfs, des mises-à-jour réseau, et l'habituel 50 % de modifications éparpillées parmi les pilotes (son, périphériques de pointage, processeurs graphiques sortent du lot, mais il y a aussi pas mal de mouvements du côté réseau et raid logiciel).
Ceci étant dit, il n'y a rien de bien dangereux et cela tend à être de petites modifications, dont plusieurs corrigent de sacrées régressions.
Je vais continuer à résister un peu auprès des gens qui m'envoient des trucs, mais j'espère aussi que c'était un accident isolé et que nous allons vraiment lever le pied maintenant.
OK ? Parce que nous voulons tous des vacances tranquilles, n'est-ce pas ? Et le père Noël n'aime pas quand je lance des bordées de jurons par courriel.

RC-6

La version RC-6 a été annoncée le 16 décembre par Linus :

Bon, les gens ont compris comment tricher avec mon timing de sortie des nouvelles versions parce que j'ai reçu aujourd'hui plus de la moitié des commits de la -rc6.
Je serai généreux et je dirai juste « OK, les gens ont simplement attendu le dernier vendredi avant les vacances pour envoyer leurs commits ». Peut-être qu'il ne s'agit pas vraiment de tricher avec le cycle des -rc, mais de manière générale je déteste quand les gens envoient leurs demandes au dernier moment.
Donc si vous avez fait exprès de faire ça, arrêtez s'il vous plait.
Ce serait bien mieux de répartir les choses sur la période - et d'avoir des développeurs qui suivent la branche -git pour réagir au fur et à mesure - plutôt que d'avoir un tir groupé juste avant la sortie de la -rc.
Ceci dit cette version est plus petite que les précédentes et les choses semblent se calmer. Nous en sommes à la -rc6 et, si je peux m'imaginer en train de faire une -rc7, je n'irai probablement pas jusqu'à la -rc8 à moins que nous ne trouvions un gros problème. Il n'y a pas vraiment de raison de faire traîner les choses un peu plus et nous aurons probablement le vrai 3.2 vers la nouvelle année.

RC-7

Finalement l'ultime version candidate, la RC-7, a été annoncée le 24 décembre par Linus :

Voilà la probable dernière -rc avant la sortie finale du 3.2, donc, testez-la bien entre vos fêtes de fin d'année s'il vous plaît.
La plupart des changements ne font qu'une seule ligne, mais quelques commits sur le pilote qla4xxx sont plus gros et concernent, en fait, 40 % du diff. Cela, avec une mise à jour du pilote VMWare DRI et quelques changements dvb ainsi que les corrections habituelles de pilotes font que 80 % des changements sont dans les pilotes.

Les nouveautés

CFS bandwidth controller

L'ordonnanceur CFS (Completely Fair Scheduler) du noyau Linux 3.2 incorpore maintenant la fonction de contrôle de bande passante (bandwidth controller) développée par Paul Turner.

En temps normal, l'ordonnanceur CFS essaye de rester fidèle à son nom en allouant le temps processeur de façon équitable entre les processus qui s'exécutent sur la machine. Le code divise simplement les ressources processeur en autant de tranches (slices) qu'il y a de processus. Bien entendu, on peut, via l'option de « Group Scheduling » introduite dans le noyau 2.6.38, favoriser un groupe de processus, si on veut une répartition différente du temps de processeur.
Que se passe-t'il si un processus ne dépense pas son temps de CPU parce qu'il n'en a plus besoin ? Par défaut, dans ce cas de figure, CFS n'est pas obtus au point de forcer le caractère « complètement équitable » de la répartition des ressources. L'ordonnanceur va donc allouer le temps CPU inutilisé aux autres processus qui tournent à ce moment-là. Certes ce n'est plus équitable mais c'est bien plus efficace !

Il y a toutefois des cas de figure où on ne veut pas de ce comportement « altruiste » qui offre les cycles processeur inutilisés aux autres processus. On veut - au contraire - pouvoir contrôler finement les allocations de temps CPU décidées par CFS.
Bharata Rao, qui - avant Paul Turner - avait proposé une première série de patchs, a listé dans son mail d'annonce les cas d'utilisation potentiels de cette fonction de « bandwidth control ».

  • On retrouve le scénario classique d'un environnement virtualisé où l'administrateur souhaite limiter la consommation CPU d'un conteneur, et ce même si des ressources inutilisées sont disponibles par ailleurs.
  • Un autre cas d'utilisation envisageable est celui ou des garanties de temps d'exécution doivent exister. En faisant du « bandwidth control » on est certain que le processus crucial ne verra pas son temps processeur mangé par les autres à un moment crucial.
  • Enfin, le scénario du « pay-per-use » devient également possible grâce à ce travail sur le contrôle de bande passante. Une entreprise qui vend à ses clients un temps d'utilisation de CPU ne veut pas que ces derniers profitent gratuitement de ressources additionnelles. La société vendeuse utilisera donc le nouveau « bandwidth controller » pour spécifier exactement ce à quoi ont droit les processus du client.

Afin d'activer le contrôleur de bande passante, il faut un noyau compilé avec l'option CFS_BANDWIDTH (attention l'option dépend encore d'EXPERIMENTAL pour le moment). Le paramétrage se fait via les deux variables cpu.cfs_period_us et cpu.cfs_quota_us avec la microseconde comme unité de compte.
La bande passante CPU qui est accordée à un groupe pendant une durée de cpu.cfs_period_us est égale au quota cpu.cfs_quota_us.
Par exemple, si je veux limiter la consommation à 20 % du CPU par période d'une demi-seconde, je vais faire un petit :

echo 100000 > cpu.cfs_quota_us
echo 500000 > cpu.cfs_period_us

Chaque demi-seconde (la période), le groupe est autorisé à consommer seulement un dixième de seconde de temps CPU (le quota), ce qui correspond bien à 20 % des ressources.
En cas de machine multiprocesseur, on augmente simplement le quota pour refléter les ressources de la machine. Si, par exemple, on désire limiter le groupe à une bande passante correspondant à deux cœurs, on peut - par exemple - définir un quota d'une seconde toute les périodes d'une demi-seconde :

echo 1000000 > cpu.cfs_quota_us
echo 500000 > cpu.cfs_period_us

La documentation explique très bien tout ce mécanisme et détaille également les possibilités qui existent en termes de génération de statistiques (via cpu.stat).

Ext4 bouge encore

Dans le tout nouveau noyau Linux 3.2, le système de fichiers Ext4 a été modifié grâce au patch bigalloc afin d'améliorer ses performances. Divers changements visant à renforcer encore un peu plus sa stabilité ont également été intégrés.

Les dernières grosses améliorations sur Ext4 ayant été ajoutées dans le noyau 2.6.37, on pouvait penser que ce système de fichiers allait maintenant entrer en mode de maintenance pure, sans ajouts importants.
Finalement, ce n'est pas le cas et les développeurs continuent d'ajouter des fonctions afin de renforcer son attractivité. On peut d'ailleurs noter que Ted Ts'o pense que Btrfs ne pourra probablement pas remplacer Ext4 dans certains cas de figure bien particuliers.

La grosse nouveauté de ce cycle est donc l'intégration du patch bigalloc qui permet de regrouper en « clusters » les blocs de données traités par Ext4. La taille de ces blocs de données est de 4 Kio et il n'est pas facile de changer cette taille car le noyau s'attend à la retrouver dans une multitude d'endroits (gestion de la mémoire, cache des pages, etc.). Dans les faits, la taille des blocs du système de fichiers est donc limitée par la taille des pages et la surcharge de travail - induite par la gestion de ces blocs - est conséquente.
Puisqu'on ne peut pas - sans des efforts démesurés - changer la situation en aval, les développeurs Ext4 ont décidé de traiter le problème en amont. C'est donc le système de fichiers lui-même qui va prendre en charge la coalescence des blocs de 4 Kio, pour former des « clusters » plus gros.
En temps normal, Ext4 gère ses blocs dans un « tableau de bits » (bitmap) et chaque bit représente un bloc de 4 Kio. Le nouveau système permet d'allouer et de désallouer , d'un seul coup, un « cluster », c'est-à-dire une collection de blocs. Chaque bit du tableau de bits représente donc maintenant 2 puissance n nombre de blocs.
On voit bien que cette notion de « cluster » est purement interne à Ext4 et que le reste du noyau ne verra que les blocs individuels classiques de 4 Kio.
La taille du cluster doit être choisie au moment du formatage initial du système de fichiers (version 1.42 au minimum pour e2fsprogs) et cette fonction bigalloc n'est pas rétrocompatible avec les anciens noyaux. Attention également à ne pas choisir une trop grande taille, si vous avez beaucoup de petits fichiers, car la perte de place sera alors importante.

Ted Ts'o a expliqué dans un message sur la LKML le gain de performance qui pouvait être espéré du fait de ce patch bigalloc.
Les ingénieurs de Google veulent utiliser au maximum de leur capacité les fort nombreuses machines de leurs centres de données. Pour économiser l'énergie et pour minimiser le coût, il est nécessaire d'envoyer le plus possible de jobs sur chaque machine. Comme le patch bigalloc réduit la charge de gestion des structures de données (le tableau de bits est plus petit), il est donc très bénéfique dans ce cas.
C'est dans ce contexte que le test de Ted a été effectué, sur une machine en production. Il a comparé le temps (en microseconde) que met Ext4 à effectuer le travail associé aux appels systèmes fallocate et truncate:

Résultats pour fallocate
Ext4 classique => 14 262 µs
Ext4 bigalloc (cluster 64 kio) => 895 µs
Ext4 bigalloc (cluster 256 kio) => 318 µs
Ext4 bigalloc (cluster 1 Mio) => 122 µs

Résultats pour truncate
Ext4 classique => 12 944 µs
Ext4 bigalloc (cluster 64 kio) => 6 911 µs
Ext4 bigalloc (cluster 256 kio) => 4 541 µs
Ext4 bigalloc (cluster 1 Mio) => 4 558 µs

On note que le gain sur l'appel système fallocate est particulièrement impressionnant avec deux ordres de grandeur pour les clusters d'un Mio !

EVM

Après une longue période de maturation, le sous-système de vérification cryptographique EVM (Extended Verification Module) a été intégré dans le noyau Linux 3.2.

Cette intégration dans la branche principale est l'aboutissement d'un long et patient travail du développeur Mimi Zohar et de ses collègues d'IBM. Depuis plusieurs années, la firme américaine se consacre inlassablement à ce projet qui vise à préserver l'intégrité totale du système contre toutes les tentatives de manipulation ou de modification.
La saga commence en 2005 avec les premiers patchs proposant l'inclusion du mécanisme IMA (Integrity Measurement Architecture) dans le noyau 2.6.12. Le noyau Linux 2.6.11 était sorti en mars de cette année, avec un pilote de gestion des puces TPM (Trusted Platform Module) et IBM voulait s'appuyer sur ce pilote pour faire entrer son architecture IMA. Cette dernière est utilisée pour prendre les empreintes SHA-1 des fichiers et binaires du système, dans le but de pouvoir attester auprès d'un tiers qu'ils n'ont pas été modifiés (voir cet exemple de listing IMA).

Il s'est avéré qu'IBM avait été bien trop optimiste dans ses prévisions, puisque les patchs d'IMA n'ont pas été intégrés immédiatement. De nombreux développeurs ont critiqué la qualité du code et le fait que l'utilisation de cette architecture empêchait le chargement d'autres modules de sécurité comme SELinux. En effet, l'architecture de gestion des modules de sécurité (LSM) ne permet pas de les empiler les uns sur les autres (stacking) et il faut en choisir un et un seul.
Il a donc fallu qu'IBM passe par une réécriture complète, qui n'utilise plus LSM pour satisfaire les gardiens du noyau. Finalement, c'est seulement en juin 2009 - au moment de la parution du noyau 2.6.30 - qu'IMA est rentré dans la branche principale de Linux.
Après ce premier succès, obtenu de haute lutte, IBM a continué ses efforts. En effet, le mécanisme d'Integrity Measurement Architecture peut lister les hashs des fichiers et des binaires, mais il est vulnérable à une attaque hors ligne comme, par exemple, le démarrage depuis un live-CD. Ce qu'il faut ajouter, c'est un mécanisme de vérification cryptographique complet de bout en bout, basé sur le TPM de la machine.
En mars 2011, le noyau Linux 2.6.38 a accueilli une première étape de ce mécanisme sous la forme du patch Trusted keys conçu pour sécuriser les clés de chiffrement (la « trusted key » qui est générée par le TPM et qui est elle-même chiffrée avec la « storage root key » interne du module).

Le nouveau noyau 3.2 apporte donc la dernière pierre de l'édifice et incorpore le mécanisme complet EVM (Extended Verification Module) qui permet de protéger le système contre tous les types d'attaques.
Techniquement, l'architecture d'ensemble est intéressante et un document PDF récapitulatif a été rédigé à l'intention des utilisateurs curieux.
L'empreinte SHA-1 des fichiers (le HMAC) - qui est générée par IMA - est stockée dans les attributs étendus du système de fichiers. Ces attributs étendus (xattr) relèvent de l'espace de noms security.* et c'est security.ima qui stocke le HMAC du fichier. Il existe d'autres attributs étendus qui concernent la sécurité, par exemple security.selinux qui stocke le label SELinux du fichier ou encore security.capability pour enregistrer les capacités POSIX spécifiques attachées au fichier.
Il faut protéger ces attributs étendus contre l'attaque hors ligne et c'est le rôle d'EVM que de veiller à cette intégrité. Le sous-système va calculer un hash de tous les attributs, signer ce hash avec la « trusted key » du TPM et stocker tout ça dans le nouvel attribut security.evm.

Supposons qu'un malandrin ayant accès à la machine utilise un live-CD pour démarrer et veuille remplacer un binaire par un autre dans lequel il aura placé un trojan. Ce qu'il ne sait pas c'est que l'administrateur est un paranoïaque et que le noyau de la machine a été compilé avec la panoplie complète de protection (CONFIG_IMA + CONFIG_TRUSTED_KEYS + CONFIG_EVM). Lors du démarrage suivant, la signature des hashs - qui est présente dans la puce TPM - sera vérifiée par la fonction evm_verifyxattr(), et le résultat indiquera clairement que le binaire a été modifié, ce qui dénoncera la manipulation.

Toute la gymnastique de mise en place de ce mécanisme IMA/EVM est décrite avec force détails sur le site linux-ima. Après tout, après plus de six ans d'efforts pour intégrer la branche principale, les développeurs ont largement eu le temps de peaufiner leur documentation !

Proportional rate reduction

La pile réseau TCP du noyau Linux 3.2 accueille le nouvel algorithme « Proportional rate reduction » conçu par l'ingénieur Google Nandita Dukkipati.

Le protocole TCP règle l'envoi des paquets sur le réseau en fonction de plusieurs algorithmes différents. Le but étant à chaque fois de faire passer le plus de données possible, d'avoir une latence la plus réduite possible et de résister aux diverses perturbations et pertes qui se produisent invariablement. Pas facile de tout concilier !
Dans le cas où des paquets se perdent dans la nature parce que la bande passante est saturée, alors l'envoyeur ne va pas recevoir les accusés de réception (les ACK pour ACKnowledgement) qui correspondent aux paquets envoyés et il saura qu'il est nécessaire de réduire le flux d'envoi. La « fenêtre de congestion » (congestion window c'est-à-dire l'idée que se fait l'envoyeur des capacités maximum de la ligne) était trop large et il va falloir être moins optimiste dans l'envoi des données.

Il existe plusieurs idées pour résoudre le problème ,mais la plus employée (RFC2581) conseille une méthode assez radicale : diviser immédiatement la « fenêtre de congestion » par deux.
C'est une mesure un peu sévère et qui dégrade trop les performances aussi le noyau Linux emploie par défaut un mécanisme un peu plus sophistiqué nommé « rate halving ». L'idée est de ne pas diviser tout de suite la fameuse fenêtre par deux. On va plutôt la réduire petit à petit, d'un segment à chaque fois que l'on reçoit deux ACK. Le résultat final est le même, puisque lorsque tous les ACK en attente auront été reçus, on aura bien divisé par deux la précédente fenêtre de congestion. L'avantage, c'est que la latence est meilleure et que la décroissance des capacités se fait de façon plus « douce » (voir, par exemple, les graphiques page 12 de ce pdf).

Les ingénieurs de Google ont voulu aller plus loin que cet algorithme de « rate halving » employé jusqu'à présent dans Linux et c'est le résultat de leur travail qui est entré dans ce nouveau noyau 3.2. Un brouillon (draft) a été soumis à l'IETF pour une future normalisation, mais l'idée peut se résumer ainsi : On va calculer la différence entre le nombre de paquets actuellement en cours de transmission et le nombre de paquets qui devraient idéalement être envoyés selon l'algorithme de contrôle de la congestion. Cette différence peut bien entendu être positive ou négative.
A) Si la différence est négative (on a moins de paquets « dans les tuyaux » que ce que peut supporter la fenêtre de congestion cible), alors on peut augmenter immédiatement le taux de transmission selon l'algorithme slow start habituel. On gagne en latence car l'augmentation du débit se fait immédiatement.
B) Si la différence est positive (on a plus de paquets « dans les tuyaux » que ce que peut supporter la fenêtre de congestion cible), alors on va réduire le taux de transmission, mais en ayant pour cible la fenêtre de transmission idéale et non en divisant par deux brutalement. On gagne en débit car on exploite mieux la bande passante disponible.

Un article au format PDF explique en détails l'algorithme « Proportional rate reduction », ainsi que les tests qui ont été effectués sur les serveurs de Google.
Les auteurs de PPR ont observé une réduction de la latence comprise entre 3 % et 10 % par rapport aux performances d'un noyau Linux classique (moins de timeout). La fenêtre de congestion obtenue en fin de processus est également plus précise et permet de faire passer plus de paquets. Le slide 9 de ce fichier indique ainsi qu'en cas de congestion, alors un noyau sans PPR doit passer entre 3 % et 5 % de temps de transaction en plus par rapport au nouveau noyau 3.2.

Bull Mountain

La société Intel a introduit dans sa future architecture Ivy Bridge une fonctionnalité dont elle est très fière. Il s'agit d'un générateur matériel de nombres aléatoires, connu sous le nom de code Bull Mountain.
Les nombres aléatoires, c'est bien sûr fort utile dans le monde de l'informatique ; on les utilise surtout pour la cryptographie, mais il y a de nombreux autres domaines d'applications.
Il faut bien distinguer les nombres pseudo-aléatoires des vrais nombres aléatoires. Les premiers sont générés très rapidement, puisqu'ils sont simplement issus de l'exécution d'un algorithme par le processeur. La contrepartie de cette rapidité, c'est que les nombres n'ont que l'apparence de l'aléatoire et qu'il faut se méfier d'eux dans les applications cryptographiques.
On peut, à l'inverse, se servir d'un dispositif physique (radioactivité, bruit quantique, etc.) pour générer de vrais nombres aléatoires, mais dans ce cas, on est souvent limité par un débit de production assez faible. En outre, ces circuits analogiques ne sont pas très pratiques, consomment en permanence du courant et sont difficiles à améliorer au même rythme que les circuits numériques qui suivent la loi de Moore.
Intel a donc choisi d'abandonner sa filière de générateurs matériels analogiques qui est présente sur certaines de ses cartes mères (description dans ce pdf de 1999) et qui se base sur le bruit thermique d'un circuit.
Le nouveau système, nommé Bull Mountain, est purement basé sur des circuits numériques ce qui va permettre de baisser la consommation, tout en ayant des débits de nombres aléatoires sans commune mesure avec ce qui existait auparavant.

Le module numérique est gravé à même la puce d'Ivy Bridge et il se base, pour simplifier outrageusement les explications de cet article d'IEEE Spectrum, sur des transistors qu'on force à être dans un état métastable. C'est un peu comme un crayon qu'on maintiendrait en équilibre sur la pointe de sa mine. Quand on lâche le crayon, on sait qu'il va retomber, mais on ne peut pas deviner la direction de sa chute (cela dépend des micro-mouvements du doigt juste avant de le lâcher). C'est pareil avec les transistors utilisés dans Bull Mountain, dès qu'on cesse le forçage métastable, ils vont revenir dans un état normal - c'est-à-dire 0 ou 1 - et le choix entre les deux possibilités est purement aléatoire, puisqu'il dépend du bruit thermique.
Tout ça se déroule à la même cadence que celle du processeur (environ 3 GHz de nos jours) et sans avoir besoin de subir les latences inutiles et les inconvénients des circuits analogiques classiques, en termes de consommation et de difficulté à faire évoluer.
Avec l'ancien système analogique, Intel parvenait à générer quelques centaines de kilobits de nombres aléatoires par seconde. Avec le module Bull Mountain d'Ivy Bridge on sera à plus de trois gigabits par seconde !

Ce flux de données aléatoires va ensuite servir à alimenter une unité matérielle spéciale qu'Intel nomme un « conditionneur ». Cette unité va chiffrer les bits aléatoires qu'elle reçoit avec l'algorithme AES (en mode CBC-MAC). C'est l'architecture classique en cascade qui utilise les nombres purement aléatoires comme valeur en entrée d'une fonction mathématique générant des nombres pseudo-aléatoires (un PRNG pour PseudoRandom Number Generator).
Cela joue un peu le rôle d'un « réservoir d'entropie » (random pool) afin de sortir en fin de parcours des nombres utilisables pour les applications cryptographiques les plus exigeantes.

Le module matériel Bull Mountain est donc complet (self contained comme disent les Anglo-saxons) et les logiciels peuvent accéder à ses nombres aléatoires, sans passer par les bibliothèques habituelles. Le processeur Ivy Bridge propose pour cela la nouvelle instruction RDRAND qui permet - au choix - d'obtenir en retour une valeur aléatoire de 16, 32 ou 64 bits.
Les patchs, soumis sur la liste de diffusion par H. Peter Anvin, ajoutent donc au noyau Linux 3.2 la gestion de cette instruction RDRAND, qui est utilisée par les applications qui veulent recevoir le flux de nombres.

Comme la LKML ne serait pas ce qu'elle est sans un certain degré « d'espièglerie », il y a eu des échanges assez féroces à propos de ces patchs. Matt Mackall a commencé par annoncer qu'il s'opposait à leur inclusion (nack) parce que, selon lui, il fallait proposer une couche d'abstraction au lieu d'un accès direct via un crochet logiciel (hook). À la fin de son message, il a même ajouté que ce serait bien d'avoir des systèmes auditables sans avoir besoin d'un microscope électronique.
Linus Torvalds s'est empressé de lui répondre que son nack ne comptait absolument pas et que sa proposition d'abstraction était stupide :

Parler de « pilote standard » pour les modules aléatoires matériels est tout simplement débile quand on peut y accéder via une simple instruction qui prend quelques nanosecondes. Toute perte de temps induite par le pilote serait une folie et aucun utilisateur ne voudrait de ça de toute façon.
L'espace utilisateur n'en voudrait pas non plus, parce qu'il veut juste profiter de cette instruction directement. Ce n'est pas un de ces trucs merdeux accessible via le bus PCI. Là c'est du haut débit avec latence faible.
Pour x86, les choix entre les différents générateurs aléatoires (si quelqu'un se préoccupe encore de ceux de Cyrix ou autres) peut s'effectuer via asm_alternate().
Et si tu ne fais pas confiance au RNG du processeur, ce n'est pas la peine de sortir des arguments stupides au sujet des microscopes électroniques. Teste-le ou bien, plus raisonnablement, fais-en juste une des sources d'alimentation d'une réserve d'entropie. Mais ne cherche pas à alourdir tout le truc alors que le but de ce module c'est justement d'être rapide et léger.

Matt Mackall n'a pas bien pris le rejet de son nack (Good to know, feel free to drop me from MAINTAINERS.) mais il n'a pas pu convaincre Linus et les autres développeurs du bien fondé de son point de vue (voir aussi la réponse ironique d'Arjan van de Ven au sujet du microscope électronique).
H. Peter Anvin a toute de même modifié ses patchs pour inclure la solution de Linus, basée sur des chemins alternatifs. Le noyau 3.2 dispose donc maintenant de la gestion de RDRAND, même si la fonction n'est utilisée qu'en tant que source non bloquante (similaire à /dev/urandom).
Après tout, la remarque de Matt sur la confiance qu'on peut accorder à un tel module recèle un fond de vérité. Comme l'a expliqué Ted Ts'o, il vaut mieux se servir de Bull Mountain comme d'une source parmi d'autres pour alimenter le vrai générateur sécurisé qu'est /dev/random.

Gestion dynamique du writeback

Le travail de fond commencé il y a plusieurs mois par le développeur Wu Fengguang a fini par porter ses fruits. Linus a accepté d'inclure dans le nouveau noyau 3.2 ses patchs qui modifient profondément le comportement du sous-système de la mémoire virtuelle.

Avant de tenter d'expliquer à quoi sert ce mécanisme très complexe, il est bon de faire un petit peu de terminologie (en adaptant un paragraphe similaire de la dépêche du noyau 2.6.32).
Les patchs de Wu changent la manière de gérer la fonction de « writeback » du système… mais qu'est-ce que ce mécanisme de « writeback » ?

Quand une application quelconque veut écrire des données, alors le noyau Linux place ces données dans un cache nommé « page cache ». Au fur et à mesure que les données sont mises dans une queue d'entrées/sorties allant conduire à l'écriture sur le périphérique, elles sont marquées par le drapeau « dirty ». Enfin les données étant vraiment en train d'être écrites sur le périphérique sont identifiées comme étant en « writeback ».

On peut visualiser ce qui se passe à un instant donné en regardant le contenu de /proc/meminfo. Par exemple ici, lors de la copie d'un gros fichier vidéo sur une clé USB :

patrick@laptop:~$ cat /proc/meminfo
MemTotal: 2052912 kB
Cached: 929652 kB
Dirty: 185268 kB
Writeback: 13020 kB

Ma mémoire totale est de 2 Go, j'ai 929 Mo en cache et il y a 185 Mo qui sont marqués comme « dirty », c'est-à-dire qu'ils sont en chemin pour être écrits sur le disque. Enfin 13 Mo de données sont vraiment en cours d'écriture sur la clé USB.
On comprend bien que l'affichage de ces totaux de pages « dirty » et « writeback » change en permanence en fonction de l'état du système et qu'un cat /proc/meminfo lancé quelques secondes plus tard donnera un autre résultat.

Quand on présente les choses comme ça, tout a l'air simple et clair. En réalité, ce mécanisme est assez fragile et source de nombreux problèmes. Que faire, par exemple, quand un processus génère une grosse quantité de pages « dirty », plus que ce que peut accepter le système ? Dans ces conditions, le noyau passe en mode « direct reclaim » c'est-à-dire qu'il va explicitement essayer de libérer des pages mémoires.
La fonction de « direct reclaim » n'est pas très bien considérée par les développeurs du noyau, car elle a tendance à dégrader fortement les performances d'entrées/sorties du système. C'est quand même gênant de réduire ainsi la bande passante vers le disque, alors que la situation initiale était justement un trop-plein de page « dirty » !
Si on ajoute à ça les risques de débordement de la pile (stack overflow), on comprend mieux les nombreuses tentatives des développeurs pour améliorer ce système du « direct reclaim ».

Wu Fengguang est parti d'une autre idée. Si le « direct reclaim » n'est pas réellement efficace, alors il ne sert à rien de passer dans ce mode. Autant travailler en amont, par exemple sur la gestion fine du débit des pages « dirty », afin de ne pas se faire submerger.
Son ensemble de patchs se nomme en anglais « IO-less dirty throttling » parce que le but est d'étrangler plus ou moins le flux des pages dirty qui vont être envoyées pour écriture sur le disque. Une régulation par rétroaction automatique est mise en place afin de trouver le ratio idéal de pages « dirty ».
Quand le nombre de pages est faible, alors l'étranglement du flux (le throttling) se relâche pour augmenter le débit.
De même, quand le nombre de pages est trop élevé, alors l'étranglement devient progressivement de plus en plus fort. Cette réduction du débit se fait très simplement puisque le code place le processus en « sleep » pendant une certaine période.
Ce message de commit de Wu est particulièrement explicite sur le mécanisme mis en place. J'en copie sans vergogne les schémas en ascii-art.

Système précédent de gestion des pages « dirty »:

                           aucune contrainte  |  zone d'intervention
----------------------------------------------+---------------------------->
                                                                 nombre de pages dirty

On voit bien qu'il existe une zone n'ayant aucune contrainte et puis, brusquement, quand un seuil déterminé est franchi, le noyau tente de réduire à tout prix le flux de pages.

Nouveau système avec rétroaction:

  ^
  |           * 
  |            *
  |             *
  |              *
  |                *
  |                  *
  |                     *
  |                         *
  |                               *
  |                               .     *
  |                               .          *
  |                               .              *
  |                               .                 *
  |                               .                    *
  +-------------------------------.-----------------------*------------>
                          OBJECTIF^                 LIMITE^       nombre de pages dirty

Le code prend en compte la quantité globale de pages ayant le flag « dirty » et il confronte ce chiffre avec la cible à atteindre (OBJECTIF) et avec le maximum absolu qui a été défini (LIMITE). Malheureusement, on ne peut pas se contenter d'un ratio aussi simple et il faut prendre en compte les différents périphériques (ou plutôt des BDI ce qui signifie Backing Device Info et qui est une abstraction au-dessus des périphériques réels).
Après tout, un BDI particulier peut être saturé en pages « dirty » sans que le système lui-même ne soit proche de la limite. Le calcul final est donc un ratio par BDI que Wu nomme le pos_ratio (le ratio en fonction de la position sur la courbe).
Le processus qui envoie des données pour écriture est donc tenu d'une main ferme par le code gérant la mémoire virtuelle. Dans le cas où il enverrait un déluge de pages « dirty », alors la pression de rétroaction se ferait de plus en plus forte (il passerait en « sleep » de plus en plus souvent), afin de réguler ce flux.
Tous ces calculs, et les formules qui sous-tendent le fonctionnement du mécanisme, sont détaillés dans ce message de Fengguang Wu (attention au risque élevé d'explosion cérébrale en essayant de comprendre les détails !). Un fichier PDF récapitulatif est également disponible pour ceux qui voudraient comprendre plus en profondeur le travail de Wu Fengguang (et des autres hackers ayant collaboré avec lui).

Bien entendu, avant d'accepter ce nouveau mécanisme invasif, les tests ont été particulièrement nombreux. Le code qui gère la mémoire virtuelle est notoirement sensible et tout changement est scruté de près sur la LKML. Ainsi, de nombreux points de traçages ont été incorporés dans le code afin de vérifier le bon comportement de ce système de gestion dynamique du « writeback ». Les régressions concernant NFS ou les disques JBOD ont été résolues une à une, jusqu'à ce que les mainteneurs du noyau soient satisfaits du résultat.

À l'issue de tout ce travail, le noyau Linux 3.2 permet donc de gérer de manière bien plus efficace la fonction de « writeback », sans risquer l'engorgement comme c'était le cas auparavant. D'après les tests de Wu Fengguang, le gain ne se situe pas nécessairement au niveau du débit de données, mais plutôt dans la réduction de la charge processeur :

Sur un simple test de 100 dd, on observe que le %system time du CPU passe de 30 % à 3 % et que le débit d'entrées/sorties passe de 38 Mo/s à 42 Mo/s.

Les résultats sont donc très encourageants et ce n'est pas un hasard si le patch de « dirty throttling » a été évoqué explicitement dans le mail de RC-1 envoyé par Linus. Bien entendu, la véritable épreuve du feu commence maintenant, avec la sortie officielle du noyau. Comme Linus le dit lui-même : Let's see how that all works out.

En bref

SHA-1 optimisé

La rapidité de la fonction de hachage cryptographique SHA-1 a été améliorée spécifiquement pour l'architecture x86-64 dans le noyau 3.2.
C'est le développeur Mathias Krause qui a proposé plusieurs séries de patchs pour ajouter une implémentation de SHA-1 en assembleur dans le noyau Linux. Le nouveau code exploite à fond les jeux d'instructions vectorielles SSSE3 et AVX.
D'après les tests effectués par Mathias sur un tunnel IPsec, et avec un processeur Core 2 Quad cadencé à 2,4 GHz, on obtient les chiffres suivants :

SHA-1 classique : 344 Mbit/s
SHA-1 optimisé : 464 Mbit/s (soit un gain d'environ 34 %).

Bien entendu, l'implémentation classique de SHA-1 en langage C reste présente dans le code de Linux et sert de recours (fallback), au cas où l'utilisation du code optimisé n'est pas possible.

Blowfish et Twofish

Il n'y a pas que SHA-1 à profiter d'une implémentation toute neuve en assembleur. Les algorithmes de chiffrement symétrique Blowfish et Twofish vont aussi pouvoir en bénéficier dans le nouveau noyau Linux 3.2.
Ces deux algorithmes, des créations de Bruce Schneier et de ses collaborateurs, sont moins connus qu'AES, mais ils restent utilisés dans de nombreux logiciels.
C'est le développeur finlandais Jussi Kivilinna qui a proposé pour ce cycle plusieurs patchs d'optimisation des performances. L'idée derrière le code est de viser les processeurs modernes (architecture x86_64 et traitement out-of-order) en proposant des chemins alternatifs optimisés.

Twofish avait déjà un code en assembleur (dans /arch/x86/crypto/twofish-x86_64-asm_64.S), mais celui-ci ne chiffrait qu'un bloc à la fois. Avec le patch de Jussi, ce sont trois blocs de données qui seront traités en parallèle (d'où le nom twofish-x86_64-asm_64-3way.S donné au fichier source). Le message de commit donne de nombreux résultats de tests en fonction des divers modes de chiffrement, on note par exemple qu'en mode ECB, on peut espérer une vitesse de chiffrement ou de déchiffrement multipliée par 1,3.

Le cas Blowfish est un peu différent puisqu'il n'existait pas - jusqu'à présent - d'implémentation en assembleur. Le code présent dans le noyau 3.2 devrait donc permettre des gains très substantiels sur les processeurs x86_64 modernes. Jussi a pris la peine de faire les choses bien avec deux chemins, le premier qui travaille de façon classique sur un bloc à la fois, alors que le second peut chiffrer ou déchiffrer quatre blocs à la fois.
Dans le message de commit du premier septembre, on trouve un test tcrypt entre l'ancienne implémentation en C et la nouvelle en assembleur. Un gain d'un facteur 2,2 ou 2,3 en mode ECB a été constaté. Le 23 septembre dernier, Jussi a soumis un dernier patch d'amélioration qui permet de gagner encore 15 % (sur AMD Phenom II) par rapport à son code initial.

RAID-5 pour Exofs

Exofs est un système de fichiers bien particulier. Ayant fait son entrée dans le noyau Linux 2.6.30, il est basé sur l'idée des « Object storage devices ». Cela signifie que le système d'exploitation ne gère plus directement les blocs et les secteurs du disque, mais se contente d'interagir avec des « objets » abstraits qui ont chacun un identifiant sur 64 bits, ainsi que des attributs et des méta-données associées. Tout le code de gestion bas niveau sur les blocs et les secteurs est délégué au micrologiciel du disque. Cela lui permet, en théorie, de prendre de meilleures décisions que l'OS.
Quelle que soit l'opinion que l'on ait à propos de cette idée, Linux propose ce système de fichiers et des développeurs continuent de travailler à son amélioration. Dans la dépêche du noyau 2.6.34, il était indiqué que le mode RAID-0 avait été intégré et que son auteur, Boaz Harrosh, travaillait maintenant sur le mode RAID-5. Cela a été plus long que prévu, mais la prise en charge du RAID-5 entre maintenant dans le noyau 3.2 (1 - 2 - 3). Si on en croit le message d'annonce de Boaz, le code est conforme avec la norme IETF qui décrit la gestion des objets dans le standard « Parallel NFS » pNFS.

Tout cela est bel et bon, mais le fait d'intégrer dans le noyau une troisième implémentation du RAID-5 - en plus de celles qui existent dans MD et DM - a fait froncer quelques sourcils. Boaz s'est donc empressé de signaler que le code ORE (Objects Raid Engine) était très générique et pouvait donc être réutilisé par d'autres systèmes n'ayant pas encore de gestion RAID-5 (par exemple Btrfs).
En dépit de ces arguments, on peut penser qu'un travail de consolidation dans ce domaine sera nécessaire à plus ou moins brève échéance.

Hexagon

Après OpenRISC dans le précédent noyau, c'est maintenant l'architecture Hexagon de Qualcomm qui intègre l'arbre des sources de Linux.
Cette puce Hexagon est assez inhabituelle puisqu'il s'agit, à la base, d'un processeur de signal numérique (un DSP). En temps normal, une telle architecture ne fait pas tourner un système d'exploitation comme Linux, elle est seulement utilisée comme processeur d'appoint pour accélérer les calculs numériques (codecs vidéos par exemple).
La firme Qualcomm a conçu Hexagon comme étant un hybride qui peut faire tourner un OS généraliste et elle axe sa communication sur ce point :

Hexagon merges the numeric support, parallelism, and wide computation engine of a DSP, with the advanced system architecture of a modern microprocessor.

Si on excepte le paragraphe introductif de Richard Kuo dans le premier patch de sa série, on trouve assez peu de détails sur le web à propos de l'architecture Hexagon. N'écoutant que mon courage, et pénétré de ma mission sacrée au service des lecteurs de LinuxFr, j'ai donc créé un compte sur le serveur « Qualcomm Developer Network » afin de pouvoir télécharger les documents techniques.
Il s'avère qu'Hexagon est un processeur possédant trente-deux registres 32 bits, avec des instructions qui peuvent être regroupées dans des « mots » de grande taille (architecture VLIW). Des unités vectorielles sont également présentes afin de faire des calculs de type SIMD. On trouve, bien entendu, une unité de gestion mémoire MMU et aussi la gestion du multiprocesseur via SMP. Le cache L1 est de 2 fois 32 Kio (données et instructions), tandis que le cache L2 est actuellement de 256 Kio, mais cette quantité augmentera sans doute dans les futures versions.
Il est à noter qu'Hexagon implémente un hyperviseur matériel natif (HVM pour Hexagon Virtual Machine) et que Linux tourne via cette couche de virtualisation. Selon les documents, cela permet de faire fonctionner en même temps une application temps-réel fortement optimisée pour un matériel spécifique et aussi un OS généraliste.
Nous verrons avec le temps si les choix de Qualcomm se révèlent justes, et comment s'opérera le partage des tâches sur les machines ayant un coeur ARM et un DSP Hexagon. Ce qui est certain, c'est que cette architecture Hexagon qu'intègre le noyau 3.2 est prometteuse et novatrice.

AMD Bulldozer

L'architecture Bulldozer des nouveaux processeurs AMD n'a pas provoqué un enthousiasme délirant dans la presse spécialisée.
La conception des puces Bulldozer est assez originale, puisqu'elle brouille la définition de ce qu'est un coeur de calcul sur un processeur. La brique de base se nomme « module » et elle contient deux pseudo-cœurs qui partagent les unités de chargement et de décodage des instructions (le front end), ainsi que l'unité de calcul sur les flottants (FP). L'idée est que ce partage n'aura que peu d'impact sur les performances et qu'il permettra d'économiser de la place pour ajouter encore plus de « modules » sur la surface de silicium.
L'ennui, c'est que ce fonctionnement est inhabituel et que les systèmes d'exploitation devront être adaptés finement pour profiter au maximum de cette architecture.
Par exemple, il s'est avéré que le partage du cache L1 des instructions entre les deux pseudo-cœurs posait, dans certains cas, un problème d'invalidation des données dans le cache. Le patch écrit par Borislav Petkov pour le noyau Linux 3.2 vise à corriger ce comportement et permet de gagner environ 3 % de performances dans un benchmark stressant le processeur.
Comme ce patch change le mode de gestion du cache, il a été décidé d'offrir le choix aux utilisateurs de l'utiliser ou pas. La nouvelle option align_va_addr doit donc être passée au noyau lors du démarrage avec quatre valeurs possibles :

1: Activation de la fonction seulement pour les processus 32 bits.
2: Activation de la fonction seulement pour les processus 64 bits.
on : Activation de la fonction pour les processus 32 ou 64 bits.
off : Désactivation de la fonction.

DVFS

Depuis longtemps, le noyau est capable de réduire la fréquence et la tension d'alimentation du processeur, afin d'obtenir un fonctionnement optimal entre performance et consommation. Ce n'est pourtant pas le seul composant capable d'une telle adaptation, mais le processeur étant le principal consommateur d'énergie, personne ne s'était jusqu'à maintenant penché sur les autres puces.
Une nouvelle interface de programmation a été intégrée dans le noyau 3.2 pour faciliter cette gestion de la consommation de tous ces périphériques. Cette API, nommée DVFS (pour Dynamic Voltage and Frequency Scaling), permet de gérer le matériel en se reposant sur des gouverneurs, comme c'est le cas pour le processeur central.
Le développeur d'un pilote voulant profiter de DVFS va d'abord se servir de l'infrastructure OPP (Operating Performance Points) incluse dans le noyau 2.6.37 et qui permet de déclarer les couples fréquences/tensions disponibles pour le périphérique. Une fois cela déclaré, il va initialiser une structure pour déclarer la fréquence de fonctionnement de départ de son périphérique (initial_freq) et indiquer s'il souhaite que le gouverneur de fréquence interroge périodiquement le matériel (polling). Pour des besoins spécifiques, il est possible d'écrire un gouverneur dédié mais, en général, les développeurs utiliseront ceux qui ont été ajoutés dans le noyau pour cette fonction devfreq:

Il est nécessaire d'avoir des gouverneurs distincts de ceux gérant le processeur car cpufreq n'accepte pas d'avoir plusieurs périphériques hétérogènes enregistrés.
Bien entendu, ce mécanisme devfreq s'interface avec le code gérant la qualité de service (QoS) pour être certain que la réduction de la consommation ne se fera pas au détriment des obligations décrites dans cette API.

Il est à noter qu'à l'heure actuelle, cette interface DVFS n'est pas encore utilisée par un quelconque matériel… mais les prochains noyaux devraient voir arriver les premiers pilotes utilisant cette nouvelle possibilité.

Samba va plus vite

Le système de fichiers CIFS (Samba), qui est utilisé pour partager des ressources en réseau avec des machines Windows, a reçu un important patch écrit par Jeff Layton.
Dans le noyau Linux 3.2, CIFS peut maintenant faire des appels asynchrones en lecture vers le serveur distant. Cette nouvelle infrastructure cifs_async_readv permet de réduire les temps d'attente et les tests effectués par Steve French montrent un gain substantiel.
Selon cette évaluation, basée sur dbench (avec soixante processus), on peut espérer une amélioration d'environ 5 % par rapport au noyau précédent.

SLUB

Christoph Lameter continue de travailler sur l'allocateur mémoire SLUB. Après ses patchs du noyau 3.1 qui visaient à retirer des verrous inutiles, Christoph a cette fois concentré son attention sur la quantité de travail effectué après la prise du verrou.
Par exemple, le noyau 3.2 permet, quand le verrou list_lock est posé, de traiter plusieurs pages partielles au lieu d'être limité à une seule. Dans son message de commit, le mécanisme est détaillé et il donne les résultats d'un test hackbench :

./hackbench 100 process 20000
Avant : 207.176 secondes
Après : 156.940 secondes

Améliorations de Btrfs

Les développeurs de Btrfs continuent d'améliorer les performances de leur bébé afin qu'il puisse, un jour, prendre la succession d'Ext4 en tant que système de fichiers de référence sous Linux. Le plan annoncé par Oracle d'utiliser Btrfs par défaut dans leur distribution dérivée de Red Hat Entreprise Linux, a conduit à mettre également l'accent sur la fiabilisation et les corrections de bugs.

Le noyau 3.2 voit notamment l'introduction du mécanisme générique de « readahead », ce qui permet d'implémenter des stratégies de lecture des données bien plus efficaces.
Après un appel à btrfs_reada_add, les extents du système de fichiers, c'est-à-dire les zones de stockage contiguës qui ont été pré-allouées, vont pouvoir être mis en cache plus efficacement. En outre, comme chaque disque a son cache readahead, on peut les utiliser en parallèle pour augmenter le débit.

Un autre raffinement concerne les disques en configuration miroir. Au lieu de lancer un readahead sur les mêmes zones (ce qui reviendrait à gâcher les capacités de recherche), le système lit des parties différentes du système de fichiers afin, là aussi, de maximiser les performances.
Tout ce travail paye puisque, selon les tests effectués par Arne Jansen, la fonction de scrubbing (vérification des sommes de contrôles des extents et des superblocs présents sur le volume de stockage) est grandement améliorée. En abandonnant l'énumération naïve des arbres de données au profit du mécanisme de readahead, le système d'Arne passe de 89s à seulement 43s pour vérifier un volume.
En outre, ce scrubbing est plus intelligent puisque l'ancien système ne renvoyait que le numéro du bloc corrompu en cas d'erreur. Le code intégré dans le noyau 3.2 permet maintenant d'obtenir directement le nom du fichier impacté, ce qui facilite le travail de l'administrateur.

Parmi les autres améliorations, on peut citer la nouvelle option de montage -o recovery qui permet de monter une racine de secours au cas où le montage de la racine principale est impossible.
Il y a aussi le patch de Josef Bacik, qui relâche un peu les contraintes vis-à-vis de l'erreur ENOSPC (plus d'espace sur le disque). En ayant une stratégie plus fine (évaluation en temps réel de l'espace libre), on peut respecter les garde-fous mis en place pour éviter l'erreur ENOSPC tout en améliorant les performances. La connaissance de la quantité d'espace non alloué permet de faire de l'overcommit. Dans son message de commit, Josef signale qu'un test simpliste d'écritures aléatoires sur un volume de 3 Tio passe de 45 minutes à seulement 10 secondes !

Cross memory attach

Le patch de « cross memory attach » développé par Christopher Yeoh a été incorporé dans le noyau Linux 3.2.
Le but de ce travail est d'améliorer les performances des processus qui utilisent le protocole MPI (Message Passing Interface). Cette norme est souvent utilisée dans le calcul haute performance puisqu'elle permet aux très nombreux processeurs d'un supercalculateur d'échanger des messages pour traiter les données.

Au sein d'un noeud de calcul (intra-node), il est nécessaire de procéder à deux opérations de copies de données. En gros, on a l'émetteur qui copie depuis son espace d'adressage dans un segment partagé et le receveur qui copie depuis ce segment partagé dans son espace d'adressage à lui.
Avec la fonction de « cross memory attach », il n'est plus nécessaire d'en passer par ce mécanisme à double-copie.
L'émetteur va simplement envoyer au receveur une adresse mémoire et une taille. Le receveur va alors lire et copier directement les données (puisqu'il a l'adresse et la taille) dans son propre espace d'adressage. La fonction utilisée est process_vm_readv() (voir les explications sur la page de man).
L'opération inverse est également prévue et le processus émetteur peut ainsi écrire directement dans l'espace d'adressage du receveur via la nouvelle fonction process_vm_writev.

Christopher Yeoh a modifié la bibliothèque Open MPI pour qu'elle exploite cette nouvelle possibilité de « cross memory attach » et il a lancé plusieurs benchmarks sur une machine ayant 64 coeurs POWER6. Comme on pouvait s'y attendre en supprimant une coûteuse opération de copie, les tests montrent un gros gain de performance :

Nombre de Processus         4   8   16  32
Nb de Mo/s sans le patch    1235    935 622 419
Nb de Mo/s avec CMA     4741    3769    1977    703

DM et « thin provisioning »

La couche « device mapper », qui permet de mapper un périphérique en mode bloc sur un autre, a reçu plusieurs ajouts intéressants dans le nouveau noyau.
C'est tout d'abord la bibliothèque des données persistantes qui est prévue pour stocker toutes les métadonnées des cibles du « device mapper ». Comme les fonctions du DM se complexifient, il devient payant de regrouper toutes les structures de données qui étaient utilisées auparavant par une couche générique.

Un des premiers utilisateurs de cette « persistent-data library » est la nouvelle application permettant de faire de l'allocation fine et dynamique (thin provisioning). Dans le cadre d'un SAN, plutôt que d'allouer vraiment tous les blocs à un client, on va les allouer à la volée pour économiser de l'espace. Chacun des clients aura un volume virtuel à sa disposition, mais ce volume n'occupera que l’espace réellement consommé. C'est avantageux car les pages non utilisées par un client peuvent être réallouées à d'autres (via la fonction de Zero Pages Reclaim).
Cette implémentation du « thin provisionning » dans le noyau 3.2 est encore marquée comme expérimentale. Elle est fort prometteuse puisqu'elle autorise la prise d'images (snapshots) à volonté et avec une administration simplifiée. Ces snapshots peuvent être hiérarchiques et le coût en performance ne dépend plus de la profondeur d'imbrication.

Enfin, dernier ajout notable au « device mapper », un cache spécialement adapté pour les entrées/sorties a été développé. Ce cache, nommé bufio, est plus efficace que les caches génériques du noyau, car il a été pensé dès le début pour satisfaire les besoins du DM. Le module de « thin provisionning » est pour l'instant le seul utilisateur de ce nouveau cache, mais il est probable que d'autres cibles DM seront converties par la suite.

TAINT_OOT_MODULE

En octobre dernier le développeur Dave Jones a proposé sur la LKML de marquer spécifiquement les noyaux ayant chargé le module externe VirtualBox. Dave semble avoir une piètre opinion de ce module vboxdrv:

Le nombre de rapports de bug que nous recevons d'utilisateurs ayant le module virtual box chargé est vraiment stupéfiant.
C'est sous GPL mais, hélas, cela ne veut pas dire que c'est de bonne qualité.

Il a donc proposé de marquer avec le drapeau « TAINT_CRAP » les noyaux ayant chargé ce module maléfique qui fait planter les systèmes et qui remplit sa boîte mail. Habituellement, le drapeau « TAINT_CRAP » est réservé aux pilotes de la branche -staging, pour indiquer que ces pilotes n'ont pas le niveau de qualité requis. Un rapport de bug dévoilant que le noyau a été marqué avec ce drapeau peut voir sa priorité réduite, ou même être tout simplement ignoré.
Greg KH a semblé enchanté par cette proposition de Dave Jones :

J'aime ça, et je pense que je vais l'ajouter aux noyaux d'OpenSUSE. Comme ça nous pourrons éviter les nombreux rapports de bugs que nous recevons au sujet de ce pilote tout pourri.

Toutefois, au fil de la discussion, plusieurs personnes ont proposé des solutions alternatives à l'infâmant stigmate « TAINT_CRAP ». L'idée de Pekka Enberg d'ajouter le module vboxdrv à la branche -staging pour l'améliorer a été rapidement rejetée (toi tu n'as jamais lu le code de ce module hein ?).
Frank Mehnert, qui travaille chez Oracle, a annoncé qu'il acceptait volontiers l'idée de marquer spécialement les modules ne faisant pas partie de la branche principale. En revanche, c'est étonnant, Frank n'était pas spécialement emballé par le terme de « CRAP » ;-)
Bastian Blank est intervenu pour signaler que Debian utilisait depuis un certain temps un patch marquant tous les modules externes avec le drapeau « TAINT_OOT_MODULE ».
C'est cette idée qui a finalement été acceptée par tous et qui fait son entrée dans le noyau Linux 3.2. Comme le code externe est bien moins testé que celui qui fait partie de la branche principale, ce sont donc tous les modules externes (Out Of Tree) qui sont marqués avec « TAINT_OOT_MODULE », et plus seulement VirtualBox.

Hibernation

Le code de la fonction d'hibernation inclus dans le noyau 3.2 a été amélioré par le développeur Bojan Smojver.
Quand l'ordre de mise en hibernation est envoyé au noyau, alors le contenu de la mémoire vive (RAM) est compressé puis sauvé sur le disque dur. À l'inverse, au moment du réveil, le disque est lu et les données sont décompressées pour revenir à l'état d'avant l'hibernation. C'est ce qui différentie l'hibernation de la simple mise en veille (Suspend) où la RAM est toujours alimentée.
Dans le cas de l'hibernation, le goulot d'étranglement est clairement la vitesse du périphérique de stockage, et c'est pour ça que l'étape de compression est utile. Même s'il s'agit d'une opération de compression coûteuse, le jeu en vaut la chandelle puisque des poignées de secondes seront économisées au moment d'écrire les données sur le disque.
Le patch de Bojan permet maintenant de faire de la compression/décompression multithread avec l'algorithme LZO. Cet usage des threads (LZO_THREADS) est limité à trois pour ne pas surcharger la mémoire… ce qui serait une mauvaise idée alors qu'on veut passer en hibernation !
Le patch ajoute également la vérification des données via CRC32 pour améliorer la robustesse des transferts entre la mémoire et le disque.
D'après les tests effectués par Bojan Smojver, le multithreading de la compression LZO a tout simplement doublé la vitesse de lecture/écriture sur son système.

Sous-système de contrôle des broches

Les systèmes complets embarqués sur une puce (SoC) ont souvent un brochage assez particulier. Il leur est possible, via un « pin controller », de gérer de façon complexe les broches du processeur. On peut multiplexer les pattes, faire varier les caractéristiques électriques, etc.
Le noyau Linux 3.2 offre aux développeurs un nouveau sous-système qui permet de gérer ces broches contrôlables et qui va, dans le futur, réduire les doublons de code au sein de l'architecture ARM.
Pour l'instant, ce « pin control subsystem » est limité à l'énumération et au nommage des broches (pinmuxing), mais les prochains noyaux apporteront la prise en charge des fonctions de gestion électrique. Linus Walleij, développeur Linaro à l'origine de ce travail, a indiqué dans son message de commit ce qui motive cet ajout :

Le but de ce travail est de dépeupler le répertoire arch/arm/* de tous les pilotes spécifiques et d'essayer d'avoir une infrastructure d'abstraction pour toutes les fonctions dont ils ont besoin.

La documentation du sous-système de contrôle des broches est très complète et le pilote ARM U300 a été converti pour servir de référence aux autres développeurs.

Pilotes graphiques

Dans le domaine des pilotes graphiques, on note l'activation de la gestion PCI-Express 2.0 pour les cartes « Northern Islands », c'est-à-dire la série des Radeon HD 6000. Divers patchs ont également été postés pour réorganiser et accélérer les opérations de blit (en gros il s'agit de combiner plusieurs bitmaps lors d'une opération de rasterisation).

En ce qui concerne les cartes NVidia et le pilote « Nouveau », on trouve notamment les patchs de refonte de la gestion de DisplayPort ainsi que l'activation de l’accélération pour les architectures NVC1, NVC8 et NVCF (1 - 2 - 3). En revanche, le travail sur la gestion des fréquences (re-clocking) n'a pas encore abouti et n'a pas pu être intégré.

Le pilote Intel i915 a été nettoyé d'un grand nombre de bugs. Le mail d'annonce de Dave Airlie cite en particulier les corrections à destination des Macbook Air d'Apple, ainsi que les patchs pour RHEL. Le patch permettant la gestion de trois moniteurs sur puce Ivy Bridge a été également intégré.
Un autre patch notable pour le pilote Intel est celui qui active la gestion du mode d'endormissement RC6. Quand le processeur graphique n'a rien à faire, il peut ainsi passer en veille profonde et réduire drastiquement la consommation (un passage de 21.5 watts à seulement 15 watts sur un laptop Sandy Bridge est évoqué dans cet article).
L'activation de RC6 avait été tentée puis retirée dans le noyau précédent, à cause de divers crashs. Maintenant que la situation semble mieux maîtrisée, il peut faire partiellement son retour.
Selon le premier message de commit de Keith Packard, ce mode RC6 ne fonctionne que sur les puces Ivy Bridge (inconditionnellement) et sur les puces Sandy Bridge (si VT-d est désactivé).
Néanmoins, à la dernière minute, Keith a demandé à Linus de désactiver une nouvelle fois le mode RC6 pour les processeurs Sandy Bridge. Seuls les Ivy Bridge pourront donc profiter pour l'instant de cette économie de consommation.

Après avoir parlé des trois « grands », il faut également signaler la sortie de -staging du pilote vmwgfx utilisé par VMware ainsi que l'introduction du pilote Samsung Exynos4 dans le nouveau noyau 3.2. C'est le tout premier pilote DRM pour un System-on-chip ARM à entrer dans la branche principale. Bien entendu, il ne faut pas s'exciter trop vite et le pilote est encore loin d'être complet. Pour l'instant, il ne s'occupe que du « kernel mode-setting » et de la gestion de la mémoire (via GEM). Pas d'accélération 2D ou 3D à l'horizon et il reste à voir si Samsung va travailler pour proposer un pilote libre en espace utilisateur.

Cronopio dentiacutus

Comme c'est devenu l'habitude, Linus Torvalds a encore une fois changé le nom de code par défaut du noyau. Après le très sage « Divemaster Edition » de Linux 3.1 on revient aux noms animaliers dans cette édition 3.2. Le commit de Linus a été effectué le 8 novembre, au moment de la première version candidate, et il indique que le nom de code est maintenant Saber-toothed squirrel (écureuil à dents de sabre).
On pourrait penser qu'il ne s'agit, comme la fameuse « Belette rose péteuse », que d'une manifestation de l'humour particulier de Linus. En fait le commentaire associé nous indique le contraire:

Linux 3.2-rc1 avec un nouveau nom. Parce que rien ne respire mieux la « version de qualité du noyau » que de le nommer d'après un animal disparu qui a fait les gros titres récemment.

En effet des paléontologues américains et argentins viennent de publier un article dans la revue Nature pour annoncer la découverte, en Amérique du Sud, d'un spécimen de petit mammifère à dents de sabre. Ce Cronopio dentiacutus a suscité l'intérêt du grand public et les articles de vulgarisation ont fleuri sur la toile (1 - 2).
Avec un air aussi féroce, nul doute que ce Scrat du Crétacé représentera dignement le noyau 3.2.

Statistiques

Du côté des statistiques, le site LWN a publié son classique article récapitulatif pour le noyau 3.2.
Ce cycle a été particulièrement chargé, avec plus de 11 800 patchs ayant intégré la branche principale. C'est une très honorable médaille de bronze au classement des plus grosses versions de tous les temps. Pour l’anecdote, la médaille d'argent revient au 2.6.30 avec 11 989 commits et la médaille d'or au 2.6.25 avec 12 243 patchs.
Ce nombre imposant de changements intégrés dans le nouveau noyau 3.2 s'explique en partie par la compromission ayant affecté les serveurs de kernel.org.
Linus a retardé l'ouverture de la période de merge parce qu'il préférait que tout revienne à la normale avant d'ouvrir les digues. Le travail des développeurs s'est donc quelque peu accumulé avant d'être finalement intégré dans ce noyau.

Si on regarde le classement des entreprises contributrices, on remarque que la domination relative de Red Hat semble s'éroder lentement. Les patchs restent nombreux (près de 1 000 dans ce cycle), mais la montée en puissance de sociétés comme Qualcomm ou Samsung dilue quelque peu ce travail, puisqu'il ne représente plus que 8,5 % du total.
Les employés de Microsoft continuent de travailler sur leur pilote de virtualisation Hyper-V avec 177 patchs de plus. La sortie du pilote de la branche -staging est programmée pour le noyau 3.3.
Au total, selon les chiffres de LWN, ce sont les développeurs de 191 entreprises différentes qui ont participé à ce cycle. Cela démontre une fois de plus la vitalité et la résilience qui caractérisent le développement de Linux. Comme le dit Jonathan Corbet :

En d'autres termes, le processus de développement semble continuer à fonctionner très correctement, et ce en dépit des difficultés de kernel.org et de l'ouverture retardée de la fenêtre de merge.
Tôt ou tard, nous sommes condamnés à rencontrer un problème qui aura un impact important - la vie est comme ça - mais cela ne s'est pas produit cette fois-ci.

Pour la suite

Pilotes Android

Après le retrait des pilotes Android de la branche -staging au moment du noyau 2.6.33, aucun vrai effort de réunification n'avait été tenté. Pourtant, un peu à la surprise générale, les développeurs Linux ont profité du sommet du noyau de Prague, en octobre dernier, pour se mettre d'accord sur un projet de réintégration de ce code ayant divergé.

À la suite de cette décision, un plan a été tracé et c'est Tim Bird, employé par Sony, qui a annoncé le 20 décembre la naissance de « Android mainlining project ». Un wiki dédié a été mis en place pour coordonner les efforts et le noyau 3.3 verra l'intégration de nombreux patchs. D'après Greg KH, ce prochain noyau devrait presque pouvoir faire démarrer l'environnement user space d'Android (the next linux-next Linux kernel release should almost boot an Android userspace).

Si on regarde le répertoire Android de la branche -next (c'est-à-dire la branche accueillant les patchs qui vont entrer dans le noyau 3.3), on constate que de nombreuses pièces critiques de l'infrastructure Android sont présentes. Qu'il s'agisse de hashmem (mécanisme de partage mémoire) de binder (permettant la communication inter-processus) ou encore de logger (infrastructure de log), tous ces sous-systèmes vont être ajoutés au prochain noyau Linux.

Bien entendu, ce n'est que le début du chemin et de nombreux pilotes seront encore absents dans la branche principale.
Il faudra également s'attaquer au gros morceau qu'est le patch wakelock si on veut que le système, une fois démarré, ne vide pas la batterie à une cadence accélérée.
Néanmoins, le delta entre le noyau Linux et le noyau que Google utilise dans Android va se réduire considérablement à brève échéance. C'est indéniablement une très bonne nouvelle.

  • # Et un de plus

    Posté par . Évalué à  5 .

    whaou y a du lourd; et j'ai envie de tester le bouzin sur mon pc ayant un ssd lent en écriture mais la je suis au travail, je l'ai pas sous la main... ;)

    Par contre, pour la future intégration des fonctionnalité d'Android dans le noyau me semble une bonne nouvelle, et ce serait bien que les dev d'Android passent sur le noyau, mais je crains que le modèle de développement ne leur conviennent pas...

    Il ne faut pas décorner les boeufs avant d'avoir semé le vent

  • # ca fait envie

    Posté par . Évalué à  5 .

    surtout la gestion dynamique du writeback car l'ecriture sur les devices (carte SD particulierement) est tellement lentes que peut etre cela va regler mon probleme.

  • # Sécurité absolue

    Posté par . Évalué à  10 .

    La partie EVM (Extended Verification Module) est bien alléchante, mais il y a un truc que je ne saisi pas.

    En gros, si on modifie hors ligne un fichier, le noyau va le détecter grâce à la signature TPM. Mais si le noyau est également modifié ?

    Parce que les attaques viennent soit de l'extérieur via un programme troué, et là TPM ne peut rien faire (si j'ai bien pigé) puisque l'OS va écraser le fichier et produire les métadonnées de contrôle. Dans ce cas, TPM& cie n'apporte rien (toujours si j'ai bien compris). Soit l'attaque est faite hors ligne... et ce serait vraiment bête de ne pas en profiter pour modifier le noyau, histoire de bien camoufler les ports utilisés, les programmes lancés, et même les fichiers supplémentaires.
    Et s'il y a un nouveau noyau, il peut très bien « oublier » de vérifier la signature des fichiers bricolés.

    Une parade serait que TPM n'autorise pas le chargement d'un noyau modifié.
    Dans ce cas, comment fait-on pour les mises à jour ? Pour la réinstallation d'un OS ? Sans qu'il soit possible d'effectuer une attaque hors ligne.

    Donc il y a un truc que je n'ai pas compris, et plus je lis de la doc, plus je ne pige pas.
    Quelqu'un a un lien ou une explication qui m'éclaire ?

    • [^] # Re: Sécurité absolue

      Posté par (page perso) . Évalué à  2 .

      Le dernier misc sur la sécurité hardware devrait t'aider à comprendre comment marche la chaîne de confiance.
      Il faut comprendre comment marche le principe de scellement des données ou alors ce que propose l'extension intel txt.

      L'idée, c'est que avant de donner la main à un composant, celui ci est obligatoirement vérifié. Dans le cas du noyal, c'est trusted grub qui s'occupe de cette vérification avant d'exécuter le code du kernel.

      Pour ce qui est de la mise à jour des noyaux, je n'ai pas de réponse, il faut que je me renseigne sur trusted grub donc je ne pourrai pas te répondre.

      Cela dit, tes interrogations sont vraiment légitimes.

      • [^] # Re: Sécurité absolue

        Posté par . Évalué à  4 .

        Tu ne fais que repousser le problème sur le composant précédant.
        À un moment, il faut bien que le premier composant logiciel de la chaine soit sûr, et pour ça, à part un vérrou matériel (jumper sur la carte mère qui empêche d'écrire dans une rom, par exemple), je ne vois pas trop comment faire.

        • [^] # Re: Sécurité absolue

          Posté par . Évalué à  3 .

          De tout de facon a partir du moment ou tu as un acces physique il est bien connu que c'est mort la securite. Maintenant imaginons que la securite en question se regarde comme ta porte et ta serrure. Rien ne peut empecher des gens determine avec un temps infini a te cambrioler, le fait d'avoir tel ou tel serrure te garantie (en gros) que ta porte resistera 10 min ou plus. La c'est un peu le meme principe je pense, c'est essentiellement pour empecher le gars en visite qui rentre dans le bureau, met rapidement un live CD copie son programme et se casse. Si il doit contourner toute la chaine de securite cela ne se fait pas en deux temps trois mouvements et peut ne pas passer inapercu. Enfin c'est l'impression que je retient de ce que j'ai lu.

          • [^] # Re: Sécurité absolue

            Posté par . Évalué à  1 .

            Contourner toute la chaîne de sécurité ?
            Quand tu installes l'OS pour la première fois, tu calcules les empruntes de tes binaires pour les vérifier ensuite, de plus, je suppose que cette étape est automatisée.
            Qu'est ce qui empêche une personne qui à un accès physique à la machine de faire la même chose depuis son live cd après avoir remplacé le binaire qu'il veut corrompre ?

            • [^] # Re: Sécurité absolue

              Posté par . Évalué à  4 .

              Il n'a pas le mot de passe.

              "La liberté de tout dire, n'a d'ennemis, que ceux qui veulent se réserver, le droit de tout faire"

        • [^] # Re: Sécurité absolue

          Posté par (page perso) . Évalué à  1 .

          Bah, un bout de code en ROM qui vérifie le code du BIOS avant de lui passer la main, je vois pas ce qui semble fou là dedans.

          Tu vois un problème à ça ?

          • [^] # Re: Sécurité absolue

            Posté par . Évalué à  1 .

            il le vérifie par rapport à quoi ?
            À un moment, tu installes un OS, un logiciel d'amorçage ou autre chose que tu veux garantir.
            Ton tu en prends l'emprunte avec la clé de la puce "sécurisée" de ta machine, et tu mets le résultat quelque part pour la vérifier au prochain lancement.
            Qu'est ce qui empêche une personne qui remplace ce logiciel de faire la même manipulation? c'est à dire d'en prendre une emprunte et de remplacer celle de référence?
            Et plus important, comment le sauras tu?

            • [^] # Re: Sécurité absolue

              Posté par (page perso) . Évalué à  2 .

              Comme je disais, je ne sais pas trop comment la procédure de mise à jour du noyau.

              Cependant, concernant le TPM, la procédure de scellement permet d'empêcher de lire/empêcher les modifications à moins d'être dans le bon état.

              Cet état est dérivé de registres de 160 bits. La seule façon d'altérer ces registres, c'est d'effectuer une extension:
              - Lire une valeur (opération appelée mesure)
              - Étendre le registre avec cette valeur: new_val = SHA1(cur_val + valeur_lue)
              Le scellement permet donc d'établir une chaîne de hash, et donc une suite d'état.

              Cette procédure ne semble pas trop adaptée pour le boot car aucune information sensible doit être stockée. Il semble donc que chaque composant de la chaîne de boot soit signé avec la clé du TPM.

              Dans ce cas, si le BIOS n'est pas signé, il ne sera pas exécuté par la ROM initiale.
              Si le kernel n'est pas signé, il ne sera pas exécuté par le trusted-grub.

              Concernant la procédure d'ajout de nouveau kernels, ça devrait être un truc du genre:
              - Le kernel vérifie ton gestionnaire de paquet
              - Le gestionnaire de paquet vérifie que le paquet du kernel a été fait par une personne de confiance
              - Le gestionnaire de paquet demande au TPM de signer l'initrd + vmlinuz

              Mais encore une fois, je commence à peine à me renseigner sur les TPMs, je pense que tu devrais t'intéresser à trusted grub si tu veux savoir vraiment ce qu'il se passe.

              • [^] # Re: Sécurité absolue

                Posté par . Évalué à  2 .

                Ce qu'on veut dire c'est que, quelque soit le système, il y a forcément un moyen d'installer un OS.
                Par exemple le disque-dur grille. J'en met un nouveau, avec un nouvel OS. Il y a forcément une procédure qui permet de dire "je signe un nouveau truc". Donc je peux installer un GRUB pourri, un noyau pourri, etc.
                --> si j'ai accès physique à la machine, c'est mort. Et moins non plus dans les docs je ne trouve rien qui vienne contrecarer ça.

                Une solution serait d'avoir un mot de passe pour "déverrouiller" la puce lors de l'installation d'un nouvel OS. Il faudrait alors que ce mot de passe ne puisse pas être remis à zéro (sinon, accès physique, remise à zéro, etc). Donc si je pers le mot de passe, la carte-mère part à la poubelle. Ce n'est pas trop grave.
                Et on passe à l'étape suivante: si vraiment tout est verrouillé, alors le truand peut changer la carte-mère (ça devient compliqué pour le faire discrètement).

                Reste la solution que la puce contienne de quoi prouver son identité. Une machine de supervision distante demande alors régulièrement cette preuve (signature via cryptographie asymétrique). Là, ok, pas possible de changer la carte-mère sans que la machine de supervision se mette en alerte.
                Il y a peut être ça d'implémenté, mais les docs sont imbittables :-) D'ailleurs j'arrête.

                • [^] # Re: Sécurité absolue

                  Posté par . Évalué à  7 . Dernière modification : le 06/01/12 à 01:14

                  Par exemple le disque-dur grille. J'en met un nouveau, avec un nouvel OS. Il y a forcément une procédure qui permet de dire "je signe un nouveau truc".

                  C'est bien là que le bât blesse. Pour signer, il te faut une des clés privées, qui seront probablement dans un de ces coffres forts :

                  1. un à Redmond, chez notre marchand de fenêtres favori ;
                  2. un chez Intel, qui fabrique le TPM (qui est dans le proco) ;
                  3. chez le Taiwanais qui a fabriquer la carte.

                  Etant même probable que le troisième n'existe pas, ou contienne la clé d'un des deux autres.

                  dans les docs je ne trouve rien qui vienne contrecarer ça

                  Ce n'est pas (ne sera pas) un problème dû à la norme UEFI, mais plutôt à l'implémentation des BIOS UEFI par les industriels :

                  • Microsoft a dit que secure boot doit être actif pour booter Windows
                  • on veut booter Windows sinon on vendra pas
                  • on active secure boot
                  • on ne prévoit rien pour le désactiver

                  La norme UEFI n'oblige pas à forcer le secure boot, c'est une option de la norme. PAr contre, la norme n'impose pas non plus une procédure de customisation du trousseau de clé dans le TPM.

                  Pour de plus amples renseignements, et des explications qui tiennent la route, lire le blog de Matthew GARRETT :

                  Hop,
                  Moi.

                  • [^] # Re: Sécurité absolue

                    Posté par . Évalué à  3 .

                    Microsoft a dit que secure boot doit être actif pour booter Windows

                    C'est incorrect. Microsoft oblige "secure boot" a être actif pour donner le logo "Designed for Microsoft Windows 8", mais Windows 8 pourra très bien démarrer sur des machines n'ayant pas de secure boot.

                • [^] # Re: Sécurité absolue

                  Posté par . Évalué à  5 .

                  Le TPM est une carte à puce donc avec de la flash. Il peut stocker et générer des clef crypto (avec des générateurs aléatoires internes), il peut signer des blob qu'on lui fournit sans que la clef privé ne sorte du TPM. Il peut se mettre dans un mode update avec le bon mot de passe.

                  Dans le cas de changement de carte mère, si tu as générer une clef perso, tu peux faire en sorte que cela ne démarre pas (disque crypté).

                  "La liberté de tout dire, n'a d'ennemis, que ceux qui veulent se réserver, le droit de tout faire"

            • [^] # Re: Sécurité absolue

              Posté par . Évalué à  10 .

              Voilà en gros comment ça peut se paser :

              • un éditeur logiciel génère une paire de clés privée/publique
              • la clé privée, il la garde pour lui, et jamais elle ne sort (en théorie) : priv-L et pub-L (L: logiciel)

              • un fabricant de carte mères :

                • génère sa propre paire de clés : priv-M et pub-M (M: matériel) avec les mêmes contraintes
                • met la clé pub-M en ROM dans un chip de sécurité
                • signe la clé pub-L avec sa clé priv-L
                • met la clé pub-L en ROM (ou en flash) dans le chip de sécurité
                • signe un tout petit bout de code avec sa clé priv-M
                • mets ce petit bout de code en ROM dans le chip de sécurité

              Comme le code du chip de sécurité est en ROM il n'est pas modifiable, donc il n'est pas physiquement attaquable (ce qui ne veut pas dire qu'il n'y a pas de faille logicielle, mais c'est une autre histoire).

              Une clé publique est valide si et seulement si sa chaîne de confiance permet de remonter à une clé en ROM :
              - soit la clé est en ROM
              - soit la chaîne de signature permet de remonter à une clé en ROM

              Dans ce cas, il est possible d'ajouter des clés publique en flash, tant qu'on possède une clé privée dont la clé publique est en ROM.

              Une fois que le chip de sécurité a établi la chaîne de confiance des clés publiques présentes, il peut vérifier que la signature du BIOS est validée par une de ces clés publiques.

              Si la signature du BIOS est OK, alors, il est exécuté. Charge au BIOS alors de vérifier de la même manière le code qu'il voudra ensuite exécuter :

              • des modules UEFI ( c'est à la mode ! )
              • un bootloader
              • autre chose...

              Une fois que le BIOS a décidé quel code charger, que ce code est à son tour signé par une clé de confiance, alors le BIOS peut l'exécuter.

              Et ainsi de suite :

              • le bootloader vérfie le kernel
              • le kernel vérifie /sbin/init
              • /sbin/init vérifie /etc/inittab

              Un autre scénario peut être :

              • le bootloader vérifie le kernel et le système de fichiers

              Le but dans tout ça, c'est bien de garantir que jamais du code ne puisse être exécuter sans que sa signature ne soit validée par une clé de confiance.

              Tout repose sur trois choses :

              1. les clés privées priv-M et priv-L ne fuient jamais
              2. les clés privées priv-M et/ou priv-L ne servent jamais à signer un malware (par exemple pour un État)
              3. tout code exécuté en chaîne n'exécute jamais du code non valide.

              Maintenant, si tu as moyen de faire signer ta clé publique par priv-M ou toute autre clé dont la chaîne de confiance remonte à priv-M, alors tu pourras entrer ta clé publique dans le chip de sécurité, et seulement là tu pourras exécuter ton propre code.

              Ou alors, si tu arrive à faire signer un GRUB par une clé priv-M ou priv-L, et que ce GRUB ne fait pas de vérification, alors tu pourras charger le noyau que tu veux.

              Mais il faut bien voir qu'à aucun moment, à partir du code initial en ROM, jusqu'à l'exécution du booloader, la chaîne de confiance n'est brisée. Et c'est ce qui posera problème pour le UEFI secure boot voulu par Krosoft :

              1. il n y aura probablement pas moyens de mettre notre propre bootloader non signé, donc impossible charger notre propre noyau non signé, etc...
              2. il ne sera probablement pas possible de charger notre propre clé dans le chip de sécurité, donc impossible d'exécuter notre propre bootloader signé avec notre clé, etc...

              Hop,
              Moi.

              • [^] # Re: Sécurité absolue

                Posté par . Évalué à  2 .

                Il me semble qu'il existe un mode TPM sans référence à une clef tier, avec une clef privé généré à la 1er installation. Elle est généré au début, avec possibilité de transfert entre TPM.

                "La liberté de tout dire, n'a d'ennemis, que ceux qui veulent se réserver, le droit de tout faire"

                • [^] # Re: Sécurité absolue

                  Posté par . Évalué à  5 .

                  Il me semble qu'il existe un mode TPM sans référence à une clef tier, avec une clef privé généré à la 1er installation. Elle est généré au début, avec possibilité de transfert entre TPM.

                  C'est probablement dans la norme UEFI, en effet. Mais il faut savoir que les fabricants de cartes mères, la norme, souvent ils s'en battent ; ce qui compte pour eux, c'est de vendre du matos, donc que Windows s'installe dessus.

                  Vu la concurrence sur les prix, implémenter quelque chose qui n'est pas nécessaire à faire tourner Windows est vu comme un sur-coût, et donc passe à la trappe.

                  Et y'a qu'à voir comment les développeurs de BIOS sont des gros gorets pour imaginer assez surement que c'est ce qui va se passer au final...

                  Hop,
                  Moi.

                • [^] # Re: Sécurité absolue

                  Posté par . Évalué à  2 .

                  C'est comme ça que fonctionnais la puce TPM de ma CM Gigabyte. Génération de la clé privé à la première activation dans le BIOS et protection de celle-ci par mot de passe.

                  Après j'ai pas beaucoup fait mumuse avec, cette CM étais une vrai merde et le SAV de Gigabyte de vrais escrocs, du coup j'ai acheté une CM Asus, sans TPM.

      • [^] # Re: Sécurité absolue

        Posté par . Évalué à  6 .

        Donc, ça peut servir à empêcher l'utilisateur (celui qui paie le matériel et en est propriétaire) d'installer une autre version de Linux, sur sa propriété à lui, sous prétexte de protection des droits d'auteur ou ce genre de connerie?

        Ça me fait flipper que ce genre de fonctionnalités soient intégrées dans Linux sans que ça provoque de remous et de réactions chez ses développeurs. Ou alors j'ai pas tout compris.

        THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.

        • [^] # Re: Sécurité absolue

          Posté par (page perso) . Évalué à  6 .

          De toutes façon tous les moyens pour avoir un système sécurisé peuvent être détournés pour empêcher l'utilisateur d'installer une autre version du soft. Si tu veux de la sécurité (et certains en veulent), c'est à ce prix.

          « Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » Raymond Devos

          • [^] # Re: Sécurité absolue

            Posté par . Évalué à  8 .

            Ça dépend de la définition de "sécurité".

            Si tu autorises un accès à la carte mère, tu es juste mort d'un point de vue sécu. Non pas que ça va forcément te permettre de lancer les programmes que tu veux en 10 minutes sur toutes les plateformes, mais tu vas pouvoir faire tout un tas de choses potentiellement intéressantes pour un attaquant, au niveau de la confidentialité, de l'intégrité ou juste de la disponibilité de sous-systèmes.

            Dans la modélisation des menaces, il y a très peu de cas pour lesquels un fabriquant de carte mère de PC classique et encore moins un utilisateur souhaiterait être résistant dans certains domaines face à un accès direct à la carte mère. Ça peut exister, mais dans des cas spéciaux, pas vraiment dans le cas général. Dans le cas général on peut considérer que la personne qui accède à la carte mère possède le pc (soit qu'elle le possède au sens légal, soit qu'elle le "own")
            Dans une modélisation des menaces qui prend ce fait en compte, il est totalement possible de concevoir, sans surcoût exorbitant, des mécanismes de boot sécurisés qui ne se résument pas simplement à la construction de prisons dorées sous iMarque, sous l'empire des Fenêtres, ni sous big brotheria Googlesque. Il suffit de permettre de rendre accessible par un jumper une zone normalement read-only, de manière à ce que l'utilisateur puisse installer ses propres clefs racines si l'envie lui prend.

            On n'a donc pas dans l'absolu à subir le prix démesuré de la perte de la possibilité par l'utilisateur d'installer ce qu'il désire dès que le système dispose d'un boot sécurisé.

            Malheureusement en pratique certaines boites ont tout intérêt à ce que les boots sécurisés n'incluent pas cette possibilité (et je parle d'informatique généraliste, pas de truc dédiée multimédia ni de console de jeux-vidéos). Toutes leurs docs de référence et de conformité seront orientés pour que les OEM fassent des cartes avec impossibilité de maj les clefs racines (rien que la simple omission serait efficace en la matière, et ne parlons pas d'une rédaction astucieuse par un type ayant explicitement ça en tête) et même de plus de préférence avec impossibilité de désactiver le boot "sécurisé", que l'on devrait alors plutôt renommer en boot de mise sous-tutelle (si vous avez une expression encore plus stylée en tête, merci de la proposer en réponse à ce commentaire). Lesdites boites se défendront d'avoir cette démarche et répondront à toute critique en disant qu'ils n'interdisent pas aux OEM d'implémenter aussi un autre mécanisme autorisant le démarrage d'OS "alternatifs" (si possible en sous-entendant au passage qu'ils ne pourront pas profiter de boot sécu ou alors dans des conditions faisant passer Windows pour un système ouvert)

            La sécurité et l'indépendance vont de pair. La capacité souveraine des possesseurs d'infrastructure numérique de régler ou faire régler par la personne de leur choix les problèmes dans les logiciels qu'ils utilisent sans pour autant être soumis au bon vouloir absolu de fournisseurs imposés (cela peut éventuellement nécessiter des moyens importants) est primordiale si l'on souhaite avoir de réelles capacités de défense, et il est tout autant primordial que cela ne nécessite pas la désactivation d'autres aspects de sécurité. Cela peut valoir pour les individus, pour les organisations, pour les états, pour tout le monde. Dans la guerre contre les ordinateurs universels qui se prépare, il est important d'exiger que les fonctionnalités du matériel ne soient pas réservées aux seuls empires sans âmes rêvant de dupliquer des modèles commerciaux de vendeurs de gadgets de luxe.

    • [^] # Re: Sécurité absolue

      Posté par . Évalué à  3 . Dernière modification : le 05/01/12 à 14:52

      Quelqu'un a un lien ou une explication qui m'éclaire ?

      Pas moi, pas sur ton questionnement direct.
      Mais un simple complément d'architecture pour laquelle c'est utile : lorsque le système est éclaté.
      Les noyaux n'étant pas présents sur les serveurs, ils sont chargés au boot pxe. Dans ce cas, tu peux toujours chercher dans les disques des lames le noyau à modifier, il ne s'y trouve pas (ils sont tous dans la lame qui est dans l'armoire du fond, tu vois ? :) Faut prendre une massue pour y aller ou bien le badge qui autorise un accès de niveau supérieur à celui d'entrée dans la salle machine).

      • [^] # Re: Sécurité absolue

        Posté par (page perso) . Évalué à  3 .

        Question: si le hacker modifie le hash stocké dans TPM pour refléter la nouvelle version du filesystem qu'il vient de corrompre, il se passe quoi?

        • [^] # Re: Sécurité absolue

          Posté par . Évalué à  1 .

          Tu ne peux pas le faire, le TPM est équivalent à une carte à puce.

          "La liberté de tout dire, n'a d'ennemis, que ceux qui veulent se réserver, le droit de tout faire"

          • [^] # Re: Sécurité absolue

            Posté par (page perso) . Évalué à  2 .

            C'est à dire? Le kernel "original", pour interroger la puce, il a bien besoin de lui passer un truc (une clé?) qu'il stocke quelque part, non?
            Le hacker pourrait la récupérer sans soucis, non?

            • [^] # Re: Sécurité absolue

              Posté par . Évalué à  2 .

              Ou alors changer la carte-mère par une que tu maîtrises. Ça devient rock'n roll mais les personnes avec les bons moyens peuvent le faire.

              • [^] # Re: Sécurité absolue

                Posté par (page perso) . Évalué à  1 .

                Nan mais sérieusement, à l'execution, qu'est ce qui différentie le kernel d'un live CD de celui du disque dur, du point de vue de TPM?

                Qu'est ce qui fait que seul le kernel du disque dur aura le droit de modifier le hash des binaires stocké dans TPM, et pas celui du Live CD?

                Une clé? Que le kernel HDD passe à TPM pour s'identifier?

                Si oui il la trouve où cette clé? Dans son disque dur forcément! Donc le hacker peut bien lire le disque dur, récupérer cette clé, puis recalculer le hash à partir de ses binaires vérolés et l'inscrire dans la puce TPM. Au prochain boot le hash correspondra à ce qui est sur le disque dur et boum; non?

                • [^] # Re: Sécurité absolue

                  Posté par . Évalué à  2 .

                  J'imagine que le TPM a besoin d'un PIN pour faire ça qui ne sera pas stoquer sur le HD.

                  "La liberté de tout dire, n'a d'ennemis, que ceux qui veulent se réserver, le droit de tout faire"

                • [^] # Re: Sécurité absolue

                  Posté par (page perso) . Évalué à  5 .

                  Si oui il la trouve où cette clé? Dans son disque dur forcément!

                  Non la clé est stockée dans le TPM.
                  C'est expliquée dans la news du noyau 2.6.38 : https://linuxfr.org/news/le-noyau-linux-est-disponible-en-version-2638#toc_12

                  Je te colle la phrase :

                  la « trusted key », est générée par le TPM et elle est chiffrée avec la clé interne du module (la « storage root key » RSA 2048 bits), de façon à la protéger (sealing). L'accès à la clé (unsealing) ne se fait que si la configuration complète de la machine n'a pas été modifiée, c'est-à-dire si le BIOS, le chargeur et le système d'exploitation, sont conformes à ce qui a été enregistré au sein du TPM dans son « Platform Configuration Register ».

                  • [^] # Re: Sécurité absolue

                    Posté par . Évalué à  1 .

                    Même avec cette phrase, je n'arrive pas à comprendre en quoi c'est sensé être sécurisé.

                    Comment la conformité est vérifiée? c'est le bios qui prends le hash du noyau ? comment fait-il ça ? et en quoi n'est-ce pas possible de charger un noyau qui a le même hash ? comme par exemple l'image du noyau qui viens du disque ?

                    Ensuite, comment le BIOS (si c'est bien lui) fait-il pour savoir où se trouve le noyau en mémoire ? on peut très bien lui dire "charge le noyau à tel adresse" puis le déplacer et mettre à l'adresse indiquée l'image (non active) du noyau qui viens du disque.

                    • [^] # Re: Sécurité absolue

                      Posté par . Évalué à  6 .

                      Comment la conformité est vérifiée? c'est le bios qui prends le hash du noyau ? comment fait-il ça ? et en quoi n'est-ce pas possible de charger un noyau qui a le même hash ? comme par exemple l'image du noyau qui viens du disque ?

                      En espérant que ça ne parte pas en troll.
                      Rapidement voici la façon dont un TPM fonctionne, il prend des hash successifs du démarrage et de l'éxecution de l'OS et en fonction de cela il ouvre des boites à clef.

                      Quand tu initialise un TPM il créé une première clef et la stocke dans sa mémoire, et il créé aussi une première boite à clef qui sont toujours accessibles depuis le TPM, cette boite à clef est chiffrée avec les hash de la première clef d'initialisation + la clef fabriquant. On a donc une boite à clef chiffrée qui ne peut être ouverte que par ce TPM là. On va l'appeler BC0 (boite à clef 0)
                      Cette boite à clef ne peut être ouverte que part le hash de la clef d'initialisation + la clef fabriquant, on va appeler ce hash H0
                      H0 = hash(clef init + clef fab).
                      On note que la boite à clef 0 peut être ouverte par le hash H0 de la façon suivante : H0 -> [BC0]
                      Au moment du boot, le TPM prend un hash des parties invariantes du BIOS (de façon à ce qu'un bios mis à jour ne pourrisse pas les boites à clef)
                      H1 = hash(BIOS + H0).
                      Si on veut on peut créer une boite à clef 1 telle que H1 -> [BC1]
                      Ensuite on commence à pouvoir s'amuser, le TPM va enregistrer et stocker tout un tas d'évèvenements à la queue leu leu. Si on décide par exemple de chiffrer le disque de démarage et de mettre la clef dans TPM. On mesurera H0 et H1 (obligatoire), mais aussi des valeurs H2 (ordre de démarrage), H3 (identité du disque de démarrage), H4 (bootloader) et H5 (état du programme de crypto au moment d'insérer le mot de passe).
                      Avec H2 = hash(boot order + H1), H3 = hash (uuid Disque Dur + H2), H4 = hash( bootloader + H3) et H5 = Hash(empreinte mémoire processus + H4)

                      On peut alors créer une boite à clef 5 avec H5 -> [BC5]. Et c'est dans cette boite que se trouve la clef de déchiffrement.

                      TPM est relativement passif, il prend certaines informations tout seul, mais pour la fabrication des hashs (à part les premiers ou le loader/l'os n'ont par encore la main), il faut lui demander explicitement. Charge donc à l'administrateur de demander des hash intelligent et de placer ses boites à clefs de façon à ce que le contenu ne soit pas facilement attaquable. De plus quoi qu'il arrive un hash de sécurité est forcément construit par dessus H1, donc je ne peux pas demander à TPM le hash d'un binaire seul et y associer une boite à clef.

                      Dans le cas qui nous intéresse, supposons que je veuille protéger une info et ne la rendre lisible que si je suis dans un environnement connu. Je vais prendre un Hn qui sera égal à Hn=hash(processus + hash(environnement + ... + hash(noyeau + hash(bootloader + hash(uuid disque dur + hash( CMOS + H1))))))
                      Et j'y associerai une boite à clef BCn.

                      Et là j'ai bien un environnement contrôlé avec un système qui est quand même assez compliqué à contourner.

                      Bon c'est une vision assez vulgarisée de la méthode, mais grosso-modo ca marche comme çà. Comme les hashs sont réévalués périodiquement, si quelqu'un trifouille le noyau ou le processus, la boite à clef se referme et il n'y a plus moyen d'utiliser les clefs qu'elle contient pour déchiffrer des messages.

                      En cas de mise à jour de l'environnement, il faut préparer le TPM à migrer/copier les clefs dans une autre boite. Donc dans l'environnement valide on créé une zone de migration (soit vers un autre TPM, soit vers le même TPM) avec un hash spécifique. Puis on récupère les clefs dans la nouvelle boite dans le nouvel environnement. A noter que les clefs ne sont jamais accessibles en clair en théorie (encore que l'on puisse contourner avec des émulateurs de TPM), les clefs accessibles au sein d'un TPM ne peuvent qu'être utilisée pour chiffrer/décoder (on envoie le flux chiffré, on récupère le flux en clair - ou l'inverse), et les clefs au sein d'une zone de migration sont dans un blob lui même chiffrée avec la clef de migration du TPM de destination.

                      Jusqu'à TPM 1.2 la norme spécifiait que seule la clef constructeur pouvait être préchargée, le reste du TPM devant être vide et non initialisé. Depuis, des NDA long comme le bras sont venus se rajouter pour l'accès aux normes, donc j'ai complètement laissé tombé TPM. Dommage c'était une technologie très inintéressante...

                      • [^] # Re: Sécurité absolue

                        Posté par . Évalué à  2 .

                        Pas de troll, c'est juste que j'ai l'impression qu'il manque une information importante dans cette histoire.

                        Donc si j'ai bien suivi, ça veut dire qu'après la première installation, s'il n'est pas posible de réinitialisez tpm, on aura inventé les cartes mère jetable ?
                        Et surtout jetable au moindre disque dur grillé ou qui a un secteur défectueux au niveau de l'image du logiciel d'amorçage ou du noyau ?
                        J'en reviens ici à mon premier point, il faut à un moment ou un autre, un point de contrôle matériel, tel qu'un switch sur la carte mère, une clé de réinitialisation externe (un genre de code puk pour carte mère)
                        Pour moi, avoir une sécurité purement logicielle est un problème récursif insolvable.

                        • [^] # Re: Sécurité absolue

                          Posté par . Évalué à  3 .

                          ça veut dire qu'après la première installation, s'il n'est pas posible de réinitialisez tpm, on aura inventé les cartes mère jetable ?

                          Pour les machines achetées complètes (eg. DELL, HP...), ce sera même dès l'achat. Le TPM sera déjà bloqué en usine, avec un Windows 8 pré-installé.

                          Pour le matériel en pièces détachées, il est fortement probable que ce soit aussi le cas pour la (très grande) majorité des cartes mères; elle seront programmée avec une des clés supportées par Windows 8.

                          Donc, même si tu montes ton PC toi-même, il y a fort à parier que tu ne pourras pas installer tes propres clés.

                          Hop,
                          Moi.

                        • [^] # Re: Sécurité absolue

                          Posté par (page perso) . Évalué à  2 .

                          J'en reviens ici à mon premier point, il faut à un moment ou un autre, un point de contrôle matériel, tel qu'un switch sur la carte mère, une clé de réinitialisation externe (un genre de code puk pour carte mère)

                          Pas si tu veux de la vrai sécurité.

                          « Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » Raymond Devos

                          • [^] # Re: Sécurité absolue

                            Posté par . Évalué à  4 .

                            Au contraire, ça dépend du modèle de menaces (et au passage influencera de manière primordiale le futur de l'informatique et de la société)

                        • [^] # Re: Sécurité absolue

                          Posté par . Évalué à  3 .

                          _Donc si j'ai bien suivi, ça veut dire qu'après la première installation, s'il n'est pas posible de réinitialisez tpm, on aura inventé les cartes mère jetable _

                          Il est possible de réinitialiser le TPM (en tout cas était possible en norme 1.2), mais forcément tu perds l'ensemble des clefs déjà présentes dans le TPM. C'est comme quand tu oublies le mot de passe de ta clef privée, c'est un poil foutu pour décoder quoi que ce soit avec.
                          La carte mère quand à elle continue à fonctionner très bien même si TPM se bloque, tu n'as juste plus accès aux clefs que TPM protège.

                          Et surtout jetable au moindre disque dur grillé ou qui a un secteur défectueux au niveau de l'image du logiciel d'amorçage ou du noyau ?

                          En environnement professionnel, charge à toi de faire une copie des clefs vers d'autres TPM pour éviter la catastrophe.En environnement personnel, il vaut mieux posséder un système double : ton logiciel possède à la fois une clef hard basé sur le TPM et une autre clef que tu peux entrer à la mano de façon exceptionnelle.

                          Pour moi, avoir une sécurité purement logicielle est un problème récursif insolvable.

                          TPM est une solution purement hardware, vu que les clefs sont générées par le TPM directement et ne sortent jamais en clair.

      • [^] # Re: Sécurité absolue

        Posté par . Évalué à  1 .

        Faut prendre une massue pour y aller ou bien le badge qui autorise un accès de niveau supérieur à celui d'entrée dans la salle machine).

        Si tu n'as pas d'accès physique et que ta bécane est 200% sûre et que tu ne fais jamais d'erreur, forcément il n'y a pas de problème :-)

        Le pépin est: si tu as un accès physique, c'est mort.
        C'est ce qu'il est proposé ici de protéger.

        Avec un accès physique, PXE ne tient pas non plus: tu branches ton portable en direct sur le serveur et zou (c'est ce que je fais sur mes serveurs en PXE, lorsqu'il y a un pépin ça me permet d'utiliser un terminal plus évolué que la console, avec copié/collé depuis mes notes).

        Bon bref, ce n'est pas nouveau: accès physique = c'est mort.
        N'empêche, il est possible d'augmenter la difficulté des intrusions.
        Éventuellement d'en annuler totalement la possibilité, mais pour l'instant, je n'ai pas pigé.

        • [^] # Re: Sécurité absolue

          Posté par . Évalué à  2 . Dernière modification : le 05/01/12 à 17:58

          PXE ne tient pas non plus: tu branches ton portable en direct sur le serveur

          Et zou quoi ? Tu charges un noyau autre ? Tu déposes en local un noyau sur la machine ? La belle affaire. Et ensuites lorsque la machines reboote sur son noyau ordinaire, il se passe quoi ? Il se passe que le noyau se rend compte que qq chose ne va pas sur le système.

          Brancher un portable pour bypasser et résoudre temporairement un problème, c'est pratique bien sûr, mais cela n'a AUCUN impact sur le mode d'archi décrite. (dans le pire des pires des cas, tu démares avec un noyau local sur une machine qui devrait être éteinte : combien de temps penses tu tenir avant que l'équipe réseau s'en apperçoive ?)

          Accès physique, c'est mort

          Oui, c'est pour ça qu'il est possible de cloisonner les accès physiques. Et cette méthode est un pas de plus vers une délégation plus sereine des accès physiques aux serveurs. Le merc qui vient juste pour faire trois trucs physiquement en salle serveur ne peut plus, désormais, pose des binaires vérolés sur une lame : le noyau n'étant pas présent, et possédant cette nouvelle fonctionnalité, c'est mort. C'est une vraie bonne évolution, dès lors que l'on regarde logiciel et emplacement/archi.

          • [^] # Re: Sécurité absolue

            Posté par . Évalué à  1 .

            Et zou quoi ? Tu charges un noyau autre ? Tu déposes en local un noyau sur la machine ? La belle affaire. Et ensuites lorsque la machines reboote sur son noyau ordinaire, il se passe quoi ? Il se passe que le noyau se rend compte que qq chose ne va pas sur le système.

            Si tu véroles la bécane ce n'est pas pour qu'elle redémarre sur le noyau d'origine :-)
            Donc exit PXE. Tu installes ton noyau en local, avec tout le reste. Mais ça complique. C'est une bonne étape supplémentaire (entre autres, faire en sorte que le noyau masque les fichiers locaux qui viennent d'être ajoutés). La marche d'entrée est déjà bien plus haute. Si j'avais à le faire, je pense que ça me prendrait des mois de préparation.

            D'un autre côté, PXE est statistiquement une faiblesse à mon goût.
            S'il faut dépenser 50 heures et 50000 € pour atteindre une machine dans un centre de données (voler la carte d'accès, ou soudoyer, ou etc) et la bricoler, on n'atteint que les machines d'un seul client. Attaque ciblée contre une entreprise.
            Pour accéder à la supervision du PXE, il faut peut-être dépenser 500 heures et 500000 €. Les humains restent des humains. Mais là tu as accès à 20000 machines. Statistiquement c'est plus faible. Après, que ça intéresse quelqu'un, c'est une autre histoire.

            • [^] # Re: Sécurité absolue

              Posté par . Évalué à  1 . Dernière modification : le 05/01/12 à 22:32

              tu véroles la bécane ce n'est pas pour qu'elle redémarre sur le noyau d'origine

              On a déjà pris comme prérecquis que tu pouvais booter sur un livecd, que le bios était configuré pour ça. Et maintenant tu veux prendre comme prérecquis que tu lances une machine sensible qui ne serait pas surveillée et dont le service ne serait pas redondée pendant son arrêt ? Ou encore plus gros, que tu ai accès au bios ? Ou encore encore plus gros : que l'équipe réseau ne soit pas équipé de sondes de détection ? Ou encore encore encore plus gros : journée portes ouvertes ?
              On parle d'envrionnement sécurisés, là, (la mise en oeuvre de telles features, telles que décrites par ce chapitre, ne concerne pas tout les cas) pas de ce qu'il serait possible de faire si ... (seulement ça était mis en oeuvre) : Il s'agit bien d'une avancée réelle pour des cas concrêts.
              Cette discussion commence à plomber la dépêche :-(

  • # dtrace un jour ?

    Posté par . Évalué à  7 .

    Hello,

    Merci à nouveau pour cette news très complète sur le noyau (que je n'aurai jamais le temps de lire en entier :/).

    J'ai une question sur le noyau. Est ce qu'il existera un jour un outil de profiling à la dtrace ?

    J'ai découvert ça récemment, en intégrant une équipe d'administrateurs système mixte (du GNU et du Solaris), et je peux dire que cet outil est impressionnant.

    Moi j'ai un background plutôt GNU/Linux et je ne me prive pas d'en vanter ses multiples qualités à mes collègues. Mais en ce qui concerne cet outil, il n'y a aucun outil qui rivalise à ma connaissance.

    Qu'est ce que vous utilisez pour espionner votre système ? Systemtap est le prétendant naturel. Il y a également les classiques strace, lsof, fuser, netstat, (h)top, iftop, iotop, sar, vmstat, free, et quelques autres. On peut aussi utiliser GDB. Mais aucun ne joue vraiment dans la même cour que dtrace. Par ailleurs les équivalent sous Solaris se basent sur dtrace désormais.

    Est ce que qu'il existe sous Linux des outils qui permettraient de savoir :
    - La liste des appels systèmes (triés par ordre croissant d'appel) générés par un processus et ses enfants
    - Savoir précisément ce qui se passe ? (y compris quel appel est fait à quelle fonction avec quels arguments)
    - Connaitre le temps précis passé dans chaque appel trié par ordre croissant.
    - Intercepter un appel à un fichier et déclencher une action (par exemple, le faire ouvrir un autre fichier de manière transparente, lui donner un code de retour factice, ou encore tuer le processus qui tente de modifier un fichier en question).
    - Quel sont les processus qui accèdent à un fichier en particulier.
    etc. ?

    Le FN est un parti d'extrême droite

    • [^] # Re: dtrace un jour ?

      Posté par (page perso) . Évalué à  3 .

      Systemtap devrait bien t'interesser, c'est un outil largement inspiré de dtrace mais optimisé pour linux.

      Et si je me souviens bien, il y a un port de dtrace pour linux. Je ne suis par contre pas sûr que ce soit intégrable dans linux même pour des raisons de licence.

    • [^] # Re: dtrace un jour ?

      Posté par . Évalué à  2 .

      oprofile fait une partie de ce que tu désires.

      • [^] # Re: dtrace un jour ?

        Posté par . Évalué à  2 .

        Puisqu'on est dans le sujet : j'ai une application qui met très longtemps à démarrer à froid, juste après le boot de la machine, mais ensuite, le redémarrage de l'appli est quasi-instantané.

        Quel est le meilleur outil pour déterminer la section de code qui ralenti le premier démarrage ?

        • [^] # Re: dtrace un jour ?

          Posté par . Évalué à  2 .

          A priori, le deuxième démarrage de ton appli est plus rapide parce que le binaire correspondant à ton appli est désormais dans le cache, et parce que les librairies qu'utilise ton appli sont en mémoire, ce qui va économiser bon nombre d'accès disques.

          • [^] # Re: dtrace un jour ?

            Posté par . Évalué à  2 .

            Oui, j'avait pensé à un truc comme cela, donc je précise la question :
            - parmi les outils cités plus haut, est ce qu'il y en a un en particulier qui permet de valider cette hypothèse facilement ?
            - est-ce qu'il existe une méthode pour accélérer le chargement des librairies ?

            • [^] # Re: dtrace un jour ?

              Posté par . Évalué à  4 .

              1) Oprofile doit faire le boulot, c'est fait pour
              2) oui : dd bs=1M mylib.so >> /dev/null (et c'est pas une blague )

              "La liberté de tout dire, n'a d'ennemis, que ceux qui veulent se réserver, le droit de tout faire"

              • [^] # Re: dtrace un jour ?

                Posté par . Évalué à  2 .

                Merci pour oprofile, je m'en vais lire la doc.

                Pour le chargement en cache, je m'attendait a plus compliqué, c'est élegant ! Par contre, pour la syntaxe sa serait plutôt "dd ds=1M -i mylib.so -o /dev/null", n'est ce pas ? Merci aussi.

                • [^] # Re: dtrace un jour ?

                  Posté par (page perso) . Évalué à  4 .

                  Pourquoi pas cat mylib.so > /dev/null? Ça change quoi d'utiliser DD?

                  • [^] # Re: dtrace un jour ?

                    Posté par . Évalué à  3 .

                    Plus rapide.

                    c'est
                    dd bs=1M if=mylib.so of=/dev/null

                    "La liberté de tout dire, n'a d'ennemis, que ceux qui veulent se réserver, le droit de tout faire"

                  • [^] # Re: dtrace un jour ?

                    Posté par . Évalué à  1 .

                    Je crois que ca n'apporte rien d'utiliser dd, j'ai fait l'essai avec dd et cat, et le resultat est identique. Peut etre pour éviter un UUOC ?

                    Et j'ai fait une boulette dans ma correction de syntaxe dd, ce n'est pas "-i mylib.so -o /dev/null" mais plutot "if=mylib.so of=/dev/null" ... bref, cat c'est plus simple...

                    Il me reste maintenant a mesurer le temps de démarrage de l'appli avec/sans cache chargé, merci a tous pour votre aide.

                    • [^] # Re: dtrace un jour ?

                      Posté par . Évalué à  2 .

                      Si tu ne mets pas le bs=1M à dd, il doit prendre la taille de 512 octets de base, ce qui est hyper lent.

                      "La liberté de tout dire, n'a d'ennemis, que ceux qui veulent se réserver, le droit de tout faire"

                      • [^] # Re: dtrace un jour ?

                        Posté par . Évalué à  2 .

                        J'ai bien mis l'option "bs=1M" à dd, je n'ai pas vu de différence notable pour le temps de chargement par rapport a cat, sur mon exemple particulier.
                        Et cat est plus sympa, parce qu'on peut charger plusieurs fichier avec une seule commande, pour dd c'est un appel par fichier.

                        • [^] # Re: dtrace un jour ?

                          Posté par (page perso) . Évalué à  1 .

                          Si tu as testé dd après cat sans vider ton cache, forcément, tu ne vois plus la différence (le fichier est déjà en cache).

                          • [^] # Re: dtrace un jour ?

                            Posté par . Évalué à  5 .

                            Hmmm, comment te dire... je parlais de la durée de remplissage du cache, ou cat et dd sont équivalent.

                            J'ai vidé le cache, puis l'ai rempli avec dd. Ensuite, je l'ai vidé à nouveau, puis rempli avec cat. Les deux remplissage ont une durée équivalente, de l'ordre de la dizaine de seconde.
                            Par contre, si on ne vide pas le cache entre les deux remplissage, alors le deuxieme est immédiat (et on voit donc une différence).

            • [^] # Re: dtrace un jour ?

              Posté par . Évalué à  4 .

              Si tu veux juste savoir si c'est le cache du VFS

              echo 3 > /proc/sys/vm/drop_caches
              
              

              Après tu peux sortir des outils plus compliqués mais l'investissement vaut pas le coup si t'as pas commencé avec les fondamentaux.

              • [^] # Re: dtrace un jour ?

                Posté par . Évalué à  2 .

                Excellent, maintenant je sais remplir et vider mon cache, merci beaucoup.
                Je vais commencer par ca avant de sortir l'artillerie.

    • [^] # Re: dtrace un jour ?

      Posté par (page perso) . Évalué à  3 .

      Systemtap est le prétendant naturel [...] Mais aucun ne joue vraiment dans la même cour que dtrace. Par ailleurs les équivalent sous Solaris se basent sur dtrace désormais.

      Qu'est-ce que tu penses qui manque à SystemTap pour « jouer dans la même cour » que DTrace ? Tous les cas d'utilisation que tu cites peuvent être implémentés avec SystempTap.

      pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question. | Free Softwares Users Group Arlon, Belgique : http://fsugar.be/

  • # Merci !

    Posté par (page perso) . Évalué à  1 .

    Comme d'habitude, une super dépêche !

    Ma pause de midi a été extrêmement instructive pour une fois. J'ai hâte de tester tout ça (faites chauffer gcc !!!)

    Merci

    Si tu ne sais pas demande, si tu sais partage !

    • [^] # Re: Merci !

      Posté par . Évalué à  10 .

      Moi je dis merci aussi, mais pour une toute autre raison !

      Grâce aux dépêches sur le kernel, j'ai des arguments pour ceux qui me disent :

      Cite-moi un exemple concret où t'as besoin d'ouvrir 150 onglets à la fois !

    • [^] # Re: Merci !

      Posté par (page perso) . Évalué à  3 .

      Pas la peine de faire chauffer inutilement le CPU : Pour tester, il suffit de tester Mageia 2 (le chaudron où mijote actuellement la version alpha 2). Personnellement, je n'ai rien à reprocher à cette version de kernel et il faut lire les fabuleux articles de patrick_g pour comprendre des évolutions qui ne sont que peu apparentes à l'utilisateur.

      J'en profite pour ajouter que Mageia 2 (Cauldron) serait tout à fait utilisable actuellement si ce n'était une version alpha. Comme elle ne peut que se bonifier dans les 5 ou 6 mois qui la séparent de sa sortie officielle, on devrait obtenir une très belle et bonne distribution. Comme on dit près de chez moi, un grand cru !

  • # Petite faute?

    Posté par . Évalué à  -10 .

    Greg KH a semblé enchanté -> a semblé être enchanté?
    Sinon merci pour cette dépêche.

  • # Blue Mountain ou Bull Mountain

    Posté par . Évalué à  7 .

    Bonjour à toi ô grand rédacteur du noyau.

    Après être allée voir sur le site Intel concernant l'architecture Ivy Bridge,
    j'ai constaté qu'ils appelle ça Bull Mountain.
    http://software.intel.com/en-us/articles/download-the-latest-bull-mountain-software-implementation-guide/?wapkw=%28bull+mountain%29

    Merci à toi pour cette dépêche toujours aussi passionnante.

  • # "piscine d'entropie"

    Posté par . Évalué à  10 .

    Je préfère souvent employer le substantif "réservoir" plutôt que "piscine" ou "bassin" quand je traduis "pool" en informatique. Je trouve que ça donne une meilleure idée de ce dont il s'agit.

  • # Page mémoire

    Posté par . Évalué à  1 .

    Toujours pas de gestion de pages de 16M ?!

  • # Méta-remarques

    Posté par . Évalué à  3 .

    Une dépêche sur le noyau toujours aussi agréable, merci. J'ai deux méta-questions.

    1. Je salue l'effort de traduction des annonces de RC (d'ailleurs je me dis à chaque fois que j'aurais pu aider, mais je ne m'en rend pas compte quand il y a quelque chose à faire, il faudrait suivre de plus près l'espace de rédaction), mais j'aime mieux lire les versions originales, ne serait-ce que parce que ça permet d'apprendre des tournures anglaises amusantes. Dans certains documents traduits comme les interview, tu mets en général le texte à la fin en commentaire, là tu mets l'adresse des annonces sur la mailing-list, mais est-ce qu'on pourrait envisager quelque chose de plus intégré? Je me dis qu'on pourrait par exemple écrire un petit bout de Javascript pour avoir un rendu "tabbed", avec un cadre qui affiche l'une des versions au choix. Est-ce que vous pensez que ça serait une bonne idée ? Dans un premier temps, je serais en faveur de mettre les deux versions à la suite, pour faciliter la lecture (sachant qu'on n'a pas à craindre le gain en longueur, vu où on en est...).

    2. J'imagine que tu suis LWN.net, en plus des listes de lecture de développement du noyau. Si c'est le cas, peut-être pourrais-tu profiter des dépêches sur le noyau pour mettre des liens vers les articles LWN (sur le noyau ou pas) qui t'ont particulièrement intéressé pendant cette période ? Le coût en temps/effort me semble relativement faible, et ça pourrait intéresser les gens qui apprécient tes dépêches, voire les motiver pour s'abonner...

    • [^] # Re: Méta-remarques

      Posté par (page perso) . Évalué à  10 .

      Sur la première question je ne suis pas certain du gain que cela apporterait de coller la VO des mails de -RC en plus de la version traduite. Après tout l'original n'est qu'à un clic de souris non ?
      Certes lors de mes interviews j'ajoute la VO en commentaire mais c'est parce que l'original n'a pas été posté sur le web et qu'il n'existe que dans ma boite mail.

      Pour ta seconde question, oui je te confirme que je lis assidument LWN. J'essaye déjà de mettre le maximum de liens vers ce site dans mes dépêches noyau. Par exemple, sur les 4 liens principaux de la dépêche, les deux premiers pointent vers des articles LWN qui récapitulent les nouveautés.
      Dans le corps de la news il y a une dizaine d'autres liens vers des articles LWN pour ceux qui veulent approfondir un point.

      • [^] # Re: Méta-remarques

        Posté par . Évalué à  2 . Dernière modification : le 06/01/12 à 07:55

        Après tout l'original n'est qu'à un clic de souris non ?

        Ben oui, mais ça fait une différence pratique importante (en termes geek, le coût de context-switching est du même ordre de grandeur que le coût de lecture); je ne sais pas si les admins ont accès à des statistiques sur ces liens, mais je m'attends à ce que les annonces de RC originales soient très peu lues, alors qu'à priori une majorité des visiteurs les liraient en anglais sans problème si elles étaient plus mises en avant.

        Dans le corps de la news il y a une dizaine d'autres liens vers des articles LWN pour ceux qui veulent approfondir un point.

        Je pensais plus à quelque chose d'explicite, à la fin de l'article par exemples, "quelques bons articles sur LWN", avec des liens et une courte phrase expliquant le contenu et son intérêt. Ça permettrait de leur donner un statut un peu plus explicite, et de mentionner aussi des sujets qui ne sont pas directement en rapport avec le kernel (par exemple il y a quelques semaines il y avait eu un article intéressant sur les modèles mémoires faibles).

        Enfin peut-être qu'il vaudrait mieux faire des dépêches séparées "Best of LWN", mais je me disais que le surcoût à les mettre dans cette dépêche serait faible, par rapport à celui de faire un truc spécialement pour ça (et donc enrober, etc.).

    • [^] # Re: Méta-remarques

      Posté par . Évalué à  2 .

      J'aime bcp ton idée de double version !

      Il faudrait calculer au niveau du site lui-meme comment arriver à faire un contenu en plusieurs versions.

    • [^] # Re: Méta-remarques

      Posté par (page perso) . Évalué à  1 .

      Je trouve que la qualité de traduction des RC est moindre que les précédentes news sur le noyau. C'est moi ou y'a une raison (nouveau traducteur, manque de temps, autre) ?

      Sinon le reste est super bien, comme d'hab ;-)
      Merci.

      • [^] # Re: Méta-remarques

        Posté par (page perso) . Évalué à  4 .

        Depuis deux éditions ces mails de -RC sont maintenant traduits de façon collaborative dans l'espace de rédaction des dépêches : https://linuxfr.org/redaction

        Donc c'est peut-être le fait d'avoir plusieurs traducteurs différents qui provoque cette sensation de traduction disparate ?

  • # Ça chauffe !

    Posté par (page perso) . Évalué à  1 .

    Celui-ci, il a bien failli avoir la peau de mon portable (tout neuf) à la compile…

    C'est monté à 95° au plus fort de l'action, d'après lm_sensors.
    Chauds les noyaux !

    Et le pire, c'est que j'utilise cpufreq avec le bon governor («conservative»), avant c'était encore pire. Enfin pour les compiles, ça ne change rien, mais au moins ensuite, ça refroidit plus vite.

    processor : 3
    vendor_id : GenuineIntel
    cpu family : 6
    model : 42
    model name : Intel(R) Core(TM) i5-2520M CPU @ 2.50GHz
    stepping : 7
    cpu MHz : 800.000

    • [^] # Re: Ça chauffe !

      Posté par . Évalué à  3 .

      Possible (pas sûr, j'affirme rien) que le support acpi ne sont pas complet pour cette machine (soit dans le bios lui même, soit à cause du bios). Tu peux regarder alors du côté des astuces de type cpulimit : c'est très bourrin, pas élégant, mais ça fait ce qu'on lui demande de faire. Lance cpulimit (contre make, cc cc1plus, ldd, ...) avant la compilation, puis admire le résultat. La compilation sera forcément un peu plus longue, mais cela t'évitera un éventuel reboot violent pour cause de threshold exceeded

      Depuis que j'utilise cpulimit, le poil de mon portable est plus soyeux

      • [^] # Re: Ça chauffe !

        Posté par (page perso) . Évalué à  2 .

        J'ai lu quelque part (phoronix je crois) qu'il y avait des régressions dans les noyaux Linux depuis la 2.6.36 (ou .37). Ceci aboutit à une consommation plus élevée d'énergie, et donc probablement à une chauffe plus importante.
        À «vide» (idle), lm_sensors m'indique une température de départ de 35°, qui monte à 60° en 5mn. Au bout de 3 heures, je suis à 70° en idle.
        La moindre compilation de quelque secondes passe la machine à 75°/80°.

        Et tout ça en restant sur le core graphique SandyBridge et sans utiliser le chip nvidia externe (techno labellée «Optimus», utilisable sous Linux avec Bumblebee). Parce là, c'est l'incendie assuré :)

        Je lis fébrilement les changelogs des noyaux, mais il semble qu'il n'y a pas eu de nouveautés depuis longtemps dans l'optimisation énergétique.

        Je n'ai pas trop envie de brider mon cpu avec cpulimit ou autre.
        Par exemple avec cpufreq, je pourrais imposer une limite haute pour le stepping de fréquences qu'il réalise selon l'activité. Je l'ai fait d'ailleurs, mais ça n'a pas changé grand chose. En plus des problèmes d'économie d'énergie, je pense qu'il y a des problèmes de dissipation physiques qui interviendraient quels que soit l'OS.

        En écrivant ça, je me rends compte que j'ai oublié de remettre cpufreq dans mon nouveau noyau. Pourtant je suis passé d'un noyau 3.1.3, en récupérant le .config et en faisant un «make oldconfig».
        Et là, ça fait 2 heures que ça tourne, sans limitation des fréquences (les deux cœurs sont à 2.5ghz depuis 2 heures au lieu des 800mhz habituels en idle).
        La température interne est de 60°, soit un léger mieux par rapport à l'ancien noyau avec cpufreq. La température extérieure est de 20°, le commandant vous souhaite une agréable recompilation.

        Autre bonne nouvelle, le support de l'hibernation par le noyau (sans patche TuxOnIce) a été beaucoup amélioré pour la restauration de l'image mémoire stockée sur la swap (presque deux fois plus rapide).

        Merci pour tes infos en tout cas.

        • [^] # Re: Ça chauffe !

          Posté par . Évalué à  2 . Dernière modification : le 06/01/12 à 11:33

          Le problème vient clairement de ton portable neuf.
          60°C ou 70°C en idle, franchement...

          Une petite vérification (tourne-t-il? air expulsé tiède ou brûlant? fait-il bien contact avec le CPU? etc...) du ventirad serait de bon aloi!

          En attendant de trouver une solution HW, tu peux passer le governor en powersave.
          De manière générale, ondemand est mieux que conservative.

        • [^] # Re: Ça chauffe !

          Posté par (page perso) . Évalué à  2 .

          Je lis fébrilement les changelogs des noyaux, mais il semble qu'il n'y a pas eu de nouveautés depuis longtemps dans l'optimisation énergétique.

          Tu pourras le lire dans le changelog du 3.3 : http://linuxfr.org/news/une-solution-au-probl%C3%A8me-de-consommation-du-noyau-linux

          « Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » Raymond Devos

  • # mon petit soulier est content

    Posté par (page perso) . Évalué à  2 .

    Merci petit patpat noël pour cette nouvelle dépêche sur le noyau, toujours aussi bien :-)

  • # Ext4 bouge encore

    Posté par . Évalué à  9 .

    Rappelons Hans Reiser!

  • # Typo de traduction

    Posté par . Évalué à  2 .

    Dans la traduction d'un extrait de mail de Linus sur Bull Mountain, "Citrix" doit être remplacé par "cyrix"

  • # Commentaire supprimé

    Posté par . Évalué à  0 . Dernière modification : le 11/01/12 à 08:32

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

Suivre le flux des commentaires

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