News Weitere Sicherheitslücke in Intel-CPUs: TLBleed trickst HyperThreading aus

Nero24

Administrator
Teammitglied
Mitglied seit
01.07.2000
Beiträge
24.066
Renomée
10.445
  • BOINC Pentathlon 2019
  • BOINC Pentathlon 2020
  • BOINC Pentathlon 2018
  • BOINC Pentathlon 2021
Ben Gras von der Vrije Universiteit Amsterdam plant Anfang August auf der Blackhat USA 2018 eine neue Sicherheitslücke in Intel-Prozessoren namens TLBleed vorzustellen. Sie nutzt den Umstand aus, dass bei einem Prozessor mit aktiviertem Simultaneous Multi-Threading (SMT), bei Intel HyperThreading Technology (HTT) genannt, zwei Threads auf einem physischen CPU-Kern laufen und sich dessen Ressourcen wie Caches und TLBs teilen.
(…)

» Artikel lesen
 
Das heißt logischerweise auch das Xeon CPU betroffen sind, die die gleiche Architektur nutzen, also mein Tip für die Intel Server "HT" abschalten und damit wieder ein Loch gestopft. ;D
 
Zuletzt bearbeitet:
Das heißt logischerweise auch das Xeon CPU betroffen sind, die die gleiche Architektur nutzen, also mein Tip für die Intel Server "HT" abschalten und damit wieder ein Loch gestopft. ;D
Es wäre ja Witzig, wenn die Server dann "schneller" laufen. *g*
Es profitieren ja nicht alle Anwendung von SMT.

Zitat von "Intel":
Schnell noch AMD SMT unterjubeln, dann betrifft es alle...
;D
 
Nicht gesagt, dass alle CPUs, die SMT nutzen, gleichermaßen anfällig dafür sind. Die Ryzen sind ja innen ganz anders aufgebaut. Auch Intels Atom-Serie könnte möglicherweise Glück haben.

Aber ich finde es doch einigermaßen bemerkenswert, dass in so relativ kurzer Zeit gleich mehrere solche Klopper rauskommen. Rein statistisch hätte die letzten Jahre und Jahrzehnte doch regelmäßig was derartiges bekannt werden müssen, aber sowas gabs nie, und jetzt gleich mehrere Fälle in kurzer Zeit.
 
Naja, eigentlich ist es nicht so verwunderlich. Im Grunde sind doch all die jetzt bekannt werdenden Lücken dasselbe in Grün, Blau, Rot, etc. Seitenkanalattacken und Timing-Angriffe auf im Cache oder TLB befindliche Daten, die dort eigentlich nicht (mehr) sein dürften, es aber aufgrund der Eigenarten von Out-of-Order-Architekturen und Speculative Execution noch sind. Nachdem man das Prinzip verstanden hat, tauchen jetzt mehrere solcher Lücken auf, die zwar im Detail anderes, aber im Prinzip auf ähnliche Weise aufgerissen werden können.

Die Frage ist hier bei TLBleed imho, ob es eine grundsätzliche Schwäche von SMT in Kombination mit OoO-Execution ist, oder eine schwache Implementierung seitens Intel.
 
Die Frage ist hier bei TLBleed imho, ob es eine grundsätzliche Schwäche von SMT in Kombination mit OoO-Execution ist, oder eine schwache Implementierung seitens Intel.
Naja, der zweite Thread greift auf die Daten des erstens zu, was er eigentlich nicht sollte und dürfte.

Das heißt, dass hier irgendwas beim Register renaming oder ähnliches schief gelaufen ist und keine Checks, ob der Zugriff legal ist oder nicht, erfolgt.


Was auch interessant ist, dass die Wahrscheinlichkeit bei der etwas älteren CPU 'nen ganzes Stück schlechter ist.
Hier wäre mal 'nen Bloomfield oder notfalls Ivy Bridge Prozessor interessant gewesen.

Der Unterschied von 1,7% zwischen dem doch recht neuem Broadwell und Coffee Lake lassen auch den Schluss zu, dass was immer Intel gemacht hat, zwar mehr Performance gebracht hat, das ganze aber auf Kosten der Sicherheit geschah.
Und hier würde ich davon ausgehen, dass Intel davon wusste, aber der Meinung war, dass niemand so verrückt wäre, das zu testen oder machen...

Und wenn es bei AMD auch der Fall wäre, dann würde man aktuell darüber sprechen und das wäre geleakt worden.
Tut man aber nicht. Da gibt es nur 2 Möglichkeiten:
a) man hat es auf AMD Nicht versucht
b) man hat sich das auf AMD angeschaut, es funktioniert, aber die Wahrscheinlichkeit ist so bescheiden, dass es sinnlos ist
c) man hat sich das auf AMD angescahut, aber die für Intel verwendete Lücke funktioniert nicht
d) man hat sich das auf AMD gar nicht angeschaut.


Aber jetzt mal ehrlich:
Eine Erfolgschance von 98.2% schaut mir sehr lukrativ aus. Bei 99,2% schaut es dann natürlich noch besser aus...
DAS ist jetzt 'nen echter Knaller.

Das Problem ist allerdings, dass der Markt nicht richtig funktioniert und wir aufgrund mangelhaftem Glauben an echten Religionen viele Leute haben, die stattdessen an irgendwelche Firmen glauben und sie auch bei diesem Mist verteidigen (werden)....
Es müssen erst mal 'nen paar Steam Accounts geklaut werden, bis diese Leute umdenken. Und bei einigen wird auch das leider nicht reichen :(

Zurück zum Markt:
Wenn der Markt sinnvoll funktionieren würde, würde Intel noch in diesem Jahre Pleite sein und jeder, der über diesen Zustand Bescheid weiß, Klagen...


Hat eigentlich jemand einen bekannten Anwalt, der öfter mal im Bereich "Verbraucherschutz" tätig ist? Und den mal gefragt??
 
Naja, der zweite Thread greift auf die Daten des erstens zu, was er eigentlich nicht sollte und dürfte.

Das heißt, dass hier irgendwas beim Register renaming oder ähnliches schief gelaufen ist und keine Checks, ob der Zugriff legal ist oder nicht, erfolgt.

Das klingt mir ganz nach dem Problem das Meltdown auf Intel verursacht und von dem AMD eben NICHT betroffen ist. Denn offenbar prüft AMD ein "Rechte"-Bit vor der Ausführung (AUCH bei Spekulativer Ausführung), Intel nicht.

WENN das so ist - ist es wie Variante 3 und 3a ein Intel Problem...

Ich hatte dazu auch einen Bookmark gesetzt zu einer Diskussion von Intel developern über diesen Unsinn diese Rechteprüfung nicht durchzuführen....mal sehen ob ich die wiederfinde...

EDIT: Ah hier wars:
https://software.intel.com/en-us/forums/intel-c-compiler/topic/754601

siehe McAlpin:"Meltdown could be considered a design flaw in the OS, but it was really a team effort between the hardware and software. The Intel hardware does maintain zero-order protection across protection domains, but fails to prevent speculative execution from using protected data to make reliably detectable changes in the cache state. This provides a high-bandwidth covert channel for reading protected data. AMD was right to block this case before execution (since there is no case in which the memory access would be allowed to complete, allowing it to execute speculatively provides no benefits). Ironically, Intel's TSX extensions provide a large increase in the throughput of the Meltdown attack, as well as eliminating the exceptions that could be monitored by the OS. (I.e., the kernel interrupt handler could monitor for page faults caused by a user process attempting to load kernel pages and take action if this occurs too frequently.)"

Das führt so wie ich das verstehe auch direkt zu SGXPectre (der Teil oben mit den TSX extensions):
https://software.intel.com/en-us/forums/intel-software-guard-extensions-intel-sgx/topic/754168

Weiter unten führt er sogar noch weiter aus: "The Meltdown exploit requires that (1) the user process page tables include the kernel page tables, and (2) speculative memory accesses from user space to kernel pages are allowed to execute (returning data to the core and allowing dependent speculative instructions to execute using the *value* loaded from the kernel address).

This can be fixed by changing either (1) or (2). AMD prohibits (2), by refraining from executing loads speculatively if the code is currently operating in user space and the Page Table Entry for the target address has the kernel attribute set.
Contrary to some comments, this is not hard to detect -- it requires comparing one bit[/I] of the current processor execution mode and one bit from the Page Table Entry that had to be present to perform the address translation and access checking for the memory reference.
In this case, the AMD processor will refrain from executing the instruction until it becomes the oldest instruction in the queue -- i.e., all prior instructions have executed and committed, so the load is no longer speculative. At this point there are two choices: (a) allow the load to execute, then trigger the fault at commit, or (b) notice that the load will fault, so just trigger the fault without executing the load. Option (a) is a bad idea, since executing the load changes the cache state (which can be used to determine kernel addresses and undo the benefits of KASLR), but (depending on the details of the implementation) it might be able to prevent speculative execution that uses the results of the load. Option (b) is a much better approach -- since there is no case in which the load could succeed, there is no benefit in actually executing it."

Eine 1 Bit-Prüfung ist wohl der KERN des Intel-Meltdown-Problems.....und der Grund warum AMD Meltdown safe ist (und varianten davon).
 
Zuletzt bearbeitet:
AMD hat ja Jahre gebraucht um zwei Threads pro Kern abzuarbeiten, die zwei Module von Bulldozer wieder in einem Kern zusammenzufassen. Ich denke mal das man teilweise Dinge im Kern doppelt hat um die Sicherheit und höhere IPC als Intel zu erreichen. Also so gut wie nichts mehr mit einem Intel Designe gemein hat.

Also ich kann mir nicht vorstellen das Intel das jetzige Designe nocht irgendwie weiterführt.
 
Ich habe einen Core I5 6500 der ja bekanntlich ohne!!! SMT läuft.

Heisst das jetzt das ich noch halbwegs sicherr bin? Oder muss ich jetzt schon auf einen AMD wechseln. Die 2te Generation wäre ja da auf die ich gewartet hatte aber noch brauche ich eigentlich nichts neues.

Mal abgesehen davon das es bei mir eh nichts zu holen gibt.

mor pheus
 
Ich habe einen Core I5 6500 der ja bekanntlich ohne!!! SMT läuft.

Heisst das jetzt das ich noch halbwegs sicherr bin? Oder muss ich jetzt schon auf einen AMD wechseln. Die 2te Generation wäre ja da auf die ich gewartet hatte aber noch brauche ich eigentlich nichts neues.

Mal abgesehen davon das es bei mir eh nichts zu holen gibt.

mor pheus

Es reißt nicht ab bei Intel
! Dabei sind einige der angekündigten Lücken noch gar nicht veröffentlicht worden. Momentan würde ich mich mit einem AMD-Prozessor sicherer fühlen bezüglich der veröffentlichten Lücken; schlicht weil AMD-Prozessoren nach aktuellem Kenntnistand davon nicht betroffen sind!
 
Zurück
Oben Unten