News AMD stellt klar: MS-Patch nur gegen Spectre auf AMD-Hardware

Onkel_Dithmeyer

Redaktion
☆☆☆☆☆☆
Mitglied seit
22.04.2008
Beiträge
12.949
Renomée
4.047
Standort
Zlavti
  • BOINC Pentathlon 2011
  • BOINC Pentathlon 2012
  • BOINC Pentathlon 2013
  • BOINC Pentathlon 2014
  • BOINC Pentathlon 2015
  • BOINC Pentathlon 2016
  • BOINC Pentathlon 2017
  • BOINC Pentathlon 2018
  • BOINC Pentathlon 2019
  • SETI@Home Intel-Race II
  • BOINC Pentathlon 2020
  • THOR Challenge 2020
  • BOINC Pentathlon 2021
  • BOINC Pentathlon 2022
  • BOINC Pentathlon 2023
  • BOINC Pentathlon 2024
Gestern berichteten wir über eine Reihe Patches, die die sogenannte Meltdown-Lücke auf AMD-Systemen schließen sollte. Diese führte auf manchen älteren AMD-Computern aus der Athlon-64-Ära zu Bluescreens beim Start. Den Fehler führte Microsoft auf fehlerhaft dokumentierte AMD-Chipsätze zurück. Dies sorgte natürlich für Verwirrung, hatte AMD kurz zuvor bekannt gegeben, nicht von Meltdown betroffen zu sein.
(…)

» Artikel lesen
 
Zuletzt bearbeitet:
Ich wuerde mal spekulieren wollen, dass AMD bei Variante 2 ein Stueck weit durch seinen geringeren Marktanteil geschuetzt wird. Fuer Variante 2 benoetigt es einiges an Wissen ueber die Funktionsweise der Sprungvorhersage und deren timing wenn ich das ganze richtig verstanden habe. Da ist bei Intel ueber die letzten 20 Jahre relativ viel bekannt geworden und auch reverse engineered waehrend man zu AMDs Branch Predictor garnichts findet. Das schuetzt AMD und es wird wohl auch niemand mit normaler krimineller Energie sich daran setzen die BP von AMD soweit zu analysieren als das s das Tool angepasst werden kann. Außer einem Geheimdienst kann sowas ja keiner leisten.

Trotzdem hat AMD offensichtlich das 110% Security Patch als microcode update rausgegeben.

This new firmware disables branch prediction on AMD family 17h processor. to address CVE-2017-5715

https://www.suse.com/de-de/support/update/announcement/2018/suse-su-20180009-1/

Ein Abschalten der Sprungvorhersage schuetzt natuerlich absolut, kann aber eigentlich keine praktikable Loesung sein. Wieviel % Performance haengen da drann? 30%?
 
Zuletzt bearbeitet:
Trotzdem hat AMD offensichtlich das 110% Security Patch als microcode update rausgegeben.

This new firmware disables branch prediction on AMD family 17h processor. to address CVE-2017-5715

https://www.suse.com/de-de/support/update/announcement/2018/suse-su-20180009-1/

Ein Abschalten der Sprungvorhersage schuetzt natuerlich absolut, kann aber eigentlich keine praktikable Loesung sein. Wieviel % Performance haengen da drann? 30%?

AMD schaltet die Sprungvorhersage nicht mit diesem Microcode ab. Da gab es Verständigungsschwierigkeiten.
 
Zuletzt bearbeitet:
AMD schaltet die Sprungvorhersage nicht mit diesem Microcode ab. Da gab es Verständigungsschwierigkeiten.

Weist du mehr? Was macht dieses µCode update? AMD kommuniziert doch quasi das CVE-2017-5715 auf AMD Systemen nicht gepatcht werden muss? Nun also doch?
 
Zuletzt bearbeitet:
Guck mal ob du hieraus schlau wirst, ich nur ein bisschen;D
Sieht für mich so aus als ob AMD mit dem Update diese "SPEC_CTRL" und/oder "IBPB_SUPPORT" MSR freischaltet, damit retpoline(?) etwas bringen kann.

When IBRS is set to 2, both userland and kernel runs with indirect branch restricted speculation. This protects userspace from hyperthreading/simultaneous multi-threading attacks as well, and is also the default on AMD processors (family 10h, 12h and 16h). This feature addresses CVE-2017-5715, variant #2.

AMD Defaults:
Due to the differences in underlying hardware implementation, AMD X86 systems are not vulnerable to variant #3. The correct default values will be set on AMD hardware based on dynamic checks during the boot sequence.

pti 0 ibrs 0 ibpb 2 -> fix variant #1 #2 if the microcode update is applied
pti 0 ibrs 2 ibpb 1 -> fix variant #1 #2 on older processors that can disable indirect branch prediction without microcode updates

Kann es sein, dass AMD früher standardmäßig ibrs 2 im Prozessor aktiviert hatte (ohne das nach außen änderbar zu machen) und mit dem µc-Update + Patch dann darauf verzichten kann und nur noch ibpb 2 benötigt?

Ist ein "Flush" beim context switch "besser" als "indirect branch restricted speculation"?

Vielleicht kommen die auch alle gerade selber nicht mehr klar;D
 
Zuletzt bearbeitet:
Ich kann mir vorstellen das man auf die Patches von MS und Linux mit einem Micocode Update reagieren oder anpassen muss.

Das ganze artet von bald in eine Hexenjagd aus. Wenn man nur erwähnt das man mit einem AMD Sys so gut wie gar keine Probleme hat wird man schon fast gelüncht.:]
 
AMD Processors: Google Project Zero, Spectre and Meltdown (Update) (AMD)

An Update on AMD Processor Security

1/11/2018

The public disclosure on January 3rd that multiple research teams had discovered security issues related to how modern microprocessors handle speculative execution has brought to the forefront the constant vigilance needed to protect and secure data. These threats seek to circumvent the microprocessor architecture controls that preserve secure data.

At AMD, security is our top priority and we are continually working to ensure the safety of our users as new risks arise. As a part of that vigilance, I wanted to update the community on our actions to address the situation.

Google Project Zero (GPZ) Variant 1 (Bounds Check Bypass or Spectre) is applicable to AMD processors.
We believe this threat can be contained with an operating system (OS) patch and we have been working with OS providers to address this issue.
Microsoft is distributing patches for the majority of AMD systems now. We are working closely with them to correct an issue that paused the distribution of patches for some older AMD processors (AMD Opteron, Athlon and AMD Turion X2 Ultra families) earlier this week. We expect this issue to be corrected shortly and Microsoft should resume updates for these older processors by next week. For the latest details, please see Microsoft’s website.
Linux vendors are also rolling out patches across AMD products now.

GPZ Variant 2 (Branch Target Injection or Spectre) is applicable to AMD processors.
While we believe that AMD’s processor architectures make it difficult to exploit Variant 2, we continue to work closely with the industry on this threat. We have defined additional steps through a combination of processor microcode updates and OS patches that we will make available to AMD customers and partners to further mitigate the threat.
AMD will make optional microcode updates available to our customers and partners for Ryzen and EPYC processors starting this week. We expect to make updates available for our previous generation products over the coming weeks. These software updates will be provided by system providers and OS vendors; please check with your supplier for the latest information on the available option for your configuration and requirements.
Linux vendors have begun to roll out OS patches for AMD systems, and we are working closely with Microsoft on the timing for distributing their patches. We are also engaging closely with the Linux community on development of “return trampoline” (Retpoline) software mitigations.

GPZ Variant 3 (Rogue Data Cache Load or Meltdown) is not applicable to AMD processors.
We believe AMD processors are not susceptible due to our use of privilege level protections within paging architecture and no mitigation is required.

There have also been questions about GPU architectures. AMD Radeon GPU architectures do not use speculative execution and thus are not susceptible to these threats.

We will provide further updates as appropriate on this site as AMD and the industry continue our collaborative work to develop mitigation solutions to protect users from these latest security threats.

Mark Papermaster,
Senior Vice President and Chief Technology Officer
 
Zuletzt bearbeitet:
Das passt ja dann auch zu dem redhat Artikel.
AMD scheint auf Nummer sicher zu gehen?
Schade, dass es noch keine Benchmarks gibt zwischen Intel (pti 1 ibrs 1 ibpb 1) und AMD (pti 0 ibrs 0 ibpb 2)
 
AMD scheint auf Nummer sicher zu gehen?
Schade, dass es noch keine Benchmarks gibt zwischen Intel (pti 1 ibrs 1 ibpb 1) und AMD (pti 0 ibrs 0 ibpb 2)

Das sehe ich genauso. Die Aussage steht ja nach wie vor, dass AMD es für sehr unwahrscheinlich und schwierig hält, Spectre auf der eigenen Hardware auszunutzen. Im Vergleich zu meltdown gilt das übrigens auch für Intel-Hardware.
Ich hatte mich schon gewundert, dass AMD nicht ohnehin präventiv ein optionales Microcode-Update zur Verfügung stellt, alleine aus dem Grund, um irgendeine Reaktion zu zeigen, unabhängig davon, wie wirklich sinnvoll sie ist.

Mich hat ohnehin gewundert: Im Juni 2017, also vor 6 Monaten, wurde das Problem von verschiedenen Sicherheitsgruppen an die HW-Hersteller gemeldet, man arbeitet gemeinsam geheim an einer Lösung und einigt sich auf ein gemeinsames Veröffentlichungsdatum KW 2 2018, und in KW 1 2018, als erst tropfenweise, dann ganz schnell Details an die Öffentlichkeit geraten, hat kein Hersteller auf Knopfdruck ein Firmware-Update noch ein umfassendes Presse-Statement bereit. Intel beschwichtigt in seinem Statement und sagt ganz frech, die CPUs funktionieren doch wie gewünscht (Will sich da jemand um Entschädigung drücken??), AMD bringt nur ein sehr knappes Statement, einzig ARM listet vorbildlich auf, welche seiner CPUs wovon betroffen sind. Da hätte ich binnen 6 Monaten doch eine bereit stehende Lösung erwartet.

Schade finde ich, dass in vielen Presseartikeln Meltdown und Spectre - zwei von der Tragweite völlig verschiedene Probleme - in einen Topf geworfen werden, und damit alle großen CPU-Hersteller gleichermaßen gebrandmarkt werden, obwohl Meltdown nur Intel betrifft.


Ich habe den Eindruck der Presse fehlt das Bewusstsein, dass Meltdown wesentlich einfacher auszunutzen ist als Spectre, und wesentlich gefährlicher ist, weil Zugriff auf den gesamten Arbeitsspeicher möglich ist, nicht bloß auf den eigenen Prozess oder andere Prozesse des gleichen Benutzers.
 
Mich hat ohnehin gewundert: Im Juni 2017, also vor 6 Monaten, wurde das Problem von verschiedenen Sicherheitsgruppen an die HW-Hersteller gemeldet, man arbeitet gemeinsam geheim an einer Lösung und einigt sich auf ein gemeinsames Veröffentlichungsdatum KW 2 2018, und in KW 1 2018, als erst tropfenweise, dann ganz schnell Details an die Öffentlichkeit geraten, hat kein Hersteller auf Knopfdruck ein Firmware-Update noch ein umfassendes Presse-Statement bereit. Intel beschwichtigt in seinem Statement und sagt ganz frech, die CPUs funktionieren doch wie gewünscht (Will sich da jemand um Entschädigung drücken??), AMD bringt nur ein sehr knappes Statement, einzig ARM listet vorbildlich auf, welche seiner CPUs wovon betroffen sind. Da hätte ich binnen 6 Monaten doch eine bereit stehende Lösung erwartet.
Womöglich war die Lücke nur einer von vielen Fehlern, die man zu bereinigen hatte und außer den Ingenieuren wusste es keiner. Noch dazu wurde es kurz vorm Wochenende bekannt, ergo war der Informationsfluss in den Firmen bis Montag sicherlich auch nicht überall gegeben oder erinnert an Stille Post.
Unsere Rechts- und Marketingabteilung wird auch nicht über technische Details informiert, an denen wir gerade knobeln. Und trotz jahrelanger Entwicklungszeit hat man immer den Eindruck, dass 50% der Arbeit in der letzten Woche vor dem Endtermin erledigt wird.
 
@Nero24, wie sieht es mit dem "Boot" aus, es werden unter Garantie ja auch ALLE Server-CPUs betroffen sein ob Intel oder AMD. Auch diese Systeme müssen ja gepatcht werden, unabhängig des Unterbaus ob Windows, Linux, etc.
 
naja, mit einem AMD-System braucht man den Patch ja nicht in aller Eile einzuspielen, man kann sich das in aller Ruhe anschauen, als Intel-Admin wäre man hingegen arg in der Bedrouille. Offensichtlich ist der Fix ja mit der heißen Nadel gestrickt und nicht ausreichend getestet für alle Systeme, deswegen ist das Problem ja, daß der Patch mehr kaputt macht als er fixt, jedenfalls auf den im Artikel genannten Systemen mit älteren AMD-Chipsätzen. "War nicht richtig dokumentiert" kann sein, kann auch eine Schutzbehauptung sein, jedenfalls sieht man, daß der Patch nicht getestet wurde vor der Auslieferung.

Langfristig muß der Patch natürlich überall funktionieren. Viele Leute updaten einfach alles, was an Updates angeboten wird, egal ob sie es wirklich brauchen, und dann soll ja nicht was kaputtgehen, was bisher lief.
 
Viele Leute updaten einfach alles, was an Updates angeboten wird, egal ob sie es wirklich brauchen, und dann soll ja nicht was kaputtgehen, was bisher lief.
Meist wissen sie es ja nicht mal, weil es standardmäßig in Windows so eingestellt ist und völlig im Hintergrund passiert.
 
Zurück
Oben Unten