Ergebnis 1 bis 10 von 10
  1. Beitrag #1
    Themenstarter
    Administration Avatar von Nero24.

    Registriert seit
    01.07.2000
    Beiträge
    19.528
    Danke Danke gesagt 
    10
    Danke Danke erhalten 
    8.364
    Blog-Einträge
    24

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

    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

  2. Die folgenden 7 Benutzer sagen Danke zu Nero24. für diesen nützlichen Beitrag:

    Dr4go (27.06.2018), eratte (26.06.2018), MrBad (27.06.2018), RedBaron (26.06.2018), Unbekannter Krieger (15.07.2018), WindHund (26.06.2018), Yoshi 2k3 (26.06.2018)

  3. Beitrag #2
    Grand Admiral
    Special
    Grand Admiral
    Avatar von Zidane
    • Mein System
      Desktopsystem
      Prozessor: Ryzen 1700
      Mainboard: Asus B350 Prime Plus
      Kühlung: AMD Wraith Kühler
      Arbeitsspeicher: 2x 4GB Crucial DDR4-2666 SR ECC
      Grafikkarte: Geforce G210 (Geforce 1050TI) geplant
      Display: Eizo S1932-SH 8ms 19" 1280x1024@75Hz DVI
      SSD(s): Crucial MX-200 500GB
      Optische Laufwerke: LiteOn BR-Combo iHES212
      Soundkarte: Asus Xonar D1 7.1 + Creative FPS 1600
      Gehäuse: Thermaltake Level 10 GTS Snow Edition
      Netzteil: Cougar GX-S 450W
      Betriebssystem(e): Windows 10 Pro 64
      Browser: Edge, Opera
      Sonstiges: HP CP 1525n, Canon Lide 50, MX 1000

    Registriert seit
    11.11.2001
    Beiträge
    11.700
    Danke Danke gesagt 
    110
    Danke Danke erhalten 
    87
    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.
    Geändert von Zidane (26.06.2018 um 16:13 Uhr)

  4. Beitrag #3
    Grand Admiral
    Special
    Grand Admiral
    Avatar von WindHund
    • Mein System
      Desktopsystem
      Prozessor: AMD FX-8350 Eight-core @ Asus enhancement Mode
      Mainboard: ASUS Sabertooth 990FX/Gen3 R2.0 sponsored by P3D
      Kühlung: WaKü EK WB Supreme LTX 366x40mm Radiator 6l Brutto m³
      Arbeitsspeicher: 4x 8GiB Crucial DDR3-1866 CL11 ECC DR
      Grafikkarte: 2x XFX Radeon R7970 DD 6GiB @ CrossFireX
      Display: 37" LE37A550P1R 60Hz 550cd/m Full HD -> best part of my system
      SSD(s): Samsung 830 128GB, Crucial BX100 256GB native SATA3
      Festplatte(n): 1x SATA2 Samsung HD103UJ, 1x SATA3 WD75000AAKS, 1x USB3.0 boost M.2 128GB
      Optische Laufwerke: 1x HL-DT-ST BD-RE BH10LS30 SATA2
      Soundkarte: ALC892 HD Audio (onboard)
      Gehäuse: SF-2000 Big Tower
      Netzteil: Corsair HX850W (80+ Silber)
      Betriebssystem(e): Windows 10 x64 Professional (up to date!)
      Browser: @Chrome.Google.CPU_Last_niedrig
      Sonstiges: Gehäuselüfter: 4x200mm + 7x120mm (inklusive Radiatorlüfter extern)
    • Mein DC

      WindHund beim Distributed Computing

      Aktuelle Projekte: SIMAP, Einstein, Collatz, RadioAktiv
      Lieblingsprojekt: none, try all
      Rechner: FX-8350, FX-6300, Galaxy S2 2xR7970 + 1xGTX580 + Galaxy SII
      Mitglied der Kavallerie: Nein
      BOINC-Statistiken:
      Folding@Home-Statistiken:

    Registriert seit
    30.01.2008
    Ort
    Im wilden Süden (0711)
    Beiträge
    8.819
    Danke Danke gesagt 
    1.108
    Danke Danke erhalten 
    70
    Zitat Zitat von Zidane Beitrag anzeigen
    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.
    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...

  5. Beitrag #4
    Moderation MBDB
    Moderation
    Avatar von OBrian
    • Mein System
      Desktopsystem
      Prozessor: Phenom II X4 940 BE, C2-Stepping (undervolted)
      Mainboard: Gigabyte GA-MA69G-S3H (BIOS F7)
      Kühlung: Noctua NH-U12F
      Arbeitsspeicher: 4 GB DDR2-800 ADATA/OCZ
      Grafikkarte: Radeon HD 5850
      Display: NEC MultiSync 24WMGX³
      SSD(s): Samsung 840 Evo 256 GB
      Festplatte(n): WD Caviar Green 2 TB (WD20EARX)
      Optische Laufwerke: Samsung SH-S183L
      Soundkarte: Creative X-Fi EM mit YouP-PAX-Treibern, Headset: Sennheiser PC350
      Gehäuse: Coolermaster Stacker, 120mm-Lüfter ersetzt durch Scythe S-Flex, zusätzliche Staubfilter
      Netzteil: BeQuiet 500W PCGH-Edition
      Betriebssystem(e): Windows 7 x64
      Browser: Firefox
      Sonstiges: Tastatur: Zowie Celeritas Caseking-Mod (weiße Tasten)

    Registriert seit
    16.10.2000
    Ort
    NRW
    Beiträge
    15.184
    Danke Danke gesagt 
    0
    Danke Danke erhalten 
    61
    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.

  6. Beitrag #5
    Themenstarter
    Administration Avatar von Nero24.

    Registriert seit
    01.07.2000
    Beiträge
    19.528
    Danke Danke gesagt 
    10
    Danke Danke erhalten 
    8.364
    Blog-Einträge
    24
    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.

  7. Beitrag #6
    Grand Admiral
    Special
    Grand Admiral
    Avatar von Stefan Payne

    Registriert seit
    17.11.2001
    Beiträge
    4.247
    Danke Danke gesagt 
    1
    Danke Danke erhalten 
    21
    Zitat Zitat von Nero24. Beitrag anzeigen
    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??

  8. Beitrag #7
    Commander
    Commander

    Registriert seit
    23.09.2007
    Beiträge
    156
    Danke Danke gesagt 
    5
    Danke Danke erhalten 
    2
    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/for...r/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/for...x/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 --[I] 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).
    Geändert von Iscaran (27.06.2018 um 11:00 Uhr)

  9. Beitrag #8
    Admiral
    Special
    Admiral
    Avatar von Peet007
    • Mein System
      Desktopsystem
      Prozessor: AMD Ryzen 1700X
      Mainboard: Asrock X370 Taichi
      Kühlung: 480 Radi(schen) WaKü
      Arbeitsspeicher: 16 GB
      Grafikkarte: Radeon RX Vega 56
      Display: Fujitsu 26 Zoll
      Soundkarte: onBoard
      Netzteil: 750 Watt
      Betriebssystem(e): Manjaro
      Browser: Chromium
    • Mein DC

      Peet007 beim Distributed Computing

      Mitglied der Kavallerie: Nein
      BOINC-Statistiken:

    Registriert seit
    30.09.2006
    Beiträge
    1.215
    Danke Danke gesagt 
    6
    Danke Danke erhalten 
    0
    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.

  10. Beitrag #9
    Grand Admiral
    Special
    Grand Admiral
    • Mein System
      Notebook
      Modell: Medion 17" Full HD SSD Onboardgraka Core i5U
      Desktopsystem
      Prozessor: Core i5 6500
      Mainboard: Asus Strix Z270F Gaming
      Kühlung: Be Quiet Rock
      Arbeitsspeicher: 2x8gb DDR4 2133
      Grafikkarte: AMD R7 370 4gb
      Display: Acer 27" 4K IPS
      SSD(s): Samsung 960Evo 256gb + Samsung 850 Pro 256gb
      Optische Laufwerke: Plextor PX-810SA,
      Soundkarte: Lehmann Linear USB+ Project Dac Box RS
      Gehäuse: Lian-Li PC A75X
      Netzteil: BeQuite Dark Power P7 550W Kabelmanagement
      Betriebssystem(e): Windows 10 64bit
      Browser: Chrome
      Sonstiges: Logitech G502 Mouse Steelseries Apex 350 Roccat Alumic Mousepad LowSense

    Registriert seit
    20.06.2003
    Ort
    Naturpark Eifel
    Beiträge
    2.459
    Danke Danke gesagt 
    2
    Danke Danke erhalten 
    13
    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

  11. Beitrag #10
    Themenstarter
    Administration Avatar von Nero24.

    Registriert seit
    01.07.2000
    Beiträge
    19.528
    Danke Danke gesagt 
    10
    Danke Danke erhalten 
    8.364
    Blog-Einträge
    24
    Zitat Zitat von morpheus1969 Beitrag anzeigen
    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!

Stichworte

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •