Intel va commencer à revoir le design de ses puces pour combler leurs vulnérabilités, Réactions à la publication du 16/03/2018

[Lionel]

Jusqu'à maintenant Intel a agi au cas par cas et dans l'urgence pour minimiser les effets de Spectre et Meltdown sur ses processeurs via des patchs du microcode.
Pour la première fois, Brian Krzanich, CEO de la société, a annoncé les premières mesures de la société pour travailler au niveau du design des puces.
Les premiers produits qui vont en bénéficier seront les Xeon Cascade Lake de huitième génération, qui arriveront au second semestre de l'année.
Pour rappel, la société s'est engagée à patcher 100% des produits commercialisés dans les 5 dernières années et a commencé à le faire aussi sur certains produits plus anciens.

Lien vers le billet original

[Fafnir]

"partitioning", autrement dit "diviser pour régner".

[iAPX]

...
Les premiers produits qui vont en bénéficier seront les Xeon Cascade Lake de huitième génération qui arriveront au second semestre de l'année.
Pour rappel, la société s'est engagée à patcher 100% des produits commercialisés dans les 5 dernières années et a commencé à le faire aussi sur certains produits plus anciens.

Intel ne patche pas la bug de conception, qui est un side-channel du cache L1, commun à beaucoup de fabricants de CPU depuis des temps immémoriaux que pour une fois les gens de moins de 20ans ne peuvent vraiment pas connaître
Intel et les autres, ont patché et/ou conseillé de modifier du code, pour diminuer les risques en limitant les possibilités d'exploitation de cette bug, sans pouvoir la corriger.

Je serais vraiment étonné que le problème initial (side-channel du cache L1) soit fixé sur les Xeon Cascade Lake, et le problème existe aussi sur les niveaux de cache au-dessus (L2, L3 et L4 quand présent), juste moins facile à exploiter!
Il serait possible de le fixer avec une architecture de caches exclusifs (les données situées dans un des niveaux de cache étant absentes des autres niveaux), avec une validation avant d'insérer les données dans le cache L1 (et sans insérer dans L2 ou L3 en intermédiaire, RAM -> L1 et/ou registres puis L1 -> L2 -> L3), mais ça se revoit pas si vite une architecture de cache complète, surtout avec le bus mémoire+QPI entre L2 et L3, ce dernier (et l'optionnel L4) étant des caches du sous-sytème mémoire totalement séparés de l'unité d'exécution.
À noter que ça n'augmenterait pas la latence, sauf dans le cas d'une modification immédiate des données, puisqu'on peut amener les données dans le port de lecture de la CPU sans avoir -encore- altéré le cache L1 (la validation nécessaire)

Ce message a été modifié par iAPX - 16 Mar 2018, 12:34.

[linus]

...
Les premiers produits qui vont en bénéficier seront les Xeon Cascade Lake de huitième génération qui arriveront au second semestre de l'année.
Pour rappel, la société s'est engagée à patcher 100% des produits commercialisés dans les 5 dernières années et a commencé à le faire aussi sur certains produits plus anciens.

Intel ne patche pas la bug de conception, qui est un side-channel du cache L1, commun à beaucoup de fabricants de CPU depuis des temps immémoriaux que pour une fois les gens de moins de 20ans ne peuvent vraiment pas connaître
Intel et les autres, ont patché et/ou conseillé de modifier du code, pour diminuer les risques en limitant les possibilités d'exploitation de cette bug, sans pouvoir la corriger.

Je serais vraiment étonné que le problème initial (side-channel du cache L1) soit fixé sur les Xeon Cascade Lake, et le problème existe aussi sur les niveaux de cache au-dessus (L2, L3 et L4 quand présent), juste moins facile à exploiter!
Il serait possible de le fixer avec une architecture de caches exclusifs (les données situées dans un des niveaux de cache étant absentes des autres niveaux), avec une validation avant d'insérer les données dans le cache L1 (et sans insérer dans L2 ou L3 en intermédiaire, RAM -> L1 et/ou registres puis L1 -> L2 -> L3), mais ça se revoit pas si vite une architecture de cache complète, surtout avec le bus mémoire+QrPI entre L2 et L3, ce dernier (et l'optionnel L4) étant des caches du sous-sytème mémoire totalement séparés de l'unité d'exécution.
À noter que ça n'augmenterait pas la latence, sauf dans le cas d'une modification immédiate des données, puisqu'on peut amener les données dans le port de lecture de la CPU sans avoir -encore- altéré le cache L1 (la validation nécessaire)

intéressant mais je manque de culture pour comprendre vraiment.

[gregoz]

...
Les premiers produits qui vont en bénéficier seront les Xeon Cascade Lake de huitième génération qui arriveront au second semestre de l'année.
Pour rappel, la société s'est engagée à patcher 100% des produits commercialisés dans les 5 dernières années et a commencé à le faire aussi sur certains produits plus anciens.

Intel ne patche pas la bug de conception, qui est un side-channel du cache L1, commun à beaucoup de fabricants de CPU depuis des temps immémoriaux que pour une fois les gens de moins de 20ans ne peuvent vraiment pas connaître
Intel et les autres, ont patché et/ou conseillé de modifier du code, pour diminuer les risques en limitant les possibilités d'exploitation de cette bug, sans pouvoir la corriger.

Je serais vraiment étonné que le problème initial (side-channel du cache L1) soit fixé sur les Xeon Cascade Lake, et le problème existe aussi sur les niveaux de cache au-dessus (L2, L3 et L4 quand présent), juste moins facile à exploiter!
Il serait possible de le fixer avec une architecture de caches exclusifs (les données situées dans un des niveaux de cache étant absentes des autres niveaux), avec une validation avant d'insérer les données dans le cache L1 (et sans insérer dans L2 ou L3 en intermédiaire, RAM -> L1 et/ou registres puis L1 -> L2 -> L3), mais ça se revoit pas si vite une architecture de cache complète, surtout avec le bus mémoire+QPI entre L2 et L3, ce dernier (et l'optionnel L4) étant des caches du sous-sytème mémoire totalement séparés de l'unité d'exécution.
À noter que ça n'augmenterait pas la latence, sauf dans le cas d'une modification immédiate des données, puisqu'on peut amener les données dans le port de lecture de la CPU sans avoir -encore- altéré le cache L1 (la validation nécessaire)

Toi tu jouais pas à cache-cache dans la cour de récréation lol

[iAPX]

...
Les premiers produits qui vont en bénéficier seront les Xeon Cascade Lake de huitième génération qui arriveront au second semestre de l'année.
Pour rappel, la société s'est engagée à patcher 100% des produits commercialisés dans les 5 dernières années et a commencé à le faire aussi sur certains produits plus anciens.

Intel ne patche pas la bug de conception, qui est un side-channel du cache L1, commun à beaucoup de fabricants de CPU depuis des temps immémoriaux que pour une fois les gens de moins de 20ans ne peuvent vraiment pas connaître
Intel et les autres, ont patché et/ou conseillé de modifier du code, pour diminuer les risques en limitant les possibilités d'exploitation de cette bug, sans pouvoir la corriger.

Je serais vraiment étonné que le problème initial (side-channel du cache L1) soit fixé sur les Xeon Cascade Lake, et le problème existe aussi sur les niveaux de cache au-dessus (L2, L3 et L4 quand présent), juste moins facile à exploiter!
Il serait possible de le fixer avec une architecture de caches exclusifs (les données situées dans un des niveaux de cache étant absentes des autres niveaux), avec une validation avant d'insérer les données dans le cache L1 (et sans insérer dans L2 ou L3 en intermédiaire, RAM -> L1 et/ou registres puis L1 -> L2 -> L3), mais ça se revoit pas si vite une architecture de cache complète, surtout avec le bus mémoire+QPI entre L2 et L3, ce dernier (et l'optionnel L4) étant des caches du sous-sytème mémoire totalement séparés de l'unité d'exécution.
À noter que ça n'augmenterait pas la latence, sauf dans le cas d'une modification immédiate des données, puisqu'on peut amener les données dans le port de lecture de la CPU sans avoir -encore- altéré le cache L1 (la validation nécessaire)

Toi tu jouais pas à cache-cache dans la cour de récréation lol

Effectivement à 10ans j'ai commencé une relation amoureuse avec une TI-57 (l'originale pas la médiocre LCD), mais aussi le 8080 plutot que le 6800 que j'ai du me fader au club Microtel pendant des années, et j'étais "différent"

Ce message a été modifié par iAPX - 16 Mar 2018, 23:57.

[zero]

En gros, Intel fait des annonces pour essayer convaincre que leurs CPU tiennent encore la route afin maintenir les ventes jusqu'à ce que les CPU soit vraiment corrigés.
Quant à AMD, elle se fait toute discrete depuis la dernière annonce de failles.

Ce message a été modifié par zero - 17 Mar 2018, 03:22.

[iAPX]

En gros, Intel fait des annonces pour essayer convaincre que leurs CPU tiennent encore la route afin maintenir les ventes jusqu'à ce que les CPU soit vraiment corrigés.
Quant à AMD, elle se fait toute discrete depuis la dernière annonce de failles.

Oui je pense qu'on a un immense problème sur les bras, tenant notamment aux promesses faites sur la virtualisation, depuis les débuts, la plupart n'étant pas tenues (et la plupart les ont oubliées depuis longtemps, comme la migration de hardware en hardware transparente en fonctionnement, les snapshot sans arrêt ni ralentissements, l'upgrade de la VM en CPU ou RAM pendant son fonctionnement, j'en passe et des meilleures), et notamment la sécurité que cela est censé apporter, alors que c'est un net recul en sécurité depuis les origines, comparé à une machine physique!

Le vol des sources de VMware a été une catastrophe, heureusement bien contenue (par le PR surtout, pour éviter que la valeur boursière de EMC puis VMware plonge, du beau travail).
Mais les différentes bugs liées à la virtualisation (ou atteignant sa pseudo-sécurité) affectant depuis au moins une décennie les CPU Intel, qui a un monopole de fait sur les serveurs, c'est vraiment problématique et démontre que le sujet qui a pourtant plus d'une vingtaine d'année sur les micro-ordinateurs est absolument pas maîtrisé (je parle de virtualisation native avec isolation en théorie parfaite, pas d'hyperviseurs existant depuis bien plus longtemps).

C'est le marché sur lequel Intel se replie (lire "The Innovator Dilemma" à ce sujet), et ça mériterait d'être traité extrêmement différemment que juste ajouter quelques fonctions dans une CPU grand-public, mais disposer d'un design où l'isolation absolue et la sécurité soient indiscutablement le but premier, quitte à limiter les performances. Peut-être aussi isoler, par cryptographie hardware (et clés maintenus dans un Vault hardware) les VM de l'hôte.
Là c'est performant et "unsafe at any speed"...

Aujourd'hui, les VM n'apportent rien des promesses faites il y a plus de 20ans, et pas vraiment plus qu'une machine physique, avec la possibilité de migrer le contenu d'une machine physique vers une autre, alors qu'il y a un net déficit en sécurité. Going backkkkwwwarrrrddddsssss



Ce message a été modifié par iAPX - 17 Mar 2018, 15:32.