Spectre: AMD benötigt auf Windows Microcode-Updates, auf Linux nicht
- Ersteller PCGH-Redaktion
- Erstellt am
AW: Spectre: AMD benötigt auf Windows Microcode-Updates, auf Linux nicht
Selbst unter Linux wäre ein Verzicht auf Microcode-Updates kritisch zu betrachten. Retpoline ist eine vergleichsweise elegante Lösung, die Sprungvorhersage aktueller CPUs in einer dem Entwickler genehmen Weise zu beeinflussen und es kann nicht ausgeschlossen werden, dass künftige Vorhersage-Algorithmen anders auf diesen Trick reagieren. Letztlich ist es ein Gegenhack, der genau wie Spectre selbst das Verhalten der CPU manipuliert, ihr im Gegensatz zu IBPB und IBRS aber keine direkten Befehle geben kann. Sollte ein Programmierer deswegen letztere Lösungsansätze bevorzugen, so ist das Ergebnis nur auf CPUs mit passendem Microcode vor Spectre geschützt. Das gilt auch für Anwendungen, die unter Linux laufen – das Betriebssystem selbst mittels Retpoline vor Angriffen zu schützen ist schließlich nur ein erster Schritt. Die meisten Angreifer dürften hinter Informationen her sein, die sich nicht im Kernel verstecken.
Selbst unter Linux wäre ein Verzicht auf Microcode-Updates kritisch zu betrachten. Retpoline ist eine vergleichsweise elegante Lösung, die Sprungvorhersage aktueller CPUs in einer dem Entwickler genehmen Weise zu beeinflussen und es kann nicht ausgeschlossen werden, dass künftige Vorhersage-Algorithmen anders auf diesen Trick reagieren. Letztlich ist es ein Gegenhack, der genau wie Spectre selbst das Verhalten der CPU manipuliert, ihr im Gegensatz zu IBPB und IBRS aber keine direkten Befehle geben kann. Sollte ein Programmierer deswegen letztere Lösungsansätze bevorzugen, so ist das Ergebnis nur auf CPUs mit passendem Microcode vor Spectre geschützt. Das gilt auch für Anwendungen, die unter Linux laufen – das Betriebssystem selbst mittels Retpoline vor Angriffen zu schützen ist schließlich nur ein erster Schritt. Die meisten Angreifer dürften hinter Informationen her sein, die sich nicht im Kernel verstecken.
hanfi104
Volt-Modder(in)
AW: Spectre: AMD benötigt auf Windows Microcode-Updates, auf Linux nicht
Bei mir steht eh schon ein BIOS Update an, eines für die Breitschaft für Zen+. Denn falls die Taktraten in meinen Erwartungsbereich liegen, kommt eine neue CPU her, auch wenn ich sie zu keine 50% nutze
Aber wie bei Windowsupdates sollten man lieber warten, bis die ersten Alpha und Beta Phasen vorüber sind.
Bei mir steht eh schon ein BIOS Update an, eines für die Breitschaft für Zen+. Denn falls die Taktraten in meinen Erwartungsbereich liegen, kommt eine neue CPU her, auch wenn ich sie zu keine 50% nutze
Aber wie bei Windowsupdates sollten man lieber warten, bis die ersten Alpha und Beta Phasen vorüber sind.
AW: Spectre: AMD benötigt auf Windows Microcode-Updates, auf Linux nicht
Vorteil bei der jetzigen Diskussion ist, dass man jetzt sehr gut Fanboys von neutralen Personen unterscheiden kann.
Die Pressemitteilung von AMD war typisch für Marketingleute. "Risiko nahe Null" bedeutet meist, dass man aktuell keine Ahnung hat und alles passieren kann.
Nach dem aktuellen Wissensstand sehe ich die Mitteilung von AMD als nicht besonders schlimm an und war in Ordnung.
Bei Intel diente die Pressemitteilung zur reinen Desinformation und man konnte dort sehr leicht komplett falsche Schlüsse ziehen und war bestimmt auch so gedacht.
Damit ist die Pressemitteilung schon etwas anders zu beurteilen.
Die Forscher kannten Haswell besonders gut und deswegen ist es klar, dass AMD aktuell weniger stark betroffen ist. Die Architekturen sind einfach teilweise sehr unterschiedlich und funktioniert deswegen 1:1 nicht.
Das heißt aber nicht, dass es nicht ähnliche Angriffe auch bei AMD geben kann und auch erfolgreich sind. Manche stellen sich auch die Lücke als etwas einfach vor. Gewisse Seiteneffekte wird man nie komplett ausschließen können.
Mal ein dummes Beispiel: Ich habe 1 Millionen Lottoscheine mit jeweils 1 Kästchen abgegeben und kenne die Ziehungsergebnisse nicht. Dann verschenke ich je 1 Schein an insgesamt 1 Million Personen und die kennen die Ziehungergebnisse, dann kann ich an deren Gesichter das Ergebnis erkennen. Mit Hilfe der Gesichtsregungen kann ich dann das Ziehungsergebnis rekonstruieren, obwohl mir keiner der Personen irgendwas gesagt hat.
Mir ist leider kein besseres Beispiel eingefallen, aber wollte das Grundprinzip etwas erklären. Für bessere Vorschläge bin ich offen.
Das Problem ist, dass man durch gewisse Aktionen beispielsweise Laufzeitmessungen gewisse Rückschlüsse ziehen kann. Wenn man es genug oft wiederholt, dann kann man gewisse Informationen "erraten", obwohl der Prozess selber eigentlich keine Informationen weitergibt und eigentlich "sicher" ist. Für mich wird es auch nicht die letzte "Lücke" dieser Art in Soft- und Hardware sein.
Vorteil bei der jetzigen Diskussion ist, dass man jetzt sehr gut Fanboys von neutralen Personen unterscheiden kann.
Die Pressemitteilung von AMD war typisch für Marketingleute. "Risiko nahe Null" bedeutet meist, dass man aktuell keine Ahnung hat und alles passieren kann.
Nach dem aktuellen Wissensstand sehe ich die Mitteilung von AMD als nicht besonders schlimm an und war in Ordnung.
Bei Intel diente die Pressemitteilung zur reinen Desinformation und man konnte dort sehr leicht komplett falsche Schlüsse ziehen und war bestimmt auch so gedacht.
Damit ist die Pressemitteilung schon etwas anders zu beurteilen.
Die Forscher kannten Haswell besonders gut und deswegen ist es klar, dass AMD aktuell weniger stark betroffen ist. Die Architekturen sind einfach teilweise sehr unterschiedlich und funktioniert deswegen 1:1 nicht.
Das heißt aber nicht, dass es nicht ähnliche Angriffe auch bei AMD geben kann und auch erfolgreich sind. Manche stellen sich auch die Lücke als etwas einfach vor. Gewisse Seiteneffekte wird man nie komplett ausschließen können.
Mal ein dummes Beispiel: Ich habe 1 Millionen Lottoscheine mit jeweils 1 Kästchen abgegeben und kenne die Ziehungsergebnisse nicht. Dann verschenke ich je 1 Schein an insgesamt 1 Million Personen und die kennen die Ziehungergebnisse, dann kann ich an deren Gesichter das Ergebnis erkennen. Mit Hilfe der Gesichtsregungen kann ich dann das Ziehungsergebnis rekonstruieren, obwohl mir keiner der Personen irgendwas gesagt hat.
Mir ist leider kein besseres Beispiel eingefallen, aber wollte das Grundprinzip etwas erklären. Für bessere Vorschläge bin ich offen.
Das Problem ist, dass man durch gewisse Aktionen beispielsweise Laufzeitmessungen gewisse Rückschlüsse ziehen kann. Wenn man es genug oft wiederholt, dann kann man gewisse Informationen "erraten", obwohl der Prozess selber eigentlich keine Informationen weitergibt und eigentlich "sicher" ist. Für mich wird es auch nicht die letzte "Lücke" dieser Art in Soft- und Hardware sein.
AW: Spectre: AMD benötigt auf Windows Microcode-Updates, auf Linux nicht
Aber wenn das grundlegende Konzept einen Fehler aufweist bleibt natürlich niemand verschont, egal wie die Implementierung aussieht.
Ich schätze das hat auch einen rechtlichen Hintergrund. Wenn sie sagen, dass sie nicht betroffen sind und man kommt drauf, dass es doch der Fall ist hat AMD ernste Probleme am Hals. Unter Anbetracht der Umstände bzw. im Vergleich zu einigen anderen Firmen (nicht nur Intel) ist es sogar ungewohnt ehrlich.
Stimmt, hier wird Intel ihre Größe auch ein wenig zum Verhängnis. AMD hat aber auch einen leichten Architektur-Vorteil, da Speicherzugriffe mit unterschiedlichen Rechten von Haus aus nicht möglich sind. Darum sind sie ja von Meltdown generell nicht betroffen.
Aber wenn das grundlegende Konzept einen Fehler aufweist bleibt natürlich niemand verschont, egal wie die Implementierung aussieht.
AW: Spectre: AMD benötigt auf Windows Microcode-Updates, auf Linux nicht
ich weiß nicht warum immer fleißig auf AMD getrampelt wird . Intel hat die größte ******* gebaut und AMD wird gebeutelt ? AMD hat nun mal eine andere Architektur als Intel , auch wenn Intel viel an Lizenzen von AMD in den eigenen CPUs hat ( siehe 64 bit erweiterung , Speicherkontroller in der cpu etc ), sind AMD-CPUs anders aufgebaut und somit nicht soooo anfällig wie INTEL-CPUs . Jeder der gegen AMD schießt , erscheint mir so , als wenn er gut bezahlt wird von INTEL um die INTEL-CPUs besser darstehen zu lassen . wenn wir mal die geschichte sehen , ist AMD immer der jenige gewesen welcher Fehler schneller zu gegeben hatte und Intel ebend nicht . warum soll AMD diesmal nicht besser da stehen wie INTEL ?
ich weiß nicht warum immer fleißig auf AMD getrampelt wird . Intel hat die größte ******* gebaut und AMD wird gebeutelt ? AMD hat nun mal eine andere Architektur als Intel , auch wenn Intel viel an Lizenzen von AMD in den eigenen CPUs hat ( siehe 64 bit erweiterung , Speicherkontroller in der cpu etc ), sind AMD-CPUs anders aufgebaut und somit nicht soooo anfällig wie INTEL-CPUs . Jeder der gegen AMD schießt , erscheint mir so , als wenn er gut bezahlt wird von INTEL um die INTEL-CPUs besser darstehen zu lassen . wenn wir mal die geschichte sehen , ist AMD immer der jenige gewesen welcher Fehler schneller zu gegeben hatte und Intel ebend nicht . warum soll AMD diesmal nicht besser da stehen wie INTEL ?
AW: Spectre: AMD benötigt auf Windows Microcode-Updates, auf Linux nicht
Ganz so einfach ist es auch nicht. Auch bei Intel ist der zugriff auf den Speicher über den privilige-level geregelt, nur das bei der Core-i Architektur auch diese Überprüfung OOO ausgeführt wird - was eben die Ausführung von syscalls eventuell beschleunigen kann, aber eben auch den Zugriff auf privilegierten Speicher (meltdown) zulässt.
Beide haben das gleiche Problem - was hier aber einige (gerechter weise) ankreiden ist das es hier einige AMD-Jünger gibt die der Wahrheit nicht ins Gesicht schauen wollen und immer nur Intel die Schuld zuweisen wollen.
Über Intel und meltdown wird genügend berichtet, aber wehe denn eas wagt jemand zu erwähnen das AMD von Spectre genauso betroffen ist - dann bricht bei den Fanboys die Hölle los. Allein schon die Aussage AMD wäre weniger betroffen zeugt doch davon das du von der Sicherheitslücke absolut keine Ahnung hast.
Die Einzigen die hier versuchen jemanden besser darstehen zu lassen sind die AMD-Jünger wie du und Trader - die es nicht gebacken kriegen auch nur einen sachlichen Kommentar zu verfassen.
(Wobei letzterer nochmal ein deutlich anderes Kaliber an eingeschränkter und verzerrter Weltanschauung ist)
Aber bitte - überzeug uns doch vom Gegenteil - leg beweise vor für deine Behauptung das AMD weniger betroffen ist. Selbst AMD hat diese initiale Falschaussage bereits revidiert und sagt jetzt das sie eben die exakt selben Maßnahmen treffen müssen wie intel.....
Ganz so einfach ist es auch nicht. Auch bei Intel ist der zugriff auf den Speicher über den privilige-level geregelt, nur das bei der Core-i Architektur auch diese Überprüfung OOO ausgeführt wird - was eben die Ausführung von syscalls eventuell beschleunigen kann, aber eben auch den Zugriff auf privilegierten Speicher (meltdown) zulässt.
Beide haben das gleiche Problem - was hier aber einige (gerechter weise) ankreiden ist das es hier einige AMD-Jünger gibt die der Wahrheit nicht ins Gesicht schauen wollen und immer nur Intel die Schuld zuweisen wollen.
Über Intel und meltdown wird genügend berichtet, aber wehe denn eas wagt jemand zu erwähnen das AMD von Spectre genauso betroffen ist - dann bricht bei den Fanboys die Hölle los. Allein schon die Aussage AMD wäre weniger betroffen zeugt doch davon das du von der Sicherheitslücke absolut keine Ahnung hast.
Die Einzigen die hier versuchen jemanden besser darstehen zu lassen sind die AMD-Jünger wie du und Trader - die es nicht gebacken kriegen auch nur einen sachlichen Kommentar zu verfassen.
(Wobei letzterer nochmal ein deutlich anderes Kaliber an eingeschränkter und verzerrter Weltanschauung ist)
Aber bitte - überzeug uns doch vom Gegenteil - leg beweise vor für deine Behauptung das AMD weniger betroffen ist. Selbst AMD hat diese initiale Falschaussage bereits revidiert und sagt jetzt das sie eben die exakt selben Maßnahmen treffen müssen wie intel.....
AW: Spectre: AMD benötigt auf Windows Microcode-Updates, auf Linux nicht
so wie es aussieht scheinst du dich nicht richtig informiert zu haben . da gibt es fachmenschen bei heise.de die dies getestet haben und genau das festgestellt haben was tatsache ist . AMD ist sicherer als Intel . auch wenn du es ungern hörst . erst informieren , dann auf AMD herum klopfen . wenn man keine ahnung hat , einfach mund halten anstatt unsinn zu reden und AMD runter zu machen . einige können es ebend nicht vertragen das Intel ******* verkauft hat und die sicherheitslücken nicht erst jetzt weiß . übrigens , ich fahre intel in meinen lapi und in meinen tower . doch sehe ich den tatsache ins auge das intel lieber geschwiegen hat um seine cpus besser zu verkaufen .
so wie es aussieht scheinst du dich nicht richtig informiert zu haben . da gibt es fachmenschen bei heise.de die dies getestet haben und genau das festgestellt haben was tatsache ist . AMD ist sicherer als Intel . auch wenn du es ungern hörst . erst informieren , dann auf AMD herum klopfen . wenn man keine ahnung hat , einfach mund halten anstatt unsinn zu reden und AMD runter zu machen . einige können es ebend nicht vertragen das Intel ******* verkauft hat und die sicherheitslücken nicht erst jetzt weiß . übrigens , ich fahre intel in meinen lapi und in meinen tower . doch sehe ich den tatsache ins auge das intel lieber geschwiegen hat um seine cpus besser zu verkaufen .
AW: Spectre: AMD benötigt auf Windows Microcode-Updates, auf Linux nicht
Bei einem Auto würde man in der Elektronik ja auch nicht das Gaspedal vor ABS, Bremsen, Airbags etc. reihen nur damit es sich "spritziger" fährt.
Fakt ist, dass bei AMD-CPUs bisher nur eine Angriffsvariante erfolgreich durchgeführt werden konnte während bei Intel alle 3 anwendbar waren. Damit sind AMD-Prozessoren (im Moment) faktisch weniger betroffen. Das bei den Untersuchungen wohl Intel-Prozessoren mehr im Fokus standen ist dabei zweitrangig.
Die Meldung von AMD mit "beinahe Null Risiko" für Spectre 2 ist in erster Linie Marketingsprech, klar. Falsch bzw. gelogen war sie allerdings auch nicht. Einen Widerspruch bzw. Korrektur zwischen "beinahe Null Risiko" und "noch nicht nachgewiesen" kann ich übrigens auch nicht erkennen. Bei Spectre 1 hat man ja von vornherein gesagt, dass man in einem bestimmten Fall betroffen ist und das patcht.
Wenn man sich hingegen das erste Statement von Intel ansieht, wurden der Informationsgehalt bewusst niedrig gehalten (Spectre+Meltdown gemischt) und unterschwellig auch die Konkurrenz angepatzt. Gefolgt von überhasteter, teils schlampiger, Patcharbeit und Aussagen des Managements deren Wahrheitsgehalt man zumindest in Zweifel ziehen darf. Da sind wir moralisch wie professionell (vom technischen Standpunkt, marketingtechnisch war es genial) auf einem ganz anderen Niveau und zwar ein paar Etagen tiefer.
Ich hab's schon ein paar Mal gesagt, den Fehler kann man Intel unmöglich vorhalten. Bei der gegebenen Komplexität passiert sowas schon mal. Wie sie damit umgehen darf man allerdings durchaus kritisieren und hier steht AMD mMn derzeit besser da.
Bin ich jetzt auch einer dieser Fanboys?
Eine grundlegende Sicherheitsfunktion für einen kleinen Geschwindigkeitsvorteil zu untergraben ist halt auch nicht gerade intelligent.
Bei einem Auto würde man in der Elektronik ja auch nicht das Gaspedal vor ABS, Bremsen, Airbags etc. reihen nur damit es sich "spritziger" fährt.
Nix für ungut, aber du bist mir bei der ganzen Geschichte als einer der größten "AMD auch"-Schreier und Intel-"White-Knights" negativ aufgefallen. Wer im Glashaus sitzt sollte nicht mit Steinen werfen.
Fakt ist, dass bei AMD-CPUs bisher nur eine Angriffsvariante erfolgreich durchgeführt werden konnte während bei Intel alle 3 anwendbar waren. Damit sind AMD-Prozessoren (im Moment) faktisch weniger betroffen. Das bei den Untersuchungen wohl Intel-Prozessoren mehr im Fokus standen ist dabei zweitrangig.
Die Meldung von AMD mit "beinahe Null Risiko" für Spectre 2 ist in erster Linie Marketingsprech, klar. Falsch bzw. gelogen war sie allerdings auch nicht. Einen Widerspruch bzw. Korrektur zwischen "beinahe Null Risiko" und "noch nicht nachgewiesen" kann ich übrigens auch nicht erkennen. Bei Spectre 1 hat man ja von vornherein gesagt, dass man in einem bestimmten Fall betroffen ist und das patcht.
Wenn man sich hingegen das erste Statement von Intel ansieht, wurden der Informationsgehalt bewusst niedrig gehalten (Spectre+Meltdown gemischt) und unterschwellig auch die Konkurrenz angepatzt. Gefolgt von überhasteter, teils schlampiger, Patcharbeit und Aussagen des Managements deren Wahrheitsgehalt man zumindest in Zweifel ziehen darf. Da sind wir moralisch wie professionell (vom technischen Standpunkt, marketingtechnisch war es genial) auf einem ganz anderen Niveau und zwar ein paar Etagen tiefer.
Ich hab's schon ein paar Mal gesagt, den Fehler kann man Intel unmöglich vorhalten. Bei der gegebenen Komplexität passiert sowas schon mal. Wie sie damit umgehen darf man allerdings durchaus kritisieren und hier steht AMD mMn derzeit besser da.
Bin ich jetzt auch einer dieser Fanboys?
G
Grestorn
Guest
AW: Spectre: AMD benötigt auf Windows Microcode-Updates, auf Linux nicht
Was denn heißt "sicherer" in diesem Zusammenhang?
Wenn man angreifbar ist, dann ist man angreifbar, Punkt. Es spielt dabei keine Rolle, ob der Code, um den Angriff durchzuführen, evtl. aufwendiger ist. Den Aufwand muss man ja nur einmal betreiben. Für den angegriffenen spielt es keine Rolle, wie aufwendig es war, den Angriffscode zu schreiben.
In so fern ist es schon ein wenig blauäugig, wenn sich AMD Fans in der vermeintlich etwas "besseren" Sicherheit baden. Abgesehen davon, dass diese "Sicherheit" ja eher Zufall ist und nicht der Genialität von AMD zuzuschreiben ist.
P.S.: Ich habe mir fest vorgenommen, dass meine nächste CPU von AMD sein wird. Nur falls mir wieder jemand Intel-Fanboyness unterstellt.
Was denn heißt "sicherer" in diesem Zusammenhang?
Wenn man angreifbar ist, dann ist man angreifbar, Punkt. Es spielt dabei keine Rolle, ob der Code, um den Angriff durchzuführen, evtl. aufwendiger ist. Den Aufwand muss man ja nur einmal betreiben. Für den angegriffenen spielt es keine Rolle, wie aufwendig es war, den Angriffscode zu schreiben.
In so fern ist es schon ein wenig blauäugig, wenn sich AMD Fans in der vermeintlich etwas "besseren" Sicherheit baden. Abgesehen davon, dass diese "Sicherheit" ja eher Zufall ist und nicht der Genialität von AMD zuzuschreiben ist.
P.S.: Ich habe mir fest vorgenommen, dass meine nächste CPU von AMD sein wird. Nur falls mir wieder jemand Intel-Fanboyness unterstellt.
rum
BIOS-Overclocker(in)
AW: Spectre: AMD benötigt auf Windows Microcode-Updates, auf Linux nicht
Bei den vielen Kommentaren ist es schwierig heraus zu lesen, wo denn nun die Wahrheit liegt ...
Daher mal eine einfache Frage von mir: wenn der Hardwareentwickler und -hersteller Schuld ist, warum braucht Linux dann kein Microcodeupdate, Windows hingegen schon?
Mir persönlich ist es eigentlich total Wurscht, wie die beiden Betriebssysteme intern organisiert oder aufgebaut sind; Fachsimpeln über die Ursachen überlasse unseren Betriebssystementwicklern und -programmierern hier. Meine Frage ist im Prinzip sehr schlicht gehalten: warum ist es Softwareabhängig? Das passt für mich irgendwie nicht.
Bei den vielen Kommentaren ist es schwierig heraus zu lesen, wo denn nun die Wahrheit liegt ...
Daher mal eine einfache Frage von mir: wenn der Hardwareentwickler und -hersteller Schuld ist, warum braucht Linux dann kein Microcodeupdate, Windows hingegen schon?
Mir persönlich ist es eigentlich total Wurscht, wie die beiden Betriebssysteme intern organisiert oder aufgebaut sind; Fachsimpeln über die Ursachen überlasse unseren Betriebssystementwicklern und -programmierern hier. Meine Frage ist im Prinzip sehr schlicht gehalten: warum ist es Softwareabhängig? Das passt für mich irgendwie nicht.
yummycandy
Software-Overclocker(in)
AW: Spectre: AMD benötigt auf Windows Microcode-Updates, auf Linux nicht
Kann jemand von euch das verifizieren? Es würde erklären, warum jetzt auf einmal Microcode-Updates nötig werden und es vorher nicht klar war:
Da ich keine hardwarenahe Programmierung mehr mache, würde mich interessieren ob die derzeitige ISA dafür nicht ausreicht.
Kann jemand von euch das verifizieren? Es würde erklären, warum jetzt auf einmal Microcode-Updates nötig werden und es vorher nicht klar war:
Da ich keine hardwarenahe Programmierung mehr mache, würde mich interessieren ob die derzeitige ISA dafür nicht ausreicht.
AW: Spectre: AMD benötigt auf Windows Microcode-Updates, auf Linux nicht
AMD hat ebenfalls von der Lücke gewusst. Dein Punkt ist also welcher - Intel ist schlimmer weil sie das selbe wie AMD machen?
Und danke das du meinen Kommentar so schön bestätigst . keine Ahnung haben, aber über andere Aufregen. Leis doch mal nach was die 'Fachmenschen' von heise geschrieben haben XD dein 'fachmenschen' passt ja schon fasst - viel Ahnung haben sie jedenfalls nicht, lies dir doch lieber die richtigen Dokumentationen zu der Sicherheitslücke durch, von Google, Amazon und co. die haben wohl genügend Ahnung, brauchst da nicht auf mich hören - der das Thema nur seit 9 Monate kennt und Live-Demos auf AMD Systemen gesehen hat
Deine Einschätzung ist also ziemlich fern ab der Wirklichkeit.
Damit ist das kalr eine Falschaussage. Nicht in dem Ausmaß wie Intel gelogen hat, trozdem finde ich es doch sehr erstaunlich wie sehr du hier versuchst den Tatsachenbestand zu verzerren.
Da miss ich mich dann ja fragen - macht das dann nicht dich nach deinen Eigenen Aussagen zu einem Intel-white-knight oder warum das Doppelmaß in deiner beurteilung mir gegenüber?
Intel hat es Probiert und ist schön von einem Fettnäpfchen ins nächste und dann noch mit dem Kopf gegen die Wand gerannt beim versuch Spectre einzudämmen. AMD hingegen sagt sie seien nur teilweise betroffen und dort wäre das Risiko angeblich beinahe 0 - nur um dann eingestehe zu müssen das Spectre bei ihnen die exakt selben Ausmaße hat wie bei Intel. PR-Technisch deutlich besser natürlich da die wenigsten diese Kehrtwende mitbekommen.
Der Unterschied zwischen deinem und Meinem verhalten hier ist recht Deutlich. Ich habe mir die Papers von Anfang an durchgelesen, ich bin mit Spectre seit nun fast 9 Monaten vertraut - habe noch die Initialen code-Revisions zu den Ersten Funden gesehen. Und ja, so lange schon gibt es schon die Grundlage zu den Angriffen, damals war den beteiligten Programmieren aber nicht klar das der von ihnen Entdeckte Sidechannel derartig leicht ausgenützt werden kann.
AMD hat ebenfalls von der Lücke gewusst. Dein Punkt ist also welcher - Intel ist schlimmer weil sie das selbe wie AMD machen?
Und danke das du meinen Kommentar so schön bestätigst . keine Ahnung haben, aber über andere Aufregen. Leis doch mal nach was die 'Fachmenschen' von heise geschrieben haben XD dein 'fachmenschen' passt ja schon fasst - viel Ahnung haben sie jedenfalls nicht, lies dir doch lieber die richtigen Dokumentationen zu der Sicherheitslücke durch, von Google, Amazon und co. die haben wohl genügend Ahnung, brauchst da nicht auf mich hören - der das Thema nur seit 9 Monate kennt und Live-Demos auf AMD Systemen gesehen hat
Wenn du das so empfindest. Klar - ich hab von Anfang an Lieber die Wahrheit gesagt - das eben AMD von Spectre genauso betroffen ist wie intel, nicht aber von der (fast)Intel-exklusiven Variante MeltDown die auch das auslesen von kernel-Speicher erlaubt. Auch das Spectre über javascripts oder öhnlichen code relativ langsam, wenn aber dediziert auf eine CPU zugeschnitten auch schnell genug zum Streamen sein kann. und nie habe ich gesagt Intel hätte ncihts Faalsch gemacht - das gegenteil ist hier der Fall.
Deine Einschätzung ist also ziemlich fern ab der Wirklichkeit.
Was nicht stimmt. AMD ist von Spectre voll betroffen, genauso wie Intel und ARM. Der einzige Unterschied ist das sich die Entwickler eben mehr auf Intel konzentriert haben - verständlich wenn die ersten Entwürfe dazu von vor 9 Monaten noch nicht wirklich was mit RyZen zu tun hatten sondern ältere Xeons and die FX-Serie zur Verfügung hatten - sie haben dort auch extra erwähnt das sie das ganze dann auf die intel Architektur zugeschnitten haben weil diese eine überwältigende Marktfüllung besitzen - im Gegensatz zur beinahe Randerscheinung FX.
Nur das Googles Team schon vor AMDs Statement bewiesen hat das RyZen von Spectre genauso betroffen ist und es keinen Unterschied im Bezug auf Sicherheit dort gibt.
Damit ist das kalr eine Falschaussage. Nicht in dem Ausmaß wie Intel gelogen hat, trozdem finde ich es doch sehr erstaunlich wie sehr du hier versuchst den Tatsachenbestand zu verzerren.
ja? und? Was war meine Aussage dazu - ach ja: sie haben Technisch gesehen nichts falsches gesagt, aber wie sie es Ausgedrückt haben ist einfach nur Schäbig und Unterste Schublade.
Da miss ich mich dann ja fragen - macht das dann nicht dich nach deinen Eigenen Aussagen zu einem Intel-white-knight oder warum das Doppelmaß in deiner beurteilung mir gegenüber?
Ah, es ist also besser so wie AMD zu reagieren - garnicht?
Intel hat es Probiert und ist schön von einem Fettnäpfchen ins nächste und dann noch mit dem Kopf gegen die Wand gerannt beim versuch Spectre einzudämmen. AMD hingegen sagt sie seien nur teilweise betroffen und dort wäre das Risiko angeblich beinahe 0 - nur um dann eingestehe zu müssen das Spectre bei ihnen die exakt selben Ausmaße hat wie bei Intel. PR-Technisch deutlich besser natürlich da die wenigsten diese Kehrtwende mitbekommen.
nach Deiner 'logik' ja. Ich würd ja einfahc nur sagen du hast ne Starke Meinung zu nem Thema wo du ähnlich viel weist wie von Ungarischen Volkstänzen.Bin ich jetzt auch einer dieser Fanboys?
Der Unterschied zwischen deinem und Meinem verhalten hier ist recht Deutlich. Ich habe mir die Papers von Anfang an durchgelesen, ich bin mit Spectre seit nun fast 9 Monaten vertraut - habe noch die Initialen code-Revisions zu den Ersten Funden gesehen. Und ja, so lange schon gibt es schon die Grundlage zu den Angriffen, damals war den beteiligten Programmieren aber nicht klar das der von ihnen Entdeckte Sidechannel derartig leicht ausgenützt werden kann.
G
Grestorn
Guest
AW: Spectre: AMD benötigt auf Windows Microcode-Updates, auf Linux nicht
Ich habs weiter oben schon mal geschrieben, aber da nicht jeder alles liest, hier nochmal:
Es gibt einen Weg, die aktuellen Spectre-Angriffe abzuwehren, in dem man in Kernel-Routinen generell auf sog. relative Branches verzichtet (also eine Verzweigung dessen Ziel abhängig vom aktuellen Stand des PC (Program Counter) ist. Dieses Verfahren wird "retpoline" genannt. Auf die kann man sehr leicht verzichten ohne messbar Performance zu verlieren. Und der Vorteil ist, dass man nur dem Compiler per Option sagen muss, dass er die nicht einsetzen soll. Man muss keine einzige Zeile Code (abgesehen vom Compiler) dafür ändern.
In Linux wurde also einfach der gesamte Kernel mit dieser Option neu übersetzt. Ebenso alle OpenSource-Kerneltreiber. Closed Source Kernel-Treiber allerdings vom jeweiligen Hersteller neu erstellt werden (z.B. nVidia).
In Windows ist dieser Ansatz nicht machbar, weil MS einfach keine Kontrolle über die immense Zahl an Closed-Source Kernel-Treiber und -Tools hat, dies es gibt. Hier rächt sich ausnahmsweise mal die Tatsache, dass unter Windows in der Regel Closed Source eingesetzt wird, im Gegensatz zu Linux, wo doch der größte Teil OSS ist.
Ich habs weiter oben schon mal geschrieben, aber da nicht jeder alles liest, hier nochmal:
Es gibt einen Weg, die aktuellen Spectre-Angriffe abzuwehren, in dem man in Kernel-Routinen generell auf sog. relative Branches verzichtet (also eine Verzweigung dessen Ziel abhängig vom aktuellen Stand des PC (Program Counter) ist. Dieses Verfahren wird "retpoline" genannt. Auf die kann man sehr leicht verzichten ohne messbar Performance zu verlieren. Und der Vorteil ist, dass man nur dem Compiler per Option sagen muss, dass er die nicht einsetzen soll. Man muss keine einzige Zeile Code (abgesehen vom Compiler) dafür ändern.
In Linux wurde also einfach der gesamte Kernel mit dieser Option neu übersetzt. Ebenso alle OpenSource-Kerneltreiber. Closed Source Kernel-Treiber allerdings vom jeweiligen Hersteller neu erstellt werden (z.B. nVidia).
In Windows ist dieser Ansatz nicht machbar, weil MS einfach keine Kontrolle über die immense Zahl an Closed-Source Kernel-Treiber und -Tools hat, dies es gibt. Hier rächt sich ausnahmsweise mal die Tatsache, dass unter Windows in der Regel Closed Source eingesetzt wird, im Gegensatz zu Linux, wo doch der größte Teil OSS ist.
AW: Spectre: AMD benötigt auf Windows Microcode-Updates, auf Linux nicht
Grad Heise ist bei diesem Thema sehr negativ aufgefallen!
yummycandy
Software-Overclocker(in)
AW: Spectre: AMD benötigt auf Windows Microcode-Updates, auf Linux nicht
Jaein. Alle Intels ab Skylake würden einen Performanceeinbruch hinnehmen müssen. Ältere CPUs und AMDs nicht. Auch aus diesem Grund stand das nie zur Wahl.
Jaein. Alle Intels ab Skylake würden einen Performanceeinbruch hinnehmen müssen. Ältere CPUs und AMDs nicht. Auch aus diesem Grund stand das nie zur Wahl.
AW: Spectre: AMD benötigt auf Windows Microcode-Updates, auf Linux nicht
Die Microcode-Updates arbeiten mit der Software zusammen. Ein Schutzansatz (Retpoline) trickst die Sprungvorhersage aus, um Spectre auszuhebeln und kann rein in Software implementiert werden. Die Lösung wurde für den Linux-Kernel angewendet. Eine andere nutzt eine Befehlssatzerweiterung, die dem Betriebssystem direkte Kontrolle über Teile der Sprungvorhersage bietet und erfordert somit CPUs respektive Microcode-Updates, die diese neuen Befehle beinhalten. Microsoft nutzt zumindest im Moment letztere Variante, so dass Windows auf angepasste Hardware angewiesen ist. Wie oben schon dargelegt, gilt dies aber nur für die Betriebssysteme selbst. Gegen Spectre muss aber auch jede einzelne Anwendung geschützt werden, so dass Linux-PCs gegebenenfalls auch neuen Microcode brauchen.
Die bisherigen x86-Befehlssätze sehen keine direkte Kontrolle der Sprungvorhersage durch Software vor. Es handelt sich auch um eine geradezu absurde Situation: Man hat ein Bauteil, dass aus Sicht der Software vollkommen unsichtbar agiert und in seiner Arbeit gar nicht auf explizite Software-Anweisungen warten kann und jetzt möchte/muss man diesem Bauteil auf einmal direkt Befehle erteilen.
Bei den vielen Kommentaren ist es schwierig heraus zu lesen, wo denn nun die Wahrheit liegt ...
Daher mal eine einfache Frage von mir: wenn der Hardwareentwickler und -hersteller Schuld ist, warum braucht Linux dann kein Microcodeupdate, Windows hingegen schon?
Mir persönlich ist es eigentlich total Wurscht, wie die beiden Betriebssysteme intern organisiert oder aufgebaut sind; Fachsimpeln über die Ursachen überlasse unseren Betriebssystementwicklern und -programmierern hier. Meine Frage ist im Prinzip sehr schlicht gehalten: warum ist es Softwareabhängig? Das passt für mich irgendwie nicht.
Die Microcode-Updates arbeiten mit der Software zusammen. Ein Schutzansatz (Retpoline) trickst die Sprungvorhersage aus, um Spectre auszuhebeln und kann rein in Software implementiert werden. Die Lösung wurde für den Linux-Kernel angewendet. Eine andere nutzt eine Befehlssatzerweiterung, die dem Betriebssystem direkte Kontrolle über Teile der Sprungvorhersage bietet und erfordert somit CPUs respektive Microcode-Updates, die diese neuen Befehle beinhalten. Microsoft nutzt zumindest im Moment letztere Variante, so dass Windows auf angepasste Hardware angewiesen ist. Wie oben schon dargelegt, gilt dies aber nur für die Betriebssysteme selbst. Gegen Spectre muss aber auch jede einzelne Anwendung geschützt werden, so dass Linux-PCs gegebenenfalls auch neuen Microcode brauchen.
Die bisherigen x86-Befehlssätze sehen keine direkte Kontrolle der Sprungvorhersage durch Software vor. Es handelt sich auch um eine geradezu absurde Situation: Man hat ein Bauteil, dass aus Sicht der Software vollkommen unsichtbar agiert und in seiner Arbeit gar nicht auf explizite Software-Anweisungen warten kann und jetzt möchte/muss man diesem Bauteil auf einmal direkt Befehle erteilen.
rum
BIOS-Overclocker(in)
AW: Spectre: AMD benötigt auf Windows Microcode-Updates, auf Linux nicht
Dann korrigiert bitte meine Konklusion, sofern sie denn falsch ist: man "kann" mit Microcode Abhilde schaffen, jedoch benötigt man "immer", also auch in Fällen ohne Microcodeupdate, "softwareseitige Unterstützung"?
Wenn meine Konklusion stimmt, haben die Hardwarehersteller etwas gemacht, was nicht immer rein über Hardwareupdates gelöst werden kann, obwohl sie schon vorher wussten, dass unter bestimmten Bedingungen eben dieser Fall eintritt, es also softwareseitig Updates geben muss, sie jedoch den Informationsfluss darüber in Richtung der Softwarehersteller nicht hergestellt haben? Wenn das stimmt, dann sehe ich hier (für mich) so etwas wie eine "Sorgfaltspflichtverletzung" bzw. eine (teilweise) weg gelassene Qualitätssicherung bezogen auf die eventuell zu erwartenden Probleme in den Gesamtsystemen, in welchen die CPU halt nur ein Teil der Hardware ist?
Ich denke aber auch, dass ich zu wenig Ahnung in dieser Materie haben
Dann korrigiert bitte meine Konklusion, sofern sie denn falsch ist: man "kann" mit Microcode Abhilde schaffen, jedoch benötigt man "immer", also auch in Fällen ohne Microcodeupdate, "softwareseitige Unterstützung"?
Wenn meine Konklusion stimmt, haben die Hardwarehersteller etwas gemacht, was nicht immer rein über Hardwareupdates gelöst werden kann, obwohl sie schon vorher wussten, dass unter bestimmten Bedingungen eben dieser Fall eintritt, es also softwareseitig Updates geben muss, sie jedoch den Informationsfluss darüber in Richtung der Softwarehersteller nicht hergestellt haben? Wenn das stimmt, dann sehe ich hier (für mich) so etwas wie eine "Sorgfaltspflichtverletzung" bzw. eine (teilweise) weg gelassene Qualitätssicherung bezogen auf die eventuell zu erwartenden Probleme in den Gesamtsystemen, in welchen die CPU halt nur ein Teil der Hardware ist?
Ich denke aber auch, dass ich zu wenig Ahnung in dieser Materie haben
Tekkla
BIOS-Overclocker(in)
AW: Spectre: AMD benötigt auf Windows Microcode-Updates, auf Linux nicht
Und hat damit nie hinterm Berg gehalten. Es wurde stets betont, dass es ältere CPUs mehr betrifft als die neueste Generation, deren andere CPU Architektur es unlängst schwerer mach diese Lücke auszunutzen.
Ähnliche Themen
