Patch de s=c3=a9curit=c3=a9 =c3=a0 cause des chips Intel
34 réponses
Rambo
On va recevoir en windows-update deux patchs pour contrer les deux
trous(ou 3) de sécurité des chip Intel découvert récemment.
On indique que ce sera de même pour Linux.
https://www.theregister.co.uk/2018/01/02/intel_cpu_design_flaw/
and
https://www.theregister.co.uk/2018/01/04/intel_amd_arm_cpu_vulnerability/
These have been helpfully grouped into two logo'd and branded
vulnerabilities: Meltdown <https://meltdownattack.com> (Variant 3), and
Spectre <https://spectreattack.com/> (Variants 1 and 2).
Comment faire pour bénéficier des corrections de ces trous de sécurité
lorsqu'on utilise Linux-Mint-Cinnamon ?
Est-ce automatique ?
In fr.comp.os.linux.configuration Michel Talon wrote:
Le 05/01/2018 à 09:48, Pierre www.zetrader.fr a écrit : utilisable, finalement par des chercheurs de Google qui ont montré que ça permettait de lire rapidement toute la mémoire de la machine à
Ou potentiellement de la modifier, en utilisant une attaque contre les bits cosanguins de DRAM https://googleprojectzero.blogspot.ch/2015/03/exploiting-dram-rowhammer-bug-to-gain.html
In fr.comp.os.linux.configuration Michel Talon <talon@niobe.lpthe.jussieu.fr> wrote:
Le 05/01/2018 à 09:48, Pierre www.zetrader.fr a écrit :
utilisable, finalement par des chercheurs de Google qui ont montré que
ça permettait de lire rapidement toute la mémoire de la machine à
Ou potentiellement de la modifier, en utilisant une attaque contre
les bits cosanguins de DRAM
In fr.comp.os.linux.configuration Michel Talon wrote:
Le 05/01/2018 à 09:48, Pierre www.zetrader.fr a écrit : utilisable, finalement par des chercheurs de Google qui ont montré que ça permettait de lire rapidement toute la mémoire de la machine à
Ou potentiellement de la modifier, en utilisant une attaque contre les bits cosanguins de DRAM https://googleprojectzero.blogspot.ch/2015/03/exploiting-dram-rowhammer-bug-to-gain.html
JKB
Le Fri, 5 Jan 2018 10:53:14 +0100, Michel Talon écrivait :
Le 05/01/2018 à 09:48, Pierre www.zetrader.fr a écrit :
Tiens, je ne savais pas qu'AMD était touché aussi. Mais c'est quoi le problème plus exactement ? J'ai entendu dire à la radio ce matin que c'est une faille qui n'a jamais exploité au niveau sécurité, mais que cela ralentirait le processeur cette faille.
La faille concerne le partage des données via les caches entre différents fils d'exécution en utilisant l'exécution "spéculative" des branches et le timing précis du moment où les opérations sont "retirées". Elle a été découverte il y a longtemps par un développeur de FreeBSD, Colin Percival en 2009 http://www.daemonology.net/papers/htt.pdf à l'époque je me souviens que les habituels linuxiens tels que Torvalds rigolaient. Depuis elle a été perfectionnée par des universitaires, Autrichiens, Français, etc. qui ont montré que c'était rééllement utilisable, finalement par des chercheurs de Google qui ont montré que ça permettait de lire rapidement toute la mémoire de la machine à partir d'un simple processus utilisateur, en particulier toutes les données protégées du noyau, les clés de cryptage, etc. Ce qui veut dire qu'il n'y a plus aucune sécurité sur un PC, même en cryptant les données. La faille existe sur tous les processeurs y compris les arm qui se trouvent dans les téléphones portables. Il paraît que les processeurs AMD sont moins atteints. Le correctif de sécurité consiste à vider tous les caches quand on passe du mode utilisateur au mode noyau et vice versa, ce qui entraîne une perte de performance énorme sur les processus faisant beaucoup d'entrées sorties. Bref c'est une catastrophe majeure pour les fournisseurs de "cloud" Google, Amazon, etc. pour l'utilisation de PC dans des domaines sensibles (transactions bancaires, etc.). Il paraît que le PDG de Intel a vendu un gros paquet d'actions il y a 6 mois, ce qui sent bon le délit d'initié.
Et ce n'est qu'une petite partie des problèmes détectés sur ces processeurs. Il y a un défaut de conception de fond sur les x86 (et les arm, bizarrement aussi touchés parce affublés du même défaut de conception). L'ABI de ces processeurs est moisie et contraint à des contorsions de la logique séquentielle pour des raisons de compatibilité. Il est même étonnant qu'il n'y ait pas plus de problèmes. Étrangement, les processeurs plus "propres" (i2 et i4) d'Intel ne sont pas affectés. JKB -- Si votre demande me parvient sur carte perforée, je titiouaillerai très volontiers une réponse... => http://grincheux.de-charybde-en-scylla.fr => http://loubardes.de-charybde-en-scylla.fr
Le Fri, 5 Jan 2018 10:53:14 +0100,
Michel Talon <talon@niobe.lpthe.jussieu.fr> écrivait :
Le 05/01/2018 à 09:48, Pierre www.zetrader.fr a écrit :
Tiens, je ne savais pas qu'AMD était touché aussi.
Mais c'est quoi le problème plus exactement ?
J'ai entendu dire à la radio ce matin que c'est une faille qui n'a
jamais exploité au niveau sécurité, mais que cela ralentirait le
processeur cette faille.
La faille concerne le partage des données via les caches entre
différents fils d'exécution en utilisant l'exécution "spéculative"
des branches et le timing précis du moment où les opérations sont
"retirées". Elle a été découverte il y a longtemps par un développeur de
FreeBSD, Colin Percival en 2009
http://www.daemonology.net/papers/htt.pdf
à l'époque je me souviens que les habituels linuxiens tels que Torvalds
rigolaient. Depuis elle a été perfectionnée par des universitaires,
Autrichiens, Français, etc. qui ont montré que c'était rééllement
utilisable, finalement par des chercheurs de Google qui ont montré que
ça permettait de lire rapidement toute la mémoire de la machine à
partir d'un simple processus utilisateur, en particulier toutes les
données protégées du noyau, les clés de cryptage, etc. Ce qui veut dire
qu'il n'y a plus aucune sécurité sur un PC, même en cryptant les
données. La faille existe sur tous les processeurs y compris les arm qui
se trouvent dans les téléphones portables. Il paraît que les processeurs
AMD sont moins atteints. Le correctif de sécurité consiste à vider tous
les caches quand on passe du mode utilisateur au mode noyau et vice
versa, ce qui entraîne une perte de performance énorme sur les processus
faisant beaucoup d'entrées sorties. Bref c'est une catastrophe majeure
pour les fournisseurs de "cloud" Google, Amazon, etc. pour l'utilisation
de PC dans des domaines sensibles (transactions bancaires, etc.). Il
paraît que le PDG de Intel a vendu un gros paquet d'actions il y a 6
mois, ce qui sent bon le délit d'initié.
Et ce n'est qu'une petite partie des problèmes détectés sur ces
processeurs. Il y a un défaut de conception de fond sur les x86 (et
les arm, bizarrement aussi touchés parce affublés du même défaut de
conception). L'ABI de ces processeurs est moisie et contraint à des
contorsions de la logique séquentielle pour des raisons de
compatibilité. Il est même étonnant qu'il n'y ait pas plus de
problèmes.
Étrangement, les processeurs plus "propres" (i2 et i4) d'Intel ne
sont pas affectés.
JKB
--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr
=> http://loubardes.de-charybde-en-scylla.fr
Le Fri, 5 Jan 2018 10:53:14 +0100, Michel Talon écrivait :
Le 05/01/2018 à 09:48, Pierre www.zetrader.fr a écrit :
Tiens, je ne savais pas qu'AMD était touché aussi. Mais c'est quoi le problème plus exactement ? J'ai entendu dire à la radio ce matin que c'est une faille qui n'a jamais exploité au niveau sécurité, mais que cela ralentirait le processeur cette faille.
La faille concerne le partage des données via les caches entre différents fils d'exécution en utilisant l'exécution "spéculative" des branches et le timing précis du moment où les opérations sont "retirées". Elle a été découverte il y a longtemps par un développeur de FreeBSD, Colin Percival en 2009 http://www.daemonology.net/papers/htt.pdf à l'époque je me souviens que les habituels linuxiens tels que Torvalds rigolaient. Depuis elle a été perfectionnée par des universitaires, Autrichiens, Français, etc. qui ont montré que c'était rééllement utilisable, finalement par des chercheurs de Google qui ont montré que ça permettait de lire rapidement toute la mémoire de la machine à partir d'un simple processus utilisateur, en particulier toutes les données protégées du noyau, les clés de cryptage, etc. Ce qui veut dire qu'il n'y a plus aucune sécurité sur un PC, même en cryptant les données. La faille existe sur tous les processeurs y compris les arm qui se trouvent dans les téléphones portables. Il paraît que les processeurs AMD sont moins atteints. Le correctif de sécurité consiste à vider tous les caches quand on passe du mode utilisateur au mode noyau et vice versa, ce qui entraîne une perte de performance énorme sur les processus faisant beaucoup d'entrées sorties. Bref c'est une catastrophe majeure pour les fournisseurs de "cloud" Google, Amazon, etc. pour l'utilisation de PC dans des domaines sensibles (transactions bancaires, etc.). Il paraît que le PDG de Intel a vendu un gros paquet d'actions il y a 6 mois, ce qui sent bon le délit d'initié.
Et ce n'est qu'une petite partie des problèmes détectés sur ces processeurs. Il y a un défaut de conception de fond sur les x86 (et les arm, bizarrement aussi touchés parce affublés du même défaut de conception). L'ABI de ces processeurs est moisie et contraint à des contorsions de la logique séquentielle pour des raisons de compatibilité. Il est même étonnant qu'il n'y ait pas plus de problèmes. Étrangement, les processeurs plus "propres" (i2 et i4) d'Intel ne sont pas affectés. JKB -- Si votre demande me parvient sur carte perforée, je titiouaillerai très volontiers une réponse... => http://grincheux.de-charybde-en-scylla.fr => http://loubardes.de-charybde-en-scylla.fr
Michel Talon
Le 05/01/2018 à 11:02, JKB a écrit :
Et ce n'est qu'une petite partie des problèmes détectés sur ces processeurs. Il y a un défaut de conception de fond sur les x86 (et les arm, bizarrement aussi touchés parce affublés du même défaut de conception). L'ABI de ces processeurs est moisie et contraint à des contorsions de la logique séquentielle pour des raisons de compatibilité. Il est même étonnant qu'il n'y ait pas plus de problèmes. Étrangement, les processeurs plus "propres" (i2 et i4) d'Intel ne sont pas affectés. JKB
Je viens de lire l'article suivant qui donne une idée d'un des problèmes et d'une solution possible, qui suppose de modifier le compilateur et de recompiler tout - un moindre mal: https://support.google.com/faqs/answer/7625886 Sinon l'article de Google qui décrit les exploits est ici: https://googleprojectzero.blogspot.fr/2018/01/reading-privileged-memory-with-side.html Sinon le problème vient, semble t'il non pas de la conception moisie des processeurs x86 mais au contraire des raffinements qui, pour augmenter la performance, mettent plusieurs coeurs dans le même processeur, se partageant les caches, et faisant de l'exécution "spéculative" des branches, c'est à dire quand il y a une branche exécutent les deux cotés de la branche jusqu'au moment où on sait quel était le bon, autrement dit parallélisent au maximum l'exécution. D'ailleurs la preuve en est que les processeurs ARM, qui sont de conception complètement différente, sont aussi atteints. -- Michel Talon
Le 05/01/2018 à 11:02, JKB a écrit :
Et ce n'est qu'une petite partie des problèmes détectés sur ces
processeurs. Il y a un défaut de conception de fond sur les x86 (et
les arm, bizarrement aussi touchés parce affublés du même défaut de
conception). L'ABI de ces processeurs est moisie et contraint à des
contorsions de la logique séquentielle pour des raisons de
compatibilité. Il est même étonnant qu'il n'y ait pas plus de
problèmes.
Étrangement, les processeurs plus "propres" (i2 et i4) d'Intel ne
sont pas affectés.
JKB
Je viens de lire l'article suivant qui donne une idée d'un des problèmes
et d'une solution possible, qui suppose de modifier le compilateur et de
recompiler tout - un moindre mal:
https://support.google.com/faqs/answer/7625886
Sinon l'article de Google qui décrit les exploits est ici:
https://googleprojectzero.blogspot.fr/2018/01/reading-privileged-memory-with-side.html
Sinon le problème vient, semble t'il non pas de la conception moisie des
processeurs x86 mais au contraire des raffinements qui, pour augmenter
la performance, mettent plusieurs coeurs dans le même processeur, se
partageant les caches, et faisant de l'exécution "spéculative" des
branches, c'est à dire quand il y a une branche exécutent les deux cotés
de la branche jusqu'au moment où on sait quel était le bon, autrement
dit parallélisent au maximum l'exécution. D'ailleurs la preuve en est
que les processeurs ARM, qui sont de conception complètement différente,
sont aussi atteints.
Et ce n'est qu'une petite partie des problèmes détectés sur ces processeurs. Il y a un défaut de conception de fond sur les x86 (et les arm, bizarrement aussi touchés parce affublés du même défaut de conception). L'ABI de ces processeurs est moisie et contraint à des contorsions de la logique séquentielle pour des raisons de compatibilité. Il est même étonnant qu'il n'y ait pas plus de problèmes. Étrangement, les processeurs plus "propres" (i2 et i4) d'Intel ne sont pas affectés. JKB
Je viens de lire l'article suivant qui donne une idée d'un des problèmes et d'une solution possible, qui suppose de modifier le compilateur et de recompiler tout - un moindre mal: https://support.google.com/faqs/answer/7625886 Sinon l'article de Google qui décrit les exploits est ici: https://googleprojectzero.blogspot.fr/2018/01/reading-privileged-memory-with-side.html Sinon le problème vient, semble t'il non pas de la conception moisie des processeurs x86 mais au contraire des raffinements qui, pour augmenter la performance, mettent plusieurs coeurs dans le même processeur, se partageant les caches, et faisant de l'exécution "spéculative" des branches, c'est à dire quand il y a une branche exécutent les deux cotés de la branche jusqu'au moment où on sait quel était le bon, autrement dit parallélisent au maximum l'exécution. D'ailleurs la preuve en est que les processeurs ARM, qui sont de conception complètement différente, sont aussi atteints. -- Michel Talon
JKB
Le Fri, 5 Jan 2018 12:01:49 +0100, Michel Talon écrivait :
Le 05/01/2018 à 11:02, JKB a écrit :
Et ce n'est qu'une petite partie des problèmes détectés sur ces processeurs. Il y a un défaut de conception de fond sur les x86 (et les arm, bizarrement aussi touchés parce affublés du même défaut de conception). L'ABI de ces processeurs est moisie et contraint à des contorsions de la logique séquentielle pour des raisons de compatibilité. Il est même étonnant qu'il n'y ait pas plus de problèmes. Étrangement, les processeurs plus "propres" (i2 et i4) d'Intel ne sont pas affectés. JKB
Je viens de lire l'article suivant qui donne une idée d'un des problèmes et d'une solution possible, qui suppose de modifier le compilateur et de recompiler tout - un moindre mal: https://support.google.com/faqs/answer/7625886 Sinon l'article de Google qui décrit les exploits est ici: https://googleprojectzero.blogspot.fr/2018/01/reading-privileged-memory-with-side.html Sinon le problème vient, semble t'il non pas de la conception moisie des processeurs x86 mais au contraire des raffinements qui, pour augmenter la performance, mettent plusieurs coeurs dans le même processeur, se partageant les caches, et faisant de l'exécution "spéculative" des branches, c'est à dire quand il y a une branche exécutent les deux cotés de la branche jusqu'au moment où on sait quel était le bon, autrement dit parallélisent au maximum l'exécution. D'ailleurs la preuve en est que les processeurs ARM, qui sont de conception complètement différente, sont aussi atteints.
Encore une fois, tu refuses de comprendre. Les ABI moisies (longueurs d'instructions différentes) font que la logique séquentielle est beaucoup, mais beaucoup plus compliquée que celle d'un vrai RISC (MIPS, AXP, Sparc...), l'ARM n'étant plus un RISC au sens originel du terme. Deux solutions pour sortir de l'ornière : définir tous les états de la machine (ce qui empêche une haute fréquence d'horloge en raison des temps de propagation et une consommation accrue) ou considérer l'introduction d'états indéterminés en croisant les droits pour qu'ils ne soient jamais atteints. Pour la consommation et la simplification du CPU, on a choisi la seconde solution. L'ARM est peut-être d'une conception totalement différente, mais la logique séquentielle est entachée du même défaut pour exactement les mêmes raisons. Les mêmes causes conduisant aux mêmes effets... JKB -- Si votre demande me parvient sur carte perforée, je titiouaillerai très volontiers une réponse... => http://grincheux.de-charybde-en-scylla.fr => http://loubardes.de-charybde-en-scylla.fr
Le Fri, 5 Jan 2018 12:01:49 +0100,
Michel Talon <talon@niobe.lpthe.jussieu.fr> écrivait :
Le 05/01/2018 à 11:02, JKB a écrit :
Et ce n'est qu'une petite partie des problèmes détectés sur ces
processeurs. Il y a un défaut de conception de fond sur les x86 (et
les arm, bizarrement aussi touchés parce affublés du même défaut de
conception). L'ABI de ces processeurs est moisie et contraint à des
contorsions de la logique séquentielle pour des raisons de
compatibilité. Il est même étonnant qu'il n'y ait pas plus de
problèmes.
Étrangement, les processeurs plus "propres" (i2 et i4) d'Intel ne
sont pas affectés.
JKB
Je viens de lire l'article suivant qui donne une idée d'un des problèmes
et d'une solution possible, qui suppose de modifier le compilateur et de
recompiler tout - un moindre mal:
https://support.google.com/faqs/answer/7625886
Sinon l'article de Google qui décrit les exploits est ici:
https://googleprojectzero.blogspot.fr/2018/01/reading-privileged-memory-with-side.html
Sinon le problème vient, semble t'il non pas de la conception moisie des
processeurs x86 mais au contraire des raffinements qui, pour augmenter
la performance, mettent plusieurs coeurs dans le même processeur, se
partageant les caches, et faisant de l'exécution "spéculative" des
branches, c'est à dire quand il y a une branche exécutent les deux cotés
de la branche jusqu'au moment où on sait quel était le bon, autrement
dit parallélisent au maximum l'exécution. D'ailleurs la preuve en est
que les processeurs ARM, qui sont de conception complètement différente,
sont aussi atteints.
Encore une fois, tu refuses de comprendre. Les ABI moisies
(longueurs d'instructions différentes) font que la logique
séquentielle est beaucoup, mais beaucoup plus compliquée que celle
d'un vrai RISC (MIPS, AXP, Sparc...), l'ARM n'étant plus un RISC au
sens originel du terme. Deux solutions pour sortir de l'ornière :
définir tous les états de la machine (ce qui empêche une haute
fréquence d'horloge en raison des temps de propagation et une
consommation accrue) ou considérer l'introduction d'états indéterminés
en croisant les droits pour qu'ils ne soient jamais atteints.
Pour la consommation et la simplification du CPU, on a choisi la
seconde solution.
L'ARM est peut-être d'une conception totalement différente, mais la
logique séquentielle est entachée du même défaut pour exactement les
mêmes raisons. Les mêmes causes conduisant aux mêmes effets...
JKB
--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr
=> http://loubardes.de-charybde-en-scylla.fr
Le Fri, 5 Jan 2018 12:01:49 +0100, Michel Talon écrivait :
Le 05/01/2018 à 11:02, JKB a écrit :
Et ce n'est qu'une petite partie des problèmes détectés sur ces processeurs. Il y a un défaut de conception de fond sur les x86 (et les arm, bizarrement aussi touchés parce affublés du même défaut de conception). L'ABI de ces processeurs est moisie et contraint à des contorsions de la logique séquentielle pour des raisons de compatibilité. Il est même étonnant qu'il n'y ait pas plus de problèmes. Étrangement, les processeurs plus "propres" (i2 et i4) d'Intel ne sont pas affectés. JKB
Je viens de lire l'article suivant qui donne une idée d'un des problèmes et d'une solution possible, qui suppose de modifier le compilateur et de recompiler tout - un moindre mal: https://support.google.com/faqs/answer/7625886 Sinon l'article de Google qui décrit les exploits est ici: https://googleprojectzero.blogspot.fr/2018/01/reading-privileged-memory-with-side.html Sinon le problème vient, semble t'il non pas de la conception moisie des processeurs x86 mais au contraire des raffinements qui, pour augmenter la performance, mettent plusieurs coeurs dans le même processeur, se partageant les caches, et faisant de l'exécution "spéculative" des branches, c'est à dire quand il y a une branche exécutent les deux cotés de la branche jusqu'au moment où on sait quel était le bon, autrement dit parallélisent au maximum l'exécution. D'ailleurs la preuve en est que les processeurs ARM, qui sont de conception complètement différente, sont aussi atteints.
Encore une fois, tu refuses de comprendre. Les ABI moisies (longueurs d'instructions différentes) font que la logique séquentielle est beaucoup, mais beaucoup plus compliquée que celle d'un vrai RISC (MIPS, AXP, Sparc...), l'ARM n'étant plus un RISC au sens originel du terme. Deux solutions pour sortir de l'ornière : définir tous les états de la machine (ce qui empêche une haute fréquence d'horloge en raison des temps de propagation et une consommation accrue) ou considérer l'introduction d'états indéterminés en croisant les droits pour qu'ils ne soient jamais atteints. Pour la consommation et la simplification du CPU, on a choisi la seconde solution. L'ARM est peut-être d'une conception totalement différente, mais la logique séquentielle est entachée du même défaut pour exactement les mêmes raisons. Les mêmes causes conduisant aux mêmes effets... JKB -- Si votre demande me parvient sur carte perforée, je titiouaillerai très volontiers une réponse... => http://grincheux.de-charybde-en-scylla.fr => http://loubardes.de-charybde-en-scylla.fr
Jo Engo
Le Fri, 05 Jan 2018 10:02:40 +0000, JKB a écrit :
Étrangement, les processeurs plus "propres" (i2 et i4) d'Intel ne sont pas affectés.
Et les i3 ? -- Le doute me ronge. Et si tout n'était qu'illusion ? Si rien n'existait ? Dans ce cas, j'aurais payé ma moquette beaucoup trop cher. -+- Woody Allen -+-
Le Fri, 05 Jan 2018 10:02:40 +0000, JKB a écrit :
Étrangement, les processeurs plus "propres" (i2 et i4) d'Intel ne sont
pas affectés.
Et les i3 ?
--
Le doute me ronge. Et si tout n'était qu'illusion ? Si rien n'existait ?
Dans ce cas, j'aurais payé ma moquette beaucoup trop cher.
-+- Woody Allen -+-
Étrangement, les processeurs plus "propres" (i2 et i4) d'Intel ne sont pas affectés.
Et les i3 ? -- Le doute me ronge. Et si tout n'était qu'illusion ? Si rien n'existait ? Dans ce cas, j'aurais payé ma moquette beaucoup trop cher. -+- Woody Allen -+-
JKB
Le 05 Jan 2018 13:17:37 GMT, Jo Engo écrivait :
Le Fri, 05 Jan 2018 10:02:40 +0000, JKB a écrit :
Étrangement, les processeurs plus "propres" (i2 et i4) d'Intel ne sont pas affectés.
Et les i3 ?
Les i3/i5/i7/i9 sont des x86 64 bits. Les i2/i4 sont des IA64. JKB -- Si votre demande me parvient sur carte perforée, je titiouaillerai très volontiers une réponse... => http://grincheux.de-charybde-en-scylla.fr => http://loubardes.de-charybde-en-scylla.fr
Le 05 Jan 2018 13:17:37 GMT,
Jo Engo <yl@icite.fr> écrivait :
Le Fri, 05 Jan 2018 10:02:40 +0000, JKB a écrit :
Étrangement, les processeurs plus "propres" (i2 et i4) d'Intel ne sont
pas affectés.
Et les i3 ?
Les i3/i5/i7/i9 sont des x86 64 bits. Les i2/i4 sont des IA64.
JKB
--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr
=> http://loubardes.de-charybde-en-scylla.fr
Étrangement, les processeurs plus "propres" (i2 et i4) d'Intel ne sont pas affectés.
Et les i3 ?
Les i3/i5/i7/i9 sont des x86 64 bits. Les i2/i4 sont des IA64. JKB -- Si votre demande me parvient sur carte perforée, je titiouaillerai très volontiers une réponse... => http://grincheux.de-charybde-en-scylla.fr => http://loubardes.de-charybde-en-scylla.fr
Alain
On 05/01/2018 09:48, Pierre www.zetrader.fr wrote:
............. Mais c'est quoi le problème plus exactement ? J'ai entendu dire à la radio ce matin que c'est une faille qui n'a jamais exploité au niveau sécurité, mais que cela ralentirait le processeur cette faille.
Voici ce qu'en dit Intel ; il me semble que c'est assez bien organisé chez eux : https://www.intel.com/content/www/us/en/architecture-and-technology/facts-about-side-channel-analysis-and-intel-products.html a+
On 05/01/2018 09:48, Pierre www.zetrader.fr wrote:
.............
Mais c'est quoi le problème plus exactement ?
J'ai entendu dire à la radio ce matin que c'est une faille qui n'a
jamais exploité au niveau sécurité, mais que cela ralentirait le
processeur cette faille.
Voici ce qu'en dit Intel ; il me semble que c'est assez bien organisé
chez eux :
On 05/01/2018 09:48, Pierre www.zetrader.fr wrote:
............. Mais c'est quoi le problème plus exactement ? J'ai entendu dire à la radio ce matin que c'est une faille qui n'a jamais exploité au niveau sécurité, mais que cela ralentirait le processeur cette faille.
Voici ce qu'en dit Intel ; il me semble que c'est assez bien organisé chez eux : https://www.intel.com/content/www/us/en/architecture-and-technology/facts-about-side-channel-analysis-and-intel-products.html a+
Pierre www.zetrader.fr
Le 05/01/2018 à 23:14, Alain a écrit :
On 05/01/2018 09:48, Pierre www.zetrader.fr wrote:
............. Mais c'est quoi le problème plus exactement ? J'ai entendu dire à la radio ce matin que c'est une faille qui n'a jamais exploité au niveau sécurité, mais que cela ralentirait le processeur cette faille.
Voici ce qu'en dit Intel ; il me semble que c'est assez bien organisé chez eux : https://www.intel.com/content/www/us/en/architecture-and-technology/facts-about-side-channel-analysis-and-intel-products.html a+
Il faut déjà le Malware installé sur l'ordi, sur Linux ça va c'est pas courant, sur d'autres systèmes c'est un poil plus courant... ;) -- http://zetrader.info & http://zetrader.fr http://aribaut.com - http://zeforums.com
Le 05/01/2018 à 23:14, Alain a écrit :
On 05/01/2018 09:48, Pierre www.zetrader.fr wrote:
............. Mais c'est quoi le problème plus exactement ?
J'ai entendu dire à la radio ce matin que c'est une faille qui n'a
jamais exploité au niveau sécurité, mais que cela ralentirait le
processeur cette faille.
Voici ce qu'en dit Intel ; il me semble que c'est assez bien organisé
chez eux :
Il faut déjà le Malware installé sur l'ordi, sur Linux ça va c'est pas
courant, sur d'autres systèmes c'est un poil plus courant... ;)
--
http://zetrader.info & http://zetrader.fr
http://aribaut.com - http://zeforums.com
On 05/01/2018 09:48, Pierre www.zetrader.fr wrote:
............. Mais c'est quoi le problème plus exactement ? J'ai entendu dire à la radio ce matin que c'est une faille qui n'a jamais exploité au niveau sécurité, mais que cela ralentirait le processeur cette faille.
Voici ce qu'en dit Intel ; il me semble que c'est assez bien organisé chez eux : https://www.intel.com/content/www/us/en/architecture-and-technology/facts-about-side-channel-analysis-and-intel-products.html a+
Il faut déjà le Malware installé sur l'ordi, sur Linux ça va c'est pas courant, sur d'autres systèmes c'est un poil plus courant... ;) -- http://zetrader.info & http://zetrader.fr http://aribaut.com - http://zeforums.com
Pascal Hambourg
Le 06/01/2018 à 09:18, Pierre www.zetrader.fr a écrit :
Le 05/01/2018 à 10:25, Marc SCHAEFER t'a déjà répond :
Sur une machine cliente, avec les patches meltdown appliqués ou non, avec du code de provenance sûre (p.ex. packages Debian signés), la seule attaque résiduelle facile est le Javascript dans le navigateur, avec work-around déjà présent aujourd'hui dans Firefox, semble-t-il.
Le 06/01/2018 à 09:18, Pierre www.zetrader.fr a écrit :
Le 05/01/2018 à 10:25, Marc SCHAEFER t'a déjà répond :
Sur une machine cliente, avec les patches meltdown appliqués ou non,
avec du code de provenance sûre (p.ex. packages Debian signés), la seule
attaque résiduelle facile est le Javascript dans le navigateur, avec
work-around déjà présent aujourd'hui dans Firefox, semble-t-il.
Le 05/01/2018 à 10:25, Marc SCHAEFER t'a déjà répond :
Sur une machine cliente, avec les patches meltdown appliqués ou non, avec du code de provenance sûre (p.ex. packages Debian signés), la seule attaque résiduelle facile est le Javascript dans le navigateur, avec work-around déjà présent aujourd'hui dans Firefox, semble-t-il.
Michel Talon
Le 05/01/2018 à 23:14, Alain a écrit :
On 05/01/2018 09:48, Pierre www.zetrader.fr wrote:
............. Mais c'est quoi le problème plus exactement ? J'ai entendu dire à la radio ce matin que c'est une faille qui n'a jamais exploité au niveau sécurité, mais que cela ralentirait le processeur cette faille.
Voici ce qu'en dit Intel ; il me semble que c'est assez bien organisé chez eux : https://www.intel.com/content/www/us/en/architecture-and-technology/facts-about-side-channel-analysis-and-intel-products.html a+
Bien entendu il n'y a aucun doute qu'Intel ne va pas présenter les choses d'une manière favorable à ses intérêts! En fait il semble que l'exécution spéculative se passant différemment chez AMD, ses processeurs sont moins affectés. -- Michel Talon
Le 05/01/2018 à 23:14, Alain a écrit :
On 05/01/2018 09:48, Pierre www.zetrader.fr wrote:
............. Mais c'est quoi le problème plus exactement ?
J'ai entendu dire à la radio ce matin que c'est une faille qui n'a
jamais exploité au niveau sécurité, mais que cela ralentirait le
processeur cette faille.
Voici ce qu'en dit Intel ; il me semble que c'est assez bien organisé
chez eux :
Bien entendu il n'y a aucun doute qu'Intel ne va pas présenter les
choses d'une manière favorable à ses intérêts! En fait il semble que
l'exécution spéculative se passant différemment chez AMD, ses
processeurs sont moins affectés.
On 05/01/2018 09:48, Pierre www.zetrader.fr wrote:
............. Mais c'est quoi le problème plus exactement ? J'ai entendu dire à la radio ce matin que c'est une faille qui n'a jamais exploité au niveau sécurité, mais que cela ralentirait le processeur cette faille.
Voici ce qu'en dit Intel ; il me semble que c'est assez bien organisé chez eux : https://www.intel.com/content/www/us/en/architecture-and-technology/facts-about-side-channel-analysis-and-intel-products.html a+
Bien entendu il n'y a aucun doute qu'Intel ne va pas présenter les choses d'une manière favorable à ses intérêts! En fait il semble que l'exécution spéculative se passant différemment chez AMD, ses processeurs sont moins affectés. -- Michel Talon
