Discussion :

[Patrick Ruiz]

Intel publie une mise à jour de microcode en prohibant benchmarking et profilage
Ce qui n’est pas du goût des mainteneurs de Linux Debian

Vous êtes un utilisateur de la distribution Linux Debian ? Vous avez besoin des correctifs pour les vulnérabilités L1TF qui affectent les processeurs du fondeur ? Il va falloir attendre que le vent de la controverse s’estompe.

Depuis le mois de janvier, Intel lutte pour maintenir ses processeurs à flot en publiant des correctifs en réponse à diverses vulnérabilités dont les plus célèbres sont Meltdown et Spectre. Jusqu’ici, le fondeur a principalement procédé par la publication de mises à jour de microcode. Pour ôter la tache L1TF de son blouson, la firme a, début août, fait pareil avec une release destinée aux processeurs des utilisateurs des distributions Linux.

« L’on ne peut malheureusement distribuer cette dernière », commente Henrique Holschuh – mainteneur Linux Debian. Le développeur souligne que les paquetages à acheminer aux utilisateurs de la distribution sont prêts depuis le 8 août. Toutefois, pour des raisons liées au contenu du contrat de licence, il décide d’ajourner leur diffusion. Le texte du contrat final d’utilisateur est assez touffu (comme d’habitude), mais si on prend la peine de le parcourir on décèle au sein de la section relative aux restrictions que « l’utilisateur ne pourra (et ne permettra pas à des tiers) de publier ou fournir des résultats de tests de comparaison ou de benchmark logiciel. » En d’autres termes, Intel dit aux utilisateurs qu’ils ne peuvent faire usage du logiciel mis à leur disposition pour jauger les performances de leurs systèmes et informer le public.

Les correctifs de sécurité émis par le fondeur sont connus pour ralentir les processeurs. De précédentes publications parues sur cette plateforme dans le cadre de la couverture relative à la famille de vulnérabilités Meltdown et Spectre font état de pertes de performances de l’ordre de 5 à 10 %. Il y a là un énorme problème pour les gestionnaires de parc de serveurs et les fournisseurs de services dans le nuage. Avec les vulnérabilités L1TF – qui tirent également parti de la fonctionnalité processeur appelée exécution spéculative – ce souci demeure très probablement d’actualité, mais Intel vient sûrement de trouver la parade avec son contrat d’utilisateur final.

À date, les utilisateurs de Linux Debian sont les seuls dans cette situation d’attente. Chez Gentoo, on anticipe sur une parade. Les mainteneurs prévoient de diffuser la mise à jour aux utilisateurs qui accepteront les termes du contrat final d’utilisateur. Les utilisateurs de RedHat et SuSE disposent de mises à jour. D’après ce que rapporte Henrique Holschuh, les mainteneurs de cette distribution sont en accord avec le nouveau contrat de licence d’Intel.

Source : liste de diffusion de bogues Debian, Contrat de licence

Et vous ?

Intel qui publie une mise à jour de microcode avec un contrat final d’utilisateur qui empêche la publication de résultats de tests de performance … Que pensez-vous de cette manœuvre ?

Que pensez-vous de la décision du mainteneur de Debian ?

Quel commentaire faites-vous de la proposition des mainteneurs de la distribution Gentoo ?

Que pensez-vous du positionnement de SuSE et RedHat ?

Voir aussi :

Encore une autre vulnérabilité découverte dans les CPU d'Intel, le fournisseur de microprocesseurs fait des recommandations pour l'atténuer

Spectre/Meltdown : de nouvelles failles dans les processeurs, elles permettent de lire les registres internes, la mémoire kernel et celle de l'hôte

Meltdown et Spectre : Intel abandonne le développement des mises à jour de microcodes pour certains processeurs, une décision qui ne surprend pas

Meltdown et Spectre : Intel recommande l'arrêt du déploiement des correctifs, des soucis avec la microarchitecture Ivy Bridge et suivantes

Vulnérabilités Meltdown et Spectre : Intel devrait livrer ses premiers processeurs dotés de protections intégrées plus tard cette année

[Invité]

Quand je vois tout ce qui se passe avec Intel avec ces failles, leur comportement excécrable et leurs prix bien trop élevés, j'ai hâte de voir AMD revenir de plus en plus et que cette mascarade s'arrête.

[Asmodan]

Oui AMD va avoir le vent en poupe, jusqu'à ce qu'un scandale ou problème s'expose au grand jour ... C'est Tik Tok, une fois l'un une fois l'autre Comme pour ATI et NVIDIA en leur temps.

Le principal est d'avoir des bons produits bien pensés dès la conception...

[phil995511]

Debian n'a pas à prendre ce genre de décisions pour les utilisateurs, c'est à eux de décider ce qu'ils veulent faire... De toute manière si ce contrat ne respecte pas les libertés individuelles de tout un chacun, il est alors illégal donc caduc...

[Vulcania]

@phil995511 debian n'est pas une entreprise privée, ils n'ont aucune obligations. Dans ce cas, si t'es pas d'accord, tu peux installer toi même le microcode.

Et quand bien même le contrat serait illégal, j'ai pas forcément envie d'entamer un bras de fer juridique avec une entreprise de cette taille ^^'

[phil995511]

@ Vulcania

Quand on lance une distribution publique, on se doit d'assurer la sécurité de ses utilisateurs.

Oui on peut patcher nous même, on peut également prendre un noyau linux y rajouter les softs qui nous intéressent développer notre propre distrib, mais bon c'est pas le but !! Ce qu'on recherche via une distribution c'est la loi de l'emmerdement minimal, avoir quelque chose de prêt à être utilisé (par analogie, je ne vais pas au restaurant pour y faire la cuisine). Un tel comportement n'est pas sérieux ni de la part de Intel ni de la part de Debian dont j'utilise un sous-produit, je suis bien déçu par les uns comme par les autres.

Après j'ai peine à croire que Intel te traquerait et déposerait une plainte contre toi pour avoir publié des benchmark relatifs à leurs patchs de sécurité. Et même si ils étaient assez fou pour le faire ils perdraient tout de suite et tu pourrais demander de gros dommages et intérêts, ce sans parler de leur réputation qui en prendrait un coup de plus...

Ce qui est sûr c'est que si on continue de trouver de telles failles de sécurité à ce rythme, on va bientôt se retrouver avec des i7 qui auront la puissance de calcul de x386 (rires). Intel à peut-être tout simplement peur de se retrouver avec des plaintes collectives aux US...

[Kannagi]

Oui on peut patcher nous même, on peut également prendre un noyau linux y rajouter les softs qui nous intéressent développer notre propre distrib, mais bon c'est pas le but !! Ce qu'on recherche via une distribution c'est la loi de l'emmerdement minimal, avoir quelque chose de prêt à être utilisé (par analogie, je ne vais pas au restaurant pour y faire la cuisine). Un tel comportement n'est pas sérieux ni de la part de Intel ni de la part de Debian dont j'utilise un sous-produit, je suis bien déçu par les uns comme par les autres.

Euh c'est peut le cas des autres OS , mais pour Linux j'attends justement de m'emmerder le maximum sur mon ordi pour avoir le maximum de contrôle dessus
(de plus au cas où tu l'ignore , le but de Debian est d’être une distribution totalement libre).
Donc pour ma part rien d'étonnant de la part de Debian comme certaine distribution qui refuse d'utiliser des drivers propriétaires , si cela ne te plais pas tu peux aller sur d'autre distribution qui accepte le micro-code d’Intel

Pour les failles et leur résolution on connais des architectures aussi performantes que celle utiliser actuellement , mais pour diverses raison on a choisi que le compilo n'optimise pas lui même la pipeline est donc de s'occuper de cette optimisation sur le processeur , ce qui a pour effet d'avoir créer ces deux failles entre autre, je trouve dommage que les constructeurs ont choisis cette voie là !

[tabouret]

Pour les failles et leur résolution on connais des architectures aussi performantes que celle utiliser actuellement , mais pour diverses raison on a choisi que le compilo n'optimise pas lui même la pipeline est donc de s'occuper de cette optimisation sur le processeur , ce qui a pour effet d'avoir créer ces deux failles entre autre, je trouve dommage que les constructeurs ont choisis cette voie là !

Une optimisation hardware sera toujours infiniment plus puissante qu'une optimisation logicielle, et ce dans tous les domaines.

[phil995511]

@ Kannagi

Comme je l'ai indiqué ci-dessus, tu devrait te faire ta propre distrib pour en rester le maître si tu as des angoisses à ce sujet.

Quand on lance une distribution publique on a des responsabilités vis-à-vis de ses utilisateurs, soit on la patche avec tout le professionnalisme requis, soit on devrait penser à faire autre chose de sa vie que de s'occuper d'une distrib et laisser la place à ceux qui bossent de manière sérieuse... Le problème chez Debian c'est que certains de leurs développeurs se prennent la tête pour rien et que dans ce cas précis ça fait chier le reste du monde. La "démocratie" à la Debian qui détermine quel chemin doit prendre cette distrib via le vote des développeurs n'apporte pas que du bon à mes yeux... Il y a des règles à ne pas enfreindre, notamment en matière de sécurité et de confidentialité !! Ils devraient avoir conscience qu'ils ne sont pas seuls à bord ou alors faire des trucs rien que pour eux même dans leur petit coin sans les rendre publique.

Te concernant si tu n'est pas en accord avec mes propos libre à toi, tu peux tout aussi bien garder cela pour toi plutôt que de me suggérer d'aller voir ailleurs ce qui est extrêmement impoli de ta part... Pas très mature tout cela à mes yeux...

[Kannagi]

@phil995511 Il existe plein de distrib différente , il y'a sûrement une qui ira avec ta 'philosophie'

Une optimisation hardware sera toujours infiniment plus puissante qu'une optimisation logicielle, et ce dans tous les domaines.

Ben oui et non , c'est ce qui m’inquiète un peu c'est l’incompréhension (même des programmeurs) de comment fonctionne nos processeurs modernes.
L'optimisation des x86 actuelles n'est pas une optimisation qui réduit le temps de cycle a proprement parler , mais de réduire des conflits de la pipeline et donc l'optimisation de la pipeline qu'elle soit faite par le hard ou par le prog/compilo , aucun des deux est mieux que l'autre (tu moment que tu évite tout pipeline stall , tu peux esperer avoir 1 cycle cpu ).
Pour faire simple ça demande en général une réorganisation des instructions et des choix des registres utilisés , soit tu le fait manuellement (comme sur le processeur CELL par exemple) , soit le cpu le fait automatiquement (comme le x86 actuellement ).

[tabouret]

L'optimisation logicielle va uniquement consister à réorganiser ton code pour justement éviter les stall on est d'accord.
Seulement des fois tu ne peux pas vraiment les éviter (et c'est d'ailleurs la ou l’exécution spéculative entre en jeu).

L'optimisation logicielle est assez limité (bah oui une fois que tu as optimisé à mort il te reste à faire quoi?)
Alors que l'optimisation hardware est illimitée (tu rajoutes un étage ou plusieurs à un des 5/7 étages du processeur superscalaire, tu fais des bypass etc..)

[Kannagi]

L'optimisation hardware n'est pas illimité, elle va dépendre de comment le fondeur a fait sa puce , les optimisation OoO ne sont pas illimité , quand il va optimiser a mort il ne va pas pouvoir faire grand chose lui non plus
Et l’exécution spéculatif qui optimise principalement les branchement (d’où le nom de spéculatif , ce n'est une astuce supplémentaire d'éviter de la pipeline , mais au contraire de ne pas attendre), tu peux le faire en in order (juste parce qu'il y'a un delay sur les branchements ,et on général étant superscalaire, tu peux exécuter plusieurs instructions pendant le branchement ).
Et en général quand tu optimise a mort de façon logicielle, tu arrive a une optimisation de 1-2cycle par instruction donc je considère que le but est atteint non ?

[Nb]

@ Kannagi
Quand on lance une distribution publique on a des responsabilités vis-à-vis de ses utilisateurs, soit on la patche avec tout le professionnalisme requis, soit on devrait penser à faire autre chose de sa vie que de s'occuper d'une distrib et laisser la place à ceux qui bossent de manière sérieuse... Le problème chez Debian c'est que certains de leurs développeurs se prennent la tête pour rien et que dans ce cas précis ça fait chier le reste du monde. La "démocratie" à la Debian qui détermine quel chemin doit prendre cette distrib via le vote des développeurs n'apporte pas que du bon à mes yeux... Il y a des règles à ne pas enfreindre, notamment en matière de sécurité et de confidentialité !! Ils devraient avoir conscience qu'ils ne sont pas seuls à bord ou alors faire des trucs rien que pour eux même dans leur petit coin sans les rendre publique.

Oui enfin...si tu installes une Debian c'est à toi d'aller lire la vision qu'ils ont du projet, de comprendre ce que ca implique et de decider en fonction si tu installes ou pas. Et comme l'a dit Kannagi ca n'a rien d'etonnant que la première réaction des gars réellement investis dans Debian soit de refuser de telles pratiques.

Te concernant si tu n'est pas en accord avec mes propos libre à toi, tu peux tout aussi bien garder cela pour toi plutôt que de me suggérer d'aller voir ailleurs ce qui est extrêmement impoli de ta part... Pas très mature tout cela à mes yeux...

Comme quoi chacun voit midi à sa porte. Moi je trouve beaucoup plus choquant ca

soit on la patche avec tout le professionnalisme requis, soit on devrait penser à faire autre chose de sa vie que de s'occuper d'une distrib et laisser la place à ceux qui bossent de manière sérieuse...

... qu'une personne qui conseille à une autre de changer de distrib si celle qu'il utilise ne lui convient pas.
Le libre est exactement là pour ca : te rendre le moins captif possible. Si une distrib ne te convient pas tu peux devenir contributeur et essayer de faire entendre ta voix et si ca ne marche pas, ou que tu n'as pas le temps/motivation/competences pour, tu peux en changer sans aucun probleme car les alternatives ne manquent pas.

[Winnt]

@phil995511

Quand on lance une distribution publique on a des responsabilités vis-à-vis de ses utilisateurs, soit on la patche avec tout le professionnalisme requis, soit on devrait penser à faire autre chose de sa vie que de s'occuper d'une distrib et laisser la place à ceux qui bossent de manière sérieuse... Le problème chez Debian c'est que certains de leurs développeurs se prennent la tête pour rien et que dans ce cas précis ça fait chier le reste du monde. La "démocratie" à la Debian qui détermine quel chemin doit prendre cette distrib via le vote des développeurs n'apporte pas que du bon à mes yeux... Il y a des règles à ne pas enfreindre, notamment en matière de sécurité et de confidentialité !! Ils devraient avoir conscience qu'ils ne sont pas seuls à bord ou alors faire des trucs rien que pour eux même dans leur petit coin sans les rendre publique.

Debian ne te dois rien. Par contre, si tu utilise cette distribution c'est toi qui dois beaucoup à Debian. Lire la partie À propos de Debian devrait être instructif pour toi.

Te concernant si tu n'est pas en accord avec mes propos libre à toi, tu peux tout aussi bien garder cela pour toi plutôt que de me suggérer d'aller voir ailleurs ce qui est extrêmement impoli de ta part... Pas très mature tout cela à mes yeux...

En quoi est-ce être immature que de te conseiller de changer de distribution si le fonctionnement du projet Debian ne te conviens pas ?

[tabouret]

L'optimisation hardware n'est pas illimité, elle va dépendre de comment le fondeur a fait sa puce , les optimisation OoO ne sont pas illimité , quand il va optimiser a mort il ne va pas pouvoir faire grand chose lui non plus
Et l’exécution spéculatif qui optimise principalement les branchement (d’où le nom de spéculatif , ce n'est une astuce supplémentaire d'éviter de la pipeline , mais au contraire de ne pas attendre), tu peux le faire en in order (juste parce qu'il y'a un delay sur les branchements ,et on général étant superscalaire, tu peux exécuter plusieurs instructions pendant le branchement ).
Et en général quand tu optimise a mort de façon logicielle, tu arrive a une optimisation de 1-2cycle par instruction donc je considère que le but est atteint non ?

Qu'est ce que tu appel une optimisation OoO?

Il me semble que l'exécution spéculative concerne uniquement les branchements?

Attend tu appel quoi in order?

Le but n'est pas forcément atteint il y a toujours moyen d'optimiser, surtout de façon hardware.

[Shao Mezzo]

Voici quelques news :

We have simplified the Intel license to make it easier to distribute CPU microcode updates and posted the new version here: https://01.org/mcu-path-license-2018 . As an active member of the open source community, we continue to welcome all feedback and thank the community.

https://twitter.com/imadsousou/statu...80311753072640

La license est directement consultable ici : https://01.org/mcu-path-license-2018


Merci aux mainteneurs Debian, grâce à leur refus, tout le monde va pouvoir profiter de la nouvelle licence.

Certains commentaires précédents sonnent encore plus creux qu'au départ, avec cette news

[Kannagi]

Qu'est ce que tu appel une optimisation OoO?

Il me semble que l'exécution spéculative concerne uniquement les branchements?

Attend tu appel quoi in order?

Le but n'est pas forcément atteint il y a toujours moyen d'optimiser, surtout de façon hardware.

Je crois que tu n'as alors pas compris ce que je dis depuis le début
Oui on peut faire des optimisations hardware bien mais ces optimisations hardware peut profiter aussi à l'optimisation logiciel (comme superscalaire , ou réduite la taille de la pipeline etc etc) , mais ce n'est pas le souci là !
La technologie actuelle est pour l'optimisation de la pipeline tu as deux façon de l'optimisé soit avec un processeur OoO comme le x86 , soit in order (comme le CELL) , je rajouterai que la différence est encore plus grande entre ces deux CPU vu que un a une mémoire cache automatique (donc que le programmeur ne décide pas vraiment de l'organisation de la mémoire cache) , l'autre a l'inverse est manuelle , c'est aux programmeurs de décider ce qu'il y'a dans la mémoire cache (et donc possibilité d'éviter une grande partie des caches miss).
Et effectivement 'exécution spéculative' n'est la que pour les branchements , parce que sur un processeur in order le branchement , tu choisis a peu près les exécutions que tu veux exécuter pendant ce laps de temps.
Et donc je me répète mais les optimisation OoO ne font automatiquement ce que fait une optimisation logiciel (ici un compilo , voir le programmeur lui même) sur un processeur in order pour cela que je ne comprend pas ton argument 'hardware' ,il ne fait absolument rien de spécifique d’où son nom 'Out of order' exécution dans le désordre , qu'on fait manuellement sur certain processeur comme je vient de le dire.
Je dirais même qu'il est plus handicapant vu qu'un compilo , vu que celui ci a une vision plus large des instructions aura une plus grande chance d'éviter les pipeline stall , qu'un processeur OoO qui ne pourra voir que sur quelque instruction à l'avance.

Sinon le but est plus ou moins atteinte quand on arrive a un point de 1 cycle/instructions , c'est le but de ces optimisations depuis 1995
Et il est assez possible de le faire sur certaine architecture (du type in order avec une pipeline courte).

[tabouret]

Je crois que tu n'as alors pas compris ce que je dis depuis le début
Oui on peut faire des optimisations hardware bien mais ces optimisations hardware peut profiter aussi à l'optimisation logiciel (comme superscalaire , ou réduite la taille de la pipeline etc etc) , mais ce n'est pas le souci là !
La technologie actuelle est pour la pipeline tu as deux façon de l'optimisé soit avec un processeur OoO comme le x86 , soit in order (comme le CELL) , je rajouterai que la différence est encore plus grande entre ces deux CPU vu que un a une mémoire cache automatique (donc que le programmeur ne décide pas vraiment de l'organisation de la mémoire cache) , l'autre a l'inverse est manuelle , c'est aux programmeurs de décider ce qu'il y'a dans la mémoire cache (et donc possibilité d'éviter une grande partie des caches miss).
Et effectivement 'exécution spéculative' n'est la que pour les branchements , parce que sur un processeur in order le branchement , tu choisis a peu près les exécutions que tu veux exécuter pendant ce laps de temps.
Et donc je me répète mais les optimisation OoO ne font automatiquement ce que fait une optimisation logiciel (ici un compilo , voir le programmeur lui meme) sur un processeur in order pour cela que je ne comprend pas ton argument 'hardware' ,il ne fait absolument rien de spécifique d’où son nom 'Out of order' exécution dans le désordre , qu'on fait manuellement sur certain processeur comme je vient de le dire.
Je dirais même qu'il est plus handicapant vu qu'un compilo , vu que celui ci a une vision plus large des instructions aura une plus grande chance d'éviter les pipeline stall , qu'un processeur OoO qui ne pourra voir que sur quelque instruction à l'avance.

J’avoue qu'on a du mal a se comprendre

Ok je vois tu parle des exécution dans l'ordre et dans le désordre.

Oula je ne pense pas qu'un programmeur décide ce qu'il y a dans le cache RAM (j'en suis même sur) : c'est la politique du processeur (write-back et write-through) et de la politique de rétention associée : Cache associatif, LRU etc...

Les optimisations in-order ou out-of-order oui je suis d'accord tu peux les faire de manière soft ou hard ça revient au même.
Je parlais des autres optimisations hard : rajout d'étages, de bypass etc... qui elles seront infiniment plus productive que les optimisations soft mais qui ont un coût.

[Kannagi]

J’avoue qu'on a du mal a se comprendre

Ok je vois tu parle des exécution dans l'ordre et dans le désordre.

Oula je ne pense pas qu'un programmeur décide ce qu'il y a dans le cache RAM (j'en suis même sur) : c'est la politique du processeur (write-back et write-through) et de la politique de rétention associée : Cache associatif, LRU etc...

Les optimisations in-order ou out-of-order oui je suis d'accord tu peux les faire de manière soft ou hard ça revient au même.

Ok , bon on est d'accord , et moi ce que je disais , c'est que les failles actuelle sont comme tu le sais a une optimisation spécifique OoO , alors que si on était rester sur du In order , on aurait pas eu ce souci là ! (Enfin je dis cela mais ça n'aurait pas était facile sur l'architecture PC de passer sur une telle architecture).
Pour la mémoire cache , oui tu as raison qu'on ne peut pas décider de ce qu'il y a dedans (sur un X86 et un ARM) , ce n'est pas le cas sur certain processeur

Je parlais des autres optimisations hard : rajout d'étages, de bypass etc... qui elles seront infiniment plus productive que les optimisations soft mais qui ont un coût.

Juste le 'infiniment' me gêne , sur l'antique console PS2 , tu pouvais on faisant une optimisation soft éviter tout les pipeline stall et donc avoir les instructions SIMD et la division pour un coût d'un cycle
Le rajout d'étage , et du principalement a cause des pipelines assez longue , et comme elle sont plus longue tu es obligé de rajouter des étages !
Surtout que sur un processeur OoO qui va l'utiliser pour exécuter d'autre instruction en même temps (via exécution spéculatif ou autre par exemple).
De même que pour le bypass il me semble , ce ne sont pas des 'optimisations ' pour réduire le taux de cycle mais encore une fois résoudre un souci de pipeline ou voir même résoudre un souci spécifique au processeur OoO

[Patrick Ruiz]

Intel met fin à la controverse liée à une mise à jour de microcode pour distributions Linux
Avec une licence qui permet le benchmarking

Un responsable de l’axe open source d’Intel a fait une apparition sur les réseaux sociaux. Par sa voix, le fondeur annonce qu’une nouvelle version de licence pour les mises à jour de microcode est disponible.

Imad Sousou parle bien de « simplification » dans son intervention, ce qui laisse filtrer que cette mouture de licence fait suite à une précédente. En effet, le fondeur a, au début de ce mois (le 7 août pour être précis), procédé à la publication d’une mise à jour de microcode (à l’intention des utilisateurs des distributions Linux) en guise de correctifs des vulnérabilités L1TF. Les mainteneurs des diverses distributions du système d’exploitation open source se sont attelés à l’apprêter. Du côté de Debian, le paquetage est prêt depuis le 8 août. Toutefois, sa diffusion est ajournée au motif de ce que le mainteneur a relevé que la licence stipule que « l’utilisateur ne pourra (et ne permettra pas à des tiers) de publier ou fournir des résultats de tests de comparaison ou de benchmark logiciel. »

Ainsi, avec l’ancien contrat d’utilisateur, Intel disait aux utilisateurs qu’ils ne peuvent faire usage du logiciel mis à leur disposition pour jauger les performances de leurs systèmes et informer le public. Difficile de ne pas entrevoir une manœuvre du fondeur destinée à empêcher que les résultats de benchmark de tiers ne viennent contredire les siens, surtout que l’application des correctifs est connue pour créer des pertes de performance des processeurs.

Le refus des mainteneurs de Debian, ainsi que les critiques de figures de proue de l’open source comme Bruce Perens ont donc porté du fruit. Intel a fait marche arrière en publiant une version de licence qui n’inclut plus la clause controversée, mais focalise sur les aspects de redistribution.

Henrique Holschuh – mainteneur Linux Debian – avait fait savoir que rien ne bougerait sans qu’Intel ne clarifie les termes de son contrat de licence. La publication de la nouvelle version veut dire que les utilisateurs de cette distribution peuvent déjà jouir des correctifs sur leurs ordinateurs. Elle vient également simplifier la vie à l’équipe Gentoo qui avait décidé de diffuser la mise à jour aux utilisateurs qui accepteraient les termes de l’ancien contrat final d’utilisateur.

Source : Intel Open Source

Et vous ?

Qu’en pensez-vous ?

Le fondeur avait-il le choix ? Pouvait-il décider de ne pas modifier la licence ?

Quels sont les aspects qui continuent de vous poser des problèmes au sein de cette nouvelle version de licence ?

Voir aussi :

Encore une autre vulnérabilité découverte dans les CPU d'Intel, le fournisseur de microprocesseurs fait des recommandations pour l'atténuer

Spectre/Meltdown : de nouvelles failles dans les processeurs, elles permettent de lire les registres internes, la mémoire kernel et celle de l'hôte

Meltdown et Spectre : Intel abandonne le développement des mises à jour de microcodes pour certains processeurs, une décision qui ne surprend pas

Meltdown et Spectre : Intel recommande l'arrêt du déploiement des correctifs, des soucis avec la microarchitecture Ivy Bridge et suivantes

Vulnérabilités Meltdown et Spectre : Intel devrait livrer ses premiers processeurs dotés de protections intégrées plus tard cette année