Journal l'Intel Core 2 Duo considéré dangereux par Theo de Raadt

Posté par  .
Étiquettes :
-2
28
juin
2007
D'après undeadly.org, Theo De Raadt, le leader d'openbsd aurait posté sur la mailing list un avertissement à propos des processeurs Intel Core 2 Duo. Selon lui, ces processeirs seraient à éviter en raison d'une liste des bugs impressionnantes, dont certains pourraient être utilisés à des fins malveillantes.

Certanis bugs peuvent être "contournés" via l'OS, mais il en reste d'autres qui ne peuvent être contournés qu'à partir du bios et que l'utilisateur reste très désarmé si les fabricants ne fournissent pas de fixs pour leurs bios.

Il termine en précisant que si AMD fait meilleure figure actuellement en terme de transparence, ils seraient de moins en communicatifs avec les projets opensource. Il suspecte que ce revirement d'attitude pourrait venir aussi d'une liste de bugs qui grossit elle aussi de jour en jour et dont AMD souhaiterait souhaiterait en limiter au maximum la visibilité.


Various developers are busy implementing workarounds for serious bugs in Intel's Core 2 cpu.

These processors are buggy as hell, and some of these bugs don't just cause development/debugging problems, but will *ASSUREDLY* be exploitable from userland code.

As is typical, BIOS vendors will be very late providing workarounds / fixes for these processors' bugs. Some bugs are unfixable and cannot be worked around. Intel only provides detailed fixes to BIOS vendors and large operating system groups. Open Source operating systems are largely left in the cold.

Full (current) errata from Intel:

http://download.intel.com/design/processor/specupdt/31327914(...)

* We bet there are many more errata not yet announced -- every month this file gets larger.
* Intel understates the impact of these erraata very significantly. Almost all operating systems will run into these bugs.
* Basically the MMU simply does not operate as specified/implimented in previous generations of x86 hardware. It is not just buggy, but Intel has gone further and defined "new ways to handle page tables" (see page 58).
* Some of these bugs are along the lines of "buffer overflow"; where a write-protect or non-execute bit for a page table entry is ignored. Others are floating point instruction non-coherencies, or memory corruptions -- outside of the range of permitted writing for the process -- running common instruction sequences.
* All of this is just unbelievable to many of us.

An easier summary document for some people to read:

http://www.geek.com/images/geeknews/2006Jan/core_duo_errata_(...)

Note that some errata like AI65, AI79, AI43, AI39, AI90, AI99 scare the hell out of us. Some of these are things that cannot be fixed in running code, and some are things that every operating system will do until about mid-2008, because that is how the MMU has always been managed on all generations of Intel/AMD/whoeverelse hardware. Now Intel is telling people to manage the MMU's TLB flushes in a new and different way. Yet even if we do so, some of the errata listed are unaffected by doing so.

As I said before, hiding in this list are 20-30 bugs that cannot be worked around by operating systems, and will be potentially exploitable. I would bet a lot of money that at least 2-3 of them are.

For instance, AI90 is exploitable on some operating systems (but not OpenBSD running default binaries).

At this time, I cannot recommend purchase of any machines based on the Intel Core 2 until these issues are dealt with (which I suspect will take more than a year). Intel must be come more transparent.

(While here, I would like to say that AMD is becoming less helpful day by day towards open source operating systems too, perhaps because their serious errata lists are growing rapidly too).


Lien undeadly :
http://undeadly.org/cgi?action=article&sid=2007062813460(...)

Lien vers la discussion sur la mailing list :
http://marc.info/?t=118296457100003
  • # désolé pour les fautes.

    Posté par  . Évalué à 9.

    oula j'ai bien fais de ne pas proposer une dépêche vu le nombre de typo et fautes que j'ai pu glisser dans ce journal...

    On va dire que c'est la fatigue :)
    • [^] # Re: désolé pour les fautes.

      Posté par  . Évalué à 10.

      Tu peux donc corriger les fautes, rajouter une traduction en français et proposer une dépêche.

      Tu as tout notre soutien moral, bon courage. :)
      • [^] # Traduction

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

        Une traduction du courriel de Theo :

        Beaucoup de développeurs sont occupés à implémenter des contournements pour des bugs sérieux touchant les processeurs Intel Core 2.

        Ces processeurs sont très gravement buggés et certains de ces bugs ne causent pas seulement des problèmes de développement/debugging, mais il vont *ASSUREMENT* être exploitable depuis du code tournant en mode utilisateur.

        Comme d'habitude, les vendeurs de BIOS vont mettre beaucoup de temps à fournir des contournement/fix pour ces bugs de processeur. Certains bugs ne sont pas fixables et ne peuvent pas être coutournés. Intel donne uniquement des données détaillées concernant les fix aux vendeurs de BIOS ou aux grand groupes éditeurs de systèmes d'exploitations. Les systèmes d'exploitation open source sont laissés de côté.

        Errata actuel complet de Intel :

        http://download.intel.com/design/processor/specupdt/31327914(...)

        * Nous parions qu'il y a beaucoup plus d'errata qui n'ont pas encore été annoncés - ce fichier grandit chaque mois
        * Intel sait très bien quel est l'impact de ces errata. A peu près tous les systèmes d'exploitation seront sujets à ces bugs.
        * Basiquement, la MMU ( ndt: http://fr.wikipedia.org/wiki/MMU ) ne fonctionne pas comme spécifié/implémenté dans les générations précédentes de matériel x86. Ca n'est pas simplement une question de bug, Intel est allé plus loin et a défini une "nouvelle manière de gérer les tables de pages" (voir page 58).
        * Certains de ces bugs sont proches d'un dépassement de tampon; lorsqu'un bit spécifiant qu'il ne faut pas exécuter ou écrire une entrée de page est ignoré. D'autres sont des incohérences dans les instructions de calcul en virgule flottante ou des corruptions de mémoires -- en-dehors des zones d'écritures permises pour le processus -- qui arrivent en exécutant des séquences d'instructions courantes.
        * Tout cela semble incroyable à beaucoup d'entre nous.

        Un résumé plus facile à lire :

        http://www.geek.com/images/geeknews/2006Jan/core_duo_errata_(...)

        Il faut noter que certains errata comme AI65, AI79, AI43, AI90, AI99 sont terrifiants. Certains ne peuvent pas être fixé dans un code exécuté et certains sont des choses que n'importe quel système d'exploitation va faire jusqu'à environ mi-2008 parce que c'est la façon dont la MMU a toujours fonctionné sur toutes les générations de matériel Intel/AMD/autres. Maintenant, Intel dit simplement au gens de gérer le vidage des TLB (ndt: http://en.wikipedia.org/wiki/Translation_Lookaside_Buffer ) de la MMU d'une façon nouvelle et différente. En fait, même en faisant ces changements, certains bugs subsisterons.

        Comme je l'ai dis précédemment, dans cette liste se cache 20-30 bugs qui ne peuvent pas être contourné par les systèmes d'exploitations et qui sont potentiellement exploitables. Je mettrais ma main au feu qu'au moins 2 ou 3 d'entre eux le sont effectivement.

        Par exemple, AI90 est expoitable sur certains systèmes d'exploitations (mais pas OpenBSD tournant avec les binaires par défaut).

        Actuellement, je ne peux pas recommander l'achat d'une quelconque machine basé sur un processeur Intel Core 2 jusqu'à ce que ces problèmes soit reglés. (ce qui je suppose va prendre plus d'une année).
        Intel doit devenir plus transparent.

        (Du moment que j'y suis, j'aimerais dire qu'AMD devient de moins en moins coopératif avec les systèmes d'exploitations open source. Peut-être parce que leurs liste d'erratas sérieux s'allonge également rapidement).
        • [^] # Re: Traduction

          Posté par  . Évalué à 2.

          Pour information, fix deviendrait corriger en Français.
    • [^] # Re: désolé pour les fautes.

      Posté par  (site Web personnel) . Évalué à 4.

      Surtout qu'une dépêche pour proposer un copier coller en anglais sur un site francophone eu été du meilleur effet...
      • [^] # Re: désolé pour les fautes.

        Posté par  . Évalué à 10.

        j'aurai bien évidemment fait un plus grand effort de rédaction le cas échéant. D'où le passage par la case journal, y'a des jours comme ça où le courage manque...
  • # Linus a dit : « c'est totalement insignifiant »

    Posté par  (site Web personnel) . Évalué à 8.

    http://www.realworldtech.com/forums/index.cfm?action=detail&(...)

    pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

    • [^] # Re: Linus a dit : « c'est totalement insignifiant »

      Posté par  . Évalué à -1.

      Theo de Raadt crit toujours au loup pour trois fois rien.
      Il aime jouer les "rebelles contre un complot planètaire".
      • [^] # Re: Linus a dit : « c'est totalement insignifiant »

        Posté par  (site Web personnel) . Évalué à 9.

        Ben quand le leader de l'OS libre le plus sécurisé du monde affirme publiquement qu'un CPU est lardé de bugs et qu'il recommande à tous d'éviter de l'acheter car l'OS tournant dessus ne pourra pas faire grand chose contre ces failles...c'est quand même une information notable !
        Tu notera que les posts de Linus se contentent d'affirmer qu'il y a des bugs dans tous les CPU et que la modif de gestion du TLB introduite dans le Core 2 ne va pas (par chance) impacter Linux.
        Il n'affirme pas que les failles du CPU sont négligeables ou dérisoires...ce qui est compréhensible quand on regarde la liste !
        • [^] # Re: Linus a dit : « c'est totalement insignifiant »

          Posté par  . Évalué à 3.

          Il n'affirme pas que les failles du CPU sont négligeables ou dérisoires...ce qui est compréhensible quand on regarde la liste !


          Mais si on regarde les autres messages, on peut lire de la part de Andi Kleen (responsable linux x86_64) [1] :
          Overall I don't have the impression that Core2 is buggier
          than earlier CPUs.


          [1] http://www.realworldtech.com/forums/index.cfm?action=detail&(...)
        • [^] # Re: Linus a dit : « c'est totalement insignifiant »

          Posté par  . Évalué à 0.

          > Ben quand le leader de l'OS libre le plus sécurisé du monde

          OS "marginal" sans service par défaut (ils sont tous désactivé).
          En passant Linux aussi roxe niveau sécurité (ENFORCE de gcc, SeLinux "à tous les étages", Audit, signature du noyau, execshield, etc).

          > affirme publiquement qu'un CPU est lardé de bugs

          Ce n'est pas la première fois qu'il fait des affirmations à la con. Voir l'épisode OLPC pour un récent.

          > il recommande à tous d'éviter de l'acheter car l'OS tournant dessus ne pourra pas faire grand chose

          D'autres "experts", et non des moindres (Linus Torvalds, tu connais ?) trouvent que le Core Dual est peu buggué et que de gros efforts sont fournis par Intel et AMD pour assurer la qualité. Linus Torvalds trouve aussi que l'incompatibilité avec les anciens CPU n'est pas un problème ici car en fait le nouveau comportement est meilleur et que c'était plustot les anciens qui étaient les plus buggués. Je trouve aussi que ça pèse dans la balance.

          > OS tournant dessus ne pourra pas faire grand chose

          C'est surtout car OpenBSD a des problème pour s'adapter aux nouveaux CPU d'Intel que Theo gueule. Mais là il ne doit s'en prendre qu'à lui.
          Il gueule car Intel bosse pour Linux et non pour OpenBSD. Ça le gouffle et donc il ne rate pas une occasion pour taper sur Intel.
          C'est minable et ce n'est pas la première fois.

          > et que la modif de gestion du TLB introduite dans le Core 2 ne va pas (par chance) impacter Linux.

          Et Linus trouve la gestion du TLB du Core 2 meilleure ... et non "lardée de bugs".

          > Il n'affirme pas que les failles du CPU sont négligeables ou dérisoires...

          Il fait "seulement" un appel au boycott...

          > ce qui est compréhensible quand on regarde la liste !

          Et cette liste n'est pas plus importante qu'un autre CPU. Pas de quoi crier au loup.
          Afficher une grosse liste de bug, c'est aussi parfois le prix de la transparence.
          Beaucoup trouvent que les Core 2 sont de qualité et je trouve très bien qu'Intel joue la transparence.

          PS : je n'utilise pas de CPU Intel. Mais Theo me gonffle à taper sur Intel gratuitement.
          • [^] # Re: Linus a dit : « c'est totalement insignifiant »

            Posté par  (site Web personnel) . Évalué à 3.

            Comme réponse reporte toi au commentaire d'Herodiade en dessous (celui qui évoque l''opinion de Matt Dillon).
            Visiblement il n'y a pas que Theo qui est effrayé par certains des bugs du Core 2....ce qui détruit ta théorie d'un Theo psychopathe solitaire détestant Intel.
          • [^] # Re: Linus a dit : « c'est totalement insignifiant »

            Posté par  . Évalué à 5.

            tu fais péter le trollomètre toi.

            Bien que Téo a parfois des manières très rustres d'exprimer ses idées, on ne peut pas dire que ce soit le cas ici. Il expose simplement des bugs qui lui (et pas seulement lui) font peur.

            Vois-tu une insultes à Intel dans son mail sur la mailing list ? zéro.

            Et crois moi, quand Theo s'énerve réellement, les insultes pleuves comme des halebardes. ^_^
    • [^] # Re: Linus a dit : « c'est totalement insignifiant »

      Posté par  (site Web personnel) . Évalué à 3.

      Si j'ai bien compris, Linus dit ça à propos d'un seul des problèmes, alors que c'est truffé de bugs :
      [http://www.geek.com/images/geeknews/2006Jan/core_duo_errata_(...)]
      • [^] # Re: Linus a dit : « c'est totalement insignifiant »

        Posté par  . Évalué à 1.

        alors que c'est truffé de bugs
        A tu des elements de comparaisons pour dire qu'il y a plus de bugs que dans les versions precedentes/chez les concurents ?

        Tout les cores aussi complexe que les x86 ont forcement des bugs (a moins de valider le truc pendant des années et le sortir alors qu'il est deja obsolète).

        Certains fournisseurs ne publient pas les bugs (regarde de quand date le dernier errata de AMD) ou encore pire dans l'embarqué ou il faut parfois se battre pour que le fondeur reconnaisse le bug.
        • [^] # Re: Linus a dit : « c'est totalement insignifiant »

          Posté par  . Évalué à 7.

          Je ne vais pas me prononcer sur le problème du core 2 qui est bien trop technique, par contre dire "a moins de valider le truc pendant des années et le sortir alors qu'il est deja obsolète" je trouve ça super révélateur de la façon dont fonctionne l'informatique moderne :-)
          (et peut être même dont elle a toujours fonctionné).

          La gent féminine, pas la "gente", pas de "e" ! La gent féminine ! Et ça se prononce comme "gens". Pas "jante".

        • [^] # Re: Linus a dit : « c'est totalement insignifiant »

          Posté par  . Évalué à 5.

          A tu des elements de comparaisons pour dire qu'il y a plus de bugs que dans les versions precedentes/chez les concurents ?

          Ce n'est généralement pas comme ça qu'on procède dans le domaine de la sécu informatique : on parle des bugs connus (« n'utilisez pas le produit x version y pour faire telle chose, il présente des déficiences notable sur le plan sécurité »). Ne serait-ce que pour encourager ceux qui maintiennent le produit à corriger leur failles prompto (et à tacher d'éviter d'en faire d'autres du même genre la prochaine fois), ou permettre à ceux qui utilisent le produit de ne pas tomber dans le cas d'utilisation qui expose le problème. Le boulot des journalistes et des professionnels de la sécurité informatique est de nous avertir pour faire bouger les choses : Cyrix, qui produisait des procs sensiblement buggués en sait quelque chose : ils l'ont senti passer, et heureusement qu'on n'a pas gardé le silence.

          Deuxièmement, on parle ici d'un type de bugs un peu particulier, surtout pour le monde du matériel : ce sont des bugs ayant un potentiel fort d'impact sur la sécurité.

          Concernant les hypothétiques mais probables bugs « dont on ne sait rien », on peut bien sûr se perdre en conjectures... mais est-ce bien utile ? ça ne l'est surement pas s'il s'agit de dédouaner ceux dont les bugs sont connus !

          Tout les cores aussi complexe que les x86 ont forcement des bugs

          Et ? faut-il s'abstenir de faire état des problèmes dont on apprend l'existence ? Tu imagine si nous réagissions comme ça pour le logiciel « (n'en parlons pas | ne jetons pas la pierre ) parce que tout logiciel de plus de 1000 lignes contient forcément des bugs » ?

          Certains fournisseurs ne publient pas les bugs

          Souhaitons que quelques bonnes vieilles full disclosure vienne leur boter le train. Encore une fois, le précédent de Cyrix devrait les inciter à la prudence (je pense à ce sujet qu'AMD est méchamment sur le déclin, et depuis leur rachat d'ATI ils sont sur ma liste noire de constructeurs travaillant comme des cochons, ne filant ni specs ni code libre pour leurs chipsets).
  • # ...

    Posté par  . Évalué à 4.

    Certanis bugs peuvent être "contournés" via l'OS, mais il en reste d'autres qui ne peuvent être contournés qu'à partir du bios et que l'utilisateur reste très désarmé si les fabricants ne fournissent pas de fixs pour leurs bios.
    Hum, contrairement au AMD, sous intel ont peut pacher le microcode au démarage avec des truc comme microcode.ctl (meme si on a pas de patch du bios).


    apt-cache show microcode.ctl
    [...]
    The microcode update is volatile and needs to be uploaded on each
    system boot i.e. it doesn't re-flash your CPU permanently, reboot and
    it reverts back to the old microcode. The ideal place to load
    microcode is in BIOS, but most vendors never update it!


    Et puis il faut souligner que intel fait l'effort de publier pas mal d'errata.
    • [^] # Re: ...

      Posté par  . Évalué à 1.

      Certains articles font état de microcode pour amd (le K8 par exemple):
      http://www.securiteam.com/securityreviews/5FP0M1PDFO.html
      • [^] # Re: ...

        Posté par  . Évalué à 3.

        Certains articles font état de microcode pour amd (le K8 par exemple):
        oui IIRC, des personnes c'étaient amusé a analysé un bios pour essayer de faire une mise a jour depuis Linux, mais je crois que ca ete vite abandonné au vu des risque de tout casser (y a toujours pas de driver offciel dans les OS et ton truc date de 2004).

        De plus c'est que pour les K8, le driver intel les supporte tous depuis les pentium pro.
        Enfin intel fait des releases de microcode pour microcode.ctl (les derniere date de 04/2007), alors que pour le truc que tu cite il faut l'extraire des bios.


        Bref rien de comparable.
        • [^] # Re: ...

          Posté par  . Évalué à 4.

          Bref rien de comparable.
          Je parlais pas forcément de chose 'comparable'.

          Il faut arreter de voir des fanatiques partout aussi.

          Moi je m'intéresse d'un point de vue pragmatique : est il possible d'un point de vue PUREMENT TECHNIQUE (peut etre pas réellement, ni sous un os libre) d'updater le microcode d'un processeur amd ?

          J'ai jamais dis que 'ouais intel c'est le mal amd ca roxxor'


          Bref je comprend pas ta réaction.

          exemple :
          'y a toujours pas de driver offciel dans les OS et ton truc date de 2004'
          Ben oui, j'ai fait une recherche comme ca parce que ce sujet m'intéressais, pas que je tenais a prouver quoi que ce soit . C'tout.
          • [^] # Re: ...

            Posté par  . Évalué à 2.

            Désolé si j'ai été un peu agressif, mais dans ce cas je comprends pas ton premier commentaire.

            Oui on peut mettre a jour le microcode d'un amd, mais on en revient a la problématique que je citais :

            Certanis bugs peuvent être "contournés" via l'OS, mais il en reste d'autres qui ne peuvent être contournés qu'à partir du bios et que l'utilisateur reste très désarmé si les fabricants ne fournissent pas de fixs pour leurs bios.

            Dans le cas d'intel, pourvu qu'intel fournisse une mise a jour, tout le monde en profitera, dans le cas d'autres cpu une mise a jour du bios (qui fera des mises a jour microcode a chaque demarage) est nécessaire.

            Voila je voulais simplement dire que dans le cas des core2duo, la mise a jour pour corriger les bugs étaient relativement aisé sous Linux et on ne dépendait pas du bios( comme pour d'autres cpu tel que AMD).
            • [^] # Re: ...

              Posté par  . Évalué à 3.

              c'est que j'ai du oublier le 'je crois que' devant mon commentaire ;)
              la fatigue toussa ...

              Pour le problème du bios, c'est vrai que je comprend pas la logique d'amd, mais bon c'est pas la première fois que je comprend pas une logique pseudo marketing reposant sur le secret.

              < rien a voir>
              Peut on créer ses propres microcodes ou c'est un truc bien protéger ?
              Je présume que c'est ultra protégé par intel non ? (vu que ca semble etre les seul a diffuser le patch publiquement)
              < /rien>

              /me rêve d'un pc où toutes les interfaces soient spécifiée et normalisées.... Et où l'état oblige les gens a collaborer entre eux (seuls logiciels autorisé : les logiciels open source, itou itou...)
              /me aime bien rêver :D
            • [^] # Re: ...

              Posté par  . Évalué à 3.

              dans le cas des core2duo, la mise a jour pour corriger les bugs étaient relativement aisé

              À condition que tout ces problèmes soit corrigeables par mise à jour du microcode.

              Lorsqu'on parle de la nécessité de mettre à jour le BIOS, dans notre cas, il peut s'agir seulement de ça (le BIOS contenant aussi le microcode, et donc là pas de problème on sait aussi le mettre à jour depuis l'OS), ou bien d'un changement ou d'un workaround pour contourner le bug très différent (le BIOS, ce n'est pas que le microcode hein).
  • # Commentaire de Matt Dillon

    Posté par  . Évalué à 7.

    Matt Dillon est le « Linus Torvalds » (ou le « Theo de Raadt » si vous préférez, bref, le lead developer quoi) de DragonFlyBSD et fut un de contributeurs majeur de la VM de FreeBSD (travaille qui le qualifie justement pour évaluer l'impact de certains de ces bugs), cf. http://en.wikipedia.org/wiki/Matt_Dillon_%28computer_scienti(...)

    Il a livré un rapide commentaire sur les principaux bugs dévoilés dans les récentes erratas d'Intel :

    - Ici, celles dont parle spécifiquement Theo (AI65, AI79, AI43, AI39, AI90 et AI99) :
    http://hardware.slashdot.org/comments.pl?sid=242663&cid=(...)

    - Ici celles concernant les Core 2, dont ne parle pas vraiment le message de TdR (en dépit du titre de son email) :
    http://hardware.slashdot.org/comments.pl?sid=242663&cid=(...)
    (et qui font dire à Dillon, au sujet des core/core2 duo : « So, in summary, AE3 scares the hell out of me, and for the others AE5, AE8, AE21, and AE30 look serious. »).

    Notez que les descriptions des problèmes dans l'errata d'Intel semblent souvent très vagues (d'où des incertitudes dans l'appréciation des conséquences possibles, selon les développeurs).

    Concernant la possibilité de corriger ces problèmes par upgrade du microcode, donnez vous la peine de regarder le pdf d'Intel : la plupart de ces bugs sont marqués : "Plan : No Fix".

    À ce sujet, voici l'errata d'Intel au sujet des Core 2 :
    http://download.intel.com/design/processor/specupdt/31327914(...)

    Et celle au sujet des Core Duo et Core Solo :
    http://download.intel.com/design/mobile/SPECUPDT/30922211.pd(...)
    • [^] # Re: Commentaire de Matt Dillon

      Posté par  . Évalué à 2.

      On peut noter quand même que Linus Torvalds a bossé un bout de temps chez Transmeta, une entreprise qui faisait des processeurs x86 à l'époque...
  • # Ça marche aussi bien dans l'autre sens...

    Posté par  . Évalué à 5.

    Theo de Raadt considéré dangereux par l'Intel Core 2 Duo...

Suivre le flux des commentaires

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