Intel kämpft mit schwerer Sicherheitslücke (Update: Intel veröffentlicht Server-Benchmarks)

oooverclocker schrieb:
Richtig, eigentlich hätte ich das gar nicht gebraucht, aber mittlerweile finde ich, dass es eine gute Idee war :rofl:
Aber ich lass es mal gut sein und gehe auf den Rest nicht nochmal ein :d
Zum Vergrößern anklicken....

Also kommt mal wieder nix außer deiner Abneigung ggü. dem Hersteller - nichtmal den Hinweis, das es selbst der Hersteller anders sieht und public anders kommuniziert bringt dich davon ab...
Glückwunsch, wenigstens bleibst du deiner Linie treu ;)
Ach ich vergaß, gesundes Neues wünsche ich...

jdl schrieb:
Das ist komplett falsch formuliert.
Bekannt ist, dass auch bei AMD (sowie bei IBM, Intel, ARM, …) die CPU Probleme mit der out-of-order Verarbeitung hat.
Es ist bisher kein funktionierender Exploit für AMD und Spectre 2 bekannt, das ist etwas anderes als "betrifft AMD aktuell nicht nachweislich", denn wir wissen nicht, ob es nicht doch eine Möglichkeit gibt Spectre2 auf AMD durchzuführen. AMD selbst weiß es nicht, sonst würden sie nicht über Wahrscheinlichkeiten sprechen.
Zum Vergrößern anklicken....

Ist dir was in Sachen GPUs bekannt? Laut heise prüfe wohl NVidia ihre GPUs und die Tegra Modelle, wie schauts mit AMD aus? Der Cell Prozessor wäre für die Leute ggf. auch noch good to know, PS3 und so...
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
DTX xxx schrieb:
Das ist wirklich traurig.
…
Zum Vergrößern anklicken....
Falls es Dir nicht aufgefallen ist, Intel ist nicht alleine davon betroffen. So ziemlich jede CPU Schmiede hat Mist gebaut, und je nachdem wie das konkrete CPU-Design aussieht wirkt sich das out-of-order Problem mehr oder minder stark aus.

- - - Updated - - -

nVidia hat in einer vorläufigen Prüfung gemeldet, dass die GPUs wahrscheinlich nicht betroffen sein werden. Aber die Prüfung ist noch nicht komplett erfolgt. Die ARM Designs stehen komplett noch aus.
 
neuli schrieb:
Ja und was willst du machen? Das Problem ist die Sprungvorhersage. Also ausschalten. Oder halt irgendwie per Software kontrollieren. Nur ist die Sprungvorhersage ja im Prozessor.
Hier auch nochmal für intel: Sicherheit: Preisgabe von Informationen in QEMU - Pro-Linux
Gut möglich, dass das erst einmal die Holzhammermethoden sind. Da es noch keine brauchbaren Patches gibt. Also lieber zunächst komplett deaktivieren.
Ich bin im phoronix Forum darauf aufmerksam geworden und Michael hat bei AMD um eine Stellungnahme gebeten.
Siehe Post #21: https://www.phoronix.com/forums/forum/phoronix/general-discussion/999103-more-linux-kernel-gcc-patches-come-out-in-the-wake-of-spectre-meltdown/page3

Meltdown ist gefixt und kostet Leistung obendrauf kommen nun noch die Spectre Patches die auch nochmal Leistung kosten. Und weil das noch nicht lustig genug ist müssen sämtliche Programme neu kompiliert werden und abgesichert werden. Die neu kompilierten Programme werden dann auch nochmal langsamer sein. Siehe: More Linux Kernel GCC Patches Come Out In The Wake Of Spectre+Meltdown - Phoronix
Aber wieviel das nun am Ende ist und welcher Hersteller mehr Leistung verliert wird man einfach abwarten müssen.
Zum Vergrößern anklicken....
Ok danke für den Info. Also scheint doch nicht die komplette "Sprungvorhersage" deaktiviert worden zu sein.

Glaube ich deaktiviere erstmal alle Updates. :)
Derartige Angriffe betreffen private Benutzer sowieso nicht.
 
nuts schrieb:
Glaube ich deaktiviere erstmal alle Updates. :)
Derartige Angriffe betreffen private Benutzer sowieso nicht.
Zum Vergrößern anklicken....

Wenn du dir allein mal die Anzahl der Ransomware Wellen des letzten Jahres ansiehst - so ne Lücke kann für allerhand holy shit die Basis sein, gerade wenn der User naiv genug ist zu glauben, er sei sowieso nicht im Fokus. Für mich sind die ganzen Angreifer auffallend häufig einfach nur auf Provit aus - kommt da mal einer, der das nicht des Provits wegen macht, sondern nur weil er es kann, dann sind sowas wie diese Lücken im Endeffekt der Punkt andem man so ziemlich ALLE erreicht. Allein die Tatsache das der Spaß seit Jahren funktioniert - und dass Dritte jetzt drauf Aufmerksam machen. Naja, deine Entscheidung, empfehlenswert ist das defakto nicht...
 
Würde mal vermuten aufgrund der Menge an CPUs die betroffen sind, über die ganzen Jahren das diese Lücke kein Zufall sein kann, auch wenn man es nicht beweisen kann. Aber schön den Kunden versuchen zu beweisen das man den Speicherbereich mittels NX-Bit etc. schützen kann das Schadcode ausgeführt werden kann und dann sowas. Sind für ein paar Zufälle Zuviel.
 
Hi

Wie sieht es aus mit virtualisierten Firewalls, VPN Gateways und sowas? Auf Linux Basis, z.B. auf dem ESXi?

Mal abgesehen von dem Hypervisor Patch? ->

  • Reicht es da auf dem Gast Linux einen neuen Kernel einspielen?
  • Oder sind da noch andere Sachen wie der Kernel von dem Problem abhängig?
 
@fdsonne: Du hast natürlich recht. Als allgemeine Empfehlung taugt meine "Entscheidung" nicht ("Kinder bitte nicht zuhause nachmachen").
 
AliManali schrieb:
Wie sieht es aus mit virtualisierten Firewalls, VPN Gateways und sowas? Auf Linux Basis, z.B. auf dem ESXi?

Mal abgesehen von dem Hypervisor Patch?
Zum Vergrößern anklicken....

Kommt auf den Virtualisierer an, VMware patchte schon vor Wochen den ESXi 6.0 und zog den 6.5er mitte Dez. nach. Meltdown ist explizit nicht (direkt) betroffen, auch auf Intel nicht, man schreibt dazu: "ESXi does not run untrusted user mode code"
Du bist mit den 11er bzw. 12er ESXi Patches von der Hostseite weitestgehend gegen Spectre imun und solltest noch schauen nach Biosupdates für den Host.
Problem ist halt weiterhin - 100% ist das im Moment nicht aushebbar.
Die Gäste zu patchen kann defakto aber nicht schaden bzw. ist definitiv empfohlen.
 
Bildbearbeitung scheint es wohl am härtesten zu treffen.
 
Schaut so aus, gut das ich vor 9 Monaten von meinem Ivy auf den Ryzen umgestiegen bin und nicht auf X99 ^^

Edit:
Peter Czanik auf Twitter:

The fix for the #Intel CPU vulnerabilities has a #brutal effect on compile times.
Compiling the #syslog_ng package on #Fedora changed drastically: from 4 minutes to 21!
As far as I can see compiling #Java is affected most.
#Meltdown #Spectre
Zum Vergrößern anklicken....
 
Zuletzt bearbeitet:
@fdsonne: Danke für die Info. Dann werd ich mal den ESXi hochziehen. Aber in den Linux Netzwerk Infrastruktur Gästen, reicht es da den Kernel zu patchen?
 
Bin mal gespannt, was noch nachfolgt. Beim Phenom I war ja der Teufel los.
 
AliManali schrieb:
@fdsonne: Danke für die Info. Dann werd ich mal den ESXi hochziehen. Aber in den Linux Netzwerk Infrastruktur Gästen, reicht es da den Kernel zu patchen?
Zum Vergrößern anklicken....

Theoretisch nein. Das Proplem an Spectre ist, es muss schlussendlich entweder in Hardware verhindert oder in Software untersagt/unwirksam gemacht werden.
Die Kernelpatches wie auch Firmware und Microcode erschweren wohl nur das Problem, beheben es aber nicht. Zumindest nach aktueller Infolage!? Kommt halt drauf an, was gemacht wird... ne Code Execution muss halt funktionieren damit das Triggert, deswegen ja oben die Aussage zu nem Kontentscanner in der Firewall bspw.
Ein simples Serverdevice ohne Zugriffe von Dritten dürfte wenig bis gar nicht gefährdet sein. Solange du nicht entsprechenden Code ausführst, untergeschoben bekommst oder ähnliches. Problematischer ist, wenn das der Fall ist/wäre. Bleibt aber halt ne pseudo Sicherheit.
 
CompuJoe schrieb:
Schaut so aus, gut das ich vor 9 Monaten von meinem Ivy auf den Ryzen umgestiegen bin und nicht auf X99 ^^

Edit:
Peter Czanik auf Twitter:
Zum Vergrößern anklicken....
Bitte auch die Antworten zitieren: "Interesting. A friend timed linux kernel compilation with PTI enabled and the difference was less than 10 seconds."
"Something else has to be completely off there, then. Gentoo user here on i7-7700K: syslog-ng-3.13.2 in December (w/o KPTI obviously): merge time 40 seconds, with KPTI enabled: 40 seconds . So no difference at all."
"I tested libvirt 3.7.0 RPM compile time and it had negligible performance impact. With kernel 4.14.8-300.fc27 it took 3 min 55 sec, and with kernel 4.14.11-300.fc27 it takes 4 minutes 5 secs. 8 cpus on a i7-3740QM - perhaps a sign of the benefit of the 'pcid' feature in that cpu"
 
Doktor Unblutig schrieb:
Bitte auch die Antworten zitieren: "Interesting. A friend timed linux kernel compilation with PTI enabled and the difference was less than 10 seconds."
"Something else has to be completely off there, then. Gentoo user here on i7-7700K: syslog-ng-3.13.2 in December (w/o KPTI obviously): merge time 40 seconds, with KPTI enabled: 40 seconds . So no difference at all."
"I tested libvirt 3.7.0 RPM compile time and it had negligible performance impact. With kernel 4.14.8-300.fc27 it took 3 min 55 sec, and with kernel 4.14.11-300.fc27 it takes 4 minutes 5 secs. 8 cpus on a i7-3740QM - perhaps a sign of the benefit of the 'pcid' feature in that cpu"
Zum Vergrößern anklicken....

Soweit ich das mitbekommen habe ist das sogar noch ohne Bios Update, bin mal gespannt wie es mit aussieht.
Und CPUs ohne INVPCID haben sowieso einen größeren Leistungsverlust, (hätte mein Ivy gehabt z.B., dazu kommt noch das viele PCID und INVPCID verwechseln, das zweite ist das wichtige, Ivy hat z.B. PCID aber nicht INVPCID) abwarten und mal schauen wie es nach dem Biosupdate aussieht wenn es den alle bekommen.
 
Wenn ich mir die von Intel veröffentlichte Liste betroffener Prozessoren durchlese, dann fehlen dort scheinbar die Intel® Celeron® Processor G Series und die Intel® Pentium® Processor G Series

Intel® Celeron® Processor J Series
Intel® Celeron® Processor N Series
Intel® Pentium® Processor J Series
Intel® Pentium® Processor N Series

Wurden diese beiden Serien vergessen, es wird ja auch von möglichen Ergänzungen der Liste geschrieben oder sind diese Prozessoren nicht betroffen, gibt es dazu Infos?
 
Zuletzt bearbeitet:
So allmählich gerät alles mal wieder aus dem Ruder.
Das System kann noch so sicher sein, das Problem sitzt eher vor dem Bildschirm der auf "I'm Admin, Accept, Yes, Are you sure?, Execute" klickt. Selber schuld.
Wer hat das nochmal gesagt: "Ich habe den roten Knopf ständig auf meinen Schreibtisch"? .....
 
Gamer1969 schrieb:
Jetzt geht’s schon los mit den Sammelklagen und Einzel Klagen gegen Intel

Branstetter, Stranch Jennings, Doyle APC Announce Filing of Consumer Fraud Case against Intel Corporation | Business Wire

District of Oregon | Lawsuit | Complaint

southern district of indiana | Kernel (Operating System) | Central Processing Unit
Zum Vergrößern anklicken....
die usa, anscheinend ziemlich einfach für anwälte geld zu verdienen. da steht auch nur anklage wegen sicherheitslücke und performanceverlust
 
Dass die USA, das Eldorado für Anwälte ist, ist nichts neues :)

Ne sinnvolle Anklageschrift würde mich aber auch interessieren. Muss für ein Verfahren, nicht absichtliche oder fahrlässige Schuld da sein?
 
Soll die Schuldfrage nicht erst in der Verhandlung nachgewiesen werden?
 
DragonTear schrieb:
Muss für ein Verfahren, nicht absichtliche oder fahrlässige Schuld da sein?
Zum Vergrößern anklicken....
ein "guter" anwalt dreht die dinge zu seinen gunsten. vielleicht läuft es ja auf eine ausergerichtliche einigung hinaus, dann hat amerika 1-2 millionäre mehr.
 
Das ist mehr als eindeutig Fahrlässig. Vorsatz könnte man ihnen bei der ME Geschichte unterstellen.
Ich würde es begrüßen wenn Intel hierfür richtig einen verpasst bekommt.
Bei einem Problem das mal eben 90% der Weltbevölkerung betrifft kann man nicht einfach sagen sorry, war unser Fehler.
 
PoCs von Meltdown und Variante 2 von Spectre gibt es schon seit einiger Zeit welche ;)
 
Ich hoffe es gibt eine Möglichkeit die Cpu zurückzugeben.
Einen Leistungsverlust von 27% sehe ich nicht ein.

Dafür habe ich nicht so viel Geld ausgegeben
 
Anmelden, um zu antworten.
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh