Ernste Sicherheitslücken in allen modernen CPUs (x86, ARM, POWER, SPARC)

Seite 1 von 21 - Forum: Prozessoren auf overclockers.at

URL: https://www.overclockers.at/prozessoren/ernste-sicherheitslcken-in-allen-modernen-cpus-x86-arm-power-sparc_250457/page_1 - zur Vollversion wechseln!

Intel: Spekulationen über ernste Sicherheitslücke in allen CPUs

Ein Hardware-Bug in Intel-CPUs erfordert tiefgreifende Umbauarbeiten an Linux und Windows, welche obendrein die Leistung schmälern werden.

Spekulationen über eine potenziell massive Sicherheitslücke in allen Intel-CPUs sorgen aktuell für Aufsehen, weil zum Umgehen dieses Hardware-Bugs tiefgreifende Umbauarbeiten an Betriebssystemen erforderlich sind, die sich obendrein negativ auf die Leistung auswirken. AMD-CPUs sind nicht betroffen.

Die Entwickler des Linux-Kernels haben in den letzten Wochen tiefgreifende Umbauarbeiten am Virtual-Memory-Subsystem des Kernels vorgenommen. Nicht-trivialen Änderungen an diesem zentralen Teil des Linux-Kernels gehen sonst üblicherweise monate- oder jahrelange Diskussionen voraus. Und als wäre das noch nicht genug, werden diese großen Patches aktuell nicht nur in die kommende Version 4.15 des Linux-Kernels eingebaut, sondern auch in die bereits veröffentlichten und als „stabil“ deklarierten Kernel 4.9 und 4.14 zurückportiert. Aufmerksamen Beobachtern wird zunehmend klar, dass es für diese insbesondere über die Feiertage außergewöhnliche Hektik einen triftigen Grund geben muss.
...
Link: www.computerbase.de

Huge Intel CPU Bug Allegedly Causes Kernel Memory Vulnerability With Up To 30% Performance Hit In Windows And Linux | HotHardware

In a nutshell, the bug allows everyday programs to "illegally" access certain contents in protected kernel memory. The "fix", so to speak, is to implement Kernel Page Table Isolation (PTI), which, for all intents and purposes, makes the kernel invisible to running processes. In a perfect world, such training wheels shouldn't be needed to isolate the kernel, but software patches that are nearing release for Windows, Linux and macOS systems will address the exploit head-on.

There's one big problem, however. Fixing this problem in software also comes with a big hit in performance. Additional overhead is introduced to keep a barrier between address spaces, which can result in a performance handicap of 30 percent or more. However, recent Intel processors with PCID (Process-Context Identifiers) enabled could have the performance impact lessened somewhat.

Link: hothardware.com

Das ist toll. Schön langsam wird's fad mit Intel. Also die nächste Kiste wird ne AMD basierende.
Sind MAC`s auch betroffen? Die meiste Zeit arbeite ich an einem iMac mit i5.

Zitat von Linus Torvald comments

+ * User space process size. This is the first address outside the user range.
+ * There are a few constraints that determine this:
+ *
+ * On Intel CPUs, if a SYSCALL instruction is at the highest canonical
+ * address, then that syscall will enter the kernel with a
+ * non-canonical return address, and SYSRET will explode dangerously.
+ * We avoid this particular problem by preventing anything executable
+ * from being mapped at the maximum canonical address.
+ *
+ * On AMD CPUs in the Ryzen family, there's a nasty bug in which the
+ * CPUs malfunction if they execute code from the highest canonical page.
+ * They'll speculate right off the end of the canonical space, and
+ * bad things happen. This is worked around in the same way as the
+ * Intel problem.
+ *
+ * With page table isolation enabled, we map the LDT in ... [stay tuned]

Zitat aus einem Post von creative2k

Intel fängt das neue Jahr gleich an wie sie im alten aufgehört haben

Zitat aus einem Post von hctuB

gehe also davon aus das auch AMD langsamer wird.

Zitat aus einem Post von COLOSSUS

Nein.

Vom Fix beeintraechtigt werden Workloads mit vielen Kontext-Switches zwischen Kernel- und User-Mode. Hier ein Beispiel fuer ein beliebtes DB-Benchmark auf PostgreSQL: https://www.postgresql.org/message-...ap3.anarazel.de


Auch "spicy": https://danluu.com/cpu-bugs/

Zitat

+ * On AMD CPUs in the Ryzen family, there's a nasty bug in which the
+ * CPUs malfunction if they execute code from the highest canonical page.
+ * They'll speculate right off the end of the canonical space, and
+ * bad things happen. This is worked around in the same way as the
+ * Intel problem.

Linux Kernel wird zukünftig sperieren, steht dann eh weiter unten im Moment wird AMD gleich behandelt wie intel, hatte das vorher überlesen.

Zitat aus einem Post von semteX

unrelated?

Insofern unrelated da es bei AMD einen anderen bug gibt, weil du nicht ausbrechen kannst das Ding stirbt dann komplett.
Denke Chriscom bei uns hatte das Problem. Bei Intel ist es ja ein Security issue.

Da gehts aber "nur" um ASLR - das ist ja nur Schadensbegrenzung für schlecht entwickelte Software wo halt Sicherheitslücken enthalten sind.

Außer es steckt mehr dahinter als reiner "By-pass" dann wird es für Intel ernst. Aber dazu hab ich bis jetzt nur Spekulationen gehört.

AMD ist davon recht sicher nicht betroffen. Könnte aber bei einem "Fix" mit unter die Räder kommen.
Das soll jetzt nicht heißen dass AMD nicht auch ihre Probleme haben

die konkrete angst ist, dass du mit der lücke aktiv hypervisoren angreifen kannst, was für cloud dienste die hölle wär

Die Frage is ob Hypervisoren davon betroffen sind da man von einer Virtuellen Maschiene den Speicher der anderen gar nicht sehen kann. Ist ja genau das was jetzt in den Kernel eingebaut wird, dass aus dem Userprozess der Kernel speicher gar nicht sichtbar ist.

Oder lauert da noch irgendwas was noch nicht publik ist.

@Semtex
Das ist die Angst bei fast jeder Lücke.
Hier gehts aber um ASLR, was selbst ja nichts wirklich sicherer macht sondern nur erschweren soll das man Softwarefehler ausnützt.

@ZARO
Man sollte den Speicher übergreifend nicht sehen, durch solche Lücken kann es aber vorkommen das man aus einer VM ausbricht und dann zugriff auf den Hypervisor bekommt.

Das was aktuell bekannt ist seh ich das Problem noch nicht so tragisch. ASLR sollte man prinzipiell ja nicht benötigen wenn man sauberen Code hat.
Aber da brodelt noch was rum weshalb ich vermute dass da doch mehr dahinter steckt.

Zitat aus einem Post von Viper780

Hier gehts aber um ASLR, was selbst ja nichts wirklich sicherer macht sondern nur erschweren soll das man Softwarefehler ausnützt.

overclockers.at v4.thecommunity
© all rights reserved by overclockers.at 2000-2025