News Prozessorgerüchte: Mehr Coffee Lake mit 2 bis 12 Threads für PC und Notebook

[Baal Netbeck]

Ich hab gestern meinen alten i5 3570K über die Powershell geprüft und die Leistung verglichen.
Ich konnte die 4K Schwäche in as ssd nachstellen.
Problematisch finde ich, dass die Powershell das System auch Meltdown sicher nennt, wenn ich per reg Eintrag den Fix umgehe.

 

[kisser]

Das ist so nicht korrekt.

Nur zum Verständnis …
Die explizite Lücke Meltdown ist nicht neu, nicht mal so ein bisschen. Wer das trotz offensichtlich anders lautender Quellen noch immer behauptet, weiß es entweder nicht besser, oder aber unterschlägt diese Fakten wissentlich und mutwillig.

Diese Behauptung kannst du dann sicher auch mit Quellen belegen!

 

[aldaric]

@kisser:

Bist du in der Lage seinen Post zu lesen zu den Blackhat-Links ? Oder ist das zu viel verlangt?

Immer süß, wie du nach Quellen schreist, dabei hat er sie schon geliefert. Diskussionskultur kann halt nicht jeder.

 

[kisser]

Hat man die Patches dann bewusst weggelassen, weil (noch) kein tatsächlicher Exploit möglich war bzw. bekannt war oder weil man wusste dass man dadurch Performanceeinbußen zum Marktstart von CL hat?

Weder noch! So etwas patched man nicht mal so nebenbei in 5 Minuten.
Änderungen am Microcode sind recht kompliziert und in diesem speziellen Fall muss ja das Betriebssystem auch auf die Änderungen angepasst werden. Das ist eine Arbeit von Monaten.

Ergänzung (18. Januar 2018)

@kisser:

Bist du in der Lage seinen Post zu lesen zu den Blackhat-Links ?

Äpfel & Birnen?
Ich habs gelesen. Hat nur nichts mit der aktuellen Thematik zu tun.

Kann es sein, dass du keinen blassen Schimmer über CPU-Architektur hast?

 

[Valeria]

Ein i5-8xxxHH 6K/6T 3Ghz+ 35-45W für einen guten Preis (<800€ Notebooks) wäre was feines.

 

[Smartcom5]

Diese Behauptung kannst du dann sicher auch mit Quellen belegen!

… was ich getan habe, ehe Du deine Frage überhaupt formuliert hast, korrekt.

…Äpfel & Birnen?
Ich habs gelesen. Hat nur nichts mit der aktuellen Thematik zu tun.

Kann es sein, dass du keinen blassen Schimmer über CPU-Architektur hast?

Ja richtig …
Nein, hat überhaupt nichts mit der aktuellen Thematik zu tun!
Die ganze Thematik rührt kausal daher und Kernel page-table isolation (KPTI) oder wahlweise Kernel Address Space Layout Randomization (KASLR) ist der kausale und eigentliche Fix, um die hier so brisante Thematik zu negieren, wobei Kernel Address Isolation to have Side-channels Efficiently Removed (KAISER) zudem eine weitere Verbesserung von KASLR darstellt.

Junge kisser, bei allem gegebenen Respekt; Zwing‘ mich nicht dazu, Dich zu fragen, ob Du dumm bist!
Entweder bist Du mittlerweile derart verblendet, daß Du gar nichts mehr mitbekommst, oder aber Du weißt darum und legst trotz alledem Zeugnis wider besseren Wissens ab, indem Du hier ganz offensichtlich belegbare Fakten als unwahr darstellst. Deine Aussage „Hat nur nichts mit der aktuellen Thematik zu tun.“ ist schlicht falsch, wahrheitswidrig oder kurzum und salopp: Lüge.

… womit Du einmal mehr eindrucksvoll unter Beweis gestellt hast, das Du unter Betroffene fällst, denen Du „keinen blassen Schimmer über CPU-Architektur“ bescheinigst.
Einen schönen Tag wünsche ich.


In diesem Sinne

Smartcom

 

[xexex]

Die ganze Thematik rührt kausal daher und Kernel page-table isolation (KPTI) oder wahlweise Kernel Address Space Layout Randomization (KASLR) ist der kausale und eigentliche Fix, um die hier so brisante Thematik zu negieren, wobei Kernel Address Isolation to have Side-channels Efficiently Removed (KAISER) zudem eine weitere Verbesserung von KASLR darstellt.[/ATTACH]

Jetzt wirfst du aber Begriffe durcheinander, die so nicht zusammen passen.

ASLR gibt es schon etwas länger. Es wurde eingeführt um klassische Buffer Overflow Angriffe abzuwehren, da mit der Randomisierung der Adressen im Speicher, es nicht mehr möglich ist mit einem einfachen Angriff eine bestimmte und immer gleiche Adresse aufzurufen.
https://de.wikipedia.org/wiki/Address_Space_Layout_Randomization

Um dies zu umgehen wurde an Möglichkeiten "geforscht" wie man den gesamten Speicher durchsuchen kann und die Adressen herausfindet. Dabei hat man Side-Channel Angriffe verwendet, die schon seit Jahren bekannt sind (1992 zu ersten mal erwähnt, 1996 zu ersten mal demonstriert).
https://de.wikipedia.org/wiki/Seitenkanalattacke

Es wurde bereits seit Jahren heiß diskutiert, dass grosser L3 Cache, den sich viele Prozesse teilen, eine Sicherheitslücke darstellt.
https://www.usenix.org/node/184416

Im Jahr 2016 wurde gezeigt wie es möglich ist mithilfe von Intel TSX, relativ viel Daten in relativ kurzer Zeit zu ergattern. Mit TSX sind ja laut den Unterlagen der Meltdown "Forscher" 500KB/s möglich ohne TSX ist es denen gelungen lediglich 123KB/s an Daten auszulesen. Die Geschwindigkeit ist wichtig, weil man ja zunächst "dank" ASLR blind agiert und herausfinden muss wo sich überhaupt der Kernel befindet.

Um diese Seitenkanalangriffe abzuwehren wurde KAISER entwickelt, womit sich die Arbeitsgruppe ja zunächst befasst hatte. Bei dieser Arbeit hatte man dann noch größere Lücke(n) entdeckt, womit man nun gezielt Speicherbereiche in den Cache laden konnte und diese mit den bereits bekannten Angriffen kombinierbar waren. Meltdown und Spectre waren geboren. KAISER ist bereits gegen Meltdown wirksam, jedoch wurde die Technik aufgrund der Forschungsarbeit noch verbessert. KPTI war geboren.
https://de.wikipedia.org/wiki/Kernel_page-table_isolation

Grob genommen ist Meltdown nichts neues. Es kombiniert seit Jahren bekannte Sicherheitslücken um die sich niemand RICHTIG gekümmert hat, zu neuen und noch größeren Lücken.

In der Reihenfolge genannt kann man sich das in etwas so zusammenstellen.

Seitenkanalangriffe sind seit Jahren bekannt und wurden als Angriff auf Verschlüsselungshardware entwickelt. (1992) Mit der Zeit bekamen die CPUs L3 Cache spendiert und mehrere Kerne, wodurch sich viele Prozesse einen gemeinsamen großen Cache teilen. Das wiederum macht es für einen Seitenkanalangriff interessant und Techniken die es erschwerten kamen erst viel später. ASLR wurde entwickelt um ganz andere Angriffe abzuwehren, auch hier hat noch niemand an bestehende Angriffsmöglichkeiten gedacht. Mit TSX hat sich Intel selbst ins Knie geschossen und hat die Leistungsfähigkeit der Seitenkanalangriffe beschleunigt. Mit KAISER wollte man dem entgegnen und hat dabei das richtig dicke Loch gefunden.

Im Grunde genommen hätte man sich bereits beim L3 Cache mehr Gedanken an Sicherheit machen müssen, hat man aber trotz Warnungen von diversen Quellen nicht. Bis Meltdown nun öffentlich wurde sind viele Jahre vergangen in denen vieles passiert ist und einiges davon werden wir vermutlich nie erfahren.

Ob Intel davon wusste? Ja und Nein! Hierzu ein (leider etwas makabres Beispiel)

Die NASA wusste jahrelang von Problemen mit ihren Hitzeschutz und es gab einige die darauf hingewiesen haben. Am Ende arbeitet aber immer ein Team an solchen Projekten und man kann schlecht alles 100% sicher machen. Also hat man die Warnungen ignoriert, wodurch Menschen gestorben sind. DANACH hat man ein Augenmerk DARAUF geworfen. Ist dadurch der Höllenritt mit einer Rakete am Hintern sicherer geworden? Bestimmt! Ist er SICHER geworden? Nö!

Hätte man allerdings immer auf alles und jeden gehört, wäre vermutlich nie eine Rakete abgehoben.

 

[Smartcom5]

Jetzt wirfst du aber Begriffe durcheinander, die so nicht zusammen passen.

Mist, ja, habe das neuerliche Kernel page-table isolation (KPTI) und Kernel Address Isolation to have Side-channels Efficiently Removed (KAISER) vertauscht – mein Fehler!

Richtig dürfte es sich so lesen:

Die ganze Thematik rührt kausal daher und Kernel Address Isolation to have Side-channels Efficiently Removed (KAISER) oder wahlweise Kernel Address Space Layout Randomization (KASLR) ist der kausale und eigentliche Fix, um die hier so brisante Thematik zu negieren, wobei Kernel page-table isolation (KPTI) zudem eine weitere Verbesserung von KAISER darstellt.

ASLR gibt es schon etwas länger. Es wurde eingeführt um klassische Buffer Overflow Angriffe abzuwehren, da mit der Randomisierung der Adressen im Speicher, es nicht mehr möglich ist mit einem einfachen Angriff eine bestimmte und immer gleiche Adresse aufzurufen.
https://de.wikipedia.org/wiki/Address_Space_Layout_Randomization

Um dies zu umgehen wurde an Möglichkeiten "geforscht" wie man den gesamten Speicher durchsuchen kann und die Adressen herausfindet. Dabei hat man Side-Channel Angriffe verwendet, die schon seit Jahren bekannt sind (1992 zu ersten mal erwähnt, 1996 zu ersten mal demonstriert).
https://de.wikipedia.org/wiki/Seitenkanalattacke

Mit dem Hinweis auf Kernel Address Space Layout Randomization (KASLR) als Kausalität, habe ich folgerichtig die bereits seit Jahren bekannte Forschungen in diesen Bereichen aufzeigen wollen (Ich weiß, daß es nicht viel mit Meltdown als solches zu tun hat, wohl aber die Überlegungen und Umsetzungen von KAISER und jetzt KPTI zu großen Teilen drauf aufbauen) – was ja kisser einmal mehr als nonsense abtut.

All dies ändert aber nichts am Umstand, daß a) KAISER und nun KPTI explizit unter anderem jene Lücke anzugehen suchten, welche nun als Meltdown bekannt geworden ist, daß b) eben jene Gefahren-Szenarios schon deutlich früher als Mitte '17 gezeichnet wurden und c) man auch aufgrund der Intel'chen Implementierung mehr als einmal an Intel selbst heran getreten ist – Jahre vorher.

Intel wurde von der schwere der architektonischen Fehler nicht nur mehr als einmal unterrichtet, sondern wußte darum auch selbst. Insbesondere John Harrison, (»Handbook of Practical Logic and Automated Reasoning«; nicht der Manager of Technology bei Intel) sondern jener, hat bereits '02 entsprechende Algorithmen aufgezeigt¹ und später seine Forschungen als direkter Vertreter Intels auf einem NASA-Symposium '10 wenigstens noch einmal öffentlich gemacht².

Nette Anekdote am Rande:

Spoiler: John Harrison

Der Google-cache vom 29.12. kann sich kurioserweise noch daran erinnern, daß er (John Harrison) seinerzeit noch bei Intel war.

„I do formal verification, most recently at Intel Corporation. I specialize in verification of floating-point algorithms and other mathematical software, but I'm interested in all aspects of theorem proving and verification. I'm also interested in floating-point arithmetic itself, and contributed to the revision process that led to the new IEEE 754 floating-point standard. Before joining Intel in 1998 …“

Die aktuelle Version ist weniger auskunftsfreudig:

„I am a member of the Automated Reasoning Group at Amazon Web Services, after being previously at Intel Corporation. I'm interested in all aspects of theorem proving and verification and at Intel focused especially on numerical and mathematical applications. I'm also interested in floating-point arithmetic itself, and contributed to the revision process that led to the new IEEE 754 floating-point standard. Before joining Intel …“

Der werte Herr scheint aufgrund seiner Expertise wohl ziemlich tief in den Untiefen von Prozessoren und hier insbesondere dem µCode sowie der Qualitätssicherung, der anschließenden Fehlersuche und Bug-Lösung auf Schaltkreis-Ebene untewegs (gewesen) zu sein. Siehe seine Liste an Publikationen.

Mußte da Wer seinen Hut nehmen?

Lektüre:
¹John Harrison • Formal Verification at Intel – Katholieke Universiteit Nijmegen, 21 June 2002
²John Harrison • Formal Methods at Intel: An Overview – Second NASA Formal Methods Symposium, Washington DC, 14 April 2010


In diesem Sinne

Smartcom

 

[kisser]

Ja richtig …
Nein, hat überhaupt nichts mit der aktuellen Thematik zu tun!

Hat es auch nicht. Ich hatte aber auch nicht erwartet, dass du das begreifst.
Wenn hier also einer lügt, dann bist du das.

Ergänzung (19. Januar 2018)

Im Jahr 2016 wurde gezeigt wie es möglich ist mithilfe von Intel TSX, relativ viel Daten in relativ kurzer Zeit zu ergattern.

Das ist so nicht korrekt. Man hat damals lediglich gezeigt, dass die Adressverwürfelung aka ASLR nutzlos ist, weil sie sich durch TSX aushebeln lässt. Man kann also die Kerneladressen herausfinden. Ein Auslesen des Inhaltes der Adressen war damit nicht möglich.

Meltdown funktioniert völlig unabhängig davon, ob ASLR implementiert ist oder nicht.
Wenn man alle Adressen abklappert, sind die Kerneladressen auf jeden fall immer mit dabei. Es dauert nur etwas länger.

Aber mit Smartcom kann man auf technischer Ebene sowas nicht diskutieren, weil er Äpfel mit Birnen vergleicht.

Ergänzung (19. Januar 2018)

All dies ändert aber nichts am Umstand, daß a) KAISER und nun KPTI explizit unter anderem jene Lücke anzugehen suchten, welche nun als Meltdown bekannt geworden ist, daß b) eben jene Gefahren-Szenarios schon deutlich früher als Mitte '17 gezeichnet wurden und c) man auch aufgrund der Intel'chen Implementierung mehr als einmal an Intel selbst heran getreten ist – Jahre vorher.

Das ist definitiv alles gelogen!
Wenn du nicht in der Lage bist, Äpfel von Birnen zu unterscheiden, dann halte dich aus fachlichen Diskussionen heraus.

 

[Iscaran]

Frage:

Ist KAISER ein Patch für ASLR (auf Linux KASLR genannt) um die Aushebelung des ASLR durch TSX zu patchen ?
JA / NEIN ?

So völlig daneben zu liegen und gleichzeitig jemanden der es richtig dargelegt hat, sogar im "historischen" Kontext der Lüge zu bezichtigen ist schon sehr dreist.

https://gruss.cc/files/kaiser.pdf

KAISER enforces a strict kernel and user space isolation such that the hardware does not hold any information about kernel addresses while running in user mode. We show that KAISER protects against double page fault attacks, prefetch side-channel attacks, and TSX-based side-channel attacks.

KAISER wurde entwickelt um die ASLR-Attacke zu mitigieren. Ein NEBENEFFEKT davon ist dass es eben auch eine 100% Mitigation von Meltdown darstellt.
(Nachzulesen im Meltdown.pdf)

Und jetzt geh die pdfs lesen oder hör auf hier derart rumzupoltern.

EDIT: https://de.wikipedia.org/wiki/Kernel_page-table_isolation
"KAISER steht für Kernel Address Isolation to have Side-channels Efficiently Removed, und wurde im Juni 2017 veröffentlicht, als Meltdown noch nicht bekannt war. KAISER verbessert KASLR noch weiter. Während KASLR lediglich die Kerneladressen versteckt, verhindert KAISER zusätzlich das Ausspähen von Speicherinhalten des Kernels, und deckt damit die Meltdown-Sicherheitslücke ab.^{[15]"
https://meltdownattack.com/meltdown.pdf}

 

[Volker]

Artikel-Update: Ein australischer Onlineshop führt erstmals den Core i3-8300, Core i5-8500 und auch den Core i5-8600 ohne freien Multiplikator. Letzterer kostet knapp 55 australische Dollar weniger als sein K-Pendant, der 8500 im Vergleich zum 8400 nur 20 Dollar mehr, der 8300er ist zum 8100er wiederum 35 Dollar teurer. Vergleichbar sind die Preise mit denen hierzulande aber nicht, insbesondere die kleinen CPUs sind fast doppelt so teuer wie hier, die Listungen sollten vielmehr als weiteres Indiz auf die in Kürze zu erwartende Vorstellung der neuen Modelle zu werten sein.

Im Fahrwasser folgen dann auch die dort ebenfalls gelisteten neuen Einsteigerprozessoren. Fünf Celeron und Pentium Gold werden dann ebenfalls aktualisiert, insbesondere bei den Pentium Gold gibt es mit 3,7 bis 3,9 GHz hohe Taktraten für die Vier-Thread-CPUs.

[Bilder: Zum Betrachten bitte den Artikel aufrufen.]​

 

[Enigma]

Ich versteh nicht warum diese Produkte interessant sein sollen.

Die gesamte Plattform von Intel ist rein durch die TDP getrieben. Für einen 6-Kerner mit guter Performance braucht man jenseits der 100W, was für einen NOTEBOOK völlig utopisch ist. Einen 6-Kerner mit weniger TDP zu vertreiben ist reine Kundenverarsche. Ein Kern braucht nunmal 10-15W unter (Turbo-)Last.

 

[DefconDev]

Ist der Pentium/Celeron ausgestorben?

 

[Quirin_1]

Wichtiger wären erstmal günstige Boards, solange es nur teure Z-Boards gibt sind die ganzen günstigen non-K CPUs hinfällig.

 

[kisser]

Frage:

Ist KAISER ein Patch für ASLR (auf Linux KASLR genannt) um die Aushebelung des ASLR durch TSX zu patchen ?
JA / NEIN ?

Was hat das nochmal mit Meltdown zu tun?

Ich zitiere:

Nur zum Verständnis …
Die explizite Lücke Meltdown ist nicht neu, nicht mal so ein bisschen.

Das ist glatt gelogen.
Fakt ist: Meltdown ist eine neue Lücke.

Ergänzung (19. Januar 2018)

KAISER wurde entwickelt um die ASLR-Attacke zu mitigieren. Ein NEBENEFFEKT davon ist dass es eben auch eine 100% Mitigation von Meltdown darstellt.

Das ist richtig.
Hat aber nichts damit zu tun, dass es sich um 2 verschiedene Lücken handelt. Wie schon oben erwähnt braucht es für Meltdown weder TSX (das können sowieso nur wenige CPUs) noch hilft da ASLR.
Oder kurz: Meltdown wird auch auf Windwos 98 und einem Pentium 2 funktionieren.

Dass KAISER (KPTI) gegen beide hilft ist selbstverständlich, denn Kernel-Adressraum, der im User-Adressraum nicht vorhanden ist, braucht man auch nicht zu verwürfeln; er sind eben nicht da!

 

[Iscaran]

"Verschieden" ist relativ...

Angriffe und Angriffsversuche auf ASLR mit ähnlichen Methoden wie Meltdown gab es schon vorher. Deswegen war man ja bemüht das zu patchen.

Also hier von glatte Lüge zu reden ist schon ein wenig weit hergeholt....Oder ist ein heutiger Mercedes E-Klasse (=Meltdown) kein Auto mehr weil er nicht mehr so aussieht wie von Otto Benz erfunden (=frühere Versuche ASLR auszuhebeln) ?

Aber ich lasse das offtopic hier mal. Das wäre / ist in den anderen Meltdown/Spectre Threads besser aufgehoben.

 

[kisser]

"Verschieden" ist relativ...

Angriffe und Angriffsversuche auf ASLR mit ähnlichen Methoden wie Meltdown gab es schon vorher. Deswegen war man ja bemüht das zu patchen.

Wäre Meltdown schon vor Juni 2017 bekannt gewesen, dann hätte man sich all die Mühen ersparen können.

Da ASLR aber durch die jeweilige Software unterstützt werden muss hat der jetzige KPTI-Patch noch einen positiven Nebeneffekt: es werden dadurch alle alten Programme ohne ASLR-Support sicherer.

 

[Iscaran]

Wäre Meltdown schon vor Juni 2017 bekannt gewesen, dann hätte man sich all die Mühen ersparen können.

Nein - denn aufgrund dieser Bemühung hat man überhaupt erst Meltdown gefunden....die Leute die das entdeckt haben, suchten ja nach einem Weg die bekannten Angriffsversuche auf ASLR ein für allemal zu vermeiden. Und stolperten dabei über eine noch viel schlimmere Lücke - was ihnen aber dann auch die Augen dazu öffnete wie man diese bis dahin veröffentlichten ASLR angriffe (die allesamt nicht WIRKLICH gut funktionierten btw.) eben Unterbinden kann und letztlich auch die Lösung war auf Software Basis Meltdown zu mitigieren. Denn ein echter Patch dafür kann nur auf Hardwarebasis sein. Was frühestens mit der nächsten CPU-Architektur in 5-10 Jahren passieren wird.

 

[kisser]

Du hast mich vermutlich falsch verstanden.
Ich bezog mich auf die unwahre Behauptung, dass Meltdown schon länger bekannt ist. Wäre dem nämlich so, dann hätte man gar nicht erst versuchen müssen, ASLR auszuhebeln.
Die Entdeckung von Meltdown im Juni 17 ist das Ergebnis weiterführender Forschung, in dem man der Frage nachging, ob sich nicht nur die Kerneladressen ermitteln, sondern evtl. auch deren Inhalte über eine side-channel-attack abgreifen ließen.

Der KPTI Patch ist ja relativ simpel. Man könnte sich fragen, ob es überhaupt je eine gute Idee war, die Kernel- und User-Adressen in einem gemeinsamen Adressraum abzulegen.
Warum geht man nicht hin und trennt CPU-intern jegliche Speicherbereiche (Cache, BTB, etc..) auf, so dass sie nur in dem jeweiligen Ring Gültigkeit haben? Der ganze aufwendige Kontext-switch mit dem performancefressenden Leeren der Buffer etc... wäre hinfällig.

 

[Iscaran]

Warum geht man nicht hin und trennt CPU-intern jegliche Speicherbereiche (Cache, BTB, etc..) auf, so dass sie nur in dem jeweiligen Ring Gültigkeit haben?

Weil man dann ggf. bei notwendigen Kontex-Switches (und diese gibt es zuhauf) halt mehrere hundert CPU-Zyklen warten muss bis man diese dann abarbeiten könnte. Intel wollte halt nicht warten (da man sich "sicher" war dass die spekulativ ausgeführten Befehle und deren erhaltene Ergebnisse später nicht mehr ausgelesen/verwendet werden könnten.
ABER AMD CPUs scheinen das ja genauso zu machen. Deswegen kommt es nicht zum Bruch der Rechte beim Prozessieren und selbst bei Spekulativen Prozessen scheinen AMD CPUs eben NUR innerhalb ihres Kontextes zu spekulieren. Und sind dann logischerweise auch etwas (bis erheblich) langsamer....nicht ohne Grund gab es ja die Studien zu den Unterschieden im I/O Durchsatz von SSDs je nachdem ob ein Intel oder AMD im Rechner hing.