• # Risque

    Posté par  . É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  (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  (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  (site web personnel) . Évalué à 3.

        Sur nos machines personnelles, le deux plus gros risques sont :

        1. de traîner sur des sites web qui exécutent du code JS/WA malicieux ;
        2. de croire que l'application conteneurisée (ou isolée autrement) ne peut pas avoir accès aux autres applications.

        Dans la pratique :

        1. Peu d'entre-nous passe son temps sur des sites suspicieux sans utiliser les protections renforcées, NoScript, uMatrix et bien d'autres…

        2. 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  (Mastodon) . Évalué à 2. Dernière modification le 16 janvier 2020 à 07:57.

          moins de failles

          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  (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  (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) :

              $ cat /proc/cpuinfo | grep bugs
bugs        : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds swapgs taa itlb_multihit

              Mon serveur maison (i3-4130)

              $ cat /proc/cpuinfo | grep bugs
bugs        : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds swapgs itlb_multihit

              EDIT :

              Mon PC perso à la maison (i7-6700K)

              $ cat /proc/cpuinfo | grep bugs
bugs        : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds swapgs taa itlb_multihit

              En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

              • [^] # Re: Risque

                Posté par  (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)

                $ cat /proc/cpuinfo | egrep 'model|bugs' | sort | uniq -c
      8 bugs        : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds swapgs itlb_multihit
      8 model       : 58
      8 model name  : Intel(R) Core(TM) i7-3610QM CPU @ 2.30GHz

                Laptop épouse i5-7200U (2016)

                $ cat /proc/cpuinfo | egrep 'model|bugs' | sort | uniq -c
      4 bugs        : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds swapgs itlb_multihit
      4 model       : 142
      4 model name  : Intel(R) Core(TM) i5-7200U CPU @ 2.50GHz

                Laptop boulot i7-8565U (2018)

                $ cat /proc/cpuinfo | egrep 'model|bugs' | sort | uniq -c
      8 bugs        : spectre_v1 spectre_v2 spec_store_bypass mds swapgs
      8 model       : 142
      8 model name  : Intel(R) Core(TM) i7-8565U CPU @ 1.80GHz

                Tour projet perso (journal) Ryzen 9 3900X (2019)

                $ cat /proc/cpuinfo | egrep 'model|bugs' | sort | uniq -c 
     24 bugs        : sysret_ss_attrs spectre_v1 spectre_v2 spec_store_bypass 
     24 model       : 113 
     24 model name  : AMD Ryzen 9 3900X 12-Core Processor

                Commentaire sous licence Creative Commons Zero CC0 1.0 Universal (Public Domain Dedication)

    • [^] # Re: Risque

      Posté par  (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.