Journal Faille dans les CPU Intel avec Hyperthreading

Posté par  (site web personnel) .
Étiquettes : aucune
0
13
mai
2005
Si vous avez un serveur qui tourne avec un Pentium 4 HT ou avec un Xeon il serait sans doute bon de désactiver l'hyperthreading.
Le papier technique va être posté cette après-midi mais il est vraiment inquiétant de lire que cette faille : allowing an unprivileged user to steal an RSA private key being used on the same machine

Annonce de Colin Percival : http://www.daemonology.net/hyperthreading-considered-harmful/(...)

Analyse de kerneltrap : http://kerneltrap.org/node/5103/print(...)

  • # Linux ?

    Posté par  (site web personnel) . Évalué à 1.

    Je reconnais que mes connaissances en architecture sont assez limitées, mais tous ces articles parlent de failles pour BSD, mais je vois nul part un problème concernant Linux.
    Notre pinguin préféré parlerait-il différement au processeur pour éviter cette faille ou est-il tout autant touché que les BSD ?

    Merci d'éclairer ma lanterne

    • [^] # Re: Linux ?

      Posté par  (site web personnel) . Évalué à 7.

      Comme c'est une faille CPU il me semble évident que tous les OS sont touchés. Je crois qu'il liste juste les OS ayant une correction disponible.....et comme c'est un dev BSD et bien c'est normal que les corrections soient déja dispo poue les OS BSD.

      • [^] # Re: Linux ?

        Posté par  (site web personnel) . Évalué à 5.

        > Comme c'est une faille CPU il me semble évident que tous les OS sont touchés.

        Sauf ceux qui ne supportent pas l'hyperthreading comme OpenBSD dont les devs ont jugé que ce n'était que du pur marketing. ;)

        • [^] # Re: Linux ?

          Posté par  . Évalué à 3.

          A l'époque (mars 2005 - il y a deux mois) où Colin avait parlé de ce bug qu'il désirait garder secret pour le divulguer à une conférence, un problème de communication entre devs de OpenBSD avait déclenché une polémique :
          http://lists.freebsd.org/pipermail/freebsd-security/2005-March/0027(...)

        • [^] # Re: Linux ?

          Posté par  . Évalué à 1.

          Si les devs de OpenBSD on réellement dit ça, c'est alors qu'ils n'y captent absolument rien, et qu'ils devraient arréter de fumer de la peau de banane séchée.
          Faut être complétement aveugle et totalement de mauvaise foi pour affirmer ça.
          J'ai la chance d'avoir un HT (p4e) et un classic (p4c) à même fréquence et même config. Les 2 font tourner sendmail, clamd, spamassassin,samba. Et, désolé si ça déçoit certains, sur un test de charge de 10 minutes sur le p4c, le HT met moins de 7 min pour faire la même chose. ou, dit d'une autre manière, le HT abbat 30% de plus que le p4c dans le même laps de temps.
          Perso, je me fie à mon utilisation pour savoir si un proc est plus rapide ou pas que l'autre, et là y'a pas photo.
          Bien sur, je suis pas entouré d'une équipe de spécialistes de 01.net ou VNUnet, donc mon avis n'a peut-être pas une grande valeur... :)

          • [^] # Re: Linux ?

            Posté par  . Évalué à 3.

            Le p4e à un cache L2 doublé par rapport au p4c je crois...

            Je ne sais pas si ça joue enormément dans les perfs (jy connais strictement rien en architecture proc), mais l'ideal serait de comparer un p4c avec un p4c... (ou p4e avec un p4e) en désactivant l'HyperThreading dans le bios, par exemple :o)

            Faudra que j'essai avec mon P4C HT à l'occase.

            • [^] # Re: Linux ?

              Posté par  . Évalué à 3.

              bien sur que ca joue : le coup d'un acces dans le cache est negligable par rapport au cout d'acces en memoire...

          • [^] # Re: Linux ?

            Posté par  . Évalué à 1.

            P4C tu es sur?
            J'ai un P4C et je te confirme qu'il a bien le support de l'HyperThreading. Ce sont les P4B et P4A qui en sont dépourvus (à mois que mon vendeur mente et que /proc aussi).
            L'HyperThreading je ne suis pas sûr de l'intéret étant donné (corrigez-moi si je me trompe) que du coup le système devient un système SMP, ce qui implique plein de choses en plus dans le kernel, qui font que ce mode ralentit autant qu'il accélère le PC.

            • [^] # Re: Linux ?

              Posté par  . Évalué à 2.

              ... Les premiers P4C sortis étaient dépourvu d'HT.

    • [^] # Re: Linux ?

      Posté par  . Évalué à 7.

      Dans le lien donné:

      "The flaw affects all operating systems, and for a secure multi-user environment essentially requires that Hyper-Threading be disabled."

    • [^] # Re: Linux ?

      Posté par  . Évalué à 3.

      Je reconnais que mes connaissances en architecture sont assez limitées, mais tous ces articles parlent de failles pour BSD, mais je vois nul part un problème concernant Linux.
      Tous les acteurs principaux du monde linux ont ete avertis il y a, au minimum, deux mois. Selon Colin, ils se prennent bien la tete dessus ;-) mais bon, c'est partial comme point de vue :-)

  • # Mauvais pour Intel

    Posté par  (site web personnel) . Évalué à 7.

    Ca risque d'entacher un peu l'image de marque d'Intel cette affaire là...
    Même si désactiver l'HT ne représente pas une trop grande perte de performances, c'est jamais bon de se dire que son processeur comporte une faille...
    Je sais pas ce que vous en pensez mais je trouve c'est un coup à se tourner vers la concurrence... Bon, ça tombe bien, j'y étais déjà :)

    • [^] # Re: Mauvais pour Intel

      Posté par  (site web personnel) . Évalué à 10.

      c'est jamais bon de se dire que son processeur comporte une faille...

      Correction : ... que son processeur comporte 0.99999999996483 faille...

    • [^] # Re: Mauvais pour Intel

      Posté par  (site web personnel) . Évalué à 6.

      il me semble (mais j'en suis pas certain) que le seul autre type de CPU qui comporte une fonction multithreading est le Power5 d'IBM.
      c'est un gros CPU avec deux coeurs et chaque coeur peut traiter 2 threads.
      il faudra voir si dans cette histoire c'est une faille d'implémentation d'Intel ou si c'est une faille générique de la technique même du multithreading (on le saura selon le papier technique de Colin).
      Peut être que le le power 5 est touché aussi ?

      • [^] # Re: Mauvais pour Intel

        Posté par  . Évalué à 3.

        Parmis les processeurs proposant du SMT, il y a au moins depuis ajourd'hui le PowerPC qui équipe la XBOX2. Peut-être bien le Cell aussi.
        Il devait y avoir l'alpha EV8, mais je crois qu'il a fini à la poubelle. Il y avait aussi un certain nombre de versions de l'ultrasparc, mais une partie à dû finir aussi à la poubelle, et l'autre partie, je crois qu'elle est pas encore sorti.
        Sinon il me semble qu'il y avait le MAJC de Sun, un design plus ou moins expérimental mais qui est sorti depuis déja pas mal de temps, et j'ai vu évoqué vaguement le cas de processeurs plus spécialisés, mais je n'ai pas de détails ou de références à proproser.

        • [^] # Re: Mauvais pour Intel

          Posté par  . Évalué à 5.

          et le SUN Niagara, l'octo-core dont chaque core fait tourner 4 threads simultanément, il fait du SMT aussi, nan ?

          et de toute facon, ya que les mips qui valent quelque chose ^^ (je suis dehors la hein :D)

          • [^] # Re: Mauvais pour Intel

            Posté par  (site web personnel) . Évalué à 5.

            tous ces trucs (Xbox 2 ou Cell ou Niagara) c'est pas sorti.
            alors que le pentium 4 HT, le xeon ou le Power 5 c'est déja en prod chez beaucoup de monde.
            de toute façon les chances pour que ce soit une faille générique sont, je pense, infinitésimales.

      • [^] # Re: Mauvais pour Intel

        Posté par  . Évalué à 2.

        Non il y a aussi les SPARC de SUN les sparc IV qui sont monocore/bithread...comme les INTEL ca...

  • # Patch ?

    Posté par  . Évalué à 4.

    Et oui tiens, comment je vais le patcher mon CPU ?

    -->[]

  • # je vais aller acheter de l'aspirine :-)

    Posté par  . Évalué à 10.

    http://www.daemonology.net/papers/htt.pdf(...)

  • # The faille

    Posté par  . Évalué à -1.

    Attendons de voir déjà la publication de la faille et les exploits qui en découlent. Jetons un oeil aux proofs of concepts, et après jugeons. Parce que pour l'instant, elle est très "vaporeuse" voir fantomatique cette faille.
    Je n'ai certes pas bac+78, mais ayant fait de la route en informatique industrielle (cconception de CM, proc, etc....), je dois avouer que je n'y crois pas à cette fameuse faille du HT. Ou alors intel est très très mauvais et le monsieur a mis le doigt dessus. A moins qu'intel ne fabrique ses procs en chine ?

    • [^] # Re: The faille

      Posté par  . Évalué à 10.

      C'est pas une faille au sens habituel où tu pourrais lire des infos directement.
      C'est plutot une attaque cryptographique, qui joue sur les stratégies de recyclage du cache (qui reste partagé entre les processes en cours d'éxécution sur le processeur).
      Dans son papier, il démontre qu'on peut obtenir suffisamment d'information pour reconstruire une clé RSA 1024 en un temps raisonnable (celui d'une clé RSA 384 de mémoire), simplement en faisant tourner un processus de mesure des temps d'accès mémoire en même temps que le processus de cryptage: c'est donc une attaque basée sur la structure de cache.
      Il existait déjà de telles attaques, basées par exemple sur une surveillance de la consommation du processeur, ou sur l'écoute des rayonnements électromagnétiques.
      Cette attaque est une faille dans le sens où elle peut être effectuée logiciellement.

  • # Fonctionnalité!

    Posté par  . Évalué à 7.

    Ce n'est pas un bogue, c'est une fonctionnalité, voyons!

    Comment donc, vous n'aviez jamais entendu parler du célèbre processeur Pentium 4 avec Hyper-Threatening?

  • # Grave faille ou réthorique de consultant ?

    Posté par  . Évalué à 2.

    Le problème avec ce genre de failles, c'est qu'elles exigent des compétences importantes pour jauger pleinement de leur gravité (leur utilisabilité dans une attaque "réaliste" vs. l'alarmisme réthorique du papier de Percival).

    En l'occurence, Linus Torvald ne semble pas très inquiet quand aux conséquences possible de ladite "faille", au moins sous Linux: http://kerneltrap.org/node/5120(...)

    Coté OpenBSD, contrairement à ce qui a été dit plus haut, le HT est supporté si (et seulement si) le bios est un bios SMP. Dans ce cas la solution proposée est bien entendu de désactiver le SMP dans le bios. Même réaction chez NetBSD.

    Bref, à part dans une partie de la communauté FreeBSD et les tabloids, pardon, les sites de news ;), personne ne semble vraiment s'affoler...

    Undeadly relativise la gravité de la faille en ces termes (cf. http://undeadly.org/cgi?action=article&sid=20050522032210&m(...) )


    What the vulnerability does, is with a certain set of pre-conditions, allows an attacker to time how long it takes for the victim process to read memory.

    Preconditions: both processes are on the same CPU for the full amount of time of the process, the attacking process gets the first slice of time, and neither is put to sleep, or moved off the CPU. In theory, the attack will work on any two execution cores that share L1 cache memory.

    This threat does NOT allow the attacker to read the actual values of memory, just the time it spends.


    S'ils disent vrai, cette histoire ressemble plus à un battage médiatique sensationaliste qu'à une grave faille de sécurité.

Suivre le flux des commentaires

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