News Meltdown & Spectre: Details und Bench­marks zu den Sicherheits­lücken in CPUs

MADman_One schrieb:
Aber anschließend müssen alle Fakten schleunigst auf den Tisch, damit die Verbraucher sich schützen können. Ich werde bei mir keine Sicherheitslücke durchschleppen nur um Performance zu retten.

deine einstellung finde ich gut. ehrlich gesagt klappere ich mit den anderen intel usern auch mit den zähnen und das, obwohl ich AMD user bin. aber mir ist klar, daß nichts sicher ist, was irgendwie an einem netzwerk hängt und eine meiner komponenten könnte morgen vielleicht genauso betroffen sein. ich hoffe sehr, im produktiven einsatz ist der bug nicht zu schlimm und nervt nicht. denkt mal an die ganzen neuen spiele, wenn die plötzlich nur noch mit 10 fps liefen - desaster.

aber nichts wird so heiß gegessen, wie es gekocht wird. abwarten und tee trinken.
 
Zuletzt bearbeitet:
CS74ES schrieb:
Vorausgesetzt es waren nicht Leute von AMD, die gezielt gesucht haben, um Intel eins reinzudrücken. "Also bei uns gibts ja sowas nicht^^" (zutrauen würde ich es AMD)

Aber Intel verfolg tatsächlich eine schlechte Nachricht nach der anderen, ist schon komisch.

Erstens ist es komplett wurscht, ob AMD diese Fehler gezielt suchen, wenn sie da sind muss etwas getan werden. Aber diese kuenstliche Hetze ("zutrauen wuerde ich es AMD") ist doch genau so schamlos wie die Annahme.

Und Intel hat seine Probleme, aber 2017 war doch recht erfolgreich und es wurde einiges an Produkt aus der Tuer geschoben was gut ankam. Ich glaube nicht, das man das als "eine schlechte Nachricht nach der anderen" klassifizieren kann.

Ich selber frage mich eher, ob die patches die fuer Windows kommen, ausgeschaltet werden koennen. Sollte der fix tatseachlich 5%+ performance kosten und ich mit den Sicherheitsluecken leben kann, will ich das gerne ausschalten. Und meine Lieblingsspiele laufen nicht gut unter Linux, also ist das keine Alternative.
 
Steffen schrieb:
Ich habe übrigens mal auf meinem Notebook mit Intel Core i7-4600U (3½ Jahre alt) Linux 4.15-rc6 mit Page-Table Isolation kompiliert.
...
Ich konnte aber in keinem auf Anhieb lauffähigen Benchmark Abweichungen außerhalb der Messungenauigkeit festellen
...
Ich glaube eigentlich nicht, das ich irgendwas falsch gemacht haben könnte (das Boot-Log sagt ja eindeutig ob PTI aktiviert ist oder nicht) aber dass meine Messungen wirklich gar keinen Unterschied zeigen macht mich dann schon stutzig.
...
Ich hätte gedacht, dass man einen kleinen Unterschied auch bei anderen Benchmarks sehen sollte.

danke für die Info. Bin mal gespannt was noch so bei rumkommt.
 
MADman_One schrieb:
AMD sagt dazu:
The AMD microarchitecture does not allow memory references, including speculative references, that access higher privileged data when running in a lesser privileged mode when that access would result in a page fault.

Möglicherweise haben sie einfach genauer gearbeitet was die Security Layer angeht. Bisher ist es meines Wissens nur eine Aussage, ich weiss nicht ob es schon genau getestet wurde.

Da hat Intel wohl ziemlich rum optimiert um spekulative Zugriffe nicht verwerfen zu müssen wenn die nicht zum Kontext des Prozesses oder des Kernels passen.

Pech gehabt, das kann ganz böse ins Auge gehen.

Und wenn MS schon länger daran fummelt wird ein µ-code Update wohl nicht in Frage kommen, evtl. eins was den Performance Impact möglicherweise etwas lindert.
 
Boah Leute ... Intel nutzt AMD GPU Technik in den neuen APUs .. wieso sollten sich die beiden aktuell gegenseitig zerfleischen?

Ich gönne es Intel dennoch, mal so richtig fett auf die Schnauze zu fallen.
Die Marktmanipulation der Vergangenheit war nicht korrekt.
Die Million Strafzahlung, ein Witz.
 
Im PCGH Forum schreibt einer das ARM64 ebenfalls betroffen sein soll. https://lwn.net/Articles/740393/
Ich kann kein englisch daher halte ich mich mit einer Meinung zurück, aber wie beurteilt ihr das?
Hat Intel ggf. ein Fertigungsproblem?
 
Der verlinkte Patch ermöglicht die Nutzung von PTI auch unter ARM64. Ohne Weiteres würde ich aber erstmal davon ausgehen, dass das auch einfach eine Vorbereitung für den potenziellen Fall sein könnte, dass zukünftig eine solche Sicherheitslücke auch in ARM-Chips gefunden wird. Damit man dann nicht in Hektik verfallen muss, sondern eine fertige Lösung hat.
 
JZedtler schrieb:
Im PCGH Forum schreibt einer das ARM64 ebenfalls betroffen sein soll. https://lwn.net/Articles/740393/
Ich kann kein englisch daher halte ich mich mit einer Meinung zurück, aber wie beurteilt ihr das?
Hat Intel ggf. ein Fertigungsproblem?

Das hat nun gar nichts mit der Fertigung zu tun, sondern mit Sicherheitsinstanzen in der CPU, die es "erlauben" als einfacher "User" auf wesentlich höhere Instanzen zuzugrfeifen.
 
Danke für die Antworten. Ich dachte halt weil Intel Auftragsfertiger für ARM ist.:)
 
Der soeben veröffentliche stabile Linux Kernel 4.14.11 enthält die vollständigen PTI-Patches (Config-Option CONFIG_PAGE_TABLE_ISOLATION): Linux Kernel (Download)

Und jemand hat Benchmarks der PostgreSQL-Datenbank mit PTI gemacht und rund 7% Leistungseinbußen festgestellt: https://lkml.org/lkml/2018/1/2/678
 
Zuletzt bearbeitet:
Wie sieht es denn mit Kernelpatches für die entsprechenden Distributionen wie z.B. Mint aus?
 
Naja, gibt leider keine genauen Daten über das Problem. Wird wohl eine spekulativer Prefetch sein bei dem die Daten erstmal geladen werden (TLB-Enträge erzeugen (wenn nicht vorhanden) und dann in den Cache geschrieben werden). Beim Lesezugriff wird dann wohl im Cache kein Privileglevel pro Eintrag/Zeile vorhanden sein (oder funktioniert nicht) und man kann die Daten lesen. Wenn es ganz blöd kommt, kann man evtl. auch die Daten im Cache modifizieren (solange write back, kein flush, Zeilen-Miss, … ) und dann hoffen, dass sie beim Switch in einen höheren Level geflusht werden :o

Um den gegenzusteuern wird wohl nach (evtl. auch vor) einem Syscall (alle TLB-Einträge auf invalid gesetzt).

Ist natürlich klar, dass du -s viel File-IO (Syscalls) betreibt und deswegen wohl unter dem Fix leidet.

Wundert mich etwas, dass es erst jetzt bemerkt wird … da es ja angeblich alle Intel CPUs betrifft (und die gibt's angeblich schon länger :watt: )
 
Seit SandyBrige haben sich an der CPU Architektur nur kleine Sachen geändert. Seit Skylake gab es gar keine Architekturänderungen mehr, sondern nur noch Verbesserungen in der Fertigung.
 
Steffen schrieb:
Ich glaube eigentlich nicht, das ich irgendwas falsch gemacht haben könnte (das Boot-Log sagt ja eindeutig ob PTI aktiviert ist oder nicht) aber dass meine Messungen wirklich gar keinen Unterschied zeigen macht mich dann schon stutzig.

Postiv Kontrolle ist das Stichwort. Es gibt ja aussagen welche Benches betroffen sind. Kein Unterschied erscheint in der Tat unlogisch.
 
Naja, mich würde viel mehr interessieren (wie viele andere wahrscheinlich auch) in wie weit das ganze dann Auswirkungen für Otto-Normal Verbraucher hat. Weil Leistungsverluste in irgendwelchen Benches oder Szenarien die für mich nicht/kaum vor kommen ist mir da logischerweise egal.
Klar sind hier auch professionelle unterwegs die ganz anderes Einsatzgebiet haben.

Aber da heißt es wohl einfach mal abwarten bis das "gefixt" wurde und entsprechend Tests dann veröffentlicht werden.
 
Da bin ich ja mal wirklich gespannt, was am Ende dabei rauskommt. Vermutlich sind die Annahmen der Redaktion (herausragender Artikel!) allesamt korrekt und der Patch wird im nächsten Patchday ausgerollt.
 
Man wird sehen, was sich so ergibt.
Auch wenige % in Serveranwendungen sind ein harter Brocken. Das könnte Intel wirklich schaden.
Die Privatanwender werden Intel egal sein. Die wissen davon nichts oder verstehen davon nichts oder kaufen trotzdem Intel.....oder sie sind in der Minderheit(dieses Forum z.B.).....und da müssen diese entweder mit Leistungverlusten leben oder halt mit weniger Sicherheit.....zweites freut die Geheimdienste....daher durchaus möglich;):

Wenn normale Benchmarks keine Einbußen zeigen, wäre es wiederum kein Problem die PTI-Patches dauerhaft zu nutzen.....oder es wird ein dynamisches An- und Abschalten betrieben.

Ich bin sehr gespannt wie es weiter geht.
 
Zurück
Oben