Diskussion zu: Wie geht es weiter im CPU-Geschäft nach Meltdown & Spectre?

[Leonidas]

Link zum Artikel:
https://www.3dcenter.org/artikel/wie-geht-es-weiter-im-cpu-geschaeft-nach-meltdown-spectre


Male ich zu schwarz? Ich dachte einfach, es wäre Zeit für eine klare Ansage - vor allem, wo das Hersteller-Marketing schon wieder überhand nimmt.

[Lowkey]

Intel:

+ Monopol
+ Stellungnahme samt Plan gleicht Geständnis
+ Aktuelle Klagen in den USA laufen bereits
+ Volle Lager
+ Kompletter Austausch der defekten CPUs kostet Geld
+ Intel beschäftigt mehr Juristen als Ingenieure.
+ Die Marketingabteilung kann in 2 1/2 Jahren die neuen CPUs mit "fehlerfrei" bewerben

[nikk]

Vielleicht gibt es auch überhaupt keinen "Hardware-Fix" und Intel setzt lieber auf kostenschonende PR-Maßnahmen:
Hier gibt es nichts zu sehen Leute! (https://www.youtube.com/watch?v=nj_DnV0Q7P0)

"This is not a bug or a flaw in Intel products." (https://www.intel.com/content/www/us/en/architecture-and-technology/facts-about-side-channel-analysis-and-intel-products.html)

[Freestaler]

Ich denke, du malst nicht zu schwarz. Im moment erwarte ich von der Industrie einfach mehr. Nicht nur HW Hersteller. Auch Richtung Security & OS Branche ist vieles einfach unklar. Man hat den Eindruck, das eigentlich keiner wirklich weiss was Sache ist. Sie wollen sich nicht mal positionieren. (Ausser Linus, wobei er auch einfach mehr über Intel abgeht, als mM. langfristige Lösung zeigt ;-) )

[Gast]

Male ich zu schwarz?

Nicht wirklich, zumindest nicht was die Entwicklungszeiten neuer Hardware betrifft.

Da Intel ja seit mitte letzten Jahres von den Problemen wusste besteht vielleicht eine sehr kleine Chance heuer tatsächlich noch Prozessoren mit einem echten Hardwarefix zu veröffentlichen, wobei das veröffentlichen maximal so viel sein kann, wie Vega der ja offiziell noch im ersten Halbjahr 2017 veröffentlicht wurde.

Knapp eineinhalb Vorlaufzeit wären mit Intels Ressourcen ein Redesign zumindest ermöglichen.

Was allerdings dagegen spricht, dass zumindest offiziell niemand in der Industrie schon wirklich eine Idee hat um Spectre wirklich 100% zu verhindern, aber zumindest ein Hardwarefix gegen Meltdown wäre für Icelake denkbar.

Was mir in dem Artikel allerdings fehlt sind die Implikationen auf die Systemsicherheit, dass leider nicht nur in diesem Artikel sondern in pratisch jedem der über die Verwundbarkeit durch diese Attacken berichtet.

Es schreiben zwar alle wie schlimm das Ganze ist, weil ja praktisch jede im Einsatz befindliche CPU davon betroffen ist, was natürlich stimmt, aber niemand schreibt darüber wie wahrscheinlich ein Angriff über diese Lücken überhaupt ist.

Diese ist nämlich für Desktop-User verschwindent gering. Keine dieser Lücken ermöglicht nämlich Remote-Code-Execution, weshalb sie auch wesentlich weniger schlimm als viele andere Lücken die regelmäßig entdeckt werden macht.
Der Angreifer muss daher erstmal das Opfer dazu bringen, dass sein Code ausgeführt wird. Und wenn man das schafft, hat man in der Regel wesentlich einfachere Methoden das System des Opfers anzugreifen. Insbesondere wenn das Opfer unter Windows mit Administratoraccount unterwegs ist und UAC deaktiviert hat oder generell einfach alle UAC-Messageboxen bestätigt ist man nicht wirklich angreifbarer als vor der Entdeckung dieser Lücken.

Ein Einfallstor für die Ausführung von Untrusted-Code ist natürlich immer der Webbrowser. Da über diesen allerdings kein direkter Maschinencode ausgeführt werden kann, ist hier eine Absicherung allerdings auch nicht so schwierig.

Als Desktop-User ist man also, sofern man einen aktuellen Browser mit den letzten Updates schon ziemlich sicher, unabhängig von den OS oder Microcode-Updates.

Für Cloud-Anbieter sieht es natürlich anders aus, insbesondere wenn keine echte Virtualisierung verwendet besteht natürlich die Gefahr, dass Daten zwischen verschiedenen Kunden geleakt werden und der Anbieter hat in der Regel keine Kontrolle darüber welchen Code der Kunde ausführt.

Und man sollte an dieser Stelle einrechnen, das hierbei mit der Sprungvorhersage an einem der heikelsten Teile der gesamten CPU-Architektur herumgebastelt wird.

Um Spectre zu verhindern sind KEINE Änderungen an der Sprungvorhersage notwendig.
Der Seitenkanal ist der Cache, also sind Änderungen am Cachesystem notwendig.
Das Problem mit der Sprungvorhersage zu bekämpfen würde nur funktionieren, wenn man entweder gar keine verwendet, was aus Performancegründen nicht möglich ist, oder eine Sprungvorhersage zu designen mit 100%iger Trefferquote, was prinzipiell unmöglich ist.

Denkbar wäre beispielsweise eine Art Shadow-Cache einzuführen, wie es ja bei den Registern schon gibt, und alle Loads wandern erstmal in diesen Shadow-Cache und werden erst in der Retirement-Stage in den echten Cache übergeführt. Das kostet aber sicher einiges an Fläche und die Adressierung ist alles andere als Trivial.

Selbst dabei könnten aber evtl. kluge Köpfe auf Ideen kommen auch über diesen Shadow-Cache an irgendwelche Informationen zu kommen, aber man würde das Zeitfenster in welchem man Informationen über den Seitenkanal holen könnte erheblich einschränken, da nur Befehle (die dann auch korrekt durchgeführt werden müssen) die gleichzeitig out of order ausgeführt werden und damit den selben "Shadow-Cache" benutzen an Informationen kommen können.

[Gast]

"This is not a bug or a flaw in Intel products." (https://www.intel.com/content/www/us/en/architecture-and-technology/facts-about-side-channel-analysis-and-intel-products.html)

Warum kapieren die Leute einfach nicht, dass das stimmt und es kein Fehler ist?

Seitenkanalattacken hat es immer gegeben und wird es auch immer geben.
Sei es über elektromagnetische Strahlung, den Stromverbrauch oder sogar über Audio.
Ein CRT-Monitor arbeitet auch nicht fehlerhaft, weil man im Nebenraum aufgrund der elektromagnetischen Strahlung teile dies Bildes wiederherstellen kann und damit potentiell an Geheimnisse kommt.

Relativ neu an Spectre ist, dass Software die auf der selben Maschine laufen kann um an Informationen zu kommen und keine physische Nähe zum angegriffenen Rechner erforderlich ist.

Es hat auch schon Angriffe über die Messung des Stromverbrauchs gegeben, was bisher allerdings physischen Zugang zum Rechner benötigte um diesen auch messen zu können.
Heutige CPUs können aber auch über Software jederzeit Auskunft über den Verbrauch geben. Wird eine CPU deshalb fehlerhaft, falls jemand eine Möglichkeit entdeckt damit an irgendwelche Daten zu kommen?

Genauso wäre es beispielsweise denkbar über das Mikrofon der Soundkarte das Hintergrundrauschen aufzuzeichnen welches vielleicht gar nicht so zufällig ist und Informationen über gerade ausgeführte Befehle auf der CPU preisgibt. Deshalb ist aber weder die Soundkarte noch die CPU defekt.


Bei den Meltdown/Spectre-Attacken ist zu keinem Zeitpunkt in irgendeinem in irgendeinem zugänglichen Register Daten drinnen die dort nicht hingehören.

Der Angreifer lässt hier einfach nur Code ausführen, der auch korrekt ausgeführt wird und kann aus dem Verhalten wie dieser Code ausgeführt wird (genauer gesagt aufgrund der Dauer) durch Beobachtung auf Daten schließen auf die er eigentlich keinen Zugriff hat. Diese sind allerdings zu keinem Zeitpunkt direkt verfügbar.


Nur durch die Einführung von ABS werden beispielsweise auch nicht Autos ohne ABS auf einmal "fehlerhaft".

[hmmm]

Bei Spectre 2 AMD und Intel undifferenziert als "betroffen" zu bezeichnen ist einfach nur lächerlich. AMD ist ohne Patch mindestens so sicher wie Intel mit Patch.

[Denniss]

Bei Spectre 2 AMD und Intel undifferenziert als "betroffen" zu bezeichnen ist einfach nur lächerlich. AMD ist ohne Patch mindestens so sicher wie Intel mit Patch.Gerade hier hätte ich erwartet daß eben dies nicht passiert.

[Screemer]

Gerade hier hätte ich erwartet daß eben dies nicht passiert.
da gibts andere tech seiten die schreiben sogar: AMD-CPUs genauso von Sepctre-Sicherheitslücke betroffen wie andere Prozessoren (https://www.tweakpc.de/news/41273/amd-cpus-genauso-von-sepctre-sicherheitsluecke-betroffen-wie-andere-prozessoren/)

[hmmm]

da gibts andere tech seiten die schreiben sogar: AMD-CPUs genauso von Sepctre-Sicherheitslücke betroffen wie andere Prozessoren (https://www.tweakpc.de/news/41273/amd-cpus-genauso-von-sepctre-sicherheitsluecke-betroffen-wie-andere-prozessoren/)

Das macht es doch nicht besser.

[Screemer]

stimmt auch wieder.

[Gast]

Bei Spectre 2 AMD und Intel undifferenziert als "betroffen" zu bezeichnen ist einfach nur lächerlich. AMD ist ohne Patch mindestens so sicher wie Intel mit Patch.

Das macht mittlerweile auch AMD selbst:

https://www.amd.com/en/corporate/speculative-execution

Bitte das Whitepaper vom 24.01.2018 ansehen, nicht die wischiwaschi-erklärung vom 3.1. in welcher noch steht dass sie eigentlich nicht betroffen sind, also nur ein bisschen.

Im Whitepaper gibt AMD endlich auch klar zu, dass sie von beiden Spectre-Varianten betroffen sind.

[Birdman]

Gibt es eigentlich Infos wie es um AMD CPU's pre Ryzen aussieht?
Irgendwie liest man verdächtig wenig in diese Richtung, auch Leonidas scheint dazu wenig bis nichts gefunden zu haben.
Soweit ich das gesehen habe scheint man da zumindest für beide Spectre Varianten voll verwundbar zu sein, bzgl. Meltdown habe ich aber keinerlei Anhaltspunkte.

[iamthebear]

Also nach meinem derzeitigem Wissensstand gibt es ein paar Fehler im Artikel:

1.) Es sind auch einige ARM CPUs von Meltdown betroffen z.B. Cortex A57

2.) Intel hat auch Updates gegen Spectre 2 für Sandy Bdridge und Ivy Bridge angekündigt

3.) Ich bin mir nicht sicher aber wurden nicht alle Spectre 2 Updates zurückgerufen?

4.) Ich bezweifle einmal sehr stark dass es wirklich jemals komplett Spectre frei CPUs geben wird. Das Problem ist die spekulative Ausführung und diese abzuschalten kostet massiv Leistung. Niemand wird einen Leistungsabfall um den Faktor 2 oder höher in Kauf nehmen. Da wird lieber wie jetzt Symptombekämpfung betrieben. Was ich mir vorstellen kann ist dass die Fixes etwas effizienter gestaltet werden aber am Prinzip selbst wird sich nicbts ändern. Ich denke hier sind eher die Softwareentwickler bzw. Compilerhersteller gefragt die an entsprechend kritischen Stellen Techniken wie Retpoline einsetzen bzw. Skriptsprachen die genauen Timingfunktionen streichen und so den Angreifern den Weg über den Seitenkanal erschweren.

[unl34shed]

Intels Aussage bei den Quartalsyahlen war, dass dieses Jahr Chips kommen, die Änderungen im Silicon haben werden wegen Meltdown/Spectre. Die haben nichts von Fix gesagt, das wurde nur hinein interpretiert.
We're working to incorporate silicon-based changes to future products that will directly address the Spectre and Meltdown threats in hardware. And those products will begin appearing later this year.
Quelle: Intel (INTC) CEO Brian Krzanich on Q4 2017 Results - Earnings Call Transcript | Seeking Alpha (https://seekingalpha.com/article/4140338-intel-intc-ceo-brian-krzanich-q4-2017-results-earnings-call-transcript)

Deckt sich auch mit früheren Aussage, wonach man dieses Jahr Chips bringen will, die den Workaround erleichtern.

Ronak and his team are accountable for doing the microarchitecture of our cores and they started making the changes in the products for our future. And you can look at those as, I'll call it refinements, so that the OS and firmware have to do less heavy lifting
Quelle: https://s21.q4cdn.com/600692695/files/doc_downloads/INTC-USQ_Transcript_2018-01-03.pdf

[hmmm]

Das macht mittlerweile auch AMD selbst:

https://www.amd.com/en/corporate/speculative-execution

Bitte das Whitepaper vom 24.01.2018 ansehen, nicht die wischiwaschi-erklärung vom 3.1. in welcher noch steht dass sie eigentlich nicht betroffen sind, also nur ein bisschen.

Im Whitepaper gibt AMD endlich auch klar zu, dass sie von beiden Spectre-Varianten betroffen sind.
Scheinbar liest du nicht das was da steht.

"While we believe that AMD’s processor architectures make it difficult to exploit Variant 2, ..."
"AMD will make optional microcode updates available..."

Frage: Wie sicher ist Intel in bezug auf spectre 2 nach dem Patch?

[Complicated]

Also ich finde das äußerst bedenklich wie die Tabelle zusammengestellt wurde in dem Artikel.
Da wird bei einem hypothetischen "Zen 4" der Eintrag Meltdown-/Spectrefreie Architektur für das Jahr 2020 avisiert, während Intel schon 2019 das selbe angeblich bewerkstelligen würde.

Was mich dabei stört, abgesehen davon dass es eine unseriöse Spekulation ist, ist die Tatsache, dass jede AMD CPU schon Meltdown-frei ist, dies in dieser Tabelle aber keinerlei Erwähnung findet.

Was ebenfalls sehr verfälschend ist, ist die Tatsache, dass AMD CPUs unter Linux überhaupt kein Microcode Update benötigen. Der Artikel stellt in keiner Weise den Umstand heraus, dass diese Updates lediglich unter Windows benötigt werden, wegen der Entscheidung auf Retpoline zu verzichten. Somit ist die komplette Tabelle schlicht falsch. Vor allem die Behautpung Nutzer älterer CPUs würden im Regen stehen gelassen ist einfach nicht nachvollziehbar. Mit einem Wechsel weg von Windows ist jedes AMD System prinzipiell gegen Spectre 2 gesichert. Was Microsoft treibt kann AMD nicht beeinflussen.
http://www.pcgameshardware.de/AMD-Zen-Codename-261795/News/Spectre-AMD-benoetigt-auf-Windows-Microcode-Updates-auf-Linux-nicht-1248821/
Im Gegensatz zu dem von Microsoft gewählten Lösungsansatz V2-4 soll der Leistungsverlust deutlich geringer ausfallen. Microsoft könnte den Spectre-Schutz von Windows theoretisch auch auf Retpotline umstellen, wodurch bei AMD-Prozessoren das nötige Microcode-Update wegfallen würde. Der CPU-Hersteller aus Sunnyvale würde diese Lösung, gegenüber den anderen neun im White Paper genannten Ansätzen, bevorzugen.

Der Artikel ist voller Fehler und fehlender aktueller Informationen, die sich in der Tabelle deutlich wiederfinden. Ein 4 Tage altes AMD Whitepaper findet überhaupt keine Beachtung, was überhaupt nicht zu verstehen ist:
http://developer.amd.com/wordpress/media/2013/12/Managing-Speculation-on-AMD-Processors.pdf

Ich glaube es ist der fehlerhafteste Artikel den ich zu diesem Thema bisher gelesen habe. Das übertrifft sogar die heise-Berichterstattung, was ich überhaupt nicht für möglich gehalten habe.

Spectre 2 AMD & Intel Windows-Patch samt BIOS-Update nach den Patches sehr wesentlich erschwert; ein 100%iger Schutz ist jedoch nur mit (wirklich) neuer Hardware möglichWechsel zu Linux sollte als mögliche Maßnahme erwähnt werden. Vor allem da durch Retpoline der Performance-Verlust deutlich kleiner ausfällt.

Klasse (2) – Ab Werk mittels Microcode-Update gefixte Prozessoren
Hierbei wird wieder ein Microcode-Update angesetzt, welches neue CPU-Befehle mitbringt, die einen weitgehenden Spectre-Schutz bieten (Meltdown wird dabei mittels eines Betriebssystem-Updates unschädlich gemacht). Selbiges kostet etwas an Performance (bei neueren Prozessoren angeblich weniger als bei älteren) und ist vor allem bereits im Auslieferungszustand vorhanden, weswegen die CPU-Herstellern dann von "Meltdown/Spectre-freie Prozessoren" sprechen, obwohl es eigentlich keine Änderungen auf echter Hardware-Ebene gegeben hat. Dafür ist jene Methode bei jeder neu herauskommenden CPU-Generation ansetzbar und wird wohl genauso auch bei allen demnächst antretenden neuen CPUs realisiert werden.Das gilt AUSCHLIESSLICH für Intel CPUs und kostet diese Performance.

[Gast]

Ich will hier ja nicht über Gebühr trollen, aber ich habe noch einen alten Phenom II - 1090 am laufen, der durch die ganze Geschichte gerade eine "relative" Leistungssteigerung in signifikanter Höhe erfährt.

Dankenswerterweise bestärkt mich dass in der Absicht erst nach dem Supportende von Win7 auf eine fehlerfreie CPU umzusteigen ...

Tja so kanns gehen ...

[Birdman]

Das gilt AUSCHLIESSLICH für Intel CPUs und kostet diese Performance.
Nein, wenn IBRS, IBPB und Co auf AMD CPU's genutzt werden, kostet es auch da massig Performance.
Nur ist es halt fraglich, ob das wirklich nötig ist. Anhand der aktuellen Ausgangslage würde zumindest ich persönlich dies auf einem Ryzen nicht nutzen und hätte trotzdem keine schlaflosen Nächte.

[Complicated]

Was mit Meltdown herzlich wenig zu tun hat. AMD benötigt KEINEN Patch für Meltdown. Beachte den Kontext in Fett!
Was hier verwirrend wirkt, ist Leonidas eigene Einteilung für die Tabellen Beschriftung. Es geht nicht um Spectre 2 ;)
"Klasse 2" bezeichnet er diese Maßnahmen und schreibt die zu Unrecht einigen AMD CPUs zu.

[Lehdro]

Bin auch ein wenig enttäuscht von der fehlenden Differenzierung im im Bezug auf Spectre in dem Artikel - wir haben so viel mehr Informationen als das was im Text verarbeitet wurde. Warum wird das alles mit keiner Zeile gewürdigt?

Das betrifft sowohl Intel als auch AMD. Gerade im Bezug Retpoline - ich hatte schonmal eine Zusammenfassung geschrieben:


So wie momentan unter Windows gepatcht wird mit den drei extra Befehlen (IBRS, STIBP, IBPB) passiert folgendes:

+ Patch schon verfügbar
+ funktioniert sofort mit jeder Software
- braucht bei AMD Microcodeupdates
- braucht bei Intel Microcodeupdates
- Leistungseinbußen auf aktuellen CPUs
- größere Leistungseinbußen auf älteren Intel CPUs

Mit Retpoline:

+ AMD braucht keine Microcodeupdates
+ Alles von Intel unterhalb von Broadwell braucht kein Microcodeupdate
+ kleinere Leistungseinbußen im Vergleich bei älteren Intel CPUs
- "größere" Leistungseinbußen bei neueren Intel CPUs
- Intel braucht ab Broadwell wieder Microcodeupdates
- Microsoft müsste alles neu patchen (Riesenaufwand gegenüber der jetzigen Lösung)

[Birdman]

Beachte den Kontext in Fett!
Dann hast Du das komplett falsch gelesen & verstanden.
In dem Abschnitt gehts ausschliesslich im Spectre_v2 - der Punkt mit Meltdown (den du fett markierst hast) steht nur da um nochmals zu verdeutlichen dass für diese Verwundbarkeit keinerlei Microcode Updates notwendig sind, sondern dass dies via OS Updates (KPTI) abgedeckt ist.

[Complicated]

Das sind 3 Klassen die Leonidas selber definiert hat. Und wenn ich ein Zitat Fett markiere in dem Meltdown steht, dann kann es nicht ausschließlich um Spectre 2 gehen. Check das bitte nochmal im Artikel selber nach:


Für denjenigen PC-Nutzer, welche derzeit oder absehbar eine neue CPU kaufen wollen, sind dies zugegeben nur schwache Trostpunkte – relevant ist an dieser Stelle, was die CPU-Entwickler im PC-Bereich demnächst an Fix-Stufen zu bieten haben werden. Gemäß der vorstehenden Ausführungen läßt sich dies in drei Klassen an möglichen Fixes seitens der CPU-Entwickler einteilen. Deren Aufgabe liegt natürlich primär in Maßnahmen gegenüber Spectre, da Meltdown wie bekannt mittels der schnellen Betriebssystem-Updates für Linux und Windows inzwischen eine faktisch erledigte Angelegenheit darstellt:

[maguumo]

Nein, wenn IBRS, IBPB und Co auf AMD CPU's genutzt werden, kostet es auch da massig Performance.
Nur ist es halt fraglich, ob das wirklich nötig ist. Anhand der aktuellen Ausgangslage würde zumindest ich persönlich dies auf einem Ryzen nicht nutzen und hätte trotzdem keine schlaflosen Nächte.
Zumindest IBRS wird auf Zen nicht genutzt.

https://arstechnica.com/gadgets/2018/01/heres-how-and-why-the-spectre-and-meltdown-patches-will-hurt-performance/2/

[Gast]

Scheinbar liest du nicht das was da steht.

Scheinbar liest du nicht was da steht.
Ich habe nicht umsonst darauf hingewiesen, dass Whitepaper zu lesen, in welchem explizit Befehlsfolgen angegeben werden, die auf AMD-Prozessoren potentiell anfällig sind.
Aber wie es scheint geht AMDs Verschleierungstaktik voll auf wenn man sieht wie sich die Medien auf Intel einschießen und nicht mal kritisieren dass AMD bis zum 24.1. braucht um eindeutig zuzugeben dass auch sie betroffen sind.

"While we believe that AMD’s processor architectures make it difficult to exploit Variant 2, ..."
"AMD will make optional microcode updates available..."


1. Glauben heißt nichts Wissen.
2. difficult heißt im Umkehrschluss nicht unmöglich, im Gegensatz zu Meltdown kann man alle Spectre-Angriffe als "difficult" beschreiben.

[unl34shed]

Aber wie es scheint geht AMDs Verschleierungstaktik voll auf wenn man sieht wie sich die Medien auf Intel einschießen und nicht mal kritisieren dass AMD bis zum 24.1. braucht um eindeutig zuzugeben dass auch sie betroffen sind.


AMDs Aussage war doch eigentlich klar. Near-Zero-Risk heißt doch, dass es möglich ist. :confused:

[Gast]

Der Artikel stellt in keiner Weise den Umstand heraus, dass diese Updates lediglich unter Windows benötigt werden, wegen der Entscheidung auf Retpoline zu verzichten.

Retpoline benötigt eine Neukompilierung der Anwendungen, und ist damit unter Windows nicht praktikabel einsetzbar, da Microsoft nicht die Anwendungssoftware von Drittanbietern neu kompilieren kann.

Es ist also weniger die Entscheidung auf Retpoline zu verzichten, MS hat nicht wirklich eine andere Wahl.

[aufkrawall]

Was ebenfalls sehr verfälschend ist, ist die Tatsache, dass AMD CPUs unter Linux überhaupt kein Microcode Update benötigen.
Intels doch auch nicht?

[Screemer]

Intels doch auch nicht?
ich dachte alles ab broadwell schon

[aufkrawall]

Laut spectre-meltdown-checker.sh ist hier ohne Microcode-Update nur Spectre Variant One nicht mitigated, und das wird mit 4.16 passieren.

[BBig]

Laut spectre-meltdown-checker.sh ist hier ohne Microcode-Update nur Spectre Variant One nicht mitigated, und das wird mit 4.16 passieren.

uname -a
Linux knot 4.14.15-1-ARCH #1 SMP PREEMPT Tue Jan 23 21:49:25 UTC 2018 x86_64 GNU/Linux

dmesg | grep microcode
[ 0.000000] microcode: microcode updated early to revision 0x80, date = 2018-01-04
[ 0.376907] microcode: sig=0x906e9, pf=0x2, revision=0x80
[ 0.376983] microcode: Microcode Update Driver: v2.2.
[21889.771840] microcode: sig=0x906e9, pf=0x2, revision=0x70
[21889.772731] microcode: updated to revision 0x80, date = 2018-01-04
[21889.773324] microcode: sig=0x906e9, pf=0x2, revision=0x80


pacman -Qi intel-ucode
Name : intel-ucode
Version : 20180108-1
Beschreibung : Microcode update files for Intel CPUs
Architektur : any
URL : https://downloadcenter.intel.com/SearchResult.aspx?lang=eng&keyword=processor%20microcode%20data%20file
Lizenzen : custom
Gruppen : Nichts
Stellt bereit : Nichts
Hängt ab von : Nichts
Optionale Abhängigkeiten : Nichts
Benötigt von : Nichts
Optional für : Nichts
In Konflikt mit : Nichts
Ersetzt : microcode_ctl
Installationsgröße : 1584,00 KiB
Packer : Christian Hesse <arch@eworm.de>
Erstellt am : Mi 10 Jan 2018 09:53:21 CET
Installiert am : Do 11 Jan 2018 04:19:54 CET
Installationsgrund : Ausdrücklich installiert
Installations-Skript : Ja
Verifiziert durch : Signatur


Vll verstehe ich dich falsch, aber du lädst beim Boot das neue Micocode von Intel.
Schau doch mal in deine /boot/grub/grub.cfg - ich bin fast sicher, dass du auch /boot/intel-ucode.img drin hast.

[Leonidas]

Also ich finde das äußerst bedenklich wie die Tabelle zusammengestellt wurde in dem Artikel.
Da wird bei einem hypothetischen "Zen 4" der Eintrag Meltdown-/Spectrefreie Architektur für das Jahr 2020 avisiert, während Intel schon 2019 das selbe angeblich bewerkstelligen würde.



Ryzen 3 - vermlt Anfang 2019
Ryzen 4 - vermtl Anfang 2020
Tiger Lake - Ende 2019

... Tiger Lake ist vermutlich terminlich näher zu Ryzen 4 als zu Ryzen 3. Hardware-Anpassungen für Ryzen 3 sind zudem unwahrscheinlich, da das Design von Zen 2 schon fertig ist. Deswegen diese Auslegung.





Also nach meinem derzeitigem Wissensstand gibt es ein paar Fehler im Artikel:

1.) Es sind auch einige ARM CPUs von Meltdown betroffen z.B. Cortex A57

2.) Intel hat auch Updates gegen Spectre 2 für Sandy Bdridge und Ivy Bridge angekündigt

3.) Ich bin mir nicht sicher aber wurden nicht alle Spectre 2 Updates zurückgerufen?


1 - der Artikel bezieht sich rein auf AMD und Intel
2 - schade, an mir vorbeigegangen. Wo nachzuschlagen? Würde ich gern fixen.
3 - so weit ich weiss nur bei HSW/BRW

[Ganon]

Vll verstehe ich dich falsch, aber du lädst beim Boot das neue Micocode von Intel.
Schau doch mal in deine /boot/grub/grub.cfg - ich bin fast sicher, dass du auch /boot/intel-ucode.img drin hast.

Wie schon im anderen Thread gesagt: Ein Mainline Linux Kernel hat noch gar nicht die Möglichkeit Intels neue Funktionen aus dem Microcode Update zu benutzen. Es ist noch gar nicht Teil des Kernels. Ob ein Mainline Linux Nutzer den Microcode drauf hat oder nicht ist so ziemlich egal, völlig unabhängig von der CPU.

2 - schade, an mir vorbeigegangen. Wo nachzuschlagen? Würde ich gern fixen.
3 - so weit ich weiss nur bei HSW/BRW

2 - Intel hat bisher gesagt: Fixes für alle CPUs der letzten 5 Jahre bis Ende Januar. Alle anderen: später, Reihenfolge je nach Nachfrage. Mit dem Rückruf der Microcodes hat sich das aber eh wieder geändert mit den zeitlichen Rahmen.

3 - Intel hat alle Microcode Updates zurückgerufen. Das komplette 2018er Microcode Update Paket hat Intel von ihren Download-Seiten entfernt und listet wieder 20171117 als aktuell: https://downloadcenter.intel.com/search?keyword=processor+microcode+data+file, siehe auch: https://www.golem.de/news/ausserordentliches-update-microsoft-deaktiviert-spectre-2-patches-fuer-windows-1801-132431.html und https://www.computerbase.de/2018-01/reboot-problem-windows-update-spectre/

Und allgemein zum Artikel und Retpoline für Skylake, linke ganz unten nicht auf meinen Foren-Beitrag, sondern auf http://lkml.iu.edu/hypermail/linux/kernel/1801.1/05556.html

[Gast]

1.) Es stört mich an dem Artikel, dass die Microcode-Updates immer als "Spectre-Fix" bezeichnet werden. Die Microcode-Updates fixen nämlich gar nichts, sie stellen nur den Unterbau (3 neue Befehle) für einen Fix in Software bereit. Ohne SW-Update bleibt die CPU trotz Microcode-Update anfällig für Spectre.

Und nach derzeitigem Stand braucht man

* Ein Betriebssystem-Update, wenn man Spectre-Angriffe auf das Betriebssystem bzw. über Programmgrenzen hinweg unterbinden will.

* Ein Update von jedem Bit Software (alle .exe und .dll !), wenn man Spectre-Angriffe innerhalb eines Programmes (z.B. durch Plugins, oder Ausbruch aus einer Sandbox, oder bei Interpretern/JIT's) verhindern will.

2.) Der Artikel blendet so wie der Rest der Welt die eigentlich interessante Frage aus: Er schaut nur auf den Spectre-Fix mit neuen Befehlen (für die natürlich auch AMD ein Microcode-Update braucht, wo sollen die Befehle denn sonst herkommen?).

Aber was ist das Problem mit Retpoline auf intel??? Retpoline ist absolut korrekter, legitimer und wohldefinierter Code, der per Definition auf jeder x86-kompatiblen CPU der letzten 25 Jahre problemlos laufen muss. Wenn moderne intel-CPU's dabei extrem langsam sind / abstürzen / trotzdem für Spectre anfällig sind / ein Microcode-Update brauchen, dann liegt hier ein echter Hardware-Bug (nicht x86-konformes Verhalten) vor, zu dem es wohl schnellstmöglich ein klares Statement und einen Fix geben sollte!

[Birdman]

Retpoline benötigt eine Neukompilierung der Anwendungen, und ist damit unter Windows nicht praktikabel einsetzbar, da Microsoft nicht die Anwendungssoftware von Drittanbietern neu kompilieren kann.

Es ist also weniger die Entscheidung auf Retpoline zu verzichten, MS hat nicht wirklich eine andere Wahl.
Das trifft doch auch auf die aktuelle Methode mit IBRS, STIBP und IBPB zu?
Nur weil der Windows Kernel diese Funktionsaufrufe unterstützt/benutzt, gilt das nicht automatisch auch für all die Applikationen welche unter Windows laufen.

[aufkrawall]

Wie schon im anderen Thread gesagt: Ein Mainline Linux Kernel hat noch gar nicht die Möglichkeit Intels neue Funktionen aus dem Microcode Update zu benutzen. Es ist noch gar nicht Teil des Kernels. Ob ein Mainline Linux Nutzer den Microcode drauf hat oder nicht ist so ziemlich egal, völlig unabhängig von der CPU.
"egal" also nicht benötigt, oder irrt sich das Script bzw. es kennt den Sachverhalt mit dem Microcode nicht?

[Ganon]

Das trifft doch auch auf die aktuelle Methode mit IBRS, STIBP und IBPB zu?
Nur weil der Windows Kernel diese Funktionsaufrufe unterstützt/benutzt, gilt das nicht automatisch auch für all die Applikationen welche unter Windows laufen.

IBRS und Co. sind Prozessor-Flags. Sie patchen quasi die gefährliche Art der Ausführung im Prozessor selbst. Der Kernel setzt und entfernt die Flags nach bestimmten Regelwerken. Der Prozessor fährt also, sofern der Kernel es benutzt, mit angezogener Handbremse und löst diese wieder, wenn es gerade nicht nötig ist.

Retpoline ist eine Ebene darüber. Es erweitert den Code der Anwendungen (inkl. Kernel) an bestimmten Stellen, damit die "gefährliche Ausführung" des Prozessors ins Leere läuft. In Auto-Sprache: Wir machen einfach stellenweise die Fahrbahn so schlecht, dass wir gar nicht schnell fahren können :D

"egal" also nicht benötigt, oder irrt sich das Script bzw. es kennt den Sachverhalt mit dem Microcode nicht?

An welcher Stelle irrt sich denn das Skript? edit: Und "egal" in Form von: Es ändert nichts. Es macht es nicht sicherer, aber auch nicht unsicherer. Etwas was vorher unsicher war, bleibt unsicher und anders herum.

[BBig]

Wie schon im anderen Thread gesagt: Ein Mainline Linux Kernel hat noch gar nicht die Möglichkeit Intels neue Funktionen aus dem Microcode Update zu benutzen. Es ist noch gar nicht Teil des Kernels. Ob ein Mainline Linux Nutzer den Microcode drauf hat oder nicht ist so ziemlich egal, völlig unabhängig von der CPU.
...

Ich glaube du hast recht: Meltdown-Mitigation -> PTI
sudo ./spectre-meltdown-checker.sh
[sudo] Passwort für bbig:
Spectre and Meltdown mitigation detection tool v0.33

Checking for vulnerabilities on current system
Kernel is Linux 4.14.15-1-ARCH #1 SMP PREEMPT Tue Jan 23 21:49:25 UTC 2018 x86_64
CPU is Intel(R) Pentium(R) CPU G4560 @ 3.50GHz

Hardware check
* Hardware support (CPU microcode) for mitigation techniques
* Indirect Branch Restricted Speculation (IBRS)
* SPEC_CTRL MSR is available: YES
* CPU indicates IBRS capability: YES (SPEC_CTRL feature bit)
* Indirect Branch Prediction Barrier (IBPB)
* PRED_CMD MSR is available: YES
* CPU indicates IBPB capability: YES (SPEC_CTRL feature bit)
* Single Thread Indirect Branch Predictors (STIBP)
* SPEC_CTRL MSR is available: YES
* CPU indicates STIBP capability: YES
* Enhanced IBRS (IBRS_ALL)
* CPU indicates ARCH_CAPABILITIES MSR availability: NO
* ARCH_CAPABILITIES MSR advertises IBRS_ALL capability: NO
* CPU explicitly indicates not being vulnerable to Meltdown (RDCL_NO): UNKNOWN
* CPU microcode is known to cause stability problems: YES (Intel CPU Family 6 Model 158 Stepping 9 with microcode 0x80)

The microcode your CPU is running on is known to cause instability problems,
such as intempestive reboots or random crashes.
You are advised to either revert to a previous microcode version (that might not have
the mitigations for Spectre), or upgrade to a newer one if available.

* CPU vulnerability to the three speculative execution attacks variants
* Vulnerable to Variant 1: YES
* Vulnerable to Variant 2: YES
* Vulnerable to Variant 3: YES

CVE-2017-5753 [bounds check bypass] aka 'Spectre Variant 1'
* Mitigated according to the /sys interface: NO (kernel confirms your system is vulnerable)
> STATUS: VULNERABLE (Vulnerable)

CVE-2017-5715 [branch target injection] aka 'Spectre Variant 2'
* Mitigated according to the /sys interface: YES (kernel confirms that the mitigation is active)
* Mitigation 1
* Kernel is compiled with IBRS/IBPB support: NO
* Currently enabled features
* IBRS enabled for Kernel space: NO
* IBRS enabled for User space: NO
* IBPB enabled: NO
* Mitigation 2
* Kernel compiled with retpoline option: YES
* Kernel compiled with a retpoline-aware compiler: YES (kernel reports full retpoline compilation)
* Retpoline enabled: YES
> STATUS: NOT VULNERABLE (Mitigation: Full generic retpoline)

CVE-2017-5754 [rogue data cache load] aka 'Meltdown' aka 'Variant 3'
* Mitigated according to the /sys interface: YES (kernel confirms that the mitigation is active)
* Kernel supports Page Table Isolation (PTI): YES
* PTI enabled and active: YES
* Running as a Xen PV DomU: NO
> STATUS: NOT VULNERABLE (Mitigation: PTI)

A false sense of security is worse than no security at all, see --disclaimer

[Ganon]

Mit Meltdown hat der Microcode auch nichts zu tun. Es gilt die Zeile: "(Mitigation: Full generic retpoline)". Das ist das was der Kernel meldet:


$ cat /sys/devices/system/cpu/vulnerabilities/spectre_v2
Mitigation: Full generic retpoline


Hier übrigens das Skript ohne Microcode-Update (habe mal zurgerollt auf die 20171117 Update Dateien):


Spectre and Meltdown mitigation detection tool v0.33

Checking for vulnerabilities on current system
Kernel is Linux 4.14.15-1-ARCH #1 SMP PREEMPT Tue Jan 23 21:49:25 UTC 2018 x86_64
CPU is Intel(R) Core(TM) i7-4750HQ CPU @ 2.00GHz

Hardware check
* Hardware support (CPU microcode) for mitigation techniques
* Indirect Branch Restricted Speculation (IBRS)
* SPEC_CTRL MSR is available: NO
* CPU indicates IBRS capability: NO
* Indirect Branch Prediction Barrier (IBPB)
* PRED_CMD MSR is available: NO
* CPU indicates IBPB capability: NO
* Single Thread Indirect Branch Predictors (STIBP)
* SPEC_CTRL MSR is available: NO
* CPU indicates STIBP capability: NO
* Enhanced IBRS (IBRS_ALL)
* CPU indicates ARCH_CAPABILITIES MSR availability: NO
* ARCH_CAPABILITIES MSR advertises IBRS_ALL capability: NO
* CPU explicitly indicates not being vulnerable to Meltdown (RDCL_NO): NO
* CPU microcode is known to cause stability problems: NO
* CPU vulnerability to the three speculative execution attacks variants
* Vulnerable to Variant 1: YES
* Vulnerable to Variant 2: YES
* Vulnerable to Variant 3: YES

CVE-2017-5753 [bounds check bypass] aka 'Spectre Variant 1'
* Mitigated according to the /sys interface: NO (kernel confirms your system is vulnerable)
> STATUS: VULNERABLE (Vulnerable)

CVE-2017-5715 [branch target injection] aka 'Spectre Variant 2'
* Mitigated according to the /sys interface: YES (kernel confirms that the mitigation is active)
* Mitigation 1
* Kernel is compiled with IBRS/IBPB support: NO
* Currently enabled features
* IBRS enabled for Kernel space: NO
* IBRS enabled for User space: NO
* IBPB enabled: NO
* Mitigation 2
* Kernel compiled with retpoline option: YES
* Kernel compiled with a retpoline-aware compiler: YES (kernel reports full retpoline compilation)
* Retpoline enabled: YES
> STATUS: NOT VULNERABLE (Mitigation: Full generic retpoline)

CVE-2017-5754 [rogue data cache load] aka 'Meltdown' aka 'Variant 3'
* Mitigated according to the /sys interface: YES (kernel confirms that the mitigation is active)
* Kernel supports Page Table Isolation (PTI): YES
* PTI enabled and active: YES
* Running as a Xen PV DomU: NO
> STATUS: NOT VULNERABLE (Mitigation: PTI)

A false sense of security is worse than no security at all, see --disclaimer


Wie man sieht, auch ohne Microcode Updates ist Retpoline aktiv. Dass Retpoline je nach CPU in der aktuellen Ausführung (ich kenne da gerade den Stand nicht) eine 100%ige Lösung ist, sagt das natürlich nicht. Darum wird/wurde Retpoline ja erweitert (siehe Link von mir weiter oben)

[Complicated]

Ryzen 3 - vermlt Anfang 2019
Ryzen 4 - vermtl Anfang 2020
Tiger Lake - Ende 2019

... Tiger Lake ist vermutlich terminlich näher zu Ryzen 4 als zu Ryzen 3. Hardware-Anpassungen für Ryzen 3 sind zudem unwahrscheinlich, da das Design von Zen 2 schon fertig ist. Deswegen diese Auslegung.
Das Problem ist nicht deine Auslegung anhand der möglichen Erscheinungstermine. Das Problem ist, dass du behauptest AMD CPUs seien heute anfällig für Meltdown, indem du Meltdown und Spectre in deiner Tabelle erst 2020 als gefixed bei AMDs Hardware bezeichnest. Das ist schlicht und ergreifend falsch. Überhaupt ist es eine Unart Meltdown und Spectre (sowohl 1 als auch 2) immer in einem Atemzug zu verwenden.

Spectre 1 ist kein Hardware Fehler und wird durch Software-Patches behoben. Spectre 2 ist ein Hardwarefehler der Intel-CPUs angreifbar macht und AMD erst nach mutwilliger Aktivierung des eBPF-JIT betroffen macht, der per default deaktiviert ist. Es gib noch kein anderes Angriffsszenario, das AMD von Spectre2 angreifbar macht im Auslieferungszustand. Deshalb benötigt AMD auch keine Hardware-fixes, wenn Retpoline zum Einsatz kommt. Deshalb ist es auch falsch zu sagen AMD hätte erst 2020 Hardware, welche nicht verwundbar ist für Spectre.

Es gilt als gesichert anzunehmen, dass Spectre1 noch weit vor 2020 sowohl für Intel als auch AMD durch Änderungen in Software eliminiert wird. Spectre 2 ist auf Linux Systemen mit Retpoline und AMD Hardware nicht mehr nutzbar und Meltdown war es noch nie auf AMD Systemen. Somit würde ich mal behaupten AMD hat schon 2018 Hardware auf dem Markt, welche gesichert ist gegen Spectre/Meltdown. Was noch fehlt ist die Absicherung der Software, wie bei jedem anderen Exploit der letzten Jahre auch. Intel hat da schwerere Problem, da dies bei Ihnen nicht zutrifft.

[aufkrawall]

An welcher Stelle irrt sich denn das Skript? edit: Und "egal" in Form von: Es ändert nichts. Es macht es nicht sicherer, aber auch nicht unsicherer. Etwas was vorher unsicher war, bleibt unsicher und anders herum.
Du meinst das Microcode-Update?
Also braucht man das mit den schon existierenden Maßnahmen im Kernel nicht?
Darum ging es mir.

[Ganon]

Du meinst das Microcode-Update?
Also braucht man das mit den schon existierenden Maßnahmen im Kernel nicht?
Darum ging es mir.

Also noch mal zusammenfassend:
- Linux hat mit Retpoline einen Schutz der keine Microcode Updates braucht
- dieser Schutz greift _vielleicht_ (ich hab gerade keinen aktuellen Stand) noch nicht zu 100% auf >=Skylake, aber er greift erst mal teilweise
- dieser Schutz wird immer weiter verfeinert (siehe Link von mir weiter oben)

weiterhin:
- ein Mainline Linux kennt die neuen Features (IBRS, IBPB, STIBP) des Microcode-Updates (noch) gar nicht
- entsprechend kann er diese auch nicht benutzen
- folglich: Ob das Microcode Update installiert ist oder nicht ist vollkommen egal

weiter weiterhin:
- voraussichtlich wird die Verwendung von IBRS, IBPB, STIBP im Linux Kernel optional bleiben.

[aufkrawall]

Alles klar, besten Dank. :)

[Complicated]

- dieser Schutz greift _vielleicht_ (ich hab gerade keinen aktuellen Stand) noch nicht zu 100% auf >=Skylake, aber er greift erst mal teilweise

Da geht es ja um die zusätzliche Anfälligkeit bei "Deep stacks" mit mehr als 16 call Aufrufen am Stück in einer "chain", wo Retpoline dann umgangen wird und die CPUs doch wieder aus dem BTB anstatt dem RSB Daten lesen. Um das zu verhindern muss IBRS aktiviert werden, was allerdings sehr viel Leistung kostet. Derzeit gibt es Ansätze für eine weitere Lösung, die deutlich weniger Performance Einbußen kosten würde. Siehe Planet3D-Artikel:
http://www.planet3dnow.de/cms/36246-amd-gibt-programmierleitfaden-gegen-spectre-heraus/
Und Original Quelle:
https://lkml.org/lkml/2018/1/23/25

[Iscaran]

Wie üblich bei der Thematik erleidet man Schiffbruch wenn man nicht klar genug die 3 unterschiedlichen Szenarien trennt.

Schlimm genug dass 2 davon als "Spectre" zusammengefasst werden.

Nicht ohne Grund gibt es ja auch 3 CVE-entries:

CVE-2017-5753 (alias Spectre v1)
CVE-2017-5715 (alias Spectre v2)
CVE-2017-5754 (alias Meltdown)

Ein Übersichtsartikel der hier "Klarheit" und "Überblick" verschaffen möchte - sollte zumindest das sauber darlegen...

Jetzt muss man eigentlich nur noch die jeweiligen CPU-Anfälligkeiten darlegen und die jeweiligen Patch-Varianten, aufgedröselt auf diese 3 Fälle. Der Artikel so wie er hier steht, ist leider in der Hinsicht unglaublich schlecht. Am besten einfach wieder vom Netz nehmen.

EDIT: Im Zweifelsfall muss man doch einfach nur ein paar der Englisch-sprachigen Quellen ins deutsche übertragen:
https://access.redhat.com/articles/3311301#indirect-branch-restricted-speculation-ibrs-7
https://gist.github.com/woachk/2f86755260f2fee1baf71c90cd6533e9
https://cloudblogs.microsoft.com/microsoftsecure/2018/01/09/understanding-the-performance-impact-of-spectre-and-meltdown-mitigations-on-windows-systems/

[Gast]

Also noch mal zusammenfassend:

- folglich: Ob das Microcode Update installiert ist oder nicht ist vollkommen egal


richtig, mit aktuellem Paket "intel-microcode" wird sogar ein Microcode Downgrade durchgeführt wenn die neuen Mircocode bereits per BIOS Update installiert wurden (intel-mircocode version: 3.20180108.1+really20171117.1)

[Gast]

@Leonidas
AMD hat mit Zen 2 schon einige Sachen implementiert um gegen Spectre und ähnliches vorzugehen:

Das Zen-2-Design habe AMD inzwischen fertiggestellt. Darin seien Anpassungen auf Hardware-Ebene enthalten, um sich gegen Spectre abzusichern - Su spricht nicht von spezifischen Varianten, sondern von einer Absicherung gegen "Spectre-ähnliche" Angriffe. (http://www.pcgameshardware.de/AMD-Zen-Codename-261795/News/Zen-2-7-nm-CPU-Spectre-1249126/)

[FlashBFE]

Zusätzlich zu Leos üblicher Schreibweise, die sicherlich auch nicht gerade einer Verwirrung bei so einem komplizierten Thema vorbeugt, muss ich speziell mal die Zitierweise im Sinne der Quellenangaben bemängeln:

Abgesehen von einem Link auf die Wikipedia verweist der Artikel immer nur auf das 3DC oder das Forum. Die komplette Abhandlung kommt also ohne vernünftige Quellenangaben daher. Das ist einfach unwürdig und macht es nicht leichter, zwischen Leos üblichen ausschweifenden Vermutungen und echten Infos, speziell dem zeitlichen Stand dieser Infos, zu sortieren.

Falls dieser Artikel nochmal aktualisiert werden sollte, dann bitte auch im handwerklichen Sinne!