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 Psychofox (Mastodon) . Évalué à 9.
On va dire que c'est la fatigue :)
[^] # Re: désolé pour les fautes.
Posté par Lucas Bonnet . Évalué à 10.
Tu as tout notre soutien moral, bon courage. :)
[^] # Traduction
Posté par Jux (site web personnel) . Évalué à 10.
[^] # Re: Traduction
Posté par Mark Havel . Évalué à 2.
[^] # Re: désolé pour les fautes.
Posté par Calim' Héros (site web personnel) . Évalué à 4.
[^] # Re: désolé pour les fautes.
Posté par Psychofox (Mastodon) . Évalué à 10.
# Linus a dit : « c'est totalement insignifiant »
Posté par Krunch (site web personnel) . Évalué à 8.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: Linus a dit : « c'est totalement insignifiant »
Posté par IsNotGood . Évalué à -1.
Il aime jouer les "rebelles contre un complot planètaire".
[^] # Re: Linus a dit : « c'est totalement insignifiant »
Posté par patrick_g (site web personnel) . Évalué à 9.
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 M . Évalué à 3.
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 IsNotGood . Évalué à 0.
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 patrick_g (site web personnel) . Évalué à 3.
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 Psychofox (Mastodon) . Évalué à 5.
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 Thierry Thomas (site web personnel, Mastodon) . Évalué à 3.
[http://www.geek.com/images/geeknews/2006Jan/core_duo_errata_(...)]
[^] # Re: Linus a dit : « c'est totalement insignifiant »
Posté par M . Évalué à 1.
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 fasthm . Évalué à 7.
(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 herodiade . Évalué à 5.
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 M . Évalué à 4.
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 briaeros007 . Évalué à 1.
http://www.securiteam.com/securityreviews/5FP0M1PDFO.html
[^] # Re: ...
Posté par M . Évalué à 3.
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 briaeros007 . Évalué à 4.
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 M . Évalué à 2.
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 briaeros007 . Évalué à 3.
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 herodiade . Évalué à 3.
À 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 herodiade . Évalué à 7.
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 Pinaraf . Évalué à 2.
# Ça marche aussi bien dans l'autre sens...
Posté par André Rodier . Évalué à 5.
[^] # Re: Ça marche aussi bien dans l'autre sens...
Posté par Sylvain Sauvage . Évalué à 0.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.