Journal : l'Intel Core 2 Duo considéré dangereux par Theo de Raadt
Posté par PsychoFox () le 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é.
Lien undeadly :
http://undeadly.org/cgi?action=article&sid=2007062813460(...)
Lien vers la discussion sur la mailing list :
http://marc.info/?t=118296457100003
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
> Lire le journal (28 commentaires, moyenne: 4,4).
Vous avez demandé le commentaire #846259.
Run by 
Cette page a été générée par Templeet en 0.0604s (dont 0.0037 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Linus a dit : « c'est totalement insignifiant »
http://www.realworldtech.com/forums/index.cfm?action=detail&(...)
Free Softwares Users Group Arlon (Sud Luxembourg, Belgique)
pertinent, e adj. Approprié ; qui se rapporte exactement à ce dont il est question.
[+] [^]Re: Linus a dit : « c'est totalement insignifiant »
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 »
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 »
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 »
> 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 »
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 »
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 »
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_(...)]
Th. Thomas.
[^]Re: Linus a dit : « c'est totalement insignifiant »
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 »
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é).
[^]Re: Linus a dit : « c'est totalement insignifiant »
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).