La sortie de la version stable 3.14 du noyau Linux vient d’être annoncée par Linus Torvalds. Le nouveau noyau est, comme d’habitude, téléchargeable sur les serveurs du site kernel.org. Le détail des évolutions, nouveautés et prévisions est dans la seconde partie de la dépêche.
Bon, ça c’est fait ! 
Mais Linus vous réserve bien d’autres nouveautés… :)
Sommaire
- La phase de test
- Les nouveautés
- Divers
- Le bilan en chiffres
- Appel aux volontaires
La phase de test
RC-1
La version RC-1 est sortie le 2 février 2014.
Eh, c’était une fenêtre ordinaire de fusion sur quinze jours, qui est maintenant terminée. Autant que je sache, j’ai intégré tout ce qui m’a été demandé (à une exception près, voir plus loin) et j’ai appliqué tous les correctifs que je devais appliquer. Si vous pensez que j’ai oublié votre travail, cela pourrait être à cause d’un courriel pris pour un pourriel (cela est arrivé plusieurs fois récemment, mais je pense que je les ai tous) ou d’une simple incompétence de ma part (cela arrive aussi).
J’ai conscience que le nombre 3,14 semble familier pour certains, et j’ai eu des demandes de nommage en rapport avec cela. Mais ce n’est tout simplement pas comme cela que fonctionne le nommage du noyau. Vous pouvez vous consoler avec le fait que le nom ne s’affiche pas partout, et que personne n’y porte un réel intérêt. Ainsi, n’importe quel nom en lien avec π que vous pourriez concevoir, serait tout aussi pertinent que celui dans le Makefile principal, donc ne soyez pas déprimé.
Par ailleurs, n’importe quel geek qui se respecte connait vingt décimales de π depuis qu’il est un jeune con. Donc, 3,14 n’est vraiment pas si proche, n’est‐ce pas ?
Qu’importe, la demande d’intégration manquante est l’appel système rename2() que je pensais devoir regarder par moi‐même, et pour laquelle j’espérais aussi plus de commentaires (je suis en train de te regarder, Al). Bref, j’ai senti que je n’avais pas le débit mental suffisant pour m’en occuper pendant cette fenêtre de fusion, mais je prendrai le temps de regarder ça tranquillement cette semaine. Je pourrais toujours l’intégrer avec la RC-2, mais franchement, c’est plus que probable que ça attende la 3.15.
Autre chose ? Le truc que j’ai vraiment fusionné ? C’était une fenêtre de fusion ordinaire, rien ne sort du lot. Les statistiques font apparaître le très traditionnel deux tiers pour les pilotes, le reste concernant un mélange de mises à jour des architectures (ARM domine, mais il y a du PowerPC, X86, MIPS, s390, et même du IA-64 avec de la suppression de code obsolète dans Xen) et du tout‐venant : cœur du noyau, gm (NDT : gestion de la mémoire), réseau, outillage, etc.
J’ai joint mon journal de fusion, vu que comme d’habitude la version courte du journal est bien trop longue. Et, encore une fois, notez que mon journal de fusion ne donne que les noms des mainteneurs, pas les noms de ceux qui ont effectivement codé. Il faut lire les journaux complets de Git pour avoir ce niveau de détail.
Linus
RC-2
La version RC-2 est sortie le 9 février 2014.
Ça a été plutôt calme, en fait, ce qui devrait me rendre heureux. Mais je suis de nature méfiante, et je vais attendre de voir si la situation empire et si les gens sont juste en train de me bercer d’un faux sentiment de sécurité. Parce que je connais les développeurs du noyau, et ils sont sournois. Je soupçonne que Davem (pour prendre quelqu’un, pas au hasard) est en train de rire nerveusement, attendant ce message, planifiant de m’envoyer demain des demandes d’intégration de gros porc.
Parce que les gars, vous êtes de ce genre‐là.
Qu’importe, le peu de nouveautés semble normal : à peu près deux tiers de pilotes (pilotes graphiques, pilotes en mode bloc, média et divers), avec presque la moitié des correctifs restants pour la mise à jour des architectures (x86, s390 et ARM64). Le reste concerne les systèmes de fichiers (VFS, NFS, OCFS, Btrfs et quelques corrections de kernfs), quelques trucs sur la gestion de la mémoire et de l’outillage (performance).
La version courte du journal est jointe, ce qui n’arrive pas à chaque RC2.
Linus
RC-3
La version RC-3 est sortie le 16 février 2014.
Quand j’ai annoncé la RC-2, j’ai mentionné combien elle était plaisante et petite. J’ai également noté que je ne vous faisais pas confiance et que je soupçonnais que certains d’entre vous gloussaient dans leur coin en retardant leurs demandes d’intégration, diaboliques petites créatures que vous êtes.
Et je déteste avoir raison. La RC-2 était assez légère, mais la RC-3 la contrebalance. J’ai tranquillement pris toutes les demandes d’intégration parce que cela n’était clairement pas une surprise, mais je vous avertis que je vais commencer à maudire des gens, si cette tendance se maintenait. Vous avez été prévenus.
Quoi qu’il en soit, parce que la version courte du journal est assez lourde, je présente les grandes lignes de mon journal de fusion ici, et je posterai sa version courte séparément en réponse à ce courriel, pour ceux qui veulent plus de détails. L’essentiel des modifications concerne le réseau et divers pilotes (réseau, de la branche staging, USB, pilote en mode bloc, InfiniBand…), mais il y a quelques mises à jour d’architecture (PowerPC, ARM, x86) et quelques mises à jour de la documentation.
Linus
RC-4
La version RC4 est sortie le 23 février 2014.
Bon, tout semble normal, et la RC-4 est plus légère que la RC-3, je suis donc heureux.
Le plus gros changement inclus (représentant environ un sixième de la taille) est seulement dû à la ré‐indentation d’un fichier ReiserFS effectuée par DaveJ. En ignorant ce nettoyage d’espaces, il ne reste que le lot habituel de mises à jour de pilotes, des couches réseau et de quelques architectures.
Rien d’énorme, ni de particulièrement effrayant.
Alors prenez‐la, et testez‐la complètement.
Linus
RC-5
La version RC5 est sortie le 2 mars 2014.
Une autre semaine, une autre RC.
Les choses ont été tout à fait calmes, et tout à fait normales. Les pilotes représentent un peu moins de 60 % des changements (le son est prédominant du fait de deux changements qui sont plus importants mais triviaux, mais il y a divers changements ponctuels partout). Le reste vient pour la plupart des mises à jour d’architectures (principalement PowerPC et Xtensa), et puis il y a une poignée de petites choses ailleurs.
Pas beaucoup. C’est exactement ce que j’aime.
Allez vérifier que tout fonctionne pour vous.
Linus
RC-6
La version RC6 est sortie le 10 mars 2014.
Nous nous approchons de la fin du cycle de RC et je dois admettre que j’aurais préféré un parcours moins chaotique.
Il n’y a pas eu d’énormes problèmes, mais il y a eu pas mal de petits heurts qui n’auraient jamais dû arriver si tard dans le cycle de sortie. Et la RC-6 est également sensiblement plus grosse que ne l’était la RC-5.
Donc, j’espère réellement que la semaine à venir sera plus calme, car sinon je devrai faire une RC-8 voire une RC-9…
Cela dit, il n’y a rien de fondamentalement inquiétant jusqu’ici. De petites erreurs idiotes et quelques malheureux retours arrières tardifs de commits, mais le gros reste des corrections triviales. Donc, je reste raisonnablement optimiste.
Linus
RC-7
La version RC7 est sortie le 16 mars 2014.
Une semaine peut vraiment faire la différence. En mieux. Il y a une semaine, en récoltant la RC-6, j’étais mécontent : il y avait trop de correctifs épars et j’augurais une RC-8, voire une RC-9, comme une réelle éventualité.
Mais maintenant, une semaine s’est écoulée, et la RC-7 semble beaucoup plus satisfaisante. Bon, il y a encore des choses imprévisibles un peu partout (les plus grosses contributions concernent le réseau, à la fois dans le cœur et les pilotes), mais c’est beaucoup plus petit que pour la RC-6, et il n’y a rien qui m’incommode. Quasiment tous les changements sont petits, et je pense que le changement qui retire la vieille et inutile option
x86 Centaur OOSTOREest probablement le plus gros d’entre eux. Le seul autre changement qui pourrait rivaliser en taille supprime du code lui aussi (« r8152 : désactiver le mode ECM »).Maintenant, les choses peuvent encore changer, et peut‐être que la prochaine semaine se terminera comme une semaine horrible, mais avec un peu de chance cela n’arrivera pas et c’est la dernière RC.
Allez-y, testez. Tout ça a l’air bon.
Linus
RC-8
La version RC8 est sortie le 24 mars 2014.
J’avais pris un délai d’un jour sur mon calendrier habituel, espérant être plus à l’aise pour sortir cette version 3.14, mais cela n’a pas été le cas. Donc, voici une RC-8, et j’espère faire la dernière version le week‐end prochain.
Il n’y avait pas tant de choses effrayantes en cours, mais il y a quelques correctifs VFS en attente, et nous avons fini par avoir quelques correctifs intéressants sur le code principal la semaine dernière (pas de nouvelles régressions, sauf celles récemment découvertes par Trinity. Félicitations à Hug Dickins pour les avoir comprises et en avoir corrigé les causes). Il y a aussi quelques correctifs réseau et des correctifs épars (principalement MIPS). Je souhaitais vraiment, par conséquent, une autre semaine avant de tout livrer.
Linus
Version finale
La version finale est sortie le 30 mars 2014.
Bon, nous avons eu quelques changements tardifs dont j’aurais pu me passer, mais la liste des changements depuis la RC-8 est assez petite, et je le sens bien tout ça. Si nous avions rencontré quelques problèmes de dernière minute à cause du sursaut de contribution final, ces corrictifs seraient très spécifiques et je n’ai donc pas vraiment de raison de retarder la publication sans rien avoir en suspens. La majorité de ce sursaut final concerne des régressions marquées comme candidates pour les branches stables ou pour des régressions connues.
Donc, la 3.14 est là et la fenêtre d’incorporation pour la 3.15 est ouverte. Veuillez, s’il vous plaît, prendre le temps de tester cette 3.14, même si vous êtes pressés de me faire parvenir votre file d’attente pour la prochaine version.
Linus
Les nouveautés
Arch
CPU
Multi‐processeurs Xtensa
Le processeur Xtensa reçoit la gestion multi‐processeurs SMP (Symetric Multi‐Processors).
Xtensa est le processeur configurable et extensible de Tensilica, racheté en 2013 par Cadence Design Systems, basé sur une architecture 32 bits de type RISC.
Connu pour sa grande personnalisation et sa modularité, il permet par exemple de choisir le « boutisme », la largeur du bus de données, l’ajout d’unités de calcul en virgule flottante supplémentaires, etc.
Co‐processeurs cryptographiques AMD
L’AMD CCP (Cryptographic Coprocessor) est maintenant pris en charge par Linux 3.14. Un co‐processeur est un circuit intégré couplé au processeur central qui permet de lui ajouter un support matériel dédié pour une tâche donnée (il en existe plein, comme par exemple des co‐processeurs arithmétiques ou vectoriels).
Selon les sources, ce CCP pourrait être embarqué dans le ARM cortex-A15 de leur futur système monopuce Opteron. Il permettrait en outre de gérer les algorithmes de chiffrement AES, AES-CMAC, XTS-AES et les fonctions de hachage SHA directement en matériel.
MIPS interAptiv et proAptiv
L’équipe MIPS nous propose la gestion des derniers processeurs de la marque, à savoir le MIPS interAptiv et le proAtiv.
MIPS fabrique principalement ses puces pour des appareils grand public, comme, par exemple, des lecteurs Blu‐ray de salons ou des télévisions numériques. On les retrouve également dans des terminaux bas de gamme de certains pays émergents.
L’interAptiv est la dernière génération de processeur à basse consommation multi‐cœur de MIPS. Il est doté de la technologie MIPS Multi‐Threading (MT), proche de la technologie hyper‐threading d’Intel. Le MT est une technologie employée dans les processeurs multi‐cœurs ces dernières années, afin que la topologie et la réalisation matérielle soit plus adaptées aux programmes disposant de plusieurs fils d’exécution, chose très répandue de nos jours. Cette technologie permet d’obtenir de meilleures performances pour les programmes qui sont correctement prévus à cet effet (ce qui n’est pas toujours le cas et peut entraîner des surprises, comme de la contention sur l’utilisation des unités de calcul partagées ou une mauvaise utilisation du cache). Ce processeur dispose également d’un protocole de cohérence de cache censé réduire et limiter les temps d’accès.
Le proAptic est le dernier processeur visant à concurrencer la société ARM sur la téléphonie mobile, les tablettes et peut‐être les télévisions connectées. Le constructeur annonce un noyau deux fois plus petit que l’ARM Cortex-A15, avec des performances similaires, voire plus élevées. Encore faut‐il que la performance soit au rendez‐vous…
ARM64 : gestion de l’allocateur mémoire CMA
Dans les ordinateurs de bureau contemporains les contrôleurs DMA (Direct Memory Access) doivent avoir accès à la mémoire principale afin de pouvoir y copier ou y lire de grosses quantités de données (requête préalablement demandée par le noyau). Ces derniers n’ont pas directement accès à la mémoire physique pour diverses raisons : les périphériques peuvent être bogués et corrompre la totalité de la mémoire du système, ou nécessiter de gros tampons de mémoire contiguë (ce qui n’est pas toujours possible dans la mémoire physique), etc.
Le lien entre la mémoire principale et ces périphériques est réalisé par le biais d’une IOMMU. Il s’agit d’une unité de gestion de la mémoire comme la MMU qui permet de faire correspondre une adresse virtuelle à une adresse physique, uniquement pour celles qui ont été enregistrées par le noyau.
De nos jours, les cartes embarquées étant de plus en plus petites, et pour certaines de moins en moins coûteuses, il est assez rare qu’elles soient munies d’IOMMU. Oui, mais, comment gérer l’obtention de tampons contigus dans la mémoire physique ? Doit‐on maintenir cette correspondance directement dans nos modules ? C’est la raison pour laquelle l’infrastructure CMA (Contiguous Memory Allocator) a été ajoutée au noyau il y a quelques années.
Il s’agit d’une boîte à outils qui permet de demander l’allocation de zones mémoire contiguës directement dans la mémoire physique (quand c’est possible) ou de respecter certaines conditions d’alignement, par exemple.
Les processeurs ARM 64 bits ont maintenant la possibilité d’utiliser cet allocateur mémoire.
Intel Merrifield
Le Merrifield, la dernière née des puces 64 bits mobile d’Intel annoncée à la Mobile World Congress 2014, est maintenant géré dans le noyau.
Comparé à la génération précédente, le Merrifield apporte de meilleures performances graphiques 2D, une fréquence d’horloge un peu plus élevée (6,5 %), il gère jusqu’à 4 Gio de mémoire vive LPDDR cadencée à 533 MHz et intégrera le processeur graphique Power VR Series 6.
Nouvelles plates‐formes ARM
De nouvelles plates‐formes à base de processeurs ARM font leur apparition :
HiSilicon intègre la gestion de sa première carte. Il s’agit d’un constructeur chinois créé par Huawei destiné à produire des systèmes monopuces (System on Chip) ARM.
Les plates‐formes embarquées EFM32 ARMv7-M sont gérées. EFM32 est une famille de microcontrôleurs basés sur ARM 32 bits et construits par Silicon Labs. Ces microcontrôleurs sont destinés à des solutions à très basse consommation énergétique. Ces principales caractéristiques sont : des temps de calcul très faibles, un temps de réveil (lors d’interruptions) très rapide et une très faible consommation.
Le Marvell Berlin, la puce à l’intérieur de la Google Chromecast, dispose d’une prise en charge officielle.
La plate‐forme industrielle Moxa ARM est gérée dans cette version 3.14.
Le Freescale i.MX50 est officiellement géré.
Allocateurs mémoire et classes d’allocations
ARM : protection des classes d’allocations des modules
Les plates‐formes disposant d’un processeur ARM peuvent configurer le noyau afin que les classes d’allocations des modules disposent de droits différents. Les classes d’allocations sont des zones mémoires disjointes dans lesquelles les données et le code sont disposés par le système au moment du chargement d’un programme ou d’un module. L’idée principale est de séparer les données entre elles en fonction de l’utilisation dont va en faire l’entité logicielle concernée, mais aussi de séparer le code de celle‐ci. Ceci est fait à la fois pour respecter une sémantique d’utilisation, mais aussi pour des raisons de sécurité. Il serait en effet regrettable de pouvoir exécuter une zone de données, comme le tas ou la pile (exploitable en cas de dépassement de tampons, par exemple) ou de pouvoir modifier la zone mémoire dans laquelle se trouve le code.
À partir de la version 3.14, les plates‐formes ARM pourront demander au système que les zones de code des modules, ou celles censées être en lecture seule, ne soient pas modifiables. Elles auront également la possibilité de restreindre l’exécution de certaines classes d’allocations.
Ordonnancement
La classe d’ordonnancement SCHED_DEADLINE est l’une des grandes nouveautés de cette version. Il s’agit d’une politique d’ordonnancement temps réel basée sur l’algorithme Earliest deadline first (EDF) — la prochaine échéance en premier.
Les processus doivent fournir trois paramètres à l’ordonnanceur : une limite temporelle au‐delà de laquelle il ne faut pas aller pour que la tâche soit accomplie, une période spécifiant la fréquence à laquelle elle doit être exécutée et un temps processeur maximum à ne pas dépasser lors de l’exécution de cette tâche (sa durée maximale). Les processus sont ensuite placés dans une file de priorité, ainsi, à chaque fois que l’ordonnanceur reprend la main (préemption ou coopération en rendant la main à ce dernier lors d’une action bloquante, par exemple), il exécute la tâche dont la limite d’exécution est la plus proche.
Les ordonnanceurs deadline sont très utiles pour les tâches en temps réel ou pour les tâches périodiques multimédias.
Développement, déboguage et outils
perf
L’une des grandes nouveautés de perf est l’ajout de la prise en charge du compteur de consommation énergétique d’Intel, RAPL.
RAPL (Running Average Power Limit) est une fonctionnalité matérielle introduite lors de la sortie des processeurs de la famille Sandy Bridge qui permet de surveiller, contrôler et collecter des informations concernant la consommation énergétique des systèmes monopuces (System on Chip) d’un ordinateur. Les développeurs du noyau pourront donc savoir précisément quels sont les composants matériels les plus sollicités énergétiquement en fonction des modifications qu’ils effectueront. Plus d’informations sur RAPL sont disponibles dans la dépêche de sortie de Linux 3.13.
L’utilitaire en espace utilisateur bénéficie également de nombreuses améliorations et nouvelles fonctionnalités. Pour plus de détails, veuillez consulter la requête de fusion d’Ingo Molnar.
Pour mémoire, perf est un outil de profilage dans Linux qui permet de superviser facilement les compteurs de performance. Les compteurs de performance sont des registres spéciaux dans le processeur qui permettent de compter les événements matériels qui ont lieu lorsque vous exécutez du code : le nombre de défauts de cache, le nombre d’instructions exécutées, les prédictions de branchements correctes ou incorrectes, etc.
kexec
kexec est désormais compatible avec les systèmes disposant d’EFI. Actuellement, ceci n’était fonctionnel qu’à partir d’un BIOS.
L’architecture M68k bénéficie également d’une prise en charge préliminaire de kexec.
kexec (kernel execution) est une fonctionnalité au sein de Linux qui permet de démarrer à chaud un nouveau noyau en écrasant l’espace d’adressage du noyau en cours d’exécution.
Cette procédure permet d’éviter les phases d’initialisation matérielle faites par le micro‐logiciel BIOS ou UEFI, ainsi que le chargeur de démarrage, réalisées au lancement de votre ordinateur. Ceci permet donc de gagner un temps considérable lorsque vous souhaitez mettre à jour votre noyau ou lorsqu’un développeur réalise des changements dans un composant central du noyau qui nécessitent un redémarrage.
smp_load_acquire() et smp_store_release()
Les barrières de synchronisation mémoire smp_load_acquire() et smp_store_release() ont été ajoutées. Voir cet article de LWN pour savoir quand elles sont nécessaires et comment les utiliser.
preempt_enable_no_resched()
preempt_enable_no_resched() est une fonction qui permet de réactiver le mode préemptif de l’ordonnanceur du noyau, préalablement désactivé, tout en demandant à ce dernier de ne pas interrompre la tâche courante immédiatement.
Cette fonction n’est plus disponible pour les modules, car elle est jugée trop dangereuse et mal utilisée par les développeurs de l’ordonnanceur du noyau qui considèrent que les modules ne devraient pas faire preuve de créativité à ce niveau‐là. Pour plus d’informations, veuillez consulter ce fil de discussion.
Pilotes graphiques libres
DRM (Direct Rendering Manager)
Peu de nouveautés pour DRM, si ce n’est une amélioration de la gestion des hotodatages et un peu de nettoyage de code.
Voir la demande d’intégration.
TTM (allocateur mémoire graphique)
La principale nouveauté de TTM devait être une augmentation des performances processeur lors de l’allocation de pages mémoire partagées, grâce à l’utilisation du drapeau VM_PFNMAP au lieu de VM_MIXEDMAP (commit). Cependant, durant le cycle des RC, un problème de performance a été trouvé dans certains cas (utilisation combinée de VM_PFNMAP, x86 PAT et du write-combining). Le correctif initial a donc été enlevé en attendant de mieux investiguer le problème (commit).
TTM se voit aussi recevoir une amélioration liée au partage de tampons graphiques entre différentes cartes graphiques (DMA-buf). TTM ne générera plus de fautes de page sur les pages importées par DMA-buf (commit).
Voir la demande d’intégration.
Adreno (pilote msm)
La principale nouveauté du pilote graphique msm est la prise en charge des Adreno 330. Cette prise en charge a nécessité de retravailler l’architecture du pilote du bloc d’affichage qui est passé de sa version 4 à 5. Comme ces blocs sont similaires, du code a été factorisé.
Le pilote msm peut maintenant fonctionner sur des systèmes ne disposant pas d’IOMMU. Dans ces cas‐là, le pilote réservera dans la mémoire centrale une zone qui sera dédiée aux rendus graphiques grâce au Contiguous Memory Allocator (CMA). La taille de cette zone mémoire est configurable grâce au paramètre noyau msm.vram. Pour des raisons de sécurité, le pilote refuse encore de se charger si aucune MMU n’est disponible, afin d’empêcher le processeur graphique d’accéder aux adresses qui ne lui sont pas réservées. Il semblerait que cette restriction puisse être levée dans le futur car le processeur graphique aurait un moyen matériel de limiter les adresses auxquelles les clients graphiques peuvent accéder.
La gestion de COMPILE_TEST fait également son entrée. Cette gestion permet de forcer la compilation du pilote, même quand on n’est pas sur une architecture gérée par msm. Cela permet de tester la compilation depuis une autre plate‐forme.
Pour finir, les systèmes monopuces APQ8060A (processeur double cœur + processeur graphique Adreno 320) sont désormais pris en charge.
Voir la demande d’intégration.
AMD/ATI (pilote radeon)
La prise en charge du DPM (Dynamic Power Management) a été ajoutée pour la famille de carte Sea Islands / CIK, ce qui devrait permettre de réduire la consommation énergétique et la température sur les cartes qui l’embarquent.
Toujours dans la famille Sea Islands, la prise en charge de l’UVD (décodage vidéo matériel) a été de nouveau ajoutée. Il semblerait que sa prise en charge ait été accidentellement supprimée il y a un an, lors de la fusion de la gestion de l’UVD dans le noyau (commit).
Dans la famille Volcanic Islands, la puce Hawaii vient de recevoir des microcodes, ce qui devrait permettre d’activer l’accélération 2D, 3D et vidéo.
Une modification tardive sur la partie gérant l’envoi de commandes a permis d’activer la prise charge des geometry shaders (GS) sur les cartes des r600 et r700. Cela permet donc à radeon d’assurer une prise charge d’OpenGL 3.2 et 3.3 sur ces cartes !
Rashika Kheria, du Programme de sensibilisation pour les femmes (Outreach Program for Women), a également écrit plusieurs correctifs pour résoudre des alertes dans le pilote, afin de pouvoir activer un niveau de débogage plus élevé dans GCC lors de la compilation du noyau (plus d’informations).
Le pilote a également reçu plusieurs corrections de bogues et légères améliorations. Voir la demande d’intégration pour plus d’informations.
Intel (pilote i915)
La gestion des processeurs graphiques Broadwell est maintenant considérée comme stable et ne nécessitera plus d’options de compilation particulières. La gestion des processeurs Baytrail s’est aussi améliorée, notamment sur l’affichage (branchement à chaud du VGA).
La deuxième grande nouveauté est que la gestion des modes d’affichage en espace utilisateur (User‐space Mode-Setting — UMS) est maintenant dépréciée en faveur de gestion des modes d’affichage par le noyau (Kernel‐based Mode-Setting — KMS). Le pilote Intel était le dernier à gérer officiellement l’UMS depuis que le pilote Radeon a décidé de déprécier sa gestion en janvier 2013. La prise en charge de l’UMS devrait être définitivement retirée dans le noyau 3.16.
Dans la même veine de suppression des vieilles interfaces, il est maintenant possible de compiler le pilote i915 sans prise en charge de fbdev. Ce n’est pas une bonne idée pour la plupart des utilisateurs de bureau, car certaines applications telles que l’écran de chargement Plymouth en dépendent. En revanche, cela permet à certaines plates‐formes embarquées de réduire le volume de code compilé. Dans le futur, nous pouvons penser qu’il sera possible d’utiliser des applications telles que kmscon, de façon à rendre totalement obsolète l’interface fbdev.
Côté sécurité, la gestion du PPGTT (Per-Process Graphics Translation Table) s’améliore, mais quelques régressions de dernière minute ont empêché l’ajout des dernières parties nécessaires pour sa gestion complète. Espérons que la prochaine version apportera une gestion fonctionnelle et permettra d’isoler chaque processus dans un espace d’adressage différent !
La partie noyau de gestion de l’extension OpenGL GL_ARB_robustness vient également d’être intégrée. Le rôle de cette extension OpenGL est de permettre aux applications de réagir à la perte de leur contexte graphique, dans le cas où le matériel aurait planté ou été mis en pause (Optimus).
Le reste des modifications concerne la gestion de l’affichage et sa gestion d’énergie. Pour plus d’informations, vous pouvez consulter l’article de blog de Daniel Vetter, mainteneur du i915.
NVIDIA (pilote nouveau)
La gestion initiale de l’accélération pour les processeurs graphiques GK110 et GK208 (NVF0 et NV108) fait son apparition dans le noyau 3.14 grâce à Ben Skeggs. Cette gestion est incomplète car elle requiert aussi des modifications dans le pilote nvc0 de Mesa 3D, à cause du changement d’architecture de processeur (ISA). Elle est cependant suffisante pour faire tourner GNOME Shell. Ilia Mirkin a corrigé une bonne partie des problèmes de génération d’instructions dans Mesa 3D. Ces modifications devraient être disponibles dans la version 10.2.
La gestion de l’affichage des erreurs a également été améliorée par Ilia et Ben, afin de mieux pouvoir diagnostiquer les problèmes remontés par la carte.
En parlant d’affichage, la gestion des superpositions vidéo (video overlays) pour les puces graphiques NV10 à NV40 vient d’être dévoilée par Ilia, grâce à l’interface de plans d’affichage KMS (KMS planes). Il faudra des modifications dans xf86-video-nouveau pour que les applications en espace utilisateur puissent l’exploiter.
Le travail de fond pour la gestion d’énergie continue, mais rien n’a encore été soumis.
Voir la demande d’intégration.
OMAP (pilote omap)
Peu de nouveautés du côté du pilote OMAP, qui ajoute la gestion du Device Tree pour le bloc TI DMM (Dynamic Memory Manager). Le reste des modifications corrige des bogues au démontage à chaud du pilote omap.
Voir la demande d’intégration.
Renesas R-Car DU (pilote rcar-du)
La principale nouveauté du pilote Renesas rcar-du est l’ajout de la prise en charge du R8A7791 DU qui est une version allégée du R8A7790 DU avec uniquement deux contrôleurs vidéo (CRTC), gérant donc deux écrans maximum, et une unique sortie LVDS (liaison habituelle pour les écrans d’ordinateurs portables). Le reste des modifications se limite à l’aspect cosmétique du code et à la correction de bogues matériels, avec l’ajout de rustines pour la sélection des voies LVDS.
Voir la demande d’intégration.
Tegra (pilotes host1x et tegra)
Cette nouvelle version du pilote host1x apporte une gestion initiale des systèmes monopuces basés sur le Tegra124.
Le pilote DRM tegra se voit aussi recevoir une gestion partielle de Prime, ce qui va permettre au Tegra (le processeur graphique) d’afficher les images calculées à l’écran grâce à host1x sans faire de copies.
Il est également maintenant possible de désactiver la gestion de fbdev à la compilation, même s’il sera compilé par défaut. Les motivations pour ce travail doivent être les mêmes que pour Intel.
Le reste des changements apportés est lié à host1x et au contrôleur d’affichage. Plus d’écrans sont gérés, et l’utilisation de l’interface HDMI est plus économe en énergie.
Voir la demande d’intégration.
VMware (pilote vmwgfx)
Pas de changement visible pour le pilote vmwgfx dans cette version. Le travail a uniquement consisté en l’écriture de la gestion pour l’allocation de ressources graphiques en utilisant la mémoire de la machine virtuelle. Ces ressources sont les contextes graphiques, les textures et les shaders.
Cette gestion permettra l’implémentation des pilotes pour la version 11 de la carte graphique virtuelle SVGA2. Maintenant que les modifications sont disponibles dans le noyau, des correctifs pour Mesa 3D devraient bientôt arriver pour gérer l’allocation locale de mémoire.
Voir la demande d’intégration.
Réseau
Adresses IPv6 temporaires en espace utilisateur
En IPv6, l’auto‐configuration des adresses est la règle par défaut. Cela a conduit à une gestion des adresses en espace noyau : à la réception d’une annonce de routeur, le noyau se charge d’attribuer une adresse globale statique dérivée de l’adresse MAC, et une adresse aléatoire temporaire, si la variable sysctl use_tempaddr est au moins à 1.
C’est bien beau et pratique, mais des outils en espace utilisateur ont parfois envie de prendre la main. L’exemple le plus typique et le plus connu est probablement NetworkManager. Ces outils pouvaient déjà, bien entendu, ajouter ou supprimer des adresses, mais uniquement des adresses permanentes. Impossible d’ajouter une adresse considérée comme temporaire par le noyau. Il serait évidemment possible de mettre un minuteur pour supprimer l’adresse depuis l’espace utilisateur, mais cela n’aurait pas les mêmes effets (une adresse temporaire est marquée comme obsolète par le noyau et n’est pas supprimée directement après son expiration).
Un nouveau drapeau de configuration des adresses a donc été ajouté, permettant l’ajout d’une adresse temporaire depuis l’espace utilisateur. Cela permettra aux outils en espace utilisateur de prendre totalement la main sur la configuration IPv6, et permettra aussi d’ajouter plus tard les adresses temporaires obtenues par DHCPv6.
Pour l’anecdote, cette fonctionnalité a eu des conséquences sur ifconfig durant le cycle de développement. En effet, ifconfig lit le fichier /proc/net/if_inet6 pour déterminer les adresses assignées à une interface. L’ajout de l’information du drapeau « adresse temporaire » cassait cette lecture, et a donc été retirée (l’information reste lisible par l’interface netlink). C’est un bon rappel pour ceux utilisant encore les vieux outils : ifconfig et les outils associés sont obsolètes et ne renvoient que des informations incomplètes sur l’état réel de la configuration réseau. La bonne méthode est d’utiliser les outils apportés par iproute (cf. cet article).
Bouchon automatique sur TCP
Les développeurs noyau de Google sont très intéressés par les performances réseau du noyau Linux, en particulier du protocole TCP (par exemple avec RPS et RFS). Pour cette version, ils ont développé des « bouchons » automatiques sur une socket TCP.
Mais qu’est‐ce qu’un bouchon ? Le principe est ancien : une application peut depuis très longtemps mettre l’option TCP_CORK sur une socket, ce qui bloque l’envoi de petits paquets. Les écritures de l’application sur le socket sont alors placées dans une file d’attente, qui peut ensuite se vider dans deux situations :
- partiellement, si elle est suffisante pour envoyer une trame complète ;
- complètement, quand l’application enlève le bouchon en désactivant l’option.
L’intérêt est de gagner en performance : chaque paquet TCP étant coûteux, il est plus simple et potentiellement plus rapide d’envoyer un gros paquet qu’une dizaine de petits.
C’est bien beau, mais cette option demande une coopération fine de l’application. Tout repose sur elle, qui doit mettre le bouchon et l’enlever au bon moment. Éric Dumazet, développeur chez Google, propose donc d’optimiser tout ça automatiquement. À présent, quand le noyau reçoit de nouvelles données à mettre dans une socket TCP, il vérifie deux choses. La première est la taille du paquet. S’il est suffisamment grand, il est ajouté dans la queue à transmettre.
En revanche, si le paquet est trop petit, il se peut qu’il soit pertinent d’attendre un peu avant de le placer dans la queue. Le noyau regarde donc s’il y a des paquets déjà en attente d’envoi. Si c’est le cas, on peut attendre, la carte réseau a déjà du travail, cela ne retarde rien de ne pas mettre le paquet dans la pile immédiatement. Le paquet sera mis à la fin du vidage de la file.
Ce petit délai donne une chance de grouper plusieurs messages de l’application dans le même paquet. Ce qui ressemble à une petite optimisation permet des gains de performance inattendus dans certains cas, à la fois en termes de débit utile et de temps processeur utilisé.
Pour désactiver cette fonctionnalité, une nouvelle variable sysctl existe : /proc/sys/net/ipv4/tcp_autocorking. On peut aussi s’amuser à compter les paquets bouchonnés avec netstat -a | grep TcpExtTCPAutoCorking. Le bouchon manuel est, quant à lui, toujours disponible pour les applications capables d’anticiper leurs besoins.
Petites nouvelles de nftables
nftables, ou le nouveau pare‐feu sous Linux, a été intégré dans le précédent noyau 3.13. Cette version contient donc logiquement de nombreuses corrections, suite aux retours des nouveaux utilisateurs.
Dans les fonctionnalités, on notera l’apparition d’une nouvelle table inet, permettant d’ajouter des règles pour IPv4 et IPv6 simultanément. Pratique pour la cohérence des règles sur les deux protocoles, notamment celles qui concernent des ports à ouvrir pour TCP et UDP. De quoi simplifier la vie des administrateurs, obligés de jongler entre iptables et ip6tables, ou d’utiliser un outil de haut niveau pour générer les règles.
Du débogage pour BPF
Le Berkeley Packet Filter est régulièrement cité dans les dépêches noyau, par exemple, pour la version 3.0. Pour rappel, il permet aux applications analysant le réseau de ne pas capturer l’ensemble des paquets, mais seulement une partie, que le noyau se charge de trier en fonction de règles définies par l’application.
Les développeurs de ces applications seront heureux de découvrir un débogueur permettant de simplement vérifier l’exécution du filtre avant de réellement l’exécuter. Pour utiliser ce débogueur, il existe un programme bpf_dbg prêt à l’utilisation, dans le dossier tools/net des sources du noyau.
Toujours dans ce dossier, le nouvel outil bpf_asm permet de compiler de l’assembleur BPF en espace utilisateur pour l’insérer ensuite directement dans le noyau. Cela est normalement réservé à des usages très particuliers pour des développeurs ne pouvant pas utiliser la bibliothèque libpcap. Soit parce qu’elle manque de fonctionnalités, soit parce qu’elle ne peut être intégrée sur le système, soit parce que le développeur veut utiliser le compilateur JIT (décrit dans la dépêche noyau 3.0), etc.
Une fois n’est pas coutume, la série de correctifs contient aussi une mise à jour de la documentation de BPF.
Systèmes de fichiers
ext4
Rien de bien croustillant pour le système de fichiers ext4 cette fois‐ci. Correction d’une régression dans bigalloc, activation par défaut de la fonction punch hole — toujours pour bigalloc — et aussi quelques autres mises à jour diverses et éparses pour un total de neuf commits. Pour plus de détails sur les changements d’ext4, voir ici.
Btrfs
Bien que les changements apportés à ext4 et XFS ne soient pas extraordinaires, le système de fichiers Btrfs avance à grands pas.
Chris Mason a écrit dans sa demande d’intégration : « C’est un gros morceau : la plupart de ces changements sont dans btrfs-next depuis très longtemps. »
Changements majeurs :
- ajout des propriétés des nœuds d’index (inodes) (Filipe David Borba Manana) ;
- exportation des infos du système de fichiers dans sysfs (Jeff Mahoney) ;
- énormément d’améliorations de performance.
[Adapté d’un article de Phoronix]
F2FS
F2FS, Flash‐Friendly File System, un système de fichiers écrit spécifiquement pour les mémoires Flash NAND, continue son évolution. Celui‐ci est écrit et maintenu par Kim Jaegeuk, employé par Samsung, et vise à fournir une meilleure prise en charge des matériels tels que les cartes SD ou autres disques durs SSD. Dans cette dernière fournée, F2FS se voit ajouter de nouvelles options afin de modifier son comportement durant l’exécution : small_discards, max_victim_search et in-place-update. Les performances en lecture‐écriture sont améliorées dans certaines situations et la gestion des données inline_data (amélioration du stockage des petits fichiers) est commencée. Comme souvent, ce fut aussi l’occasion de réaliser du nettoyage de code et de clore plusieurs rapports d’erreurs.
Voir la demande d’intégration.
kernfs
kernfs est une version plus générique de sysfs, afin que d’autres sous‐systèmes puissent l’utiliser pour créer leur propre système de fichiers virtuel. Ces sous‐systèmes bénéficieront ainsi facilement des attributs propres à sysfs (gestion de la déconnexion d’un périphérique, création et suppression d’entrées dynamiques…). sysfs a donc été modifié pour utiliser kernfs (commit), et le système de fichiers virtuel utilisé pour représenter les cgroups en espace utilisateur est en cours de conversion (commit). La conversion de debugfs est aussi prévue.
Attention à ne pas confondre avec le kernfs de NetBSD.
Pour rappel, sysfs est un système de fichiers virtuel introduit dans le noyau 2.5. Il permet de fournir à l’espace utilisateur des informations sur le matériel et ses pilotes. Plus concrètement parlant, sysfs permet de fournir une méthode générique de chargement à chaud (hot plug), un arbre de relation générique entre un matériel son unité logique (device tree), mais aussi de simplifier procfs. Cette mise à jour fut fournie par Patrick Mochel, puis corrigée par Maneesh Soni.
RBD
En parlant stockage, et bien qu’il ne s’agisse pas d’un système de fichiers, un problème de stabilité a été résolu dans le module RBD (le « périphérique de type bloc » des grappes de serveurs Ceph), qui pouvait provoquer une panique du noyau (kernel panic) à haut régime.
Sécurité
Audit
Le système d’audit change temporairement de code de retour d’erreur dans certains cas. Cela concerne principalement les utilisateurs de conteneurs qui devaient jusqu’à présent désactiver l’audit pour pouvoir ouvrir une session dans un conteneur (commit). Ce commit est un bidouille temporaire, un correctif propre sera proposé pour inclusion dans le 3.15 (bugzilla) à la suite des changements déjà implémentés dans le 3.13. Cet bidouille est similaire à celle déjà implémentée dans systemd-nspawn.
D’autres bogues liés à l’interaction d’audit avec les espaces de noms ont été corrigés (commit).
Chaque changement dans la configuration des éléments audités tracera les informations du processus l’ayant effectué (commit).
La taille du tampon de stockage temporaire des messages d’audit peut être illimitée (seulement limitée par la quantité de mémoire vive (commit).
Le journal généré lors d’un plantage et de la création d’un core dump contient le nom de l’exécutable qui a planté (commit).
Le code a été globalement retravaillé (commit).
Protection de la pile à la compilation par GCC (GCC stack protector)
La version 4.9 de du compilateur GCC gèrera l’option -fstack-protector-strong, qui se positionne entre -fstack-protector et -fstack-protector-all. Ces options activent la protection de la pile à l’aide de canaris, qui consiste à détecter et ainsi prévenir les effets néfastes des dépassements de tampon. Cette nouvelle option choisit plus judicieusement dans quels cas la protection est appliquée à une fonction. Cela évite d’avoir à choisir entre protéger toutes les fonctions (même celles pour lesquelles la protection n’est pas vraiment nécessaire) et ne protéger que très peu de fonctions (seulement 2,81 % avec -fstack-protector).
Kees Cook a ajouté la gestion de cette option dans le noyau Linux. Les détails sont sur son blog avec le document de travail pour l’implémentation dans GCC.
Intel Memory Protection Extensions (MPX)
Le noyau Linux 3.14 inclut les bases de l’infrastructure pour gérer l’extension matérielle MPX, pour l’instant spécifique aux futurs processeurs Intel. Les fonctionnalités, elles‐mêmes, seront incluses plus tard.
L’extension MPX vise à mieux protéger le système des vulnérabilités de type dépassement de tampon. Pour cela, des registres supplémentaires seront introduits pour stocker les valeurs maximales et minimales que peuvent prendre certains pointeurs. Lorsque l’un de ces pointeurs est déréférencé, l’adresse est comparée aux valeurs précédemment stockées dans les registres. Les accès en dehors de ces limites déclenchent une exception #BR (boundary range exceeded) qui peut ainsi être traitée soit par le noyau, soit par le programme en espace utilisateur.
À terme, la prise en charge devrait fonctionner pour les programmes en espace utilisateur ainsi que pour le noyau (la gestion pour l’hyperviseur KVM est prévue). Ces protections sont contrôlées séparément.
La prise en charge complète de MPX nécessite donc des changements dans les compilateurs. En outre, la protection n’est pas « tout ou rien », car un programme peut fonctionner même si seulement une partie du code est compilée pour MPX, et ce même code sera aussi fonctionnel sur les processeurs ne gérant pas l’extension.
kALSR
kASLR (kernel Address Space Layout Randomization (commit) consiste à rendre aléatoire l’adresse physique et l’adresse virtuelle à partir de laquelle est décompressé le noyau Linux lors de la phase de démarrage.
Ceci devrait rendre un peu plus difficile l’exploitation de vulnérabilités dans le noyau, puisqu’un attaquant ne pourra plus simplement utiliser une même adresse statique sur tous les systèmes vulnérables (et avec la même version du noyau). Il lui faudra au préalable récupérer une adresse mémoire d’un élément dans le noyau (memory infoleak) pour pouvoir calculer l’adresse de la structure ou fonction à utiliser dans une exploitation de vulnérabilité.
Comme cette étape se déroule très tôt au démarrage du système, les contraintes de placement en mémoire sont fortes et l’entropie disponible est faible. Il n’est donc possible d’utiliser que 9 bits d’entropie pour l’architecture AMD64 et 8 bits pour l’architecture x86.
Les développeurs du correctif grsecurity ont vivement critiqué cet ajout, car il n’apporte que très peu d’avantages en termes de sécurité. En effet, les vulnérabilités de type fuite d’information sont assez courantes dans le noyau Linux, et elles ne sont pas corrigées avec la même rapidité que les failles plus immédiatement critiques. Une explication détaillée est disponible sur le blog de grsecurity.
Note importante : l’hibernation n’est pour l’instant plus possible avec un noyau configuré avec kASLR (option RANDOMIZE_BASE).
Vérification des copies entre espaces utilisateur et noyau
Une première étape vers plus de vérification sur les copies entre espace utilisateur et espace noyau a été ajoutée sous forme de module noyau vérifiant les appels à copy_to/from_user (commit). Les erreurs à ce niveau sont justement souvent source de bogues ou de fuites d’information.
Trousseaux de clés
Plusieurs bogues dans la gestion des trousseaux de clés par le noyau ont été corrigés (1, 2).
LSM
SELinux
La politique SELinux stockée dans le noyau incorporera les informations nécessaires aux outils en espace utilisateur pour déterminer quelle contrainte a levé une interdiction (commit). Les contraintes SELinux sont un ensemble de règles d’une politique qui ont précédence sur toutes les autres règles. Elles sont vérifiées à l’exécution, d’où l’importance de ce correctif dans l’investigation des erreurs de ce type. Les contraintes sont particulièrement utilisées dans la politique de sécurité multi‐niveau (MLS).
Les étiquettes de sécurité (security labels) associées à des paquets IPsec seront vérifiées à la fois pour les paquets entrants (ce qui est fait actuellement) et les paquets sortants (commit). Il est en effet possible de marquer les paquets IPsec avec des étiquettes SELinux pour qu’elles soient interprétées par le destinataire. Le composant netfilter peut alors prendre des décisions de filtrage en fonction de ces étiquettes.
SMACK
Les exécutables ne peuvent plus être étiquetés avec « * » ou « @ », car les fichiers qu’ils créeraient ne disposeraient pas de restrictions suffisantes par (« * » signifie que tout le monde peut lire le fichier), ce qui est contraire aux principes du contrôle d’accès obligatoire — Mandatory Access Control, MAC — (commit).
Le contrôle du socket /dev/log était limité par défaut aux processus avec l’étiquette « _ ». Or, le système Tizen n’utilise cette étiquette que pour un nombre très limité de processus. Il fallait donc autoriser l’administrateur à définir une étiquette personnalisée chargée de la gestion de ce socket. La nouvelle valeur par défaut est « * », ce qui autorise l’accès par n’importe quelle étiquette. Pour restreindre à nouveau l’accès, il suffit d’écrire l’étiquette désirée dans smakfs/syslog (commit).
Les contrôles SMACK effectués lors du montage de systèmes de fichiers sans droits particuliers (utilisateurs autres que le super‐utilisateur root) étaient trop laxistes et pouvaient permettre à un processus d’effectuer des opérations nécessitant la capacité CAP_MAC_ADMIN en temps normal. Il n’est ainsi plus possible d’indiquer des options SMACK lors d’un montage non privilégié. Cette fonctionnalité sera potentiellement réactivée plus tard, si un modèle valide est trouvé pour gérer ce cas (commit).
Un autre petit changement corrigeant une vulnérabilité potentielle a été ajouté (commit).
Chiffrement
Ajout de versions de l’algorithme AESNI-GCM exploitant les jeux d’instructions AVX et AVX2 (commit) optimisant les opérations de chiffrement et de déchiffrement pour des blocs de données de grandes tailles. Les gains sont de 6, 11 et 18 % pour des blocs respectivement d’une taille de 1, 2 et 8 Kio, par rapport aux versions des ces algorithmes exploitant les instructions SSE. Les gains devraient être encore plus importants pour les futurs processeurs Intel.
Virtualisation
KVM
Du côté d’Intel, la virtualisation imbriquée (qui consiste à avoir les machines virtuelles qui exposent les instructions de virtualisation, ce qui permet d’avoir un hyperviseur en machine virtuelle sans problème de performance, très pratique pour tester une solution de virtualisation sur son portable) est corrigée, car elle n’était plus disponible depuis le noyau 3.13. Pour les architectures ARM, la supervision du contrôleur d’interruptions est désormais possible, ce qui permet la migration à chaud de machines virtuelles. Pour les ordinateurs centraux (mainframes) IBM (s390), il y a la prise en charge des transactions et de la « aptitude au paramètre de charge du programme pour les invités » (Load Program Parameter facility for guests), cette dernière est un prérequis pour avoir un compteur de performance matériel sur ces processeurs. Enfin, toujours chez IBM, l’architecture POWER accepte les invités « petit‐boutiste » et prend en charge des nouveautés des POWER 8.
Il y a eu deux demandes d’intégration concernant KVM auxquels vous pouvez vous référer pour plus d’informations : 1 et 2.
Xen
Cette version apporte deux nouveautés majeures dans Xen. Premièrement, l’extensibilité du canal des événements matériels (IRQ). Au lieu d’avoir une table à deux niveaux par processeur, il y a maintenant une file FIFO avec priorité, ce qui permet d’avoir une plus faible latence, de gérer plus d’événements et d’être plus extensible.
La deuxième fonctionnalité est le mode PVH ; pour ceux qui ne connaissent pas Xen, il y a plusieurs modes. Le premier est le mode paravirtualisé (PV), qui implique l’utilisation d’un noyau invité prévu pour fonctionner avec Xen, mais qui offre des fonctionnalités intéressantes comme des bonnes performances avec un processeur 32 bits ne prenant pas en charge les instructions de virtualisation ; et le fait de ne pas devoir émuler le matériel. L’autre mode est le mode Hardware Virtual Machine (HVM) qui virtualise classiquement le système et permet de faire tourner n’importe quel système d’exploitation.
Le mode paravirtualisé pose problème avec les invités 64 bits, car les appels système sont lents. Cela est dû au fait que sur 32 bits, Xen utilise la segmentation de la mémoire du processeur, mais comme cette fonctionnalité était utilisée par très peu d’applications, AMD l’a supprimée des instructions 64 bits, et Xen doit faire plus de travail de vérification pour éviter les failles. Pour résoudre ce problème, l’équipe a décidé d’utiliser l’infrastructure de virtualisation des processeurs pour la paravirualisation : ce mode hybride est le PVH. Il permet d’avoir des invités beaucoup plus réactifs en 64 bits, et beaucoup moins de code dans le noyau.
Pour plus d’information sur le PVH, vous pouvez regarder la vidéo (en anglais) de la conférence du FOSDEM : How we ported FreeBSD to PVH, et lire la demande d’intégration.
Divers
Pour ceux à qui cette dépêche aurait donné l’envie d’ouvrir le capot et mettre les mains dans le moteur, il n’est pas trop tard pour vous inscrire au Challenge Eudyptula. Le but est, petit à petit, d’amener les participants via des exercices progressifs à apprendre à utiliser les outils nécessaires et comprendre les règles du développement du noyau Linux.
L’Eudyptula Minor est le nom scientifique du manchot Pygmée bien connu des Linuxiens.
Le bilan en chiffres
En ce qui concerne les statistiques du cycle de développement du noyau 3.14, le site LWN.net a publié son traditionnel article récapitulatif et l’on peut également se reporter la page dédiée du site remword.com qui compile des statistiques relatives au développement de Linux.
Le nombre final de correctifs incorporés dans cette version est de 12 300, soit légèrement au‐dessus des 12 122 correctifs du noyau 3.13. Ces ajouts sont le résultat du travail d’environ 1 500 développeurs soit, là encore, une hausse notable par rapport aux 1 402 développeurs du noyau précédent.
C’est Intel qui occupe la tête du classement des entreprises, avec une marge assez confortable par rapport à Red Hat. Rappelons toutefois que la hiérarchie s’inverse complètement quand on examine les tags de type « _signoffs_ ». Ces tags sont employés par les mainteneurs pour marquer leur approbation d’un changement.
Dans ce rôle de gardien des portes du noyau, les développeurs employés par Red Hat représentent (selon LWN) 20 % des tags de type « signoffs », alors que les développeurs d’Intel ne sont qu’à 11,8 % et ceux de la Fondation Linux sont à 13,4 % (il s’agit essentiellement de Greg Kroah‐Hartman).
Appel aux volontaires
Cette dépêche est rédigée par plusieurs contributeurs dont voici la répartition :
| Mainteneur | Contributeur(s) | |
|---|---|---|
| La phase de test | aucun | Jarvis, Thomas Debesse |
| Arch | Romain Perier | |
| Pilotes graphiques libres | Martin Peres | |
| Réseau | Florent Fourcot | |
| Systèmes de fichiers | Jiehong (inactif) | Timothée Ravier |
| Sécurité | Timothée Ravier | |
| Virtualisation | Xavier Claude | |
| Édition générale | Martin Peres, Mali, Patrick_g |
Un peu de vocabulaire :
- Le mainteneur d’une section de la dépêche est responsable de l’organisation et du contenu de sa partie. Il s’engage également à l’être dans le temps, jusqu’à ce qu’il accepte de se faire remplacer.
- Un contributeur est une personne qui a participé à la rédaction d’une partie d’une section de la dépêche. Il n’y a aucune forme d’engagement pour le futur.
Malgré cette équipe importante, beaucoup de modifications n’ont pas pu être expliquées par manque de temps. Si vous aimez ces dépêches et suivez tout ou partie de l’évolution technique du noyau, veuillez contribuer dans votre domaine d’expertise. C’est un travail important et très gratifiant qui permet aussi de s’améliorer. Essayons d’augmenter la couverture sur les modifications du noyau !
Aller plus loin
- Noyaux précédents (436 clics)
- Site officiel du noyau Linux (484 clics)
- Le détail des nouveautés sur kernelnewbies.org (649 clics)
- Phoronix: Recapping The Top Changes Of The Linux 3.14 Kernel (240 clics)
# Merci aux mainteneurs et contributeurs
Posté par Omnisilver . Évalué à 10.
Je sais que ce commentaire est bateau, mais merci aux moules qui contribuent à cette dépêche si intéressante et détaillée, et qui comme chaque fois me fait rêver !
[^] # Re: Merci aux mainteneurs et contributeurs
Posté par Sten Spårvagnhög (site web personnel) . Évalué à 2.
C'est gentil de remercier claudex< et sidonie_tardieu<, mais je pense qu'on peut remercier tout autant les 23 autres contributeurs !
[^] # Re: Merci aux mainteneurs et contributeurs
Posté par Martin Peres (site web personnel) . Évalué à 8.
Il faut clairement remercier tout le monde, mais il est aussi important d'avoir une attribution des remerciements par parties!
L'écriture de la dépêche ne se fait pas uniquement à coup de traduction. Écrire une partie nécessite de suivre attentivement le développement de cette partie du noyau afin de pouvoir resituer tous les changements dans leur contexte et pouvoir expliquer quelque chose de cohérent. Ce travail de fond DOIT être remercié.
Tu remarqueras que depuis que ce système de contributeurs / mainteneur est mis en place, les dépêches sont plus longues et plus fournies. Ce n'est clairement pas grâce à moi que c'est le cas car je comprend peu de choses dans le reste du noyau. Tu remarqueras qu'on remercie tous les contributeurs du noyau, mais c'est quand même important de savoir qui fait quoi. C'est pareil ici!
# Poulsbo, le retour du come-back again ?
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 10.
C'est moi, ou Intel vont nous refaire une troisième fois le coup de la carte graphique à pilote propriétaire de mairde ?
[^] # Re: Poulsbo, le retour du come-back again ?
Posté par Martin Peres (site web personnel) . Évalué à 1.
Yep, ça va être fun ça! …. Ou pas …..
[^] # Re: Poulsbo, le retour du come-back again ?
Posté par deasy . Évalué à -2.
Il me semble que c'est un SoC donc on s'en fout un peu.
[^] # Re: Poulsbo, le retour du come-back again ?
Posté par Martin Peres (site web personnel) . Évalué à 5.
On s'en fou justement par ce qu'on ne peut pas avoir une plateforme bien libre! Vivement que le pilote graphique pour le rasp pi soit dans mesa de façon à avoir une plateforme entièrement libre et donner envie aux autres plateformes de faire pareil!
[^] # Re: Poulsbo, le retour du come-back again ?
Posté par deasy . Évalué à 1. Dernière modification le 07 avril 2014 à 00:04.
J'aurais du ajouter un SoC à destination de smartphones donc on s'en fout un peu.
ça serait un SoC avec sata and co je dis pas…
# Btrfs
Posté par Jiehong (site web personnel) . Évalué à 6.
Salut,
Il est vrai que je n'ai pas eu trop de temps pour la partie système de fichiers…
Btrfs avance bien, puisque Facebook vient de lancer un test de déploiement.
Avec OpenSuse qui est passé à Btrfs par défaut cette année, on peut peut-être dire que 2014 est l'année du Btrfs.
[^] # Re: Btrfs
Posté par Martin Peres (site web personnel) . Évalué à 2.
Timothée a couvert pour toi, on va espérer que ton emploi du temps (comme le mien) se libérera un peu dans les 3 prochains mois!
[^] # Re: Btrfs
Posté par Siosm (site web personnel) . Évalué à 1.
Petite précision : je n'ai pas tout fait dans la partie système de fichiers, juste un bout. Je ne sais pas qui a fait le reste (d'où l'importance de s'ajouter dans la liste des contributeurs).
[^] # Re: Btrfs
Posté par maboiteaspam . Évalué à 4.
ayant fait quelques broutilles sur le fs, ce qu'il faudrait, il me semble, c'est qu'un expert, toi si j'ai bien compris, puisse répondre ou reprendre les parties délicates, voir peut être se suppléer en donnant des liens qui explique les parties technique du texte.
Le gros de la trad peut être fait par plus de gens, alors que comprendre les relations entre les différents sous systèmes c'est plus compliqué et demande parfois plus d'énergie, aussi il faut savoir trouver l'info correcte.
Ce qui ne se révèle pas si évident que cela, selon moi.
En tout cas cela m'aurait bien aidé.
Perso, et en tant qu'exemple, le truc de inline_data dans btrfs, je n'ai encore qu'une vague idée du concept.
Aussi je me demande si ce ne sera pas intéressant de récapituler les nouvelles options d'api quand il y en à.
Si j'étais dev système, je pense que j'apprécierais ce genre de recap.
Mais encore une fois cela peut s'avérer très technique, et consommateur de temps. Juste une idée.
Éventuellement, les dev systèmes lèveront la voie en ce sens.
# π
Posté par Elfir3 . Évalué à 10.
Petit joueur Linus.. Il aurait pu attendre 2 jours de plus et annoncer la nouvelle numérotation des versions du noyal qui va converger vers π.
[^] # Re: π
Posté par lecteur . Évalué à 0.
Comme TeX.
[^] # Re: π
Posté par Sytoka Modon (site web personnel) . Évalué à 3.
Hommage caché à Leslie Lamport en plus (LaTeX converge vers e). Cela aurait un beau poisson effectivement ;-)
# Fish pie.
Posté par ParaDoxe . Évalué à 5.
Ce n'est pas un poisson d'avril?
Parait que c'est la saison.
[^] # Re: Fish pie.
Posté par Vincent14 (site web personnel) . Évalué à 4.
J'y ai cru. Ça aurait été la blague la plus longue de l'histoire si ça avait été le cas. Mais oui aujourd'hui je n'ai plus confiance dans les infos de mon agrégateur RSS. ='(
# Résumé
Posté par rogo . Évalué à 10.
Vue la taille de la dépêche, un résumé serait le bienvenu. Je propose :
Résumé pour un utilisateur standard
PC portable ou de bureau ou serveur basique, proc x86, système de fichiers stable.
[^] # Re: Résumé
Posté par WhiteCat . Évalué à 2.
Juste pour compléter concernant OpenGL 3.2 avec les R600/R700, il faut avoir une version 10.1 de Mesa.
[^] # Re: Résumé
Posté par Maxime (site web personnel) . Évalué à 8.
Pour les utilisateurs de Debian, je rajouterai que Mesa 10.1 est enfin arrivé dans sid depuis 2 semaines environ. J'en ai profité pour passer au driver radeon et wow, tout est plus mieux ! Fini les crashs aléatoires, fini le lag dans firefox sur certaines pages. Et en bonus, il est capable de gérer mes 3 écrans sans problème :).
[^] # Re: Résumé
Posté par cluxter . Évalué à 1.
Lorsque tu dis qu'il est capable de gérer tes 3 écrans sans problème, tu parles des performances ? Qu'est-ce qui n'allait pas ?
[^] # Re: Résumé
Posté par tuxicoman (site web personnel) . Évalué à 1. Dernière modification le 01 avril 2014 à 22:00.
Moi je peux toujours pas jouer à HoN avec mesa 10.1 et une radeon 7850. http://www.heroesofnewerth.com/
Je vais attendre le noyau 3.14. Et glamor, ca sert à quelque chose?
[^] # Re: Résumé
Posté par Maxime (site web personnel) . Évalué à 6.
Sur ma config au boulot j'ai 2 écrans 17 pouces reliés à mon ordi portable. Avec le driver proprio, il ne me proposait tout simplement pas la possibilité d'activer plus de 2 affichages à la fois. J'ai donc maintenant la possibilité d'avoir une surface totale de 1920x1080 (baissé en 1280x720 pour garder un dpi identique partout) + 1280x1024 + 1280x1024. Utilisé avec Awesome WM qui me fait bien une gestion de workspace par écran physique et non au total, c'est vraiment cool :D. Même si j'ai pas vraiment besoin d'un 3ème écran au fond…
Aucun soucis de perf non plus.
[^] # Re: Résumé
Posté par cluxter . Évalué à 1.
# proActiv, proAtiv ou proAptic ?
Posté par Cilyan Olowen (site web personnel) . Évalué à 2.
Est-ce juste une coquille ? En cherchant sur le web on tombe effectivement sur proAptic dans un article en japonais, en revanche le produit en lui-même semble être le proActiv et j'ai pas tout compris mais proAptic serait une technologie sous-jacente ? Des infos ?
http://www.imgtec.com/mips/mips-proaptiv.asp
http://www.imgtec.com/jp/News/Release/index.asp?NewsID=564
# Sécurité: Contournement de kASLR par Brad Spengler (grsecurity)
Posté par Siosm (site web personnel) . Évalué à 4.
Comme prévu (c'était en quelque sorte annoncé dans sa critique sur le blog de grsecurity), Brad Spengler a trouvé plusieurs méthodes pour contourner kASLR sur le noyau 3.14, dès sa sortie, avec vidéos à l'appui, mais pas de code source :
* https://twitter.com/grsecurity/status/450760661463998465
* https://twitter.com/grsecurity/status/450831571487301632
[^] # Re: Sécurité: Contournement de kASLR par Brad Spengler (grsecurity)
Posté par Victor STINNER (site web personnel) . Évalué à 10.
Brad Spengler n'a pas changé. Il se moque des améliorations liées à la sécurité dans le noyau Linux et insulte les développeurs noyau. Au lieu d'écrire un framework pour écrire des exploits noyau, il ferait mieux d'apprendre à communiquer avec les développeurs pour faire entrer ses grosses modifications GRSecurity dans le noyau.
Je pense que le travail de fond sur la randomization de l'espace d'adressage du noyau est une bonne chose. Aucune protection n'est infaillible, mais j'ai cru comprendre que plus il y en a, plus l'écriture d'un exploit "stable" (qui fonctionne sur plusieurs versions de Linux, différentes versions, architectures, etc.) devient complexe.
Un travail a été entamé par plusieurs développeurs pour cacher progressivement les adresses mémoires. Je doute que Linux 3.14 soit parfait, mais je suis sûr que ça ne peut que s'améliorer.
Les changements dans le noyau se font progressivement, pas à pas, et sans dégrader les performances.
Publier une vidéo sur Youtube sans fournir aucune information ne fait pas avancer le schmiblick. Pourquoi ne pas montrer clairement le code source et aider à corriger la faille de sécurité ? Sûrement pour se faire mousser et vendre son travail sur GRSecurity.
[^] # Re: Sécurité: Contournement de kASLR par Brad Spengler (grsecurity)
Posté par Zenitram (site web personnel) . Évalué à -10.
C'est quand même utile pour vérifier que le noyau est sûr.
Qui dit que c'est mieux? Toi? Est-ce obligatoire? Ou est la liberté?
Pourquoi?
C'est libre, tout le monde peut faire le boulot, si ce n'estp as fait c'est que pas foule du côté des développeurs Linux n'est vraiment interessé par son travail (il s'est déjà fait jeté), donc bon c'est dans les deux sens…
1/ Ca montre qu'il y un problème, et peut-être ça bouge le cul des dév'.
2/ C'est mieux que de publier le code source en 0-day. Ca sera sans doute patché par grsecurity, libre à chacun ensuite de savoir ce qu'il veut.
Sans doute.
Mais pour contre-balancer ton commentaire qui laisse un arrière-gout de négatif, je trouve ça au pire neutre, au pire pas mal, ça fait de la compétition avec quelque chose de différent que la pensée majorité des dév' Linux, et n'importe qui peut reprendre et améliorer ses modifs (vive le libre).
[^] # Re: Sécurité: Contournement de kASLR par Brad Spengler (grsecurity)
Posté par barmic . Évalué à 9.
Parce que la LKML est réputé pour être un lieu de consensus mou sociocratique ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Sécurité: Contournement de kASLR par Brad Spengler (grsecurity)
Posté par Victor STINNER (site web personnel) . Évalué à 6.
C'est mieux que de publier le code source en 0-day.
Je ne suis pas d'accord. La sécurité se passe mieux quand c'est transparent. En l’occurrence, une faille dans la randomization de l'espace d'adressage n'est pas une régression en terme de sécurité, étant donné que le noyau 3.13 ne l'avait pas. C'est juste que la protection n'est pas efficace. Publier la faille (le code source de l'exploit) ne va mettre en danger quiconque.
Avec le code source de l'exploit, il serait plus facile de chercher de corriger la faille, mais aussi de réfléchir à une solution plus générale pour corriger le problème.
Pour la faille de sécurité "vmsplice", un correctif d'urgence avait été mis en place. Il bloquait l'exploit qui circulait, mais était insuffisant. Plus tard, avec plus de temps, un correctif complet a été écrit. La faille :
http://linuxfr.org/news/important-bug-de-s%C3%A9curit%C3%A9-sur-noyau-2617-%C3%A0-2624
(je ne me souviens plus des détails sur les différents correctifs.)
[^] # Re: Sécurité: Contournement de kASLR par Brad Spengler (grsecurity)
Posté par Zenitram (site web personnel) . Évalué à -7. Dernière modification le 02 avril 2014 à 11:43.
Pas en "transparence quoi qu'il arrive, allez hop je te file le code soure à tous" (full disclosure).
vieux débat.
chacun son façon de penser sans doute…
Si, si c'est fait de manière non contrôlée.
C'est mieux de ne pas publier que de publier en full disclosure.
Après, c'est mieux de faire du responsible disclosure, mais je comprend aussi que cette personne essaye de vivre de son travail.
Je suis sûr que si tu sponsorises le monsieur, il te filera son code.
Mais demander au gars de tuer son gagne-pain pour tes beaux yeux est un peu du foutage de gueule. J'attend de voir une politique de récompenses comme le font Google ou Microsoft pour les failles de sécurité. Si la sécurité est importante, on incite les gens à faire part de leur trouvailles, à en vivre de de leur travail, pas à leur demander de faire du travail gratos pour eux.
Désolé de comprendre le monsieur et ne pas charger qu'un côté pour le plaisir de charger.
[^] # Re: Sécurité: Contournement de kASLR par Brad Spengler (grsecurity)
Posté par pasBill pasGates . Évalué à 3.
Sisi c'est dangereux, meme si il n'y avait pas kASLR avant.
Quasiment tous les bypass d'une techno comme ASLR reposent sur un info leak, et un info leak en lui-meme est une vulnerabilite, ASLR ou pas. cf. l'info leak d'OpenSSL en ce moment…
Raison pour laquelle il vaut mieux ne pas ouvrire le code source de l'exploit a tout le monde…
[^] # Re: Sécurité: Contournement de kASLR par Brad Spengler (grsecurity)
Posté par reno . Évalué à 6.
YAQUAFAUQUON?
Plus facile a dire qu'a faire.. Il y a eu plusieurs tentatives pour intégrer les modifications de sécurité de GRsecurity sur lesquelles il a travaillé dans Linux, mais seule une petite partie ont réussi a être intégrée.
[^] # Re: Sécurité: Contournement de kASLR par Brad Spengler (grsecurity)
Posté par Albert_ . Évalué à 10.
Tout le monde sait que si tu arrives avec le plus tip top changement pour le noyau mais qu'il fait 200 000 lignes d'un coup, il se fera toujours refusé. Linus Torvalds a toujours ete clair sur le sujet, il veut des petits patchs car c'est possible de les analyser et de les integrer petit a petit. Cela demande du boulot mais bon la regle du jeu est la meme pour tout le monde.
[^] # Re: Sécurité: Contournement de kASLR par Brad Spengler (grsecurity)
Posté par Zenitram (site web personnel) . Évalué à 4.
Yep, et comme GrSecurity est libre, tout le monde peut faire le travail.
Pourquoi l'accuser lui, c'est obligatoire de commiter upstream?
Si Linux est troué (ou du moins pas au top de la sécurité) faute de patchs à la GrSecurity c'est la faute de tout le monde, qui est capable de faire le boulot.
Reste à savoir si ça interesse du monde, il faut croire que non. Donc reste GrSecurity en attendant, qui lui est disponible la maintenant (on doit faire un choix entre la source qui est toujours super à jour mais sécurité moyenne et GrSecurity qui est pas toujours à jour mais pour le noyau des versions stables des plus grosses distro donc ça va encore pour les machine de prod - et sécurité renforcée)
Si Linux a des trous, c'est la faute de tous.
[^] # Re: Sécurité: Contournement de kASLR par Brad Spengler (grsecurity)
Posté par Albert_ . Évalué à 1.
Yep, et comme GrSecurity est libre, tout le monde peut faire le travail.
Super tu es volontaire? Parceque les gens qui bossent sur le noyau ils ont deja leur assiette bien rempli.
[^] # Re: Sécurité: Contournement de kASLR par Brad Spengler (grsecurity)
Posté par Zenitram (site web personnel) . Évalué à 3.
Pourquoi le serais-je? J'ai GrSecurity la, dispo.
Mais si tu me payes, je peux être volontaire.
Question de priorité. On est donc d'accord que la sécurité n'est pas une priorité. C'est un choix.
Tu fais peut-être exprès de ne pas comprendre, j'essaye de tourner ça autrement : c'est faux-cul d'accuser Brad Spengle de ne pas le faire quand en fait on peut le faire soit-même et qu'on ne le fait pas, il y a toujours des bien pensants pour dire que que les autres doivent faire. Ma critique va envers les gens qui reprochent à Brad Spengle de ne pas faire ce que eux peuvent faire. La critique est facile, se bouger est plus difficile.
Bref, je critique simplement ceux qui critiquent gratuitement Brad Spengle parce qu'il n'est pas comme ils souhaitent.
[^] # Re: Sécurité: Contournement de kASLR par Brad Spengler (grsecurity)
Posté par Albert_ . Évalué à 1.
Pourquoi le serais-je? J'ai GrSecurity la, dispo.
Mais si tu me payes, je peux être volontaire.
Je vois pas en quoi tu peux critiquer les devs de Linux alors.
Bref, je critique simplement ceux qui critiquent gratuitement Brad Spengle parce qu'il n'est pas comme ils souhaitent.
Mais je te rassure tout le monde s'en fout. Ceux qui veulent utiliser son enorme patch comme toi peuvent le faire les autres ils s'en tapent. Tu fais une confiance aveugle a Brad Spengle c'est ton droit d'autre personne prefere un truc qui meme imparfait a ete revu par d'autre devs.
Tu as le droit de considerer que Linus Torvalds ne sait pas manager un developement de kernel et que c'est honteux qu'il refuse un enorme patch tres invasif que personne ne lira c'est ton droit mais critiquer gratuitement les devs du kernel c'est exactement ce que tu reproches…
[^] # Re: Sécurité: Contournement de kASLR par Brad Spengler (grsecurity)
Posté par Zenitram (site web personnel) . Évalué à 1.
Je n'ai pas dit ça, j'ai rien dit à ce sujet même! J'ai parlé uniquement de ceux qui critiquent gratuitement une personne, mais bon, comme tu ne veux pas parler de ça… Hop, parlons d'autre chose, inventons des critiques à critiquer, c'est plus simple.
Merci pour la démonstration.
[^] # Re: Sécurité: Contournement de kASLR par Brad Spengler (grsecurity)
Posté par Albert_ . Évalué à 0.
Tu reponds a un message sur la raison principale du refus du parch dans le kernel (taille du patch). Refus decris dans un mail (lien present dans ce journal) de Linus Torvalds. Par consequent quand tu dis que les critiques sont gratuites, tu dis que c'est la personne refusant le patch, Linus Torvalds, qui fait une critique gratuite donc tu critiques la facon de manager le kernel pas Linus Torvalds.
CQFD
[^] # Re: Sécurité: Contournement de kASLR par Brad Spengler (grsecurity)
Posté par Zenitram (site web personnel) . Évalué à 1.
Si il faut détailler précisement : je répond à cette phrase pourrie "il ferait mieux d'apprendre à communiquer avec les développeurs".
Ah oui, désolé de ne pas penser qu'il ferait mieux de, de juger les gens qui ne font pas comme si comme ça.
Je n'ai rien contre la politique de Linus (qui est même plutôt normale), mais comme d'hb : si tu n'es pas à 100% avec moi, tu es contre moi. Triste.
[^] # Re: Sécurité: Contournement de kASLR par Brad Spengler (grsecurity)
Posté par barmic . Évalué à 6.
Pas obligatoire, mais c'est toujours moins bien vu de travailler hors de la LKML (libre ou non).
Après faut savoir ce que lui veut, s'il est content de s'emmerder tout seul à suivre les développements du noyau et à devoir sauter perpétuellement 3 ou 4 versions du noyau. C'est aussi à lui de voir.
Probablement, mais si GRsecurity n'est pas intégré c'est la faute de celui qui l'a créer sans respecter les règles du noyau et qui ne souhaite pas s'y conformer. Simplement parce que ces règles précédent CRsecurity. Si demain j'écris un patch pour le noyau, mais que j'utilise une licence incompatible, que mon patch casse une partie des API actuelles du noyau ou qu'il ne respecte pas les règles de codage du noyau, ce sera pas la faute des hackers du noyau si mon patch n'est jamais intégré.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Sécurité: Contournement de kASLR par Brad Spengler (grsecurity)
Posté par Victor STINNER (site web personnel) . Évalué à 9.
Yep, et comme GrSecurity est libre, tout le monde peut faire le travail.
Il existe peu de gens qui ont des compétences en développement noyau. Seule une partie de ces développeurs sont sensibles à la sécurité. Il y a encore moins de développeurs noyau qui ont les compétences pour comprendre l'énorme patch Grsecurity. Autrement dit, à part Brad, je ne vois pas qui pourrait redécouper son énorme patch et l'intégrer petit à petit, en expliquant l'intérêt de chaque patch, argumenter, etc.
[^] # Re: Sécurité: Contournement de kASLR par Brad Spengler (grsecurity)
Posté par Zenitram (site web personnel) . Évalué à -10.
Un homme unique, irremplaçable, donc.
Rien que ça.
Le plus gros du travail est fait (le gros des compétances est de coder un truc utile à la sécurité), si personne d'autre n'est capable d'analyser et comprendre le code ajouté au noyau, ho ho…
(faut arrêter le délire : je comprend parfaitement que les gens qui ont les compétences pour analyser et découper le patch n'ont aucune envie de le faire car pas leur priorité, comme je comprend que personne n'ai envie de payer pour plus de sécurité quand GrSecurité est la gratos, mais il faut pas me sortir des excuses comme quoi tous les autres sont super incompétants en lecture de code source et compréhension de comment un logiciel fonctionne. Faut arrêter de chercher de fausses excuses et accepter le constat : ce n'est pas la priorité, c'est tout. Pourquoi donc chercher à le cacher?).
[^] # Re: Sécurité: Contournement de kASLR par Brad Spengler (grsecurity)
Posté par Albert_ . Évalué à 10.
Un homme unique, irremplaçable, donc.
Ce que Victor dit c'est que le patch est tellement gros que personne ne peut le comprendre sans un travail enorme. Ce travail doit etre fait par celui qui code le patch car c'est comme ca que cela marche dans le developement du kernel linux. Une fois le patch divise en petit morceau le travail d'analyse peut prendre place. Cela a ete exige de Microsoft, cela a ete exige de Google, cela a ete exige pour ReseirFS, cela est exige pour TOUT le monde, il n'y a pas d'exception. Que le dev de Grsecurity ne veuille pas le faire c'est son droit mais du coup il perd le droit de critiquer quoi que ce soit dans le kernel. Tu joues avec les autres en respectant les regles ou tu joues a cote a un autre jeu.
La securite du linux n'est peut etre pas la priorite des devs du kernel (ils preferent un truc qui fonctionne, soit veloce plutot que passer des mois a debugguer les effets de bords d'un enorme patch chacun son truc) mais c'est encore moins la priorite de Brad Spengle. Sa priorite a lui c'est le developement d'un patch externe au noyau linux.
[^] # Re: Sécurité: Contournement de kASLR par Brad Spengler (grsecurity)
Posté par Zenitram (site web personnel) . Évalué à -10. Dernière modification le 02 avril 2014 à 12:13.
On est bien d'accord : il fait être dans la ligne du parti ou pas.
(sinon, je ne vois pas la perte si c'est une autre personne qui découpe c'est même mieuxça fait 2 personne qui ont vu le code, mais bon, c'est la règle du parti et pas de critique de ce point ne semble autorisé)
Ah ah ah
Voila donc : si on n'est pas du parti, on n'aurait pas le droit.
Il a tout à fait le droit, ne t'en déplaise, et il ne se gène pas d'ailleurs. Ce droit, ni toi ni les mainteneurs ne peuvent lui enlever, dommage.
Merci pour cette grande preuve de tolérance (et après on critique le monsieur, ha ha ha)
Non, la, c'est juste que la sécrité n'est pas le plus important, c'est tout (ce n'est pas un mal, chacun ses priorités), sinon quelqu'un s'y collerait (pas la peine de reprendre le code de GrSecurité, suffit de reprendre les idées), pas le peine de le cacher sous 36 excuses pour s'auto-convaincre que son dieu est le meilleur (parce que la, c'est du religieux, le journal était lui plus neutre).
[^] # Re: Sécurité: Contournement de kASLR par Brad Spengler (grsecurity)
Posté par Thomas Debesse (site web personnel) . Évalué à 6.
Ahah, ligne du parti !
Non, discriminer ceux qui respectent les méthodes de travail et les autres ce n’est pas une question de ligne de parti.
Dans un entretien d’embauche, il ne serait peut-être pas embauché s’il refuse les méthodes de travail de l’entreprise.
Linus n’a aucune obligation morale à accepter quoi que ce soit comme patch sous prétexte que le patch est compatible Linux. Ben nan, il faut le séduire, et pour le séduire, il faut que ça soit sexy, et à minima, lisible.
Je vais pas râler si je soumet à Adobe un plugin Photoshop de mon invention et qu’ils ne l’intègrent pas par défaut dans l’itération suivante de Photoshop. Ils n’ont aucune obligation morale à intégrer du code compatible. C’est pareil.
De même, Microsoft n’a jamais intégré le plugin Open Document Format de Sun. Ils n’en avaient aucune obligation sous prétexte que c’est compatible.
OK, mais qui doit être désigné pour cela, et qui désigne ?
OK. SUSE peut affecter un développeur à cette tâche, OK. IBM peut affecter un développeur à cette tâche, OK. Red Hat peut affecter un développeur à cette tâche, OK. Oracle peut affecter un développeur à cette tâche. Pourquoi ne l’ont-ils pas fait ? Je ne sais pas mais c’est pas la faute à Linus.
Après, si personne ne s’est dévoué pour le faire, ou si personne n’a payé quelqu’un pour le faire, c’est pas la faute à Linus.
Si les gens préfèrent payer directement Brad Spengler pour faire du support GRsecurity plutôt que payer un tiers pour travailler à l’intégration de GRsecurity dans la branche principale du noyau, c’est que la situation convient aux payeurs. Donc tout le monde est content.
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Sécurité: Contournement de kASLR par Brad Spengler (grsecurity)
Posté par Zenitram (site web personnel) . Évalué à -10. Dernière modification le 02 avril 2014 à 12:41.
Par curiosité, cite une personne qui dit que c'est la faute à Linus.
Mais il y en a quand même pour sortir "ce gars ferait mieux de", ce à quoi je répondais. Ah c'est idiot, je ne critiquais pas Linus, mais l'auteur de cette phrase… Mais tu évites de parler de ça et parle de Linus je ne sais pourquoi. Du coup tout ce que tu réponds est HS.
hum, bon je m'arrête ("tout le monde" sera content, facile tout le monde), c'est trop dans l'invention d'attaques que je n'ai pas faites pour ne pas me répondre sur ce que je dis.
[^] # Re: Sécurité: Contournement de kASLR par Brad Spengler (grsecurity)
Posté par zebra3 . Évalué à 10.
Toi. Tu as écrit plus haut que c'est la faute de tous, donc y compris Linus.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Sécurité: Contournement de kASLR par Brad Spengler (grsecurity)
Posté par Zenitram (site web personnel) . Évalué à -8.
C'est effectivement sa faute si il ne veut pas développer lui-même, mais sur ça, c'est sa faute pour beaucoup de choses.
Je ne remet pas en cause sa politique d'acceptation de patch.
Je recite donc en entier la phrase à laquelle je répond :
Hop, encore à côté. dommage…
[^] # Re: Sécurité: Contournement de kASLR par Brad Spengler (grsecurity)
Posté par Thomas Debesse (site web personnel) . Évalué à 5.
C’est pas plus ridicule que la faute au parti, hein…
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Sécurité: Contournement de kASLR par Brad Spengler (grsecurity)
Posté par Albert_ . Évalué à 9. Dernière modification le 02 avril 2014 à 14:52.
On est bien d'accord : il fait être dans la ligne du parti ou pas.
Tiens petite question: je t'envoie un patch avec tous les commentaires et variable en chinois et UTF-16. Tu vas l'accepter? Attention si tu dis non cela veut dire qu'il faut etre inscrit dans un parti (pour reprendre tes dires) pour avoir un patch accepter dans ton projet.
[^] # Re: Sécurité: Contournement de kASLR par Brad Spengler (grsecurity)
Posté par Zenitram (site web personnel) . Évalué à -10. Dernière modification le 02 avril 2014 à 15:10.
La question est : si quelqu'un le traduit en anglais, vas-tu le refuser car ce n'est pas l'auteur original qui a fait la traduction?
Car on parle de ça.
Ah oui, c'est tellement facile de se cacher des faits :
- Je n'ai pas parlé d'accepter un patch en chinois, je l'ai dit plusieurs fois, au début on peut se tromper, à force c'ests un mensonge voulu pour un but.
- Personne ne trouve utilité à traduire le patch car personne ne pense que le sujet du patch est la priorité
Ici, la conclusion est que personne ne pense que la sécurité dans Linux ne vaut le coup (qui doit pas être simple, certes) de travailler sur l'inclusion des améliorations développées par un autre, que ce soit "traduire" dans un format acceptable ou en prendre les idées.
Bref, ne surtout pas contre-argumenter sur ce que je dis, il faut croire qu'il n'y a rien à contre-argumenter dessus vu qu'on parle d'autre chose. Merci, je prend cette fuite comme un compliment.
[^] # Re: Sécurité: Contournement de kASLR par Brad Spengler (grsecurity)
Posté par barmic . Évalué à 10.
Tu arrête de débiter des âneries qui te ferrait crever de honte AFAK ?
Il y a des gens qui y travaillent ou du moins on essayé :
http://linuxfr.org/users/patrick_g/journaux/renforcer-la-s%C3%A9curit%C3%A9-du-noyau
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Sécurité: Contournement de kASLR par Brad Spengler (grsecurity)
Posté par Kioob (site web personnel) . Évalué à 5.
Et pourtant, du peu que je vois, certaines idées/concepts de GRSecurity sont progressivement intégrées dans le kernel upstream (je prends pour exemple l'option "hidepid" du /proc, qui est probablement l'aspect le plus visible de GRsec pour l'utilisateur). Mais ça arrive après des années.
Visiblement des personnes considèrent bien qu'il s'agit de bonnes idées/concepts, mais c'est l'implémentation / le manque de commentaire qui pose problème. Bref, pour pas mal de points les gens semblent d'accord avec Brad sur le fond, mais c'est la forme qui pose problème.
Il se passe exactement la même chose avec le patch «suhosin» de PHP, pour des raisons très similaires.
alf.life
[^] # Re: Sécurité: Contournement de kASLR par Brad Spengler (grsecurity)
Posté par Thomas Debesse (site web personnel) . Évalué à 10.
Woah, je suis pas toujours d’accord avec Albert_< , mais là, je plussoie de tout mon cœur. \o/
Si la sécurité de Linux était une priorité pour Brad Spengler, ça fait longtemps qu’il aurait fait rentrer ses patchs petit bout par petit bout en prenant toutes les précautions pour que le bébé soit accueilli et choyé.
Je dis ça je dis rien, mais Linux ou pas, méthode officielle exigée ou pas, le meilleur moyen pour faire accepter son code c’est de le faire petit bout par petit bout pour ne faire peur à personne et mettre ainsi toutes les chances de son coté. C’est une bonne vieille méthode de démarcheur, le pas dans la porte, et c’est très efficace.
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Sécurité: Contournement de kASLR par Brad Spengler (grsecurity)
Posté par Batchyx . Évalué à 10.
Indépendamment de si tu veux faire intégrer ton code ou pas, séparer ton code en plusieurs changements testables indépendamment est une bonne pratique logicielle, ce n'est pas pour te faire chier que les dev noyau te demandent de découper ton code. C'est notamment pour qu'il puisse reverter tes changements séparément s'ils pètent tout.
Et même si tu en a rien à foutre de contribuer upstream ou de la qualité de ton code, séparer en plusieurs commits te facilitera grandement la mise à jour de tes patch avec les nouvelles releases d'upstream.
[^] # Re: Sécurité: Contournement de kASLR par Brad Spengler (grsecurity)
Posté par spider-mario . Évalué à 4.
Et pour trouver quel changement annuler exactement, vive
git bisect![^] # Re: Sécurité: Contournement de kASLR par Brad Spengler (grsecurity)
Posté par Albert_ . Évalué à 7.
Avec un patch de 100 000 lignes tu as plus besoin de cet outil.
[^] # Re: Sécurité: Contournement de kASLR par Brad Spengler (grsecurity)
Posté par pasBill pasGates . Évalué à 6.
Quoi qu'on puisse dire sur les qualites 'sociales' de Brad Spengler, il est incontestable qu'il en a fait plus pour la securite de Linux que 99.99% des gens qui ont touche Linux, y compris les devs du kernel.
Faudrait donc quand meme penser a avoir un minimum de respect pour le gars, meme si il peut etre sacrement abrasif, car les gens qui ont autant apporte que lui niveau securite, on les compte sur les doigts d'une main sous Linux.
[^] # Re: Sécurité: Contournement de kASLR par Brad Spengler (grsecurity)
Posté par barmic . Évalué à 4.
Non ça ne représente un surplus de travail que pour ceux qui travail tout seul dans leur coin.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Sécurité: Contournement de kASLR par Brad Spengler (grsecurity)
Posté par Siosm (site web personnel) . Évalué à 10.
Tout d'abord, je tiens à préciser que le fait que je rapporte ses propos (ou ses vidéos) dans la catégorie sécurité (et les commentaires) ne veut pas dire que je cautionne son comportement. Je trouve son attitude, son égocentrisme et ses critiques gratuites à tout va déplacés.
En revanche, il faut noter que sur le plan de la réflexion en terme de sécurité, le projet grsecurity est très en avance sur la majeure partie des protections. Il faut donc absolument tenir compte de leurs arguments même si ils ne les expriment pas de la meilleure façon malheureusement.
Je pense que kASLR n'est pas une bonne idée. Les raisons sont simples et elles sont détaillés dans l'article sur le blog/forum de grsecurity :
- Le principe même d'ALSR est un cache misère et non pas une solution ;
- ASLR marche pour les processus parce les adresses mémoires changent à chaque exécution. Avec kASLR, ce n'est pas le cas, les adresses ne changent qu'au démarrage ;
- ASLR marche parce que l'intervalle disponible pour rendre les adresses mémoires aléatoires est très grand, donc les probabilités de trouver la bonne très faibles. Dans le cas de kASLR, l'intervalle est beaucoup plus petit : il est beaucoup plus facile de tomber sur la bonne adresse ;
- ASLR est efficace sur un système si et seulement si l'on dispose d'un mécanisme pour empêcher un programme en cours de brute force de s'exécuter après un certain nombre de crashs suspects. Ce n'est pas le cas de kASLR, puisqu'il est possible de faire crasher en continu un driver par exemple qui sera rechargé à nouveau et que l'on pourra continuer d'exploiter car les adresses ne sont changées qu'au démarrage de la machine. N'importe quel bug non fatal dans le kernel pourra être utilisé ainsi ;
- kASLR introduit de la complexité (inutile) dans le noyau au démarrage, lors du débogage…
On espère tous que cela se produira un jour. Je pense qu'il nous faut plutôt un courageux pour faire le boulot.
[^] # Re: Sécurité: Contournement de kASLR par Brad Spengler (grsecurity)
Posté par patrick_g (site web personnel) . Évalué à 10. Dernière modification le 02 avril 2014 à 07:28.
Sauf que Spender est un maximaliste qui ne pense qu'à la sécurité et se fiche de tout le reste (perfs, portabilité, etc). Les mainteneurs du noyau eux doivent faire des choix et des compromis.
Dans l'article LWN dédié on comprend bien que KASLR n'est pas une solution miracle mais que ça apporte quand même des bénéfices non nuls en terme de sécurité et sans aucune dégradation des perfs.
[^] # Re: Sécurité: Contournement de kASLR par Brad Spengler (grsecurity)
Posté par Zenitram (site web personnel) . Évalué à -10. Dernière modification le 02 avril 2014 à 07:58.
Tiens, c'est exactement ce que disait Microsoft et il était super critiqué par nombre de Linuxiens comme quoi la sécurité n'était pas prise au sérieux.
Bon, il faut croire qu'en fait, la sécurité n'est pas le plus important, des deux côtés (Linux et Microsoft), faudrait donc parfois un peu arrêter de taper sur Microsoft, tu viens de dire que tu aimes la politique de Microsoft en termes de sécurité, j'espère que tu défendra la politique de sécurité de Microsoft la prochaine fois qu'un Linuxien tapera dessus en oubliant que pour son noyau préféré c'est la même politique.
Le problème avec la sécurité est que plus tu ajoutes du code, plus tu as des risques de bug qui ajoutent des trous quand tu pensent protégér. "Non nuls" ne suffit pas, il faut que ça vaille le coup par rapport au risque d'introduction de nouvelles failles. Reste à savoir si ça vaut le coup, et la tout le monde n'est pas d'accord…
Un peu facile de taper sur une personne qui a le malheur de ne pas rentrer dans le moule "gentil qui fait tout comme les mainteneurs upstream et/ou certains utilisateurs attendent". Reste que son noyau patché a un certain succès. Vive le libre et sa possibilité de choisir des choses différentes.
[^] # Re: Sécurité: Contournement de kASLR par Brad Spengler (grsecurity)
Posté par patrick_g (site web personnel) . Évalué à 10.
Et après tu t'étonnes qu'on te tape dessus parce que tu racontes n'importe quoi.
En quoi la politique de sécurité de Microsoft (à l'époque, parce qu'ils ont changé depuis) était comparable à l'actuelle politique suivie par les mainteneurs Linux ? Autrefois Microsoft se foutait royalement de la sécurité et seul le "time to market" comptait. Depuis ils ont bien appris leur leçon et ils ont maintenant une politique assez efficace.
Donc évoquer Microsoft comme tu le fais n'a aucun sens à part le plaisir d'agiter un chiffon rouge pour faire dérailler la conversation.
Et cela n'a absolument rien à voir avec la nécessité de faire des compromis entre plusieurs buts contradictoires.
C'est sûr que c'est confortable pour Spender de cracher sur les devs Linux quand on se branle royalement des perfs du noyau patché Grsecurity/PaX.
Regarde donc le journal que j'avais écris à l'époque sur ces perfs : https://linuxfr.org/users/patrick_g/journaux/les-performances-d-un-noyau-avec-le-patch-pax
Les résultats des micro-benchmarks sont absolument catastrophiques !
Tu crois que je suis le seul à lui taper dessus ? Tout le monde lui reproche son attitude infecte, son arrogance inouïe ,sa propension à se faire mousser en permanence et son incapacité absolue à travailler avec les autres.
Bien entendu il est très compétent, et là personne ne remet ça en cause…mais des gens compétents il y en a d'autres (par exemple Kees Cook, l'auteur de KASLR). Pour bosser sur le noyau il ne suffit pas d'être compétent, il faut collaborer avec les autres puisque c'est un projet collectif et il faut accepter les compromis puisque c'est un noyau généraliste.
[^] # Re: Sécurité: Contournement de kASLR par Brad Spengler (grsecurity)
Posté par Zenitram (site web personnel) . Évalué à -10. Dernière modification le 02 avril 2014 à 10:39.
Ben tu viens de dire le contraire (pour Microsoft, le Time to Market était contradictoire avec une plus grande sécurité à l'époque), CQFD.
désolé de te donner des exemples où on voit que les arguments dépendent de qui est défendu. Mais je sais, je touche au dieu Linux…
Faux, je peux le prouver : je ne lui reproche rien du tout et le remercie de faire ce qu'il fait, ce qui rend par définition de "tout le monde" ta phrase fausse.
Mais je sais, c'est un grand classique de transformer "quelques personnes" en "tout le monde" pour mieux faire croire qu'on a que des gens d'accord avec soit, en ignorant volontairement les gens qui ne pensent pas pareil. Ce genre de discours "tout le monde pense comme moi" se retrouve très souvent en politique aussi.
[^] # Re: Sécurité: Contournement de kASLR par Brad Spengler (grsecurity)
Posté par patrick_g (site web personnel) . Évalué à 10.
Tu fais exprès de jouer au boulet ?
Par "tout le monde" j'entends "les gens impliqués dans le développement de Linux". Et toi tu fais semblant de prendre ça au pied de la lettre comme si j'incluais également le paysan du fin fond de la Mongolie.
Oui je te confirme que ce paysan ne reproche absolument rien à Spender.
Mais bon j'arrête là parce que tu as un talent particulier pour toujours avoir le dernier mot, quel que soit le sujet.
[^] # Re: Sécurité: Contournement de kASLR par Brad Spengler (grsecurity)
Posté par Zenitram (site web personnel) . Évalué à -10.
Ah oui, OK, donc tout le monde qui est dans le parti est d'accord pour dire que la personne pas dans le parti n'est pas bien.
Merci d'énoncer l'évidence. Ca montre beaucoup de chose sur la considération que tu as des gens qui ne sont pas en phase avec le parti.
[^] # Re: Sécurité: Contournement de kASLR par Brad Spengler (grsecurity)
Posté par François (site web personnel) . Évalué à 10.
La vache sérieux t'es ouf quoi :)… tellement mono maniaque, tu dois être un bot ou tourner en rond chez toi je sais pas…
[^] # Re: Sécurité: Contournement de kASLR par Brad Spengler (grsecurity)
Posté par khivapia . Évalué à 5.
Ça doit être cette explication-là, et du coup ça ne donne pas envie de travailler tout le temps à domicile.
[^] # Re: Sécurité: Contournement de kASLR par Brad Spengler (grsecurity)
Posté par zebra3 . Évalué à 10.
C'est pourtant exactement ce que tu fais quand tu écris « ce que disait Microsoft et il était super critiqué par nombre de Linuxiens » pour en déduire que « la sécurité n'est pas le plus important, des deux côtés (Linux et Microsoft) »
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Sécurité: Contournement de kASLR par Brad Spengler (grsecurity)
Posté par pasBill pasGates . Évalué à 6.
D'un autre cote, il faut etre stupide pour dire que kASLR est inutile.
kASLR est super utile. Le probleme est que les info leaks sont legion et doivent etre corriges sinon ils rendent kASLR inutile.
Oh, et pour comparaison, cela fait depuis 2008 que Windows a ASLR dans le kernel, il y avait tres peu d'entropie au depart, mais depuis Windows 8 :
12bit sur x86
22bits sur x64
http://media.blackhat.com/bh-us-12/Briefings/M_Miller/BH_US_12_Miller_Exploit_Mitigation_Slides.pdf est d'ailleurs un tres bon recapitulatif des mitigations qu'il y a dans Windows en comparaison
[^] # Re: Sécurité: Contournement de kASLR par Brad Spengler (grsecurity)
Posté par pepp . Évalué à 4.
On perd quand même le support de l'hibernation.
Et les contraintes d'alignement limitent à 512 le nombre d'emplacements mémoire possibles pour le noyau.
C'est quand même léger comme aléatoire…
[^] # Re: Sécurité: Contournement de kASLR par Brad Spengler (grsecurity)
Posté par patrick_g (site web personnel) . Évalué à 10.
Sauf que tu as 511 chances sur 512 de faire planter le noyau quand tu tentes d'en prendre le contrôle. Et un plantage noyau ça a tendance à se remarquer un peu plus qu'un plantage de process en userspace.
Et tout ça c'est sans évoquer les autres bénéfices du patch (protection de la table IDT par exemple).
[^] # Re: Sécurité: Contournement de kASLR par Brad Spengler (grsecurity)
Posté par pepp . Évalué à 5.
Oui pour un attaquant en brute force.
Mais 512 adresses posssibles + des infos leak (nombreux d'après Spender) qui donnent des indications : les chances de l'attaquant de trouver l'adresse réelle augmentent.
Pour résumer, peut-être que KASLR est utile, mais rejetter les arguments de Spender parce-qu-il-développe-grsecurity-et-qu-il-aide-pas-upstream me parait un peu dommage.
[^] # Re: Sécurité: Contournement de kASLR par Brad Spengler (grsecurity)
Posté par patrick_g (site web personnel) . Évalué à 7.
L'idée c'est de boucher progressivement les infos leak afin que la défense KASLR devienne plus efficace (sachant que ça restera une défense statistique et pas absolue).
Je ne pense pas que quiconque rejette les arguments de Spender sur le fond, c'est juste que, pour Kees Cook, le jeu en vaut la chandelle puisque ça ajoute un peu de protection sans enlever grand chose; Et puis, selon l'article LWN, le système sera amélioré par la suite (retour de l'hibernation, augmentation du nombre de slots au delà de 512, etc).
[^] # Re: Sécurité: Contournement de kASLR par Brad Spengler (grsecurity)
Posté par Zenitram (site web personnel) . Évalué à -10. Dernière modification le 02 avril 2014 à 10:43.
Je croyais que la politique de Linux était de refuser les patchs introduisant des régressions?
Hop encore un mythe qui s'en va… (ok, je pousse, si c'est optionel et désactivé par défaut il n'y a pas de régression, juste un coût à payer si on veut une fonctionnalité, c'est un choix à faire en connaissance de cause et sur les serveurs on s'en fout un peu de l'hibernation donc ça va)
Questions idiote : c'est optionel? désactivé par défaut?
[^] # Re: Sécurité: Contournement de kASLR par Brad Spengler (grsecurity)
Posté par Albert_ . Évalué à 7.
Linus Torvalds il a mange ton chat ou il t'a force a acheter un kernel linux? Parceque franchement tu te l'emplafonnes de facon systematique.
[^] # Re: Sécurité: Contournement de kASLR par Brad Spengler (grsecurity)
Posté par Zenitram (site web personnel) . Évalué à -10.
Non, juste que ça me fait sourire de voir les adorateurs du dieu Linux sortir des arguments ou laisser le autres les sortir, pour les oublier quand ça n'arrange pas.
Encore une fois, tu évites le sujet et parle de Linus dont je n'ai pas parlé. Je parle de toi (par exemple).
[^] # Re: Sécurité: Contournement de kASLR par Brad Spengler (grsecurity)
Posté par Albert_ . Évalué à 1.
Et voila on l'attendait la petite attaque ad hominem.
[^] # Re: Sécurité: Contournement de kASLR par Brad Spengler (grsecurity)
Posté par patrick_g (site web personnel) . Évalué à 10.
Évidement que c'est désactivé par défaut.
+config RANDOMIZE_BASE
+ bool "Randomize the address of the kernel image"
+ depends on RELOCATABLE
+ depends on !HIBERNATION
+ default n
[^] # Re: Sécurité: Contournement de kASLR par Brad Spengler (grsecurity)
Posté par xcomcmdr . Évalué à 6.
C'est surtout de refuser les patchs qui cassent l'user-space.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Sécurité: Contournement de kASLR par Brad Spengler (grsecurity)
Posté par zebra3 . Évalué à 10.
Seulement si ces régressions sont systématiques. En l'occurence, il est désactivé mais il reste disponible pour ceux qui veulent l'utiliser. Les autres n'ont aucune régression.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Sécurité: Contournement de kASLR par Brad Spengler (grsecurity)
Posté par Batchyx . Évalué à 1.
Référence nécéssaire.
Si tu a un sombre code qui fait un OOPS gentil alors que tu sais même pas à quoi sert le driver, si tu ne regarde pas le
dmesg, tu risque pas de le voir, et ton système semblera fonctionner normalement, sauf peut-être à l'arrêt du système, quand des gens chercheront à verrouiller le lock que le code crashé avait obtenu … Par contre je nie pas la présence de plantages méchants récursifs que même la détection de plantage récursif ne voit pas.Enfin bref, les plantages en userspace et en kernel space sont globalement aussi visible les un que les autres.
[^] # Re: Sécurité: Contournement de kASLR par Brad Spengler (grsecurity)
Posté par pasBill pasGates . Évalué à 7.
Euh…. un crash dans le kernel, tu le vois au moment ou tu te rends compte que ta machine a un kernel panic ou ne repond plus, on va dire que c'est quand meme sacrement different…
[^] # Re: Sécurité: Contournement de kASLR par Brad Spengler (grsecurity)
Posté par pepp . Évalué à 5.
Ce post (le lien est dans la vidéo que tu cites et également dans la dépêche) détaille son point de vue qu'on pourrait résumer par : KASLR est une mauvaise implémentation d'une idée de départ douteuse (ASLR).
Et toujours d'après son texte il n'y a pas "une faille de sécurité" à corriger : il y en a des tonnes.
Je suis loin d'être expert en sécurité, mais ses arguments ont l'air de se tenir et son post est largement sourcé.
[^] # Re: Sécurité: Contournement de kASLR par Brad Spengler (grsecurity)
Posté par Victor STINNER (site web personnel) . Évalué à 7.
Et toujours d'après son texte il n'y a pas "une faille de sécurité" à corriger : il y en a des tonnes.
Selon Brad, il n'existe que deux options : aucune zéro ou GRSecurity. Ce raisonnement ne se tient pas. Il y a de bonnes raisons de pas utiliser GRsecurity : l'énorme patch est très intrusif et n'est pas intégré upstream. En conséquence, GRsecurity n'est pas utilisable directement sur RHEL, Debian ou OpenSuse. Quand des bugs sont corrigés, les distributions Linux fournissent des correctifs. Avec GRsecurity, il faut mettre à jour le noyau soit même, c'est très délicat. Bien sûr, il existe des personnes qui utilisent GRsecurity et sûrement des paquets tout prêt, mais c'est différent du point de vue de la responsabilité que d'utiliser des paquets fournis par une distribution Linux.
L'attitude de Brad n'est pas constructive. Les développeurs noyau ne veulent pas de son patch, car personne n'est capable de dire de relire son patch et parce qu'il tue les performances.
Je pense qu'il existe un juste milieu entre GRsecurity (lent mais sûr) et aucune sécurité. Comme je l'ai dit, les améliorations liées à la sécurité prises indépendemment ne sont pas efficaces, mais mises bout à bout, ça devient complexe d'écrire un exploit noyau.
[^] # Re: Sécurité: Contournement de kASLR par Brad Spengler (grsecurity)
Posté par Zenitram (site web personnel) . Évalué à -6.
Et alors?
[^] # Re: Sécurité: Contournement de kASLR par Brad Spengler (grsecurity)
Posté par Albert_ . Évalué à 6. Dernière modification le 02 avril 2014 à 12:09.
comme ton lien le montre c'est donc volontaire de la part de Brad Spengle de ne pas integrer upstream et donc il fait de grand effets d'annonce pour faire mousser sa boite.
De tout de facon c'est peut etre super son patch mais bon le probleme de securite numero un n'est toujours pas resolu avec puisque c'est l'interface chaise-clavier.
[^] # Re: Sécurité: Contournement de kASLR par Brad Spengler (grsecurity)
Posté par Thomas Debesse (site web personnel) . Évalué à 3.
Donc y a pas besoin que ce soit dans Linux, Linus peut refuser d’intégrer GRsecurity sans état d’âme, il sait que les intéressés trouveront un support commercial dédié et que donc ça manquera pas, tout le monde est content. \o/
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Sécurité: Contournement de kASLR par Brad Spengler (grsecurity)
Posté par barmic . Évalué à 7.
C'est même pire que ça. Linus ne veut pas intégrer GRsecurity pour que Spengler puisse continuer de vivre de son travail sur la sécurité de linux
^^Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Sécurité: Contournement de kASLR par Brad Spengler (grsecurity)
Posté par CrEv (site web personnel) . Évalué à 9.
En fait c'est juste une variante du fait que « les bugs d'aujourd'hui sont nos emplois de demain » :-)
# Les commentaires de Linus sur les cycles de RC sont-ils bien nécessaires ?
Posté par coid . Évalué à 3.
Pas grand-chose à dire, sinon que ça me paraît quand même superflu de traduire ça à chaque fois. Je ne vois pas ce que ça apporte par rapport aux fonctionnalités. Pas taper, hein. Je salue les traducteurs dévoués. Mais ça m’interpelle quand même. Linus ne dit-il rien de plus intéressant ?
[^] # Re: Les commentaires de Linus sur les cycles de RC sont-ils bien nécessaires ?
Posté par Zarmakuizz (site web personnel) . Évalué à 8.
Il y a quelques années de cela, les commentaires de Linus étaient plus rigolos.
À mon avis, ce n'est pas la partie la plus compliquée de la dépêche noyau, mais ça reste une introduction sympa, ça permet aux gens qui n'ont jamais lu de dépêche noyau d'un peu mieux comprendre comment les choses se passent au sein du noyau, etc. Les habitués peuvent la sauter via le sommaire, ou la lire quand même pour voir s'il y a eu une modification critique.
Commentaire sous licence LPRAB - http://sam.zoy.org/lprab/
[^] # Re: Les commentaires de Linus sur les cycles de RC sont-ils bien nécessaires ?
Posté par Albert_ . Évalué à 4.
Il y a quelques années de cela, les commentaires de Linus étaient plus rigolos.
Depuis il y a un truc qui est passe qui s'appelle le politiquement correct… Mais bon Linus Torvalds craque heureusement encore de temps en temps (cf Nvidia).
[^] # Re: Les commentaires de Linus sur les cycles de RC sont-ils bien nécessaires ?
Posté par arnaudus . Évalué à 10. Dernière modification le 03 avril 2014 à 13:20.
Je pense qu'on pourrait créer très facilement un générateur aléatoire de commentaires de Linux sur les sorties des RC.
[^] # Re: Les commentaires de Linus sur les cycles de RC sont-ils bien nécessaires ?
Posté par Pierre Jarillon (site web personnel) . Évalué à 4.
Les commentaires de Linus permettent de lire tout cela comme on lit un roman d'aventure. Et l'aventure du noyau Linux est tout simplement fantastique.
# Typos
Posté par NilugeKiWi . Évalué à 3.
Typo: AMD CPP -> AMD CCP
[^] # Re: Typos
Posté par Benoît Sibaud (site web personnel) . Évalué à 3.
Corrigé, merci.
[^] # Re: Typos
Posté par oinkoink_daotter . Évalué à 4.
l'UMS après que le pilote Radeon a
(proof)
[^] # Re: Typos
Posté par Benoît Sibaud (site web personnel) . Évalué à 3.
Corrigé, merci.
# statistiques du bouchonnage TCP automatique
Posté par Cyril Chaboisseau (Mastodon) . Évalué à 0.
pour avoir les statistiques sur l'utilisation du bouchon automatique, c'est la commande nstat et non netstat qu'il faut utiliser :
nstat -a | grep TcpExtTCPAutoCorking
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.