Automne, saison chaude chez Intel

Posté par (page perso) . Édité par ZeroHeure, Ysabeau, Nils Ratusznik, M5oul, Davy Defaud et palm123. Modéré par Ysabeau. Licence CC by-sa.
58
27
nov.
2019
Matériel

Mardi 12 novembre, Arte diffuse le concert du Bal des enragés au Helfest 2019.
L’attention du public ainsi détournée, Intel en profite pour lancer une vague de correctifs, 77 correctifs, un grand nombre de CVE (des failles) y est dévoilé. Les failles concernent les processeurs eux‑mêmes (et microcontrôleurs) et les micrologiciels trop nombreux qui tournent dans vos cartes‐mères.

Sommaire

Matériel

Fin mai 2019, Intel dévoilait une faille autour de sa technologie MDS.

MDS est une optimisation qui permet de remplir des petites structures temporaires (micro‐architecturaux) lors des opérations load, fill et store. Lorsque le code d’une branche est rencontré, le mécanisme de prédiction va exécuter le code en avance sans attendre le résultat de la branche et ainsi remplir ces structures. Consultez ce diagramme pour mieux vous le représenter. En cas d’invalidation de la branche, ces structures ne sont pas vidées.

Exploitée par le biais désormais célèbre de l’attaque par canal auxiliaire d’exécution spéculative — speculative execution side channel —, la faille permet trois attaques : RIDL, Fallout et zombieload.

Pour les contrer, les développeurs du noyau Linux ont d’abord introduit le paramètre de démarrage mds. Enfin, parce que, bon, ça commence à bien faire, la version 5.2 amène le paramètre mitigation qui permettra à terme d’activer ou non une bien belle collection de contre‑mesures processeur.

Cette fois, Intel remet le couvert avec la technologie TSX Asynchronous Abort (TAA), liée aux extensions TSX déjà abordées lors de faille Lazy‑FPU. Souvenez‐vous, il est noté à propos de ces extensions que « ce serait presque étudié pour ». L’exploitation de la faille repose aussi sur des registres dits « micro‑architecturaux ». De fait, les correctifs du mois de mai n’ont corrigé qu’une partie du problème…

La contre‑mesure repose sur le détournement d’une instruction obsolète, ou annexe, pour nettoyer les registres concernés par la faille. Ceci implique une mise à jour du microcode et du système, ce dernier devant appeler à point nommé cette instruction. En cas d’annulation de transaction TSX, les écritures effectuées au cours de la transaction sont annulées et les registres restaurés. Mais, lorsqu’une annulation en cours est asynchrone, une opération load peut encore se terminer et lire ces registres micro‐architecturaux pour les faire passer à la branche exécutée de manière spéculative.

Sous Linux, le paramètre d’amorçage tsx_async_abort=off|full a été ajouté pour gérer les contre‑mesures. La directive tsx=off|on|auto autorisera au non les extensions TSX. Vous pouvez combiner ces deux variables.

Ce n’est pas tout, une autre faille Jump Conditional Code Erratum, toujours liée à cette complexité micro‐architecturale, est annoncée. Une série d’instructions appelées micro‑ops, est mise en cache (structure DSB) et décodée en dehors de sa chaîne de traitement. Seulement l’une de ces instructions (JCC) peut provoquer un comportement indéfini lorsqu’elle est mal alignée.

La contre‑mesure consiste à éviter que toute instruction de saut conditionnel soit mise en cache DSB, d’où de nombreux retours sur le traitement standard et une perte de performance significative. Évidemment, Intel recommande donc de mettre à jour les microcodes de ses processeurs via les outils de vos distributions et systèmes d’exploitation :

Sans lien avec MDS, la faille Machine check error erratum permet à un attaquant de redémarrer ou d’arrêter un système. Une instruction fetch dans certaines conditions va lever par erreur l’exception machine check et provoquer un redémarrage ou un arrêt.

Les cartes graphiques ne sont pas épargnées, via notamment le mode d’exécution en ring‑2, System Management Mode (SMM), qui permet d’interrompre l’exécution normale du système d’exploitation pour passer la main à un micrologiciel. On peut se demander si cette faille n’est pas liée au correctif du SDK SGX, qui a un mode d’exécution réservé dans lequel aucun autre mode (ou ring) n’est censé pouvoir accéder.

Sous Linux, vous trouverez dans /sys/devices/system/cpu/vulnerabilities/ une liste des failles. Il suffit de lancer un cat sur chaque fichier de ce répertoire pour obtenir le statut de votre processeur.

Sous FreeBSD, la clef hw.mds_disable active les contre‑mesures.

Micrologiciels (firmwares)

Ces failles matérielles ont pour effet de bord de se propager aux micrologiciels fournis par Intel pour vos machines, qui vont permettre d’exploiter au mieux ces failles. Et ce, d’autant plus que le code, fermé, de ces derniers, ne semble pas d’une qualité très élevée, malgré des noms pompeux, avec trust dedans.

On trouve beaucoup d’erreurs de codage, telles que :

  • insufficient session validation ;
  • insufficient access control ;
  • insufficient input validation ;
  • unhandled exception ;
  • stack overflow ;
  • out of bound read ;
  • memory corruption ;
  • heap corruption.

Intel® Trusted Execution Engine (TXE), Technologie Intel® Platform Trust

Elles sont supposées être les garantes du sytème d’exploitation et des environnements que vous allez faire tourner, basées sur un module TPM, troué lui aussi. Au menu, élévation de privilèges et fuite de données.

Malheureusement, on commence à trouver aussi ce genre de micrologiciels (trusted) sur des architectures non‑Intel, comme des systèmes monopuces (SoC) ARM.

Intel® Active Management Technology (AMT)

Un outil d’assistance et de maintenance à distance, qui permet une élévation de privilèges. À distance.

Il repose principalement sur l’Intel Management Engine (IME). Autrefois planqué dans le hostbridge, aujourd’hui dans le PCH. Pensez à le désactiver, si vous le pouvez.

Un outil qui repose sur plein de petits modules :

  • Intel® Converged Security and Manageability Engine ;
  • Intel® Securing and Management Engine ;
  • Intel® Server Platform Services.

Baseboard Management Controller

C’est un autre outil de maintenance à distance que l’on retrouve sur les serveurs et modules de calcul, dont une version libre existe. Pour celui‑ci, il y a un risque critique d’élévation de privilèges, déni de service et de fuite de données, via le réseau.

UEFI

Une vulnérabilité a été annoncée sur la famille Xeon.

Périphériques

Les microcodes des cartes réseau Intel Ethernet 700 Series permettent une évaluation de privilèges, déni de service et fuite de données.

Logiciel

Le SDK Intel® SGX (Software Guard Extensions) permet une élévation de privilèges.
Télécharger la dernière version.

[N. D. M. : le site 01.org appartient bien à Intel.]

Bilan

Intel affirme que la majorité de ces failles a été trouvée « en interne ». Pourtant, on trouve nombre de chercheurs indépendants remerciés dans les CVE. En fait, une bonne partie des failles découvertes dans les microcodes me semble sortie d’un logiciel d’analyse de code.

Malheureusement, une partie de ces contre‑mesures et mises à jour, surtout celles concernant les micrologiciels, devront être apportées par les constructeurs, les fournisseurs de cartes. Les machines dédiées au marché des particuliers risquent d’attendre longtemps…

Greg Kroah‑Hartman a conclu lors de l’Open Source Summit Europe : vous allez devoir choisir entre la sécurité et la performance. Car, désactiver l’hyperthreading, les extensions TSX, retirer des µops du cache induit une importante perte de performance.

Notez que si la désactivation de l’hyperthreading rend plus difficile la plupart de ces attaques, cela ne suffit généralement pas. De même, la distribution aléatoire de l’espace d’adressage noyau (KASLR) n’empêche pas l’exploitation de ces failles.

Aller plus loin

  • # Accès

    Posté par (page perso) . Évalué à 6 (+4/-0).

    En pratique il me semble que pour exploiter ces failles (au moins une bonne partie d'entre elles) il faille tout de même avoir gagné le droit d'exécuter du code sur la machine ? Me tromperais-je ? Ça limite tout de même les nécessités de mise à jour, non ? Y a-t-il des exploitations connues passant par les navigateurs ?

    « IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace

    • [^] # Re: Accès

      Posté par (page perso) . Évalué à 10 (+13/-0).

      Les failles Spectres et meltdown étaient exploitable par du JS dans le navigateur (src), donc je suppose que pour celles là aussi ça doit être possible.

      Ou alors par un chaînage de vulnérabilité, tel que par exemple dans la libpng où une image spécialement formée peut permettre à l'attaquant d'exécuter du code (cf)

      • [^] # Re: Accès

        Posté par (page perso) . Évalué à 7 (+5/-0).

        J'ai au moins en tête l'attaque RIDL écrite en javascript, sur leur site, parmi d'autres.

        Les failles Spectres et meltdown étaient exploitable par du JS dans le navigateur

        Tout à fait et les failles ici sont des variantes de Spectre. C'est juste «l'angle d'attaque» qui change.

    • [^] # Re: Accès

      Posté par . Évalué à 5 (+4/-0).

      Je présume qu'il y a un risque pour les hébergements de serveurs mutualisés à base de conteneurs type docker/kubernetes/lxc vu qu'il y a des changements des contexte entre différents clients sur un même coeur CPU. Et ça inclurait aussi les fournisseurs de services PaaS. Quelqu'un peut confirmer?

      • [^] # Re: Accès

        Posté par (page perso) . Évalué à 7 (+4/-0).

        Et ceux qui hébergent des VM.

        « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

    • [^] # Re: Accès

      Posté par (page perso) . Évalué à 3 (+1/-0).

      Ça limite tout de même les nécessités de mise à jour, non ?

      Non. Tout dépend de ton modèle de menace.

  • # Question de modèle

    Posté par . Évalué à 9 (+7/-0).

    Il suffit d’avoir un processeur honnête :

    $ grep . /sys/devices/system/cpu/vulnerabilities/*
    /sys/devices/system/cpu/vulnerabilities/itlb_multihit:Not affected
    /sys/devices/system/cpu/vulnerabilities/l1tf:Not affected
    /sys/devices/system/cpu/vulnerabilities/mds:Not affected
    /sys/devices/system/cpu/vulnerabilities/meltdown:Not affected
    /sys/devices/system/cpu/vulnerabilities/spec_store_bypass:Not affected
    /sys/devices/system/cpu/vulnerabilities/spectre_v1:Not affected
    /sys/devices/system/cpu/vulnerabilities/spectre_v2:Not affected
    /sys/devices/system/cpu/vulnerabilities/tsx_async_abort:Not affected
    

    Non, je n’ai pas triché et si, c’est un Intel…

    ¯ : macron (typographie), petit signe diacritique, qui prétend ne pencher ni à gauche ni à droite, mais se place nettement au dessus des vraies lettres, qu’il considère avec mépris.

    • [^] # Re: Question de modèle

      Posté par . Évalué à 5 (+6/-1).

      Non, je n’ai pas triché et si, c’est un Intel…

      C'est quoi ? Un Pentium III @800Mhz ??? :p

      • [^] # Re: Question de modèle

        Posté par (page perso) . Évalué à 2 (+1/-1). Dernière modification le 27/11/19 à 21:41.

        C'est quoi ? Un Pentium III @800Mhz ??? :p

        Un truc reposant sur l' architecture EPIC ?

        • [^] # Re: Question de modèle

          Posté par (page perso) . Évalué à 1 (+0/-2).

          Ce n'est pas trop Intel.

          « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

          • [^] # Re: Question de modèle

            Posté par (page perso) . Évalué à 4 (+2/-0).

            EPIC != Epyc


            La gamme Epyc s'appuie sur une architecture appelée ZEN.

            • [^] # Re: Question de modèle

              Posté par (page perso) . Évalué à 3 (+0/-0).

              Désolé, j'ai vu tellement de fois Epy mal écrit que je n'ai pas réfléchi plus loin.

              « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

              • [^] # Re: Question de modèle

                Posté par (page perso) . Évalué à 3 (+1/-0).

                Bah, c'était l'occasion de rappeler que la gamme des Itanium n'est touchée par aucune faille de type Spectre ou Meltdown.


                Ce n'est pas le même prix qu'un Atom, par contre.

                • [^] # Re: Question de modèle

                  Posté par (page perso) . Évalué à 3 (+1/-1).

                  Ce n'est pas le même prix qu'un Atom, par contre.

                  Ni le même tdp.

                  « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

                  • [^] # Re: Question de modèle

                    Posté par (page perso) . Évalué à 4 (+1/-0).

                    Et surtout le plus puissant des Itanium (4500 €) est 30 fois plus cher d'un Intel Core i3-8100 (140 €), et pourtant ne lui arrive pas à la cheville côté puissance de calcul.

      • [^] # Spéculer, c’est mal !

        Posté par . Évalué à 9 (+7/-0). Dernière modification le 28/11/19 à 00:39.

        À ma connaissance le dernier processeur Intel de gamme x86_64 qui ne fasse pas de spéculation : l’Atom D2550.

        Pas le plus puissant de la gamme, c’était le D2700, que le D2550 a bizarrement remplacé (peut-être pour éviter de marcher sur les plates-bandes de la gamme du dessus, celle du Celeron).

        La puissance de calcul est plutôt faible (un peu moins pour le D2700), mais d’après des calculs à la louche que j’avais fait, le rapport puissance de calcul / puissance électrique consommée était similaire à celle des autres Intel de l’époque, celui-ci étant basé sur un cœur nettement plus simple et plus petit.

        Le chip graphique intégré n’est pas supporté sous Linux, mais heureusement pour moi, j’ai avec un chip graphique AMD (prévu pour être associé à cette gamme de processeur).

        On pourrait imaginer une mise à jour de cette gamme de processeurs avec la technologie actuelle (notamment finesse de gravure) et un nombre important de cœurs pour atteindre une puissance similaire aux processeurs actuels, mais sans failles de conception !
        Par contre, la puissance par fil d’exécution serait nettement moindre et il faudrait paralléliser les traitements, à défaut de contourner les failles.

        D’un sens, de tels processeurs seraient sûrement en dessous des Arm en puissance par fil de calcul (alors qu’actuellement Intel a l’avantage sur ce point), mais seulement en dessous des Arm qui font de la spéculation et sont donc vulnérables à des failles de type Spectre.

        ¯ : macron (typographie), petit signe diacritique, qui prétend ne pencher ni à gauche ni à droite, mais se place nettement au dessus des vraies lettres, qu’il considère avec mépris.

        • [^] # Re: Spéculer, c’est mal !

          Posté par (page perso) . Évalué à 7 (+5/-0).

          aie…
          [jjkhkb@fixe ~]$ grep . /sys/devices/system/cpu/vulnerabilities/*
          /sys/devices/system/cpu/vulnerabilities/l1tf:Mitigation: PTE Inversion; VMX: conditional cache flushes, SMT disabled
          /sys/devices/system/cpu/vulnerabilities/mds:Mitigation: Clear CPU buffers; SMT disabled
          /sys/devices/system/cpu/vulnerabilities/meltdown:Mitigation: PTI
          /sys/devices/system/cpu/vulnerabilities/spec_store_bypass:Mitigation: Speculative Store Bypass disabled via prctl and seccomp
          /sys/devices/system/cpu/vulnerabilities/spectre_v1:Mitigation: usercopy/swapgs barriers and __user pointer sanitization
          /sys/devices/system/cpu/vulnerabilities/spectre_v2:Mitigation: Full generic retpoline, IBPB: conditional, IBRS_FW, STIBP: disabled, RSB filling

          • [^] # Re: Spéculer, c’est mal !

            Posté par . Évalué à 2 (+0/-0).

            « Félicitations », tu as un Intel.

            Le plus ennuyeux, ce n’est peut-être pas tant les vulnérabilités listées (et « mitigées »), que celles que ton noyau (pas tout à fait à jour, non ?) ne prend manifestement pas en charge, itlb_multihit et tsx_async_abort…

            ¯ : macron (typographie), petit signe diacritique, qui prétend ne pencher ni à gauche ni à droite, mais se place nettement au dessus des vraies lettres, qu’il considère avec mépris.

  • # preums

    Posté par (page perso) . Évalué à 4 (+4/-2).

    [NdM : le site 01.org appartient bien à Intel.]

    Oui, ceux sont des modestes chez Intel.


    ou alors il faut qu'ils installent leurs centres dans l'Ain.

    • [^] # Re: preums

      Posté par (page perso) . Évalué à 9 (+6/-0).

      C'est le nom de leur division dédiée à l'opensource.

      « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

  • # Et les autres ...

    Posté par . Évalué à 5 (+5/-0).

    Je me demande si les autres (AMD, ARM, IBM, …) ont mes même problèmes où si c'est Intel qui est particulièrement mauvais (acheté, verolé ?)

    • [^] # Re: Et les autres ...

      Posté par (page perso) . Évalué à 8 (+5/-0).

      Une partie des failles de la famille Spectre ont aussi touchés les autres. Cependant Intel a été beaucoup plus touché. Je ne sais pas si c'est parce qu'ils ont fait plus de connerie ou parce qu'ils sont beaucoup plus scrutés que les autres (vu la part de marché).

      « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

      • [^] # Re: Et les autres ...

        Posté par (page perso) . Évalué à 4 (+2/-0).

        Ou parce qu'ils ont beaucoup plus d'optims de ce genre que les autres, ce qui explique que leur processeurs soient plus rapides.

        • [^] # Re: Et les autres ...

          Posté par (page perso) . Évalué à 8 (+6/-1).

          Je classe ça dans les conneries (faire des optimisations non désactivables qui ont des implications de sécurité).

          « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

          • [^] # Re: Et les autres ...

            Posté par (page perso) . Évalué à 2 (+0/-0).

            Ça dépend du contexte.

            Si tu as besoin de perfs en calcul pour un cluster où tu contrôles ce qui s'exécute, ça peut être intéressant.

            Si tu es hébergeur pour des clients qui font tourner ce qu'ils veulent, en direct ou en virtualisé, c'est pas bon.

            Python 3 - Apprendre à programmer en Python avec PyZo et Jupyter Notebook → https://www.dunod.com/sciences-techniques/python-3

            • [^] # Re: Et les autres ...

              Posté par (page perso) . Évalué à 10 (+10/-0).

              C'est pour ça que j'ai écrit "non désactivable". Il y a plein de cas où il préférable de privilégier les performances sur la sécurité. Par contre, par défaut, la sécurité devrait primer.

              « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

        • [^] # Re: Et les autres ...

          Posté par . Évalué à 7 (+6/-1).

          ce n'est pas une excuse :), je pense plutot que la partie securité est passé à la trappe pour toujours être les premier dans la course à la performance. et celle de leur action en bourse.

          codé avec le cul comme on dit en france, mais ca va plus vite forcement. Toute ressemblance avec une ssi de base est fortuite.

          la fameuse dette technique, ils doivent se regaler en reunion maintenant qu'ils doivent tenir compte de la securité.

          • [^] # Re: Et les autres ...

            Posté par . Évalué à 3 (+3/-1). Dernière modification le 29/11/19 à 10:23.

            ``C'est clair que ça doit arrondir les benchmarks pour montrer de meilleurs perfs ou perfs équivalentes que les concurrents.

            Ça me fait penser aux code du fameux constructeur automobile allemand qui change l'algo de ses voitures pour réduire sa pollution uniquement sur les banc d'essais ou aux machines à voter électronique tout ça. Dans tous ces cas les résultats trompent et ont des conséquence sur la vente du produit.

            Au passage l'architecture RISC-V n'a été touché par aucune de ces failles.

            • [^] # Re: Et les autres ...

              Posté par (page perso) . Évalué à 7 (+4/-0).

              Ça me fait penser aux code du fameux constructeur automobile allemand qui change l'algo de ses voitures pour réduire sa pollution uniquement sur les banc d'essai

              Ou aux smartphone qui laisse chauffe plus le cpu quand une appli de benchmark tourne.

              Au passage l'architecture RISC-V n'a été touché par aucune de ces failles.

              Ce n'est pas lié à l'architecture, la preuve, il y a des atom qui ne sont pas affectés. Il y a aussi des ARM qui ne sont pas affecté. Aucun cpu RISC-V n'a été affecté parce que personne n'a fait un cpu assez puissant, sinon, ils auraient utilisé les même techniques que les autres (Power, ARM, z/processor, x86).

              « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

    • [^] # Re: Et les autres ...

      Posté par . Évalué à 10 (+9/-0).

      Les autres sont affectés par Spectre (à part certains petits cœeurs ARM n'ayant pas de prédiction de branches) mais pas sur autant d'angles d'attaque et ils n'ont pas toutes les autres familles de vulnérabilités comme Meltdown ou LazyFPU.

      Côté GPU, Nvidia a récemment été affecté par une faille majeure dans son pilote mais rien d'aussi inquiétant que chez Intel.
      Côté module de management/sécurité, le Trustzone de ARM a aussi essuyé beaucoup de vulnérabilités, en particulier via l'implémentation faite par Qualcomm. Le PSP de AMD n'est pas non plus à l'abri.

      Intel a pris beaucoup de raccourcis en terme de sécurité pour apporter des fonctionnalités et augmenter les performances mais ils n'ont pas comblé les lacunes par la suite, même pas l'implémentation de killswitch. Ils ont eu une dizaine d'année sans concurrents sérieux et ont pêché par négligence, maintenant ils payent leurs erreurs de gestion à un moment où ils sont eux-même pénalisés par leur retard en matière de lithographie et d'architecture processeur et où ARM et AMD sont devenu assez costauds pour grignoter davantage que des miettes au niveau du marché CPU.

      • [^] # Re: Et les autres ...

        Posté par (page perso) . Évalué à 4 (+2/-0).

        Pour ma part, je mesure le niveau du problème à la chute de performances obtenue avec les correctifs. Et là, il n'y a pas photo, Intel est loin devant ;-)

        ⚓ À g'Auch TOUTE! http://afdgauch.online.fr

        • [^] # Re: Et les autres ...

          Posté par (page perso) . Évalué à 1 (+4/-3).

          Il y a des fois, où on se demande si c'est de l'incompétence. Ou s'ils ont plus que moins discrètement fourni à la NSA des portes d'entrée béantes pour de nombreuses années en toute connaissance de cause…

      • [^] # Re: Et les autres ...

        Posté par . Évalué à -1 (+0/-2).

        RISC-V n'est pas affecté à ma connaissance.

        • [^] # Re: Et les autres ...

          Posté par . Évalué à 3 (+1/-0). Dernière modification le 29/11/19 à 15:04.

          Il y a tout de même eu un POC de Spectre sur BOOM.
          Mais par chance pour les fabricants et les clients, les puces déjà créés ne reposaient pas sur cette architecture mais sur des designs plus simples comme Rocket ou Pulp.

          Bref, si RISC-V avait été développé et commercialisé plus tôt, il y aurait eu des problèmes similaires aux gros processeurs MIPS ou ARM existants.
          Edit : Ça rejoint ce que Xavier Claude disait plus haut, j'avais pas lu.

    • [^] # Re: Et les autres ...

      Posté par . Évalué à 3 (+3/-0).

      grep . /sys/devices/system/cpu/vulnerabilities/*
      /sys/devices/system/cpu/vulnerabilities/itlb_multihit:Not affected
      /sys/devices/system/cpu/vulnerabilities/l1tf:Not affected
      /sys/devices/system/cpu/vulnerabilities/mds:Not affected
      /sys/devices/system/cpu/vulnerabilities/meltdown:Not affected
      /sys/devices/system/cpu/vulnerabilities/spec_store_bypass:Mitigation: Speculative Store Bypass disabled via prctl and seccomp
      /sys/devices/system/cpu/vulnerabilities/spectre_v1:Mitigation: usercopy/swapgs barriers and __user pointer sanitization
      /sys/devices/system/cpu/vulnerabilities/spectre_v2:Mitigation: Full AMD retpoline, IBPB: conditional, STIBP: disabled, RSB filling
      /sys/devices/system/cpu/vulnerabilities/tsx_async_abort:Not affected
      
      

      avec un AMD ryzen (1)…. un peu mieux que intel… (et les Ryzen 2 on moins de failles… et sont bien plus rapide…)

      • [^] # Question hors sujet

        Posté par . Évalué à 3 (+1/-0).

        Sais-tu s’il y a chez AMD des processeurs prévus pour être montés sans ventilateur, même dans un portable, équivalents des Intel Pentium N… (exemple) ou Core …Y (successeurs des Core M…, exemple), et des portables construits avec ?

        Après un Toshiba, j’ai décidé de ne plus acheter que des PC fanless, mais si le processeur pouvait ne pas être une collection de failles, ça ne serait pas plus mal…

        ¯ : macron (typographie), petit signe diacritique, qui prétend ne pencher ni à gauche ni à droite, mais se place nettement au dessus des vraies lettres, qu’il considère avec mépris.

        • [^] # Re: Question hors sujet

          Posté par (page perso) . Évalué à 4 (+2/-0).

          Je pense que n'importe quel Ryzen peut être monté sans ventilateur : tu le brides avec cpufreq et problème réglé. Et au moins, c'est toi qui choisis, pas le micrologiciel comme chez intel.

          Pas de risque thermique, ils ralentissent tout seuls en cas de surchauffe.

          ⚓ À g'Auch TOUTE! http://afdgauch.online.fr

          • [^] # Re: Question hors sujet

            Posté par (page perso) . Évalué à 5 (+2/-0).

            ils ralentissent tout seuls en cas de surchauffe.

            Ce n'est pas le cas des Intel ?
            Je suis quasi persuadé que c'est le cas. Mais peut-être que dans une certaine mesure.

            • [^] # Re: Question hors sujet

              Posté par (page perso) . Évalué à 3 (+1/-0).

              J'ai pas dit le contraire : j'indiquais seulement que les AMD avaient une protection thermique, depuis 2003 et les AMD64 en fait. Avant, on pouvait griller les Athlon ;-)

              Côté Intel, la protection thermique est arrivée avec les Pentium 4 : il surchauffaient bien trop pour ne pas avoir une catastrophe industrielle sans ça. J'ai vu des portables qui n'arrivaient pas à tenir la fréquence maximale plus de 3 secondes!

              ⚓ À g'Auch TOUTE! http://afdgauch.online.fr

              • [^] # Re: Question hors sujet

                Posté par . Évalué à 3 (+1/-0).

                j'indiquais seulement que les AMD avaient une protection thermique

                Le ralentissement automatique, le thermal throttling, ne fait pas tout.
                Si le CPU n'a pas la possibilité de dissiper la chaleur malgré le niveau de puissance minimale (automatiquement ou forcé via le gouverneur powersave), il se coupe par sécurité. C'est ce dernier mécanisme, le thermal shutdown, qui manquait cruellement aux Athlon K7 et plus anciens.

                Sans un design étudié pour un usage passif, un ordi portable a très peu de marge de dissipation avec une ventilation désactivée et il y a de fortes chances que même à son minimum de puissance, l'appareil se coupe au bout de quelques dizaines de minutes une fois que l'inertie thermique du radiateur arrive à la température critique. C'est un peu pour cette raison que le POST vérifie le bon fonctionnement du ventilateur et que souvent sur les portables cela peut carrément bloquer la suite du démarrage.

        • [^] # Re: Question hors sujet

          Posté par . Évalué à 4 (+2/-0).

          Si tu veux un portable AMD, il vaut mieux attendre quelques mois que leur gamme Zen2 sorte. On aura plus d'infos durant le CES en Janvier.
          La gravure 7nm fait déjà des merveilles en terme de conso et d'échauffement sur leur gamme de bureau.
          Et même si tu te fiches d'avoir la dernière génération, ça voudra aussi dire que les modèles actuels vont baisser de prix (bien plus qu'au Black Friday ou Cyber Monday).

  • # Merci

    Posté par . Évalué à 3 (+3/-0). Dernière modification le 28/11/19 à 10:03.

    Super dépêche, fort intéressante ! Le schéma du processeur est génial ! On voit la complexité de l'affaire.
    Merci :)

  • # HP

    Posté par . Évalué à 5 (+4/-0).

    Chez HP aussi, on trouve des trucs sympa. :
    https://www.cert.ssi.gouv.fr/avis/CERTFR-2019-AVI-594/

  • # Et toujours aucune vulnérabilité pour ceux qui utilisent uniquement du logiciel libre, de confiance

    Posté par . Évalué à 2 (+10/-10).

    Petit rappel : ces failles sont exploitables par un code d'un adversaire qui tournerait sur votre machine. Bref, c'est valable uniquement si vous aimez faire tourner du code provenant d'inconnus malveillants. Si vous n'utilisez que du logiciel libre, issu du personnes de confiance (comme par exemple de personnes cooptées ayant approuvé une constitution garantissant la liberté des utilisateurs), aucun problème pour vous !

    Bien sûr, vu qu'une bonne partie du web moderne marche uniquement sous les prémices d'accepter de faire tourner n'importe quoi n'importe quand, ça vous limite un peu dans les sites accessibles : mais c'était déjà le cas pour les logiciels si vous respectez vos convictions. Noscript est votre ami, et les réseaux sociaux sont mauvais pour la santé de toutes façons.

    Je trouvais ça important de rappeler ce fait sur notre bon vieux linuxfr.

  • # Possibilité de contourner l'absence de correctif du revendeur ?

    Posté par (page perso) . Évalué à 3 (+3/-0). Dernière modification le 28/11/19 à 19:06.

    Malheureusement, une partie de ces contre‑mesures et mises à jour, surtout celles concernant les micrologiciels, devront être apportées par les constructeurs, les fournisseurs de cartes. Les machines dédiées au marché des particuliers risquent d’attendre longtemps…

    Une question à ce sujet car je n'y connais rien :
    Si le fabriquant/vendeur de mon ordinateur/carte mère ne propose pas de mise à jour pour le BIOS/UEFI, est-il possible de contourner le problème et de mettre à jour les micrologiciels avec des paquets comme microcode_ctl ou fwupd ?

    • [^] # Re: Possibilité de contourner l'absence de correctif du revendeur ?

      Posté par . Évalué à 3 (+1/-0). Dernière modification le 29/11/19 à 00:41.

      Si le correctif n'a pas été fourni publiquement il y a peu de chances.
      Puis hélas, tout ne se résout pas à coup de microcodes : les correctifs réguliers d'AGESA et d'IME nécessitent que le fabricant du matériel fournisse un outil de MÀJ ou un nouveau "BIOS".
      Après contrairement à l'AGESA, pour l'IME tout n'est pas perdu mais en terme de complexité ce n'est pas très loin d'un radical me_cleaner.

      Enfin, il me semble que fwupd est justement un accord des constructeurs pour fournir du support donc pas possible de l'utiliser pour flasher un nouveau BIOS/firmware qu'ils ne fournissent pas.

    • [^] # Re: Possibilité de contourner l'absence de correctif du revendeur ?

      Posté par (page perso) . Évalué à 2 (+0/-0).

      Une question à ce sujet car je n'y connais rien

      Oui, c'est bien le but de microcode : il remplace le micrologiciel CPU au boot.

      ⚓ À g'Auch TOUTE! http://afdgauch.online.fr

  • # Ah, Intel...

    Posté par . Évalué à -1 (+1/-4).

    … à voir le travail de pro, z'ont pas besoin de fuites quantiques pour rendre leurs processeurs plus poreux que des passoires!

    (C'est pas nous, les électrons ont sauté une couche et du coup ils se sont retrouvés dans le mauvais canal en dévoilant les clés privées des applications depuis le cache L12. C'est la faute à Schrödinger!)

Envoyer un commentaire

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.