Nein. Intel mappt den Kernel-Speicher in den Speicherbereich des Nutzers, damit der Zugriff beschleunigt ablaufen kann. Soweit ich das nun korrekt mitbekommen habe, macht das AMD nicht, und ARM wohl nur beim neuesten Modell. Die Kernel-Speicherinhalte sind bei Intel jedoch in einem "geschützten" Bereich - leider ist dieser "Schutz" aber unwirksam. Der saubere Fix bedeutet, dass man die Adressbereiche physisch trennt, damit man erkennen kann, woher der Zugriff kommt. Aktuell geht das nicht und dafür müsste man eine neue Architektur entwickeln.
Die andere Möglichkeit wäre, das Ding so zu fixen, wie es jetzt wohl in Software gefixt wurde. Ob das in der CPU ohne Architekturänderung geht, weiß ich nicht, aber wenn ja, wird es sicherlich sehr viel komplexer sein, als Du es Dir jetzt vorstellst. Wie bereits geschrieben, kann man nicht so leicht feststellen, dass der Zugriff aus dem Nutzerumfeld kommt, weil es die gleichen Adressen sind. Beides kostet wahrscheinlich Leistung und ist höchstwahrscheinlich auch ein Mitgrund, warum Intel-Prozessoren gegenüber AMD-Prozessoren in der Vergangenheit für Datenbanken etc. mit mehr I/O-Leistung und geringeren Latenzen glänzen konnten. Es ist durchaus wahrscheinlich, dass sie diesen Vorteil durch das Beheben der Sicherheitsprobleme wieder teilweise einbüßen. (Bei Datenbanken wie PostgreSQL sind nach dem Softwarefix Performanceeinbußen von ca. 20% aufgetreten).
Es ist mühsam über derartige Details zu sprechen, da ich nach all den Kommentaren der letzten Zeit der Meinung bin, du hast an Softwareentwicklung, vor allem in derartigen Tiefen, keine Anteile. Das Verhalten bei AMD ist ähnlich. Bei AMD - weswegen AMD von architektonischer Differenz spricht -> wirft ein Access auf höher priviligierte Speicher aber sofort eine Exception. Bei Intel wird die Exception später geworfen - dies lässt sich dahingehend angreifen eben WEIL man gezielt Abbruchbedingungen in Schleife laufen lässt und sich der OoO Ausführung bedient - gepaart mit nem Offset Speicherbereiche zu lesen die nicht gelesen werden dürften. Intel betont hierbei klar, es funktioniere genau so wie es soll...
"Vulnerable CPUs: This attack requires that the CPU fails to promptly check security flags while performing L1 D-cache loads for a speculatively-executed instruction. Various Intel CPUs (everything from Nehalem and Silvermont onwards, including Coffee Lake and Xeon Phi) are vulnerable. AMD CPUs are not vulnerable."
Aus dem Whitepaper entnimmst du den Part zu Intel - und wenn nötig auch mehr Background über die Funktionsweisen.
Leider gibt sich Intel an der Stelle zwar einsichtig scheint aber zu versuchen das nicht als Hardwarefehler zu sehen. Kann man sicher drüber streiten
"Ob das in der CPU ohne Architekturänderung geht, weiß ich nicht, aber wenn ja, wird es sicherlich sehr viel komplexer sein, als Du es Dir jetzt vorstellst."
Du hast keinen Plan, gestehst dir das selbst ein, aber damit deine Aussage Rund wird behauptest du, es sei sicherlich komplexer als ich es mir vorstelle? Im Grunde beschreibe ich aber nur das, was AMD im Endeffekt macht(e). Nämlich das, siehe oben, sofortige Abfangen. Ich sehe hier keinen Grund zu einer vollständigen Architekturänderung. Da du ihn aber sehen willst - bitte ich dich doch einfach darzulegen an welcher Stelle die für dich zu einer Architektuänderung führen sollte und vor allem, warum dies ensprechend nicht in 6 Monaten +- x durchführbar sein sollte.
Aus meiner Sicht, entweder du urteilst objektiv - dann kannst du es begründen, oder eben nicht. Dann ists Wunschvorstellung, Einbildung oder ähnliches... Einfach zu behaupten - derartiges steht seit Jahren fest. Nunja, Stammtischargument, noch dazu eins, was sich nicht belegen geschweige denn widerlegen lässt. Und nur weil es möglicherweise dann doch eintritt oder eben gerade nicht - macht das schmücken mit so einer Diskusionsweise auch nicht gerade objektiv...
PS: auch wenn es nichts mit dem Thema zu tun hat:
Der Postgres Kommentar respektive das Bilden des Zusammenhangs ist auch nicht ganz treffend. Der Performanceverlust kommt durch das Kontextswitching. Vorher - ohne Fix - ging das schnell. Nach dem Switch MUSS der Speicher erst bemüht werden, die Daten wurden entsprechend ja entfernt, damit es nicht abgreifbar ist. Ich sehe da keinen Zusammenhang mit der AMD Umsetzung, zumal auch - nach Whitepaper auch die AMD Umsetzung den Speicher mappt, was das notwendige Switchen eben schnell macht. Deswegen sprach ich auch von dirty Workarround - es ist im Moment die Brechstangenmethode. Kritisiert im übrigen auch Kollege Torvalds...
Hast Du dafür vielleicht einen Link zum Originalzitat? Ich könnte mir gut vorstellen, dass es so formuliert war, dass alle CPUs, die 2018 designed werden, diesen Fix haben. Und zweitens muss man bedenken, dass Intel den Core H mit Vega-GPU schon letztes Jahr angekündigt hat. Da muss man auch differieren, wann Intel ein Produkt als "herausgekommen" sieht, und wann das der Leser des Statements sieht, wenn sie das Wort "herauskommen" benutzt haben. Nehmen wir mal an, es war "appear" im englischen, dann ist das auf Deutsch "in Erscheinung treten" und wenn Intel 2017 sagt, wir werden ab 2018 Core Hs mit Vega verkaufen, dann ist er schon 2017 "in Erscheinung getreten". Man sollte nie vergessen, dass das PR-Aussagen sind und die sind häufig mit Finessen gespickt, die am Rande der Legalität sind.
Stand im Luxx-Artikel - mittlerweile aber revidiert, leider aber in irgend nem Update mittendrin. Also nicht ganz direkt ersichtlich wann genau. Glaube Update 5 war es, was angepasst wurde...
Siehe Ausführung von unl34shed. Aber auch hier das gleiche, du wusstest selbst nichts davon. Warst ohne Faktenbasis aber überzeugt von der Nichtmachbarkeit? Zumindest soweit überzeugt eine Wahrscheinlichkeit zu beziffern?
Das Wiegen der Übersetzung oder Bedeutung auf der Goldwage stand übrigens nicht zur Debatte. Auch WENN es durch die korrekte Aussage nun klar unwahrscheinlicher ist, bleibt es immerhin im Rahmen des möglichen. Weiterhin gilt, abwarten. Wie bei jedem Release - meckern kannste doch immernoch? Warum nicht lieber über das Thema als solches diskutieren - anstatt hier Fehler einseitig zu suchen? Siehe oben, ist so ziemlich der Kritikpunkt meines Posts ggü. den deinigen der letzten Zeit.
Edit: Ich hoffe, dass AMD und ARM den Spectre-Bug einfacher und schneller beheben können, als Intel den Meltdown aussitzen muss, sonst gibt es erst mal keine gescheiten CPUs mehr zu kaufen
Ironischerweise ist der dirty Workarround in Software zwar dreckig ohne Ende, dafür aber wirksam. Technisch gesehen kann ein gepatchtes System über diesen Weg nicht angegriffen werden, weil mit Workarround nix mehr zum abgreifen geladen ist. Der Spectre Bug in beider Form wirkt dahingehend eher problematisch, weil es eher ein "works as designed" ist - in wie weit uns das die nächsten Monate und Jahre begleiten wird, ist völlig offen. Nach bisherigen Erkenntnissen ist ein Hardwarefix für diese Lösung eher schwer möglich. Hier müsste man aber - siehe oben, mehr Details kennen.
Nach der Ausführung der Inteljungs gibts dafür von Intel auch keinen fix in Hardware - eher baut man auf das Zusammenspiel von Firmwareanpassungen und Softwareupdates.
Übrigens, diese Aussage ist ja doch objektiv
imun gemacht wird... RavenRidge dürfte nicht geklappt haben zeitlich, ausgeschlossen ists aber nicht. Vllt wurde der Desktop deswegen verzögert um die drei Monate?
