Déjà je crois que par défaut la plupart des distribs GNU/Linux n'ont pas choisi la protection maximale mais ont choisi il me semble de garder l'hyperthreading alors que pour une protection maximale je crois qu'il faut le désactiver, avec la chute de perfs que cela implique
J'avais cru comprendre que le gros de ces failles concerne la porosité des VMs, et des superviseurs. En gros, il ne faut surtout pas les désactiver sur des machines qui hébergent des VMs, et encore, des VMs qui ont un risque d'attaque mutuelles : en gros un hébergeur qui loue à plusieurs clients différents.
Sur un PC perso, même si il est sur Internet H24, tu risques pas grand chose non.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
La plupart des applications sur nos machines ne sont pas conteneurisées/isolées/virtualisées et quelquefois nous en avons installées avec la périlleuse commande curl example.com/installer | sh ce qui est bien plus grave que l'exploitation des failles du processeur.
Personnellement, j'ai remarqué un gain en performance lors des gros traitements, après avoir ajouter à mon GRUB (machine avec processeur Intel) les options du site web https://make-linux-fast-again.com
noibrs noibpb nopti nospectre_v2 nospectre_v1 l1tf=off nospec_store_bypass_disable no_stf_barrier mds=off tsx=on tsx_async_abort=off mitigations=off
Sinon, je préfère acheter du AMD maintenant : moins de failles et moins cher.
Commentaire sous licence Creative Commons Zero CC0 1.0 Universal (Public Domain Dedication)
Oui, tous les processeurs ont potentiellement des défauts de sécurité permettant des attaques par canal auxiliaire ;
Non, ce ne sont pas exactement les mêmes failles, car les processeurs Intel et AMD ne partagent pas les mêmes implémentations, ce sont des entreprises différentes qui conçoivent leurs processeurs indépendamment, même si les processeurs peuvent exécuter les mêmes instructions.
Historiquement, la course à la performance a poussé les fondeurs à user de tous plein d’optimisations dans la conception de leurs processeurs, par exemple, en partageant des parties du processeur non utilisées pour accélérer un autre thread.
Dans cette course, Intel a été moins regardant au niveau sécurité. AMD, de son côté, a été moins ingénieux (ou plus sensible à ce type d’attaques). Peut-être aussi que les chercheur⋅ses en sécurité ont davantage travaillé sur les processeurs Intel que ceux d’AMD.
Attention, je ne suis pas sûr à 100 % de ce que je viens d’écrire, j’ai peut-être pas bien compris mes lectures, et peut-être que les processeurs AMD ont également toutes les failles des processeurs Intel.
Commentaire sous licence Creative Commons Zero CC0 1.0 Universal (Public Domain Dedication)
# Risque
Posté par R. Danell Olivaw . Évalué à 3. Dernière modification le 14 janvier 2020 à 10:33.
Dans la pratique, que risque-t-on à désactiver les mitigations de ces failles ? Sont-elles exloités en masse ?
[^] # Re: Risque
Posté par antistress (site web personnel) . Évalué à 2. Dernière modification le 14 janvier 2020 à 19:06.
Déjà je crois que par défaut la plupart des distribs GNU/Linux n'ont pas choisi la protection maximale mais ont choisi il me semble de garder l'hyperthreading alors que pour une protection maximale je crois qu'il faut le désactiver, avec la chute de perfs que cela implique
[^] # Re: Risque
Posté par gUI (Mastodon) . Évalué à 2.
J'avais cru comprendre que le gros de ces failles concerne la porosité des VMs, et des superviseurs. En gros, il ne faut surtout pas les désactiver sur des machines qui hébergent des VMs, et encore, des VMs qui ont un risque d'attaque mutuelles : en gros un hébergeur qui loue à plusieurs clients différents.
Sur un PC perso, même si il est sur Internet H24, tu risques pas grand chose non.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Risque
Posté par Oliver (site web personnel) . Évalué à 3.
Sur nos machines personnelles, le deux plus gros risques sont :
Dans la pratique :
Peu d'entre-nous passe son temps sur des sites suspicieux sans utiliser les protections renforcées, NoScript, uMatrix et bien d'autres…
La plupart des applications sur nos machines ne sont pas conteneurisées/isolées/virtualisées et quelquefois nous en avons installées avec la périlleuse commande
curl example.com/installer | sh
ce qui est bien plus grave que l'exploitation des failles du processeur.Personnellement, j'ai remarqué un gain en performance lors des gros traitements, après avoir ajouter à mon GRUB (machine avec processeur Intel) les options du site web https://make-linux-fast-again.com
noibrs noibpb nopti nospectre_v2 nospectre_v1 l1tf=off nospec_store_bypass_disable no_stf_barrier mds=off tsx=on tsx_async_abort=off mitigations=off
Sinon, je préfère acheter du AMD maintenant : moins de failles et moins cher.
Commentaire sous licence Creative Commons Zero CC0 1.0 Universal (Public Domain Dedication)
[^] # Re: Risque
Posté par gUI (Mastodon) . Évalué à 2. Dernière modification le 16 janvier 2020 à 07:57.
en l’occurrence, ces failles sont sur AMD également non ?
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Risque
Posté par Oliver (site web personnel) . Évalué à 2.
Oui, tous les processeurs ont potentiellement des défauts de sécurité permettant des attaques par canal auxiliaire ;
Non, ce ne sont pas exactement les mêmes failles, car les processeurs Intel et AMD ne partagent pas les mêmes implémentations, ce sont des entreprises différentes qui conçoivent leurs processeurs indépendamment, même si les processeurs peuvent exécuter les mêmes instructions.
Historiquement, la course à la performance a poussé les fondeurs à user de tous plein d’optimisations dans la conception de leurs processeurs, par exemple, en partageant des parties du processeur non utilisées pour accélérer un autre thread.
Dans cette course, Intel a été moins regardant au niveau sécurité. AMD, de son côté, a été moins ingénieux (ou plus sensible à ce type d’attaques). Peut-être aussi que les chercheur⋅ses en sécurité ont davantage travaillé sur les processeurs Intel que ceux d’AMD.
Au final, les failles trouvées concernent davantage les processeurs Intel que ceux d’AMD. C’est du moins ce que j’ai appris lors de ma remise à niveau sur les processeurs avant d’écrire le journal https://linuxfr.org/users/oliver_h/journaux/intel-14-nm-amd-7-nm-arm-7-nm-et-mon-serveur
Attention, je ne suis pas sûr à 100 % de ce que je viens d’écrire, j’ai peut-être pas bien compris mes lectures, et peut-être que les processeurs AMD ont également toutes les failles des processeurs Intel.
Commentaire sous licence Creative Commons Zero CC0 1.0 Universal (Public Domain Dedication)
[^] # Re: Risque
Posté par gUI (Mastodon) . Évalué à 3. Dernière modification le 21 janvier 2020 à 19:06.
Le mieux c'est d'y mettre les mains dedans : on va faire des stats basées sur ce qu'on a sous la main.
Au boulot (i7-8700) :
Mon serveur maison (i3-4130)
EDIT :
Mon PC perso à la maison (i7-6700K)
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Risque
Posté par Oliver (site web personnel) . Évalué à 3. Dernière modification le 24 janvier 2020 à 18:48.
Mes machines listées par ordre chronologique
Je me rends compte que se sont mes vieux processeurs qui contiennent le plus de failles connues.
Laptop perso i7-3610QM (2012)
Laptop épouse i5-7200U (2016)
Laptop boulot i7-8565U (2018)
Tour projet perso (journal) Ryzen 9 3900X (2019)
Commentaire sous licence Creative Commons Zero CC0 1.0 Universal (Public Domain Dedication)
[^] # Re: Risque
Posté par antistress (site web personnel) . Évalué à 2. Dernière modification le 16 janvier 2020 à 05:48.
Et sinon celle-là, tu l'as vue ? Ça complète bien le tableau.
https://linuxfr.org/users/antistress/liens/intel-s-mitigation-for-cve-2019-14615-graphics-vulnerability-obliterates-gen7-igpu-performance
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.