Login
Newsletter
Werbung

Thema: Prozessorfehler mit katastrophalen Ausmaßen

71 Kommentar(e) || Alle anzeigen ||  RSS || Kommentieren
Kommentare von Lesern spiegeln nicht unbedingt die Meinung der Redaktion wider.
1
Von Performance am Do, 4. Januar 2018 um 12:41 #

Ist jetzt die Frage ob man die Patches aufspielt oder nicht. Bei meinem Tablet werde ich wohl Pech haben, da kann man keine einzelnen Patches abwählen. Doch wenn es laut Aussage bis zu 30 % an Leistung kosten (kann) ist das schon eine Überlegung. Kann diese Lücke denn praktisch genutzt werden?

  • 1
    Von asdasdsda am Do, 4. Januar 2018 um 12:47 #

    Wenn du die TLB Lücke meinst, dann ist sie eher für Multi-User und Cloud-Systeme kritisch. Als Privatnutzer würde ich mir da erst einmal kein Sicherheits-Horrorszenario ausmalen.

    Die Performance sollte jedoch gezielt mit Benchmarks überprüft werden. Dazu gibt es hier erste Einschätzungen:

    https://www.phoronix.com/scan.php?page=article&item=linux-415-x86pti&num=1

    1
    Von Anonymous am Do, 4. Januar 2018 um 12:57 #

    What CAN happen, WILL happen.

    https://en.wikiquote.org/wiki/Murphy's_law

    Die ersten Proof of Concepts kursieren schon, und nun muss jamand das zusammen mit anderen Lücken zu einer Javascript-Angriffskaskade zusammenbauen und z.B. über Werbenetzwerke verteilen.

    Größer ist aber die Gefahr, dass das auf Cloud-Servern ausgenutzt werden kann, um aus einer Instanz auszubrechen und in den Instanzen anderer Leute rumzuschnüffeln.

    • 1
      Von Performance am Do, 4. Januar 2018 um 13:35 #

      Man kauft sich einen schnellen Prozessor der dann nichts mehr bringt, ist auch ärgerlich. Mal sehen ob man das durch neue Prozessorgenerationen in den Griff bekommt. Im Moment scheint man noch nicht zu wissen ob man eine sichere Implementation hinbekommt oder nicht.

      • 2
        Von UChef am Do, 4. Januar 2018 um 14:40 #

        Man kauft sich einen schnellen Prozessor der dann nichts mehr bringt, ist auch ärgerlich.
        Wieso das denn? Der Prozessor ist doch immer noch schnell - jedenfalls so schnell er eben bei sicherem Betrieb sein kann. Zudem ist er genauso viel schneller, als ein langsamerer Prozessor vorher langsamer war. Es verschiebt sich eben nur alles... 8)

        1
        Von qwertzui am Do, 4. Januar 2018 um 21:12 #

        Die Performanceeinbußen wirst Du bei halbwegs aktuellen Prozessoren kaum bemerken, da diese sich erst unter Last wirklich zeigen werden. Bei einem Quadcore-Prozessor sollte dieses Szenario auf dem Desktop wohl eher nicht auftreten.

        Das dürfte etwa dem Performanceverlust vergleichbar sein, der auftritt, wenn man z.B. AES-Verschlüsselung einsetzt ohne dass der Prozessor diese nativ beherrscht. Auch hier bemerken die meisten Nutzer keinen Performanceeinbruch.

        Zudem besteht auch ein Riesenunterschied zwischen 5% oder 30% Performanceverlust. Die Angabe 5-30% ist viel zu wage.

        Hier wurden offenbar in die Prozessorhardware über 20 Jahre hinweg schwere Sicherheitslücken eingebaut, ob absichtlich oder unabsichtlich, müsste IMO aber auch noch geklärt werden.

1
Von Josef Hahn am Do, 4. Januar 2018 um 12:44 #

Jaja...

Seit der Jahrzehntenwende halten wir uns sowieso mit Maturity in allen technischen Bereichen vornehm zurück.

Und auch früher war nicht alles Gold...

1
Von Töppke am Do, 4. Januar 2018 um 14:07 #

Zitat:
Die gefundenen Fehler beruhen auf der Tatsache, dass alle modernen Prozessoren (ab ca. 1995) versuchen, die Befehlsausführung zu beschleunigen.
Ende

Kann man diese Einstellung nicht im Bios deaktivieren-> Prefetch?

https://en.wikipedia.org/wiki/Cache_prefetching

Ausführlich, aber englisch

  • 1
    Von Ignatz am Do, 4. Januar 2018 um 17:21 #

    Hab noch kein BIOS gesehen, bei dem das geht. Warum sollte man da auch was einstellen wollen (jetzt abgesehen von diesem Prozessorfehler)?

    • 1
      Von blablabla233 am Do, 4. Januar 2018 um 22:06 #

      Fuer Real-Time Betriebsmodus, nahezu alle HP-Workstations und Server haben diese Einstellung

      0
      Von schmidicom am Fr, 5. Januar 2018 um 09:40 #

      Bei einigen DELL-Rechnern, vor allem Server, lässt sich im BIOS/UEFI immer mal wieder so etwas finden. Warum weiß ich auch nicht aber es gibt sicher auch abseits von diesem Fehler einen Anwendungsfall.

    0
    Von mw am Fr, 5. Januar 2018 um 10:42 #

    Das hat mit prefetching nichts zu tun. Es geht um die spekulative Ausführung von Maschinencode bei der branch prediction und da wird eben auf die Absicherung durch die MMU geschlampt und die Daten landen in Cache. Dort können sie dann über Seitenangriffe ausgeölsen werden (dauert relativ ewig, aber wenn man nur ein paar Byte haben will ...).

    Das Problem ist, daß z. B. bei Linux Kernelspace nicht vom userspace getrennt ist, sondern jeder Prozess Userspace und Kernelspace erreichen kann, wenn die Berechtigungen in der MMU da sind. Und eben die werden bei der spekulativen Ausführung umgangen.

    Also Trennung von Userspace und Kernelspace. D. h. aber bei jedem syscall die Pagetables neu laden. Und das ist eben der Performanceverlust.

3
Von klaus818 am Do, 4. Januar 2018 um 14:39 #

https://www.computerbase.de/2018-01/intel-cpu-pti-sicherheitsluecke/

Da wird genau beschrieben, was für Fehler es gibt. Es sind derer drei. Und es wird auch beschreiben, welche CPU von welchem Fehler betroffen ist. Von Meltdown soll AMD nicht betroffen sein, von Spectre schon. Aber das ist genauso schwer auszunutzen wie zu patchen.

Des weiteren geht man da auch auf die Performance ein, über die ja die dollsten Dinge im Umlauf sind. In Bezug auf Linux ist da auch Phoronix zu empfehlen, wo man sehen kann, was da wo passiert.

1
Von Potz Blitz am Do, 4. Januar 2018 um 15:51 #

Wenn man sicherheitsbewusst unterwegs sein will, hilft langfristig wohl nur der Tausch der Hardware (wenn es die denn mal gibt). Auf die Kulanz der Hersteller verlasse ich mich dabei lieber nicht. Wie auch? Intel ginge wohl bankrott, müssten sie alle im Einsatz befindlichen CPUs austauschen. Besonders ärgerlich ist das für diejenigen, die sich erst kürzlich neue Hardware zugelegt (und dabei nicht am Prozessor gespart) haben. Da wurde imho viel Vertrauen verspielt.

1
Von Lars Otte am Do, 4. Januar 2018 um 18:34 #

Offenbar sind langsame in-order-execution Kerne nicht betroffen,
das heißt dann wohl das sehr alte Intel Atom nicht betroffen sind. Ebenfalls sicher: ARM Cortex A7, ARM Cortex A53 und ARM Cortex A35. Die meisten ARM-Boards sind dann wohl nicht betroffen.
Ich frage mich wie es bei RISC-V aussieht...

  • 1
    Von qwerertzui am Fr, 5. Januar 2018 um 00:02 #

    Nicht betroffen sind ebenfalls: Sämtliche Raspberry Pi-Cortex-CPUs laut einer Liste auf der ARM-Webseite, und als einzige Intel-CPU-Serie Pentium I und frühere Intel-CPUs.

    Laut AMD sind AMD-Prozessoren von Meltdown generell nicht betroffen. Deswegen wurde der jüngste Linux-Patch für AMD-CPUs auch wieder deaktiviert. AMD-Prozessoren erleiden somit keinerlei Performanceeinbruch, weder AMD K6-2 noch AthlonXP noch Athlon Piledriver, Bulldozer oder Zen. Die eigenen CPUs sind laut AMD im Vergleich zu Intel einfach viel zu unterschiedlich im Design.

1
Von eMme am Do, 4. Januar 2018 um 21:20 #

Interessant ist doch, ob man das mit Microcode patchen kann, oder ob man mehr machen muss. Ein Microcode-Paket sollte jetzt kein Drama sein.

1
Von debian-user am Fr, 5. Januar 2018 um 08:28 #

Ich überlege gerade, ob Zwei-Faktor-Authentifizierung (Mail, ssh usw.) und das Meiden von Programmen oder Anbietern, die keine Zwei-Faktor-Authentifizierung anbieten, Maßnahmen bezüglich der Sicherheitslücke sein könnten.

0
Von mw am Fr, 5. Januar 2018 um 10:47 #

Wenn Du in den letzen zwei Jahren ein gerät gekauft hast, muss der Händler im Rahmen der Gewährleistung den mangel beseitigen. Es gibt wohl keinen Zweifel, daß der fehler bereits von Beginn an vorhanden war und so gelten die 24 Monate Gewährleistung. Bin mal gespannt, wie das mit meinem Smartphone Huawei P8lite, gekauft im Sept. 2017 bei Mediamarkt ausgeht. Freue mich schon auf deren Antwort.

1
Von Ruediger am Fr, 5. Januar 2018 um 11:29 #

OpenBSD wusste das schon 2007.

https://www.linuxquestions.org/questions/showthread.php?p=5801639#post5801639

  • 0
    Von W. Kern am Fr, 5. Januar 2018 um 12:27 #

    Die wussten von der Sicherheitslücke und haben sie bewusst in Kauf genommen, damit die Geschwindigkeit (Verkaufsargument) verbessert wird.

    Vergleichbar ist das mit der Schummelsoftware bei VWs.

    Das darf nicht einfach hingenommen werden. Die Firmen müssen sich verantworten. Nicht nur die Hersteller der Prozessoren, auch die Firmen, die diese in ihre Geräte eingebaut haben.

    Wenn ich davon gewusst hätte, hätte ich mir meinen Rechner nicht gekauft. Jetzt habe ich den Mist und die Hersteller mein Geld.

    • 0
      Von ClosedBSD am Fr, 5. Januar 2018 um 19:46 #

      Und trotzdem fährst du VW und kaufst Intelprozessoren. Und wenn nicht dann kaufst du AMD, die auch nicht verantwortlich sind für das was sie tun. Jetzt darfst du dir aussuchen was du machen willst.

      0
      Von Ede am Sa, 6. Januar 2018 um 12:46 #

      [url=http://www.handelsblatt.com/unternehmen/it-medien/sicherheitsluecke-bei-intel-us-verbraucher-verklagen-chip-hersteller/20819228.html]US-Verbraucher verklagen Chip-Hersteller[/url]

      0
      Von Anonymous am Sa, 6. Januar 2018 um 13:47 #

      Microsoft, RedHat usw. beschäftigen tausende von Kernelhackern und Treiber-Schreibern. Auch die meisten Linux-Kernel-Hacker hacken für Geld und nicht aus Spass in der Freizeit.

      Und keine von den Microsoft- und Linux-Koniferen hatte irgendeine Ahnung, was im Inneren eines "modernen" Prozessors vor sich geht?

      Aber die haben halt Reisenglück, dass sie den Konsumenten vor Jahrzehnten aufs Auge drücken konnten, dass für Software keiner haftet.

0
Von Anonymous am Sa, 6. Januar 2018 um 00:06 #

Hier mal eine kindgerechte Erklärung von Spectre und Meltdown im Raspberry Pi Blog , die sogar ich halbwegs verstehe ;)

0
Von klaus818 am Sa, 6. Januar 2018 um 08:49 #

Leider gibt es sehr viel blabla zu diesem Thema, besonders Intel wirft da Nebelkernen (AMD ist auch betroffen):

Es gibt Meltdown und Spectre. Von Meltdown ist nur Intel betroffen. Meltdown ermöglicht, dass ein Prozess den gesamten realen Speicher des Rechners auslesen kann. Also eine VM kann den Speicher anderer VMs lesen. Ein Gau für Anbieter virtueller Server. Dieser Bug ist durch Patches am Kernel zu beseitigen.

Von Spectre sind AMD, ARM und Intel betroffen. Es erlaubt z.B. einem im Browser laufenden Script, auf den gesamten Speicher des Browsers zuzugreifen. Um Spectre unmöglich zu machen, ist ein komplett neues CPU-Design nötig, es kann nicht vollständig gepatched werden. Spectre ist aber nur sehr schwer auszunutzen, weil ein Exploit an jede einzelne CPU angepasst werden muss. Von Chrome und Firefox gibt es inzwischen Updates, die das Ausnutzen dieser Lücke zumindest noch weiter erschweren.

Intel hat wohl nicht vor, an seinem für Meltdown verantwortlichem Design etwas zu ändern. Der entsprechende Kernelpatch wurde fest im Kernel eingebaut und ist nicht per Option abschaltbar. Was Linus zu der Aussage motiviert hat: "Intel, wollt ihr Scheiße für ewig verkaufen?". Dieses Feature ist also für alle Prozessoren fest in künftigen Kernels eingebaut. Man kann es aber über einen Boot-Parameter deaktivieren.

0
Von Anonymous am Sa, 6. Januar 2018 um 13:54 #

Besonders vergnüglich finde ich, dass der FDP-Posterboy mit dem Spruch "Digital first, Bedenken second" durch den Bundestagswahlkampf tingelte, während zur gleichen Zeit die Vorstandsetagen der Prozessorhersteller schon bei den Stufen 4 (SuperGAU) bzw. 5 (Meltdown; Intel) angekommen waren.

0
Von Janko Weber am So, 7. Januar 2018 um 16:52 #

Sind Google jetzt die Guten?
Ich kotze gleich!

Ihr schlauen Helden sollt blosz einfach alle mal wieder einen neuen Computer kaufen.

Wenn ich recht erinnere war so im August 1999 in der Zeitschrift PC-Praxis mal Titel-Thema: So deaktivieren sie JavaScript
Davon wollten die ein paar Wochen spaeter schon nichts mehr wissen. Warum wohl?

Bei mir ist JavaScript fast immer deaktiviert. Und mir sind Internet-Seiten die ohne diesen Mist einwandfrei funktionieren schon immer sympathischer gewesen.


MfG Janko Weber

0
Von Atalanttore am So, 7. Januar 2018 um 17:30 #

Wie die Zeit vergeht ...

0
Von Anonymous am So, 7. Januar 2018 um 21:54 #

Den Parameter CONFIG_PAGE_TABLE_ISOLATION (der den Intel MELTDOWN Bug neutralisiert) gibts nur für 64bit-Kernel.

Wenn man einen 32bit-Kernel kompilieren will, ist der Parameter ausgeblendet. Mit der exotischen Kombination 64bit-CPU und 32bit-Kernel steht man also erst mal im Regen, denn MELTDOWN ist ja wohl nicht auf den 64bit-Modus beschränkt, oder?

Wird wohl Zeit, endlich mal auf 64bit umzustellen...

  • 0
    Von qwertz am Fr, 12. Januar 2018 um 17:07 #

    Die Umstellung auf 64bit wird langfristig nichts nützen, da Intel auch 64bit-CPUs, die älter als 2013 sind, genauso wie seine alten 32bit-CPUs nicht mit Patches bzw. Updates versorgen wird und diese CPU-Hardwarefehler bei Intel nun schon mehrfach vorgekommen sind.

    Im Prinzip ist damit die ganzevon Intel dominierte x86-Architektur komromittiert und sollte aufgegeben werden.

    Ich bin deshalb auf der Suche nach PC-kompatiblen ARM-Mainboards (die fehlerhaften ARM-CPUs wurden von ARM im Gegensatz etwa zu Intel ja eindeutig benannt, die Raspberry-ARM-CPUs etwa sind ja nicht betroffen), die man als Ersatz für die x86-Mainboards von Intel und AMD verwenden könnte. Vielleicht gibt es ja auch eine verfügbare CPU-Architektur, die für ebenfalls Server geeignet ist und diese in Hardware fest einkodierten OOE-Designfehler nicht aufweist.

    0
    Von -.,-.,-.,-.,-.,-.,-.,-., am So, 14. Januar 2018 um 01:51 #

    Fürs Erste kannst Du auf Deinem 32bit-System mit 64bit-CPU direkt den "amd64"-64bit-Kernel nachinstallieren. Der spielt problemlos mit dem 32bit-Userland zusammen.

    Das funktioniert z.B. unter Debian Wheezy reibungslos, dank Multiarch-Fähigkeit.

    0
    Von qwertzu am Mi, 17. Januar 2018 um 23:49 #

    Die ersten 32bit-Patches gegen Meltdown wurden gerade auf kernel.org eingereicht:

    https://lkml.org/lkml/2018/1/16/817

    Die Patches müssen aber erst noch auf einer reinen 32bit-Rechnerbox getestet werden, der 32bit-Meltdown-Patch-Entwickler hatte offenbar zunächst keine mehr zur Verfügung und musste erst noch frisch einen 32bit-Rechner aufsetzen:

    "The code has not run on bare-metal yet, I'll test that in the next days once I setup a 32 bit box again. I also haven't tested Wine and DosEMU yet, so this might also be broken."

    Torvalds scheint das gut zu finden:
    "But yes, checking bare metal, and checking the "odd" applications like Wine and dosemu (and kvm etc) within the PTI kernel is certainly a good idea."

    Zudem laufen Wine und Dosemu ja auch auf 64bit-Systemen und Wine z.B. dabei meist im 32bit-Modus.

    Was ich damit sagen will: 32bit wird nicht und ist nicht aufgegeben. Niemand auf kernel.org wird die Meltdown-/Spectre-Krise dazu benutzen, die 32bit-Plattform nun einfach abzusägen.

Pro-Linux
Pro-Linux @Facebook
Neue Nachrichten
Werbung