News AMD Opteron: Microcode-Patch für Fehler in Piledriver-CPUs

[Brötchenesser]

alter Hut

kann sich noch jemand an den alten Pentium Bug erinnern..wo der Prozessor dann falsch rechnete
das war aber ein richtiger Hardware Fehler....

 

[TrueAzrael]

Ja und wie will man den Fehler einfach mal so finden, wenn man nicht weiß, wonach man genau suchen muss? Hätte AMD eine Verbreitung wie Intel, wäre der sicher schneller aufgefallen.

Worüber diskutieren wie hier eigentlich?

Zu diskutieren gibt es da nicht viel.
Der Artikel ist "falsch" geschrieben. AMD hat den Fehler eben nicht schnell erkannt, sondern schnell behoben. Ist aber i-Punkt-Reiten sondergleichen. Aber zumindest korrekt der Einwand aus der Sicht, wenn auch unnötig.

 

[Popey900]

"....der fast 3,5 Jahre alten Piledriver-Architektur bereitstellen"

und

"AMD hat das Problem schnell erkannt...."

läuft bei AMD also :-D

zu Komplex die paar Zeilen für dich was ?
Läuft bei Dir

 

[hrafnagaldr]

Zu diskutieren gibt es da nicht viel.
Aber zumindest korrekt der Einwand aus der Sicht, wenn auch unnötig.

Naja, oder AMD hat nach Aufkommen der Problemmeldung schnell erkennt, dass das ein Fehler in der Architektur ist, den sie beseitigen müssen. Lässt sich so auch lesen.

 

[Iscaran]

@Iscaran u. Conceptions: Warum wird die "Anti-AMD"-Vermutung von paunaro eigentlich gleich einer "Pro-Intel"-Vermutung gleich gesetzt?
Die Aussage "AMD hat Scheiße gebaut." ist nicht gleich der Aussage "INTEL hat es besser gemacht." Das wird von euch aber scheinbar so gesehen, sonst würde man nicht mit Negativbeispielen von Intel auf seine Vermutung/Frage antworten.

Naja:
1.) gibt es halt nur noch AMD / Intel im CPU Markt. => es gibt keine anderen "beispiele" außer die von Intel.
2.) War das nicht der Punkt. Deswegen bei mir auch die Frage WAS er mit der Unterstellung "öffentlich" bekannt denn Aussagen möchte

Ja und ? Was willst du damit sagen ?

 

[strex]

Bei Intel waren es ja größere Sachen. AVX Bug und dann die OC Beschränkung. Und jetzt muss man eben zeigen das auch AMD und nicht nur Intel solche Patches braucht.

Definitiv ist das nicht der Fall. Das eine beeinflusst nur die Performance und die Stabilität, dass andere gefährdet massiv die Sicherheit, besonders wenn man AMD auch mal bei Server in Betracht ziehen möchte. Der Durchbruch durch die Hardware-Virtualisierung ist in diesem Bereich ein absoluter Gau.

 

[pipip]

Der Durchbruch durch die Hardware-Virtualisierung ist in diesem Bereich ein absoluter Gau.

http://www.golem.de/news/kritische-...rtuellen-maschinen-ausbrechen-1206-92519.html

http://fds-team.de/cms/articles/2012-06/sicherheitsluecke-bei-64-bit-intel-prozessoren.html

 

[strex]

Lesen der Artikel scheitert bei dir scheinbar. Wohl schnell nur gesucht nach "intel bug hypervisor". Aber ich weiß doch, AMD ist unfehlbar.

http://www.golem.de/news/kritische-...rtuellen-maschinen-ausbrechen-1206-92519.html

Hier wurde die Lücke in Xen ausgenutzt, kein Fehler oder Microcode Update bei Intel. Das liegt an der spezifischen Implementierung der Virtualisierung, die ist zwischen AMD und Intel unterschiedlich und erfordert jeweils eigenen Code. Der natürlich in der jeweiligen Stellen Fehler haben kann, dir nur einen Treffen oder den anderen.

http://fds-team.de/cms/articles/2012-06/sicherheitsluecke-bei-64-bit-intel-prozessoren.html

Intel’s version of SYSRET, however, has a very subtle difference in behavior than AMD’s version. It is this difference that is the source of the problem.

Selbiges hier, selber Fehler. Intel nutzt volle 64 Bit in VAS, AMD nur 48 Bit, das Handling in Software prüft aber nur 48 Bit..

Um genauer zu werden, ist der Fehler in der Hardware-Virtualisierung in diesem Fall in der CPU selbst und die von dir genannten Lücken sind Fehler in der Software-Implementierung bzw. des Interaktionenshandling mit den CPU-Befehlen. Wären das Fehler in der Hardware, würde der Fehler wie bei AMD per Microcode gefixt und nicht im Hypervisor. Das sind zwei paar Schuhe, beides aber schlimm nur dass das eine alle Virtualisierungen betrifft und das andere abhängig vom Hypervisor ist. VMware hatte das Problem nicht.

Das war ein Eigentor.

--

Apropo, scheinbar benutzt keiner Opterons der anfälligen CPUs, sonst wären schon viele Reboots der Webhoster angekündigt.

 

[malajo]

Jeder Chip mit Millionen, ja sogar Milliarden an Transistoren können entsprechende Fehler enthalten, sei es von Intel, AMD, nvidia. Das sollte eigentlich jedem klar sein.

Jeder Chip in diesen feinen Strukturen hat Hardwarefehler, welche durch vorgesehene Renundanzen gefixt werden.
So richtig war das bei der ersten AMD APU Llano in die Hose gegangen, weil dort einfach zuwenig Renundanzen im Design waren (zuwenig Via`s zwischen den Layern z.B.) Neuartiges Produkt mit einem neuen Prozess und das Design auf Kante genäht.....rumgehackt wurde dann auf dem Fertiger.

 

[pipip]

strex

Wenn ich möchte, könnte ich noch mehr google befragen, was so in der Vergangenheit war. Es ist völlig egal, es sind "komplexe Systeme" und da sind Lücken und Fehler sind hier immer vorhanden. Egal ob Hardware, Software oder was auch immer.
Aber ich habe gewusst, dass irgendwas komplett negatives von dir kommen wird. Das ist wie das Amen in der Kirche.

Aber vllt sollte AMD sich jetzt GAU nennen. Passt wohl besser zu deiner Sprache.

 

[LoRDxRaVeN]

Naja:
1.) gibt es halt nur noch AMD / Intel im CPU Markt.

Klar, IBM, ARM bzw. zahlreiche Lizenznehmer und wahrscheinlich noch einige(/viele?) mehr...

 

[strex]

Wenn ich möchte, könnte ich noch mehr google befragen, was so in der Vergangenheit war.

Das kannst du gerne machen. Ein Exploit in der Hardware-Virtualisierung in den Ring 0 gab es bei Intel noch nicht. Den hättest du aber schon genüsslich gepostet würde es den geben.

Es ist völlig egal, es sind "komplexe Systeme" und da sind Lücken und Fehler sind hier immer vorhanden. Egal ob Hardware, Software oder was auch immer.

Das hat aber auch keiner behauptet.

Aber ich habe gewusst, dass irgendwas komplett negatives von dir kommen wird. Das ist wie das Amen in der Kirche.

Klar, wer damit jeden Tag zu tun hat kann das sicherlich beurteilen. Ein Durchbruch durch die Virtualisierung ist heute eines der größten Probleme überhaupt. Denn damit lassen sich einfach und schnell zig Maschinen infizieren und auslesen. Für Cloud Hoster kann das lebensgefährlich sein, nicht umsonst werden die Großen meist vorher und heimlich informiert damit sie vorher bereits Maintenance Windows durchführen können.

Aber vllt sollte AMD sich jetzt GAU nennen. Passt wohl besser zu deiner Sprache.

Das ist deine Aussage, meine war es nur das ein Durchbruch des Hypervisors heute als Gau bezeichnen kann. Da würden mir andere Hypervisor-Gurus sicher zustimmen. Das Wort meltdown in diesem Zusammenhang ist nicht so selten: http://www.theregister.co.uk/2015/02/28/new_xen_vuln_causes_cloud_reboot/

Klar, IBM, ARM bzw. zahlreiche Lizenznehmer und wahrscheinlich noch einige(/viele?) mehr...

Sparc gehört da noch in die Liste, sind sie doch im Mission Critical Computing noch oft zu finden.

 

[hrafnagaldr]

Das ist deine Aussage, meine war es nur das ein Durchbruch des Hypervisors heute als Gau bezeichnen kann. Da würden mir andere Hypervisor-Gurus sicher zustimmen.

Ein Gau ist aber der größte annehmbare zu beherrschende Unfall. Meinst also wohl eher Super-Gau?
Wäre es "nur" ein Gau, hätte das System Maßnahmen zur Gegensteuerung.
Klugscheißen kann ich auch.

 

[strex]

@hrafnagaldr

Nö, ein Super-Gau wäre es wenn eine Lücke in der Hardware-Virtualisierung nicht durch einen Microcode schließen liese. Das ist nicht ausgeschlossen, dann müsste man alle CPUs tauschen..Hier lässt sich die Lücke noch schließen, somit kein Super-Gau lediglich ein Gau den es bei Xen in letzter Zeit auch öfters gab. Nicht umsonst musste Amazon, Rackspace und co. einige Reboots durchführen.

Glücklich hier ist immer nur, dass diese Lücke meist verheimlicht werden, bis die meisten Großen alle aktualisiert haben. Denn Amazon kann nicht so einfach mal alle Instanzen vom Netz nehmen, nur weil es eine Lücke gibt, die wären aber eines der ersten Ziele für eine Attacke.

 

[Conceptions]

Da würden mir andere Hypervisor-Gurus sicher zustimmen.

Willst du uns mit diesem Satz mitteilen das du ein (Hypervisor-)Guru bist?

 

[strex]

@Conceptions

Könnte man schon meinen.

 

[Iscaran]

Zitat von LoRDxRaVeN:
Klar, IBM, ARM bzw. zahlreiche Lizenznehmer und wahrscheinlich noch einige(/viele?) mehr...

Zitat von strex:
Sparc gehört da noch in die Liste, sind sie doch im Mission Critical Computing noch oft zu finden.

ARM ist überhaupt erst SEIT Q4/2015 im "Serverbereich" tätig.

http://www.reuters.com/article/arm-servers-share-idUSL3N0WL27S20150319

Und ich hab noch keinen Smartphone Prozessor gesehen den man im Serverbereich einsetzt.

IBM und SPARC findet man eigentlich nur bei Supercomputer wo es auf Maximale Rechenleistung und riesige Grids aus parallele computinng units geht.

Aber gut wenn man diese "sonderformen" von CPUs mitnimmt gibt es in der Tat mehr als AMD/intel.

 

[hrafnagaldr]

Nö, ein Super-Gau wäre es wenn eine Lücke in der Hardware-Virtualisierung nicht durch einen Microcode schließen liese. Das ist nicht ausgeschlossen, dann müsste man alle CPUs tauschen..Hier lässt sich die Lücke noch schließen, somit kein Super-Gau lediglich ein Gau den es bei Xen in letzter Zeit auch öfters gab.

Na also, dann ist ja nix Schlimmes passiert. Man kann ja offensichtlich gegensteuern und solche Vorfälle sind auch in gewisser Weise planbar. Wozu dann die ganze Dramatik?

In dem Fall ist ein Fehler in Xen natürlich auch wesentlich drastischer als bei AMD in Hardware. Wo sind wohl mehr Systeme betroffen? Da schreibst das eher beiläufig, wohingegen dass bei AMD gleich ein absoluter Gau sein soll? Wie lange braucht Citrix für die Fixes so im Schnitt?

 

[strex]

IBM und SPARC findet man eigentlich nur bei Supercomputer wo es auf Maximale Rechenleistung und riesige Grids aus parallele computinng units geht.

Das ist nicht so ganz richtig. Sparc findet man oft im Enterprise-Umfeld im besonderen mit Oracle Software und das ist weit weg von Grid oder Supercomputing. Bewirbt das Oracle selbst sogar für das Umfeld:

Whether you’re running your enterprise applications on a traditional IT infrastructure or implementing cloud services, Oracle’s SPARC Servers can transform your business with advanced security, breakthrough integration, and extreme performance. Engineered to meet cyber threats head on, SPARC systems offer end-to-end data protection when you need it most. From scale-out to scale-up systems, SPARC Servers are the best for Oracle Database and Java applications and provide the greatest value for enterprise computing.

https://www.oracle.com/servers/sparc/index.html

Na also, dann ist ja nix Schlimmes passiert. Man kann ja offensichtlich gegensteuern und solche Vorfälle sind auch in gewisser Weise planbar. Wozu dann die ganze Dramatik?

Das muss nur zeitlich schief laufen. Würde jetzt ein Exploit veröffentlicht werden oder bereits existieren wäre es schon ein großes Problem. Bis die Microcodes veröffentlich getestet und eingespielt wurden vergehen gut mal ein paar Tage. Bis dahin wäre aber zum Beispiel Amazon massiv in Gefahr. Es heißt das Update wird heute an die Partner ausgeliefert, wann bekommt das ein Mittelstandshoster in die Hand. Wahrscheinlich im laufe der Woche, bis dahin kann er eigentlich nur den Betrieb einstellen, wenn er seine Kunden nicht gefährden würde.

Das nenne ich nicht "nichts schlimmes passiert".

Dann doch lieber Microcode verbreiten und sagen, soll eingespielt werden und erst später mitteilen warum siehe Citrix. Ich kann mir schon den einen oder anderen Kollegen hier vorstellen, die jetzt gerade beschäftigt entsprechend Exploits zu schreiben. Den muss nur einer veröffentlichen.

In dem Fall ist ein Fehler in Xen natürlich auch wesentlich drastischer als bei AMD in Hardware. Wo sind wohl mehr Systeme betroffen? Da schreibst das eher beiläufig, wohingegen dass bei AMD gleich ein absoluter Gau sein soll? Wie lange braucht Citrix für die Fixes so im Schnitt?

Bei AMD betrifft es alle Hypervisor, bei Xen nur Xen. Xen hat jetzt keine allzu große Verbreitung mehr. Man musste nur wissen wieviel Opterons davon im Umlauf sind, um das zuverlässig sagen zu können.

Da schreibst das eher beiläufig, wohingegen dass bei AMD gleich ein absoluter Gau sein soll? Wie lange braucht Citrix für die Fixes so im Schnitt?

Der Glibc Bug war auch ein Super-Gau. Remote Code Execution über DNS..Bei Xen betrifft das aber nur Xen, nicht KVM, VMware, Hyper-V..bei Harware aber alle. Eine solche Lücke wäre auch bei Intel ein Gau, sogar ein größerer da viel mehr Systeme betroffen sind.

Bei Citrix ist abhängig in welcher Liste du steckst. Amazon und co. bekommen vorab Informationen über kritische Bugs, die werden auch zügig behoben und an andere in dieser Liste geliefert. Der Fehler wird dann angekündigt und erst wenn der Patch im Umlauf ist, wird mitgeteilt was es überhaupt war.

 

[TrueAzrael]

Ernst gemeinte Frage: Gibt es irgend einen Grund warum in letzter Zeit die Microcode-Patches auf Newsseiten wie CB "breit getreten" werden?
Hätte das bis vor kurzem, zumindest in dem Umfang, nicht mitbekommen.
Neue Quelle? Neue Ausrichtung von CB? Oder kommen in letzter Zeit doch vermehrt Patches die kritisch genug sind um darüber zu schreiben?

Bei Intel waren es ja größere Sachen. AVX Bug und dann die OC Beschränkung. Und jetzt muss man eben zeigen das auch AMD und nicht nur Intel solche Patches braucht.

Definitiv ist das nicht der Fall. Das eine beeinflusst nur die Performance und die Stabilität, dass andere gefährdet massiv die Sicherheit, besonders wenn man AMD auch mal bei Server in Betracht ziehen möchte. Der Durchbruch durch die Hardware-Virtualisierung ist in diesem Bereich ein absoluter Gau.

http://www.golem.de/news/kritische-...rtuellen-maschinen-ausbrechen-1206-92519.html

http://fds-team.de/cms/articles/2012-06/sicherheitsluecke-bei-64-bit-intel-prozessoren.html

Zur Sicherheit noch mal den ganzen Verlauf der Geschichte.
Was hat das Posten von neuen Problemen mit Intel-CPUs damit zu tun, dass Knuddelbärlis Einschätzung das die in den Medien breit getretenen Intel-Bugs (namentlich AVX Bug und OC Beschränkung) laut strex' Einschätzung falsch ist.
Die Nennung neuer Fehler macht die Aussage über die zuvor genannten Fehler nicht richtig oder falsch.

Im übrigen würde ich da mit strex überein gehen, ein Sicherheitsleck ist sicher "größer"/schwerer zu werten, als ein Freeze oder gar die damit verglichen beinahe schon lächerliche Beschränkung des OC.

Das gesagt, heißt das ja nicht, dass Intel nicht schon ähnliche/schlimmere Bugs gehabt hätte.