Push-Nachrichten von MacTechNews.de
Würden Sie gerne aktuelle Nachrichten aus der Apple-Welt direkt über Push-Nachrichten erhalten?

Intel Core 2 Duo Desktop und Core 2 Extreme mit besonders vielen Fehlern?

Bereits seit Jahrzehnten ist das Phänomen von Fehlern in Prozessoren bekannt. Durch die steigende Komplexität von Prozessoren und Chipsätzen lassen sich nicht alle Fehler finden, da sie meistens nur unter ganz bestimmten Bedingungen auftreten. Wie DailyTech berichtet, herrscht momentan eine Diskussion zwischen verschiedenen Entwicklern, ob die von Intel veröffentlichten Hardware-Fehler der Core 2 Duo Prozessoren für Desktop-Computer besonders viele und kritische Fehler aufweisen. Auf 37 Seiten hat Intel nämlich insgesamt 105 Fehler dieser Prozessoren veröffentlicht, wobei drei von ihnen kritischer Natur sind. Sie treten während der Ausführung des Software-Code auf und führen meist zu einem veränderten Ablauf. Allerdings lassen sich viele dieser Fehler durch Compiler-Optimierungen und Änderungen im Code umgehen. Darüber hinaus veröffentlicht Intel auch BIOS-Updates, mit denen sich einige Fehler der Prozessoren bereits beheben lassen. Dennoch findet OpenBSD-Gründer Theo de Raadt die veröffentlichte Fehlerliste bedenklich, da einige Fehler nicht behoben werden können und von jeder Software aus nutzbar sind, was die Sicherheit beeinträchtigen kann. Linus Torvald sieht dagegen die Fehler nicht als besonders kritisch an und glaubt auch, dass x86-Prozessoren aufgrund der hohen Aufmerksamkeit besonders gut auf Fehler hin getestet werden und dadurch weniger Software-Fehler aufweisen.

Weiterführende Links:

Kommentare

DonQ
DonQ03.07.07 12:05
interessant, bsd gründer mit einer lean, clean strucur im hintergrund bemängelt dies, linux gründer meint das ist normal und gut getestet.

hmm, das kommt halt davon wenn jeder ein eckchen dranklebt und dauernd die instructions erweitert an dem was halt verfügbar ist.

an apple a day, keeps the rats away…
0
Lolipoldie03.07.07 12:11
ein hoch auf den PPC !
0
strife03.07.07 12:11
Willkommen im Land der vollständig Ausdrucks- und Stilbefreiten. Und damit meine ich sowohl den Redakteur als auch den bisherigen Poster. Einfach nur traurig.
0
DonQ
DonQ03.07.07 12:15
strife

du bist hier "online", deutsch ist halt nur der kleinste gemeinsame nenner, finde dich damit ab oder lass es.

an apple a day, keeps the rats away…
0
xenophanes03.07.07 12:15
Naja, ich könnte jetzt auch auf den Nörgelzug aufspringen so à la, «Was hat diese Meldung hier verloren?!? Jedes Kind weiss doch, dass Apple keine Desktopversion des Core 2 Duo einsetzt!!! Es ist echt zum kotzen!!! Ich meine, MTN ist sicher eine tolle Newsseite, aber in letzter Zeit überspannt Ihr den Bogen!!!»

:-P:-P
0
felixdacat
felixdacat03.07.07 12:16
Ich hab noch Core Duo
0
datzl03.07.07 12:27
Lolipoldie:
Jede CPU hat Fehler, auch der PPC
0
datzl03.07.07 12:29
Lolipoldie:
Jede CPU hat Fehler, auch der PPC
0
Tekl03.07.07 12:33
Ohne die Bugs wäre der C64 sicher nicht so weit gekommen
0
ma-ka03.07.07 13:06
kann man die nicht einfach für die nächste revision ausbessern?
0
rgoetz03.07.07 13:15
Hallo,

Wie datzl schon schrieb: Jede CPU hat Fehler.

Nur geht Intel besonders offen damit um, da sie sich beim Pentium-FDIV-Bug die Finger besonders heftig verbrannt hatten.

Entscheident ist also nicht, ob es Fehler gibt, sondern wie schwerwiegend diese sind. In diesem Fall ist Theo de Raadt der Meinung, das einige der Fehler dazu geeignet seine, Sicherheitsmechanismen der CPU (insbesondere das NX-bit) zu umgehen. Sollte dies so sein, wäre das in der Tat ein Problem, weil das OS sich dann auf den NX-bit-Mechanismus verlässt und u.U. Schadkode nicht erkennt, weil der ja dank NX-Bit nicht ausgeführt werden dürfte (es aber dank bug wird).

Ob diese Fehler wirklich so ausgenutzt werden können, ist aber umstritten.


Für die anderen CPUs der Core2Duo-Familie wird es ähnliche Errata geben (bin jetzt zu faul zum suchen). In der heise-meldung dazu
(BTW vom 29.6.2007 , dafür mit mehr Deatils zu den Bugs ) ist nicht spezifisch von den Desktop-Varianten die Rede.

Bis dann

R"udiger
0
SirRichard
SirRichard03.07.07 13:52
Theo de Raadt ist die Opensource-Antwort auf Steve Ballmer! An was hat der Mann eigentlich nichts zu kritisieren (außer an seinem sicheren aber lahmen OpenBSD)? Er und Thorvald sind Charaktere, die unterschiedlicher nicht sein können. Soll de Raadt doch lieber noch ein paar OpenBSD-T-Shirts verkaufen, damit die OpenSSH weiterentwickelt werden kann kann und ein paar bekannte Exploits gestopft werden können!
0
Maxefaxe03.07.07 14:00
Ja der PPC hatte auch Fehler, allerdings in der Größenordnung von weit unter 20.

Bei der Anzahl der Transistoren der Core Duos und den ganzen Kompatibilitäts-Altlasten wundert mich das wenig.
0
Resistance03.07.07 15:51
Ich finde, das wird viel zu stark übertrieben.

Man muß sich nur mal die Bedingungen anschauen, unter denen man den "NX Bit Bug" ausnutzen kann. Ich halte das für ziemlich schwierig, diese Vorbedingungen zu erfüllen um überhaupt erst Mal in den "Genuß" des Bugs zu kommen...
0
-MacNuke-03.07.07 16:13
@ maxefaxe

Nur haben die normalen PowerPCs auch keinerlei Sicherheitsmechanismen.

Es geht hier schlicht um Sicherheitslücken in Sicherheitshardware. Wenn eine CPU gar keine Sicherheitshardware hat (wie die PowerPCs), dann ist es nicht gerade sinnvoll hier weniger Fehler als positiv hinzuhalten.

Wäre genauso als wenn man sagt das Flugzeuge häufiger abstürzen als Autos
0
rgoetz03.07.07 16:28
Hallo,

-MacNuke-

Laut der wikipedia (http://de.wikipedia.org/wiki/NX-Bit , vierter Absatz oder 1.Absatz nach dem Inhaltsverzeichnis) wird eine dem NX-bit vergleichbare Technik bereits seit längerem bei SPARC, Alpha, PowerPC und beim Itanium eingesetzt. Diese Sicherheitshardware gibt es also auch beim PowerPC. Ob sie genutzt wird ist dann eine zweite Frage.

Zumindest habe ich beim Googlen danach Kernelsourcen vom FreeBSD und Linux gefunden, die dies nahelegen.

maxefaxe

Ich meine mich zu erinnern, dass Intel bei der Offenlegung von Hardwarebug in den CPUs besonders offen ist (weil sie sich damals halt die Finger verbrant haben) und auch kleinste bugs dokumentiert, welche andere Hersteller u.U. als irrelevant ansehen und daher nicht nach aussen dokumentieren. Insofern ist es fraglich, ob man anhand der puren Zahl Vergleiche anstellen kann.

Bis dann

R"udiger
0
-MacNuke-03.07.07 16:47
@rgoetz

ggf. verwechselt man hier PowerPC mit POWER-Architektur.

G4 und G5 haben diese Technik nach meinen Infos nicht drinnen.
0
rgoetz03.07.07 16:59
Hallo,

Ich habe leider keine Details gefunden (jedenfalls auf die Schnelle).
Und alle Power genannten CPUs seit dem Power 4 sind PowerPCs. Power sind seit dem die "High-end"-PowerPCs (so wie dier Xeons High-End-x86er sind (na ja Power ist schon mehr High-End als Xeon)).

Und da der G5 direkt vom Power4 abgeleitet ist (d.h. es ist ursprünglich ein Single-Core-Power4 mit nur einem L2-Cache-Segment aber dafür mit AltiVec), wird er es wohl auch haben, wenns der Power4 hatte.

Ich such mal weiter, wenn ich was finde melde ich mich.

Bis dann

R"udiger
0
Namedrop03.07.07 17:12
Laut c´t existieren in der Fehlerliste größtenteils die gleichen Fehler der Core Architektur wie der Pentium III Architektur.
Dies zeigt zum Einen dass sie stark verwandt sind und zum Anderen dass Intel hier nichts getan hat.

Auch ist bekannt dass Intel immer dort sehr stark rudert, wo es sich marketingmäßig ausschlachten lässt. Cachegröße, TDP (auch wenn es eine irrwitzige Definition davon gibt..), ....

Auch anzumerken ist, dass jeder CPU-Fehler Rechenzeit kostet, da er umgangen werden muss. Desweiteren kann er SIcherheitsprobleme nach sich ziehen...
0
rgoetz03.07.07 18:12
Hallo,

Noch zu NX beim Power/PC

Laut

hatte der PowerPC schon immer ein NX bit, das aber nur Segementweise vergeben werden konnte. Ein Segement umfasst beim PowerPC wohl immer 256MB.

Seit dem Power4 beherrscht der PowerPC das ganze auch Page-weise, wobei eine Page normalerweise 4KB groos ist (es gibt aber auch large pages)

Laut dem PowerPC Architecture Book, Book III Version 2.01 , Seite 31 enthält der Page Table Entry (PTE) besagtes no-execute bit.


Beim PPC970FX (bei den anderen hab ich nicht genauer geguckt) wird es nun komplizierter. Einfach ist zunächst, dass der PPC970FX auch 16MB große large pages unterstützt.


Der PPC970FX (und vielleicht auch frühere) unterstützen aber auch ein pageweise guarded bit. Dies verhindert out-of-order Load-Store-Zugriffe z.B. bei Addressen an denen I/O-Register liegen (siehe PowerPC Architecture Book, Book III S.24)

Laut S 135, hat das Guard-bit bei instrution fetches aber einen dem no-execute-bit vergleichbaren Effekt. Das explizite no-execute-bit fehlt dem PPC970FX und dem 970MP wohl aber. Ob das Guard-bit sich wirklich dazu "misbrauchen" lässt kann ich auch nicht wirklich beurteilen.

Zusammenfassen kann man wohl, dass (nahezu) alle PowerPCs ein segementweises No-Execute beherrschen, aber erst die neueren (ab Power4, und wohl auch bei einem hätte-sein-können-PPC970-Nachfolger) diese auch pro page.

Bis dann

R"udiger
0
rgoetz03.07.07 18:19
Ach so, eines hatte ich noch vergessen. Hier hat jemand wohl einen Patch für den Linuxkernel und ältere PowerPC (PCC 6xx, PPC7xx, PPC7xxx) entwickelt, der einen vergleichbaren Schutz liefern soll. Ob das eine reine Softwarelösung ist, oder sowas wie das Guard-bit nutzt ist mir nicht klar. Dazu kann ich zuwenig assembler

Bis dann

R"udiger
0

Kommentieren

Sie müssen sich einloggen, um die News kommentieren zu können.