Meltdown & Spectre: Sicherheitsrisiken durch Spekulation bei aktuellen Prozessoren [Archiv]

davidzo

2018-01-02, 15:16:40

UPDATE: Erste Tests zu den Leistungseinbußen: Anscheinend ist der PTI Patch von Microsoft seit Ende November schon über das Insider Preview (Build 17063) vom Win10 Fall Creators Update, verfügbar. In der Theorie sind nur i/o lastige Szenarien betroffen wo eine nennenswerte Anzahl an Kontextswitches zwischen kernel und User erfolgt. Daher wurde hier von CB und Phoronix besonders getestet.

Tests von CB mit Samsung 960Pro (i/o-Lastig): https://www.computerbase.de/2018-01/intel-cpu-pti-sicherheitsluecke/#update2
-2-7%

Tests von Hardwareluxx in Spielen: https://www.hardwareluxx.de/index.php/news/hardware/prozessoren/45319-intel-kaempft-mit-schwerer-sicherheitsluecke-im-prozessor-design.html#x3634d73fcb915e47afd26e0d5bfc66d2
0%

Linux Filesystem Benchmarks (FS-Mark) von Phoronix: https://www.phoronix.com/scan.php?page=article&item=linux-415-x86pti&num=2
-12-110%

Linux gaming Performance von Phoronix: https://www.phoronix.com/scan.php?page=news_item&px=x86-PTI-Initial-Gaming-Tests
0%

Originalartikel:

Es geht gerade die News herum dass Intel einen schwerwiegenden Bug hat, der ein regelmäßiges flushen des TLB bei Syscalls erforderlich macht. Das negiert einen Großteil der Performancegewinne durch spekulatives Prefetching.

http://pythonsweetness.tumblr.com/post/169166980422/the-mysterious-case-of-the-linux-page-table

Over the past day you've likely heard lots of hysteria about a yet-to-be-fully-disclosed vulnerability that appears to affect at least several generations of Intel CPUs and affects not only Linux but also Windows and macOS. The Intel CPU issue comes down to leaking information about the kernel memory to user-space, but the full scope isn't public yet until the bug's embargo, but it's expected to be a doozy in the data center / cloud deployments.

Wahrscheinlich ist mit ähnlichen Performanceinbußen wie bei Phenom I Barcelona zu rechnen, die Fachleute reden von im Mittel 5%, aber biszu 30% in Randszenarien. Damals ist der TLB-Bug AMD selber aufgefallen und ein patch wurde noch veröffentlicht während die cpus in den Handel kamen gefolgt von einem fehlerbereinigten stepping.

The software fix for this Intel CPU problem for Linux/Windows/macOS is expected to introduce a performance penalty and reports are anywhere from 5% to 30%.

Ältere CPU Architekturen brechen noch stärker ein, da hier PCID nicht für schnelleres flushen des TLBs genutzt werden kann. Anscheinend wurde PCID von Intel aber schon für westmere eingeführt, das betrifft also nur wirklich alte Architekturen.
https://news.ycombinator.com/item?id=16047564

Das peinliche für Intel ist, dass ihnen der Fehler seit Jahren nicht aufgefallen ist bzw. jetzt von fremden Entwicklern der TU Graz gefunden wurde. Nach dem ME-Fiasko stellt dies Intels Vertrauenswürdigkeit bzw. Securitystrategie schon wieder in Frage: Wusste man von dem Fehler und hat bewusst geschwiegen um den Skandal zu vermeiden oder hatte man selber keine Ahnung?

Der Linux Patch ist bereits live, Microsoft arbeitet an ähnlichem:
https://t.co/7PriLIJHe1

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

Was noch unklar ist:

Ist der Patch bei AMD wirklich automatisch deaktiviert? Es gibt Berichte mit aktiviertem Flag würde ein Epyc biszu 49% performance verlieren: https://twitter.com/grsecurity/status/947439275460702208?ref_src=twsrc%5Etfw
Welche Intel CPU Architekturen sind betroffen und seit wann? Schließt dies Goldmont, Airmont, Silvermont auch ein oder ist das nur ein Core Problem?
Wann reagiert Apple auf das Problem? - Nach Apples obscurity-Strategie wird es vermutlich erst eine Presseerklärung geben wenn der Patch ausgeliefert ist...

Fefe hält die Aufregung für übertrieben, da er "Address space layout randomization" als Hardwarefeature sowieso für eine billige Ausrede für eine echte Securitystrategie in der eigenen Software hält.
http://blog.fefe.de/?ts=a4b423a5
Aus Sysadmin-Sicht hat er imo recht, das fällt in die Sparte Security by Obscurity wie Self-encrypting devices und ist am Ende gar nichts wert oder nur ein gefährliches zusätzliches Einfallstor wie Intels ME nachdem die Bugs bekannt wurden.
Security muss immer überprüfbar und patchbar sein und deshalb in Software laufen. Alles andere wird irgendwann kompromittiert.

Edit: Fefe regt sich nun doch auf weil er ne Ahnung bekommen hat um was es gehen könnte:
Es sieht so aus, als sei das mehr als ASLR-Bypass, als könne man so vom User Space aus Kernel Memory lesen. AMD ist nicht betroffen, wie es aussieht.
Ist das schlimm? Ja, ist es. Der Kernel hat beispielsweise der Buffer Cache im Speicher, und da könnten Inhalte aus irgendwelchen Dateien stehen, die der User sonst nicht lesen könnte, ich sage mal Krypto-Schlüssel oder so. Oder vielleicht die letzten Tastendrücke, und so könnte man die Passphrase auslesen. Das ist ein Riesenproblem. Das ist schlimm genug, dass Intel ein Recall droht, wenn wir sie da jetzt nicht um irgendwelchen Performance-killenden Maßnahmen drumherummogeln lassen.

Der Intel CEO Brian Krzanich hat im November für 11Mio $ Intel Aktienoptionen abgestoßen, das Maximum was ihm erlaubt war. Seit November ist der Fehler wohl bei Microsoft und einigen Kernel Entwicklern bekannt.
https://www.fool.com/investing/2017/12/19/intels-ceo-just-sold-a-lot-of-stock.aspx
Das ist ein klares Zeichen das Krzanich nicht mehr an die selbstgesetzten hohen Growth Targets für 2018 glaubt, sondern kurzfristige massive EInbrüche kommen sieht.

TwoBeers

2018-01-02, 15:20:49

Ich hoffe ja inständig, dass der Fix bei AMD deaktiviert ist.
Ich sehe es schon kommen, Intel reißt Sicherheitslücken auf und AMD CPUs verlieren bis zu 50% Performance .. muhaha. ;)

Mr.Bug

2018-01-02, 15:30:03

Ich hoffe ja inständig, dass der Fix bei AMD deaktiviert ist.
Ich sehe es schon kommen, Intel reißt Sicherheitslücken auf und AMD CPUs verlieren bis zu 50% Performance .. muhaha. ;)

Die Schadenfreude kannst dir sparen, denn tatsächlich sind AMD CPU's von dieser schwerwiegenden Lücke nicht betroffen!

"AMD processors are not subject to the types of attacks that the kernel page table isolation feature protects against. The AMD microarchitecture does not allow memory references, including speculative references, that access higher privileged data when running in a lesser privileged mode when that access would result in a page fault."

Details:

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

Die Patcherei wird "lustig" für viele Admins...

Dino-Fossil

2018-01-02, 15:30:35

Was mich bisschen wundert - gibt es nicht teils wegen jedem Pups, der am Kernel gemacht wird eine riesige Diskussion und hier wird das alles angeblich durchgewunken?

davidzo

2018-01-02, 15:33:28

Für die Admins ist die Patcherei wirklich aufwändig und eventuell geht das blinde Vertrauen in den Marktführer etwas zurück, die 5% performancehit sind denen aber weitgehend egal.

Aber sobald Microsoft geliefert hat, sehen wir auch die Auswirkungen auf den Consumermarkt. Wenn da ähnliche Performance-Implikationen sind wie bei den Linuxpatches, dann könnte das den Markt komplett umkrempeln. 5% Performancedifferenz könnte Ryzen wieder vor Coffe-lake positionieren, mit dem folgenden Start von Ryzen2 im März könnte das ein Erdrutschgewinn für AMD im X86 Markt auslösen!

Loeschzwerg

2018-01-02, 15:37:05

Wie sieht das denn mit LTSS Distributionen aus, also z.B. SLES 11 SP4? Wird da auch was gepatcht?

Dino-Fossil

2018-01-02, 15:38:46

Bisher ist mMn noch nicht ganz klar, ob das Consumer-CPUs überhaupt groß betrifft.
Die Lücke klingt mir eher nach einem Problem für Server und Rechenzentren, da es dort massive Sicherheitslücken aufreißen kann.

davidzo

2018-01-02, 15:39:22

https://www.forum-3dcenter.org/vbulletin/showthread.php?t=585993

Wie sieht das denn mit LTSS Distributionen aus, also z.B. SLES 11 SP4? Wird da auch was gepatcht?

Nope, SP4 hat noch einen 3.0er Kernel. Der älteste Kernel der mit PTI ausgerüstet wird ist 4.9
- Das bedeutet für Sysadmins jetzt viele viele überstunden weil außerplanmäßig eine neue Upgradestrategie entwickelt werden muss. Das einfachste wird wohl sein manuell einen neueren Kernel in SLES zu installieren, dafür wird man wohl aber einige compliance-regeln biegen müssen...

davidzo

2018-01-02, 15:42:14

So wie ich das verstanden habe betrifft dies jeden Kontext-switch zwischen Prozessen und Kernel. Normale Betriebssysteme haben ja auch memory protection und sandboxing bei manchen Anwendungen. Nur sind da wohl die Kontext-switches wesentlich seltener als bei dicken VM-Maschinen, wo tausende Prozesse vor sich hin idlen, also eventuell sind die performance-Auswirkungen geringer.

With the page table splitting patches merged, it becomes necessary for the kernel to flush these caches every time the kernel begins executing, and every time user code resumes executing.

Linux Disk Usage klingt irgendwie nicht nach VM-spezifischer Software:

No older systems here to test, but just to get a sense of how much PCID helps the PTI performance hit on post-Westmere (in our experience with UDEREF and using PCID since 2013, it about halved it): 63% hit on the same Skylake i7-6700 w/ the du -s benchmark and nopcid/noinvpcid

Natürlich ist das Security-Risiko bei VM Hypervisorn am größten, da hier SLAs gebrochen werden können die empfindliche Strafen kosten.
Auch wenn der Bug noch sehr theoretisch ist, so wie Rowhammer, hat jeder Kunde der eine VM gebucht hat einen Hammer in der Hand das System inklusive der VMs anderer Kunden zu kompromittieren.

Auf einem Clientrechner ist es unwahrscheinlicher dass man sich Code herunterlädt und ausführt der dann dem Code einer anderen Anwendung schadet, aber auch nicht völlig abwegig. Es geht hier um einen Angriff aus dem Userland, irgendwie muss die Anwendung also schon in den Speicher gekommen haben und Ressourcen zugeteilt bekommen haben.

Vermutlich wird Microsoft den Patch trotzdem an alle ausrollen, das wäre sonst zu einladend für Hacker mal zu testen was das für Consumer bedeutet. Das war ja mit dem Phenom1 TLB-Bug auch nicht anders, reproduzierbar nur im Labor, aber den Patch haben trotzdem alle bekommen.

BoMbY

2018-01-02, 15:53:06

Was mich bisschen wundert - gibt es nicht teils wegen jedem Pups, der am Kernel gemacht wird eine riesige Diskussion und hier wird das alles angeblich durchgewunken?

Wenn Linus mitspielt ist prinzipiell alles möglich.

Loeschzwerg

2018-01-02, 16:07:09

Nope, SP4 hat noch einen 3.0er Kernel. Der älteste Kernel der mit PTI ausgerüstet wird ist 4.9

Ich sehe da ja eigentlich SUSE in der Pflicht :D Mal schauen ^^

Den Kernel komplett hochzuziehen oder die HW zu tauschen ist beides nicht ohne weiteres möglich.

MikePayne

2018-01-02, 16:17:44

Wenn (und danach sieht es aus) der TLB angefasst werden muss bzw beeinträchtigt ist, dann wird das sehr wohl auch alle Consumer treffen. Wenn es dann nur 5% sind, freut euch.

Dino-Fossil

2018-01-02, 16:31:08

Das der TLB für Consumer-Systeme ebenfalls wichtig ist ist mir schon klar, die ersten Berichte zu diesem Bug klangen für mich eben mehr danach, dass die Sicherheitsprobleme, die aus ihm resultieren Systeme betreffen, die z.B. zahlreiche VMs betreiben.
Aber vielleicht gibt es auch reale Bedrohungen für Durchschnittsanweder.

gravitationsfeld

2018-01-02, 16:56:59

Soweit ich da zwischen den Zeilen lese gibt es eine Moeglichkeit Kernel-Speicher vom User-Space zu lesen. Das ist *absolut* ein Problem fuer Consumer-Maschinen und muss gepatcht werden.

davidzo

2018-01-02, 17:04:01

Was mich bisschen wundert - gibt es nicht teils wegen jedem Pups, der am Kernel gemacht wird eine riesige Diskussion und hier wird das alles angeblich durchgewunken?

Das könnte so gedeutet werden dass die Lücke anscheinend besonders heftig ist und man sich ein zögern da nicht erlauben kann. Das Problem bei VM Hypervisorn ist dass diese durch SLAs gebunden sind und potentiell enorme finanzielle Schäden eintreten können, wenn man die Compliance nicht mehr garantieren kann, Praxis hin oder her.

Usually I go into these things with a fair amount of skepticism but given the linux kernels usual pace of development and the nature of undisclosed bugs we have seen in the past this seems like a large hypervisor bug could be the reality. It must be pretty bad if its the kind of bug that they can't really fix easily, and have to push through an entire new feature into something as old and important as the paging code.
https://news.ycombinator.com/item?id=16047530

Gipsel

2018-01-02, 17:06:07

Soweit ich da zwischen den Zeilen lese gibt es eine Moeglichkeit Kernel-Speicher vom User-Space zu lesen. Das ist *absolut* ein Problem fuer Consumer-Maschinen und muss gepatcht werden.Ja, was CB dazu schreibt und auch AMDs (wohl noch inoffizielles) Statement scheinen darauf hinzudeuten, daß man eventuell irgendwie an Daten kommt (die per Prefetch spekulativ geladen wurden?), auch wenn sie eigentlich zum Kernel gehören und gegen Zugriff geschützt sein sollten.

Ganon

2018-01-02, 17:10:03

Das Lustige an dem Bug ist nur, dass es ein Hardware-Fehler ist, der per Kernel-Update umgangen werden muss. Das Sicherheitsproblem an sich ist aber relativ "Standard" und kein Armageddon wie es auf diversen Seiten und Foren so dargestellt wird.

Ist natürlich ein schwerer Fehler, aber auch nicht der erste schwere Fehler :D

gravitationsfeld

2018-01-02, 17:12:55

Das man Kernel-Speicher vom User-Space aus lesen kann ist kein "Standard"-Sicherheitsproblem. Nicht mal ansatzweise. Das ist praktisch der GAU.

Hardware-Fehler im Kernel zu fixen ist gaengige Praxis.

davidzo

2018-01-02, 17:15:54

Ja, was CB dazu schreibt und auch AMDs (wohl noch inoffizielles) Statement scheinen darauf hinzudeuten, daß man eventuell irgendwie an Daten kommt (die per Prefetch spekulativ geladen wurden?), auch wenn sie eigentlich zum Kernel gehören und gegen Zugriff geschützt sein sollten.
Den Comments bei Hackernews entnehme ich dass es sich hier wahrscheinlich um ein Rowhammer-ähnliches Phänomen bei den SRAM-Zellen des TLBs handelt.

It's a hardware level thing. Essentially, when you start rapidly flipping a single bit, that starts to 'leak' some current to the adjacent physical bits. This then allows you to flip a single bit. Especially if you can control bits on both sides of your target.
https://news.ycombinator.com/item?id=16047668

Aber Rowhammer ist angeblich eher eine Laborsituation und ansonsten ziemlich Praxisfremd: Just curious: Even after an attacker goes through all the effort of finding out the physical address of the memory location they want to manipulate, how would someone make sure to get an adjacent memory location to even attempt to execute the Rowhammer attack? And even then, the smallest memory units allocated are basically pages within page frames, right? So if your target memory row is within a physical page frame, does the RowHammer attack even work? (Since there's no adjacent row an attacker has access to then.)
https://news.ycombinator.com/item?id=16047303

Auf der anderen Seite gibt es aus Rowhammerbasis angeblich schon erfolgreiche jailbreaking Routinen doe einfach brute forcing machen bis es klappt. Das würde heißen es ist schon eine praxistaugliche Methode: https://news.ycombinator.com/item?id=16047541

Das der TLB für Consumer-Systeme ebenfalls wichtig ist ist mir schon klar, die ersten Berichte zu diesem Bug klangen für mich eben mehr danach, dass die Sicherheitsprobleme, die aus ihm resultieren Systeme betreffen, die z.B. zahlreiche VMs betreiben.
Aber vielleicht gibt es auch reale Bedrohungen für Durchschnittsanweder.

Soweit ich da zwischen den Zeilen lese gibt es eine Moeglichkeit Kernel-Speicher vom User-Space zu lesen. Das ist *absolut* ein Problem fuer Consumer-Maschinen und muss gepatcht werden.

Anscheinend ja:

This affects more than just cloud providers though; that is just one of the more high-profile implications of this potential bug
https://news.ycombinator.com/item?id=16047328

gravitationsfeld

2018-01-02, 17:18:23

Den Comments bei Hackernews entnehme ich dass es sich hier wahrscheinlich um ein Rowhammer-ähnliches Phänomen bei den SRAM-Zellen des TLBs handelt.
Das waere extrem kurios. SRAM im Chip ist immer ECC geschuetzt. Und generell ist SRAM eigentlich nicht von sowas wie Rowhammer betroffen.

Ganon

2018-01-02, 17:19:20

Das man Kernel-Speicher vom User-Space aus lesen kann ist kein "Standard"-Sicherheitsproblem. Nicht mal ansatzweise. Das ist praktisch der GAU.

Es gab auch im Vorfeld schon Hypervisor-Lücken, in der du aus einer VM ausbrechen kannst und fröhlich mit root-Rechten dich auf dem Host bewegen konntest. Wüsste nicht was für den normalen Admin hier anders ist. Er muss ein Update einspielen und den Host rebooten.

Genauso wie er es bei Microcode-Updates und anderen Kernel-Lücken auch tun muss. Das was zur Behebung der Lücke getan werden muss ist nichts besonderes. Man muss Updates einspielen.

Ein GAU ist für mich eine unpatchbare Lücke, oder Lücken die eine komplette Feature-Abschaltung inkl. Einschränkungen benötigen. Hier verliert man "nur" ein paar % Performance. Wecke mich wenn ich ein EFI-Update einspielen muss, um solche Lücken zu patchen.

davidzo

2018-01-02, 17:23:10

ECC doesn't protect you from from all rowhammer problems because they can flip more than two bits at a time, the limit which ECC can detect.
"Tests show that simple ECC solutions, providing single-error correction and double-error detection (SECDED) capabilities, are not able to correct or detect all observed disturbance errors because some of them include more than two flipped bits per memory word"

https://en.wikipedia.org/wiki/Row_hammer#Mitigation

Vielleicht ist es auch kein Zufall das Apple ausgerechnet jetzt nur noch auf ECC Ram im neuen imac setzt obwohl das Performance kostet. Bei den RAMgrößen heutzutage und der Fertigungstechnologie ist ein erfolreicher Rowhammer Angriff langsam wesentlich wahrscheinlicher als früher. Dass aktueller RAM verwundbar ist hat ja nichts mit dem konkreten Bug zutun und ist schon länger bekannt, ECC hilft - ist aber keine Garantie.

Ganon

2018-01-02, 17:31:21

Vielleicht ist es auch kein Zufall das Apple ausgerechnet jetzt nur noch auf ECC Ram im neuen imac setzt obwohl das Performance kostet.

Apple hatte in ihrer Desktop-Pro-Linie schon immer ECC-RAM. Und so viel Performance kostet das nicht. Würde mich wundern, wenn das überhaupt sinnvoll messbar wäre. Anders sieht es vermutlich bei Registered RAM aus, in Spezialfällen.

Darum sehe ich auch keinen Grund, warum ECC nicht überall eingesetzt wird. Würde Intel es nicht künstlich limitieren wäre das mit der Verbreitung auch nicht so das Problem.

Tech_FREAK_2000|GS

2018-01-02, 17:53:59

Ich sehe da ja eigentlich SUSE in der Pflicht :D Mal schauen ^^

Den Kernel komplett hochzuziehen oder die HW zu tauschen ist beides nicht ohne weiteres möglich.

SUSE hat ja in der Vergangenheit schon immer Security Bugfixes in den alten Kernel Rückportiert, ähnlich wie es auch RedHat durchführt.
Daher sollte es nur eine Frage der Zeit sein, bis (wieder) ein Kernel-Update für SLE11 bereitsteht (technische Machbarkeit vorausgesetzt).

in der Mailing-Liste sowie in den SUSE Update Advisories gibt es zumindest noch nichts neues. Wie es bei Redhat aussieht, kann ich nicht sagen.

Das letzte Kernelupdate für SLE11 SP4 ist von Dezember.
https://www.suse.com/de-de/support/update/announcement/2017/suse-su-20173265-1/

gravitationsfeld

2018-01-02, 17:58:28

Apple hatte in ihrer Desktop-Pro-Linie schon immer ECC-RAM. Und so viel Performance kostet das nicht. Würde mich wundern, wenn das überhaupt sinnvoll messbar wäre. Anders sieht es vermutlich bei Registered RAM aus, in Spezialfällen.

Darum sehe ich auch keinen Grund, warum ECC nicht überall eingesetzt wird. Würde Intel es nicht künstlich limitieren wäre das mit der Verbreitung auch nicht so das Problem.
ECC kostet nur Leistung wenn aktives Scanning aktiviert ist.

Es gab auch im Vorfeld schon Hypervisor-Lücken, in der du aus einer VM ausbrechen kannst und fröhlich mit root-Rechten dich auf dem Host bewegen konntest. Wüsste nicht was für den normalen Admin hier anders ist. Er muss ein Update einspielen und den Host rebooten.
Andere Liga. Wir sprechen hier von einer Luecke, die nicht nur Hypervisor betrifft, sondern alle Betriebssysteme auf allen Intel-CPUs der letzten Jahre. Ausserdem ist es mit einem ziemlich grossen Performance-Hit verbunden.

LadyWhirlwind

2018-01-02, 18:04:47

Es gab auch im Vorfeld schon Hypervisor-Lücken, in der du aus einer VM ausbrechen kannst und fröhlich mit root-Rechten dich auf dem Host bewegen konntest. Wüsste nicht was für den normalen Admin hier anders ist. Er muss ein Update einspielen und den Host rebooten.

Genauso wie er es bei Microcode-Updates und anderen Kernel-Lücken auch tun muss. Das was zur Behebung der Lücke getan werden muss ist nichts besonderes. Man muss Updates einspielen.

Ein GAU ist für mich eine unpatchbare Lücke, oder Lücken die eine komplette Feature-Abschaltung inkl. Einschränkungen benötigen. Hier verliert man "nur" ein paar % Performance. Wecke mich wenn ich ein EFI-Update einspielen muss, um solche Lücken zu patchen.

Alles was noch Support für Sicherheitspatches hat, wird den Patch dafür auch bekommen. Wer irgendwo was anderes in grösseren Mengen einsetzt ist einfach selber Schuld.

Solange es nur ein paar Prozent Performance-Verlust sind, geht das noch. Wird gehandhabt wie jeder anderer Sicherheitspatch. Wer grössere Mengen an Systemem betreibt hat ja wohl hoffentlich einen Plan wie man notfllmässig auf allen Systemen einen Patch ausrollt. Problematisch wird es erst wenn die Performance zu stark darunter leidet oder andere benötigen Funktionen nicht mehr funktionieren. Was zu stak ist, ist natürlich relativ.

Solange man den Performance-Hit mit mehr physikallischen Ressourcen bekämpfen kann, kostet es zwar Geld, ist aber immer noch handhabbar.

Ein GAU haben wir erst, wenn gewissen Szenarien nicht mehr funktionieren und es dort zu einem massiven Kostenschub kommt.

Ganon

2018-01-02, 18:12:23

Andere Liga. Wir sprechen hier von einer Luecke, die nicht nur Hypervisor betrifft, sondern alle Betriebssysteme auf allen Intel-CPUs der letzten Jahre. Ausserdem ist es mit einem ziemlich grossen Performance-Hit verbunden.

Dass die Lücke schwer ist ist klar. Aber trotzdem reicht ein Sicherheitsupdate, ein apt upgrade, ein yum upgrade, ein pacman -Syu oder was auch immer man für ein Update-Tool benutzt... und nach einem Reboot ist das Problem weg. So wie 50 andere Lücken auch.

Und der Performance-Hit muss sich noch zeigen. Die 50% kamen bisher nur von einem AMD-Prozessor, den der Patch mittlerweile gar nicht mehr betrifft. Andere Seiten reden von 5%...

Wenn du andere Werte hast, immer her damit.

gravitationsfeld

2018-01-02, 18:26:42

Die 50% sind von einem Micro-Benchmark der ueber Syscalls loopt. Das wird auch auf Intel-HW nicht anders aussehen.

Diese Prozent-Angaben sind voellig uninteressant. Es kommt auf den Workload an. I/O-Sachen wie Datenbanken werden wegbrechen ohne Gnade. Linpack wird 0% betroffen sein.

BlackArchon

2018-01-02, 18:33:13

Vielleicht ist es auch kein Zufall das Apple ausgerechnet jetzt nur noch auf ECC Ram im neuen imac setzt obwohl das Performance kostet. Bei den RAMgrößen heutzutage und der Fertigungstechnologie ist ein erfolreicher Rowhammer Angriff langsam wesentlich wahrscheinlicher als früher. Dass aktueller RAM verwundbar ist hat ja nichts mit dem konkreten Bug zutun und ist schon länger bekannt, ECC hilft - ist aber keine Garantie.
Apple hatte in ihrer Desktop-Pro-Linie schon immer ECC-RAM. Und so viel Performance kostet das nicht. Würde mich wundern, wenn das überhaupt sinnvoll messbar wäre. Anders sieht es vermutlich bei Registered RAM aus, in Spezialfällen.

Darum sehe ich auch keinen Grund, warum ECC nicht überall eingesetzt wird. Würde Intel es nicht künstlich limitieren wäre das mit der Verbreitung auch nicht so das Problem.
Das Märchen, dass ECC- oder Registered ECC-RAM irgendwie nennenswert Performance kostet, stirbt einfach nicht aus: https://www.techspot.com/article/845-ddr3-ram-vs-ecc-memory/

gravitationsfeld

2018-01-02, 18:41:19

Registered RAM erhoeht die Latenz, das sollte messbar sein. ECC ist aber orthogonal dazu.

maguumo

2018-01-02, 18:51:05

del

lumines

2018-01-02, 19:10:44

Das ist ein Subscriber-Link. Die Paywall ist noch immer aktiv. Ist nur ein nettes Feature von LWN, dass Subscriber einen eigenen Link bekommen, den sie mit anderen Leuten teilen können. Den öffentlich zu posten ist AFAIK in kleinem Umfang in Ordnung, aber nur so als Hinweis, dass der Artikel noch immer hinter einer Paywall ist.

fondness

2018-01-02, 19:17:38

Sehe ich das richtig: Jeder Intel-Prozessor von Westmere bis zum aktuellsten Modell ist betroffen (und damit praktisch jeder aktuell noch im Einsatz befindliche Intel-Prozessor), ein Fix kann also frühestens mit Ice-Lake kommen und der Performance-Hit liegt je nach Use-Case bei 5-50%? Wundert mich, dass es hier so ruhig ist, das doch eine absolute Katastrophe. Gerade im Server-Bereich mit viel I/O könnte das spannend werden mit Schadensersatzforderungen.

Loeschzwerg

2018-01-02, 19:27:32

Öh ja, ich habe die Info zumindest gleich weitergeleitet, abwarten wie die Experten bei uns das Thema bewerten.

SUSE hat ja in der Vergangenheit schon immer Security Bugfixes in den alten Kernel Rückportiert, ähnlich wie es auch RedHat durchführt.
Daher sollte es nur eine Frage der Zeit sein, bis (wieder) ein Kernel-Update für SLE11 bereitsteht (technische Machbarkeit vorausgesetzt).

So ist auch meine Erfahrung, aber es bleibt natürlich die Frage wie einfach das technisch umsetzbar ist, da bin ich zumindest lange nicht tief genug in der Materie drin.

Ganon

2018-01-02, 19:36:27

Schadensersatz-Forderungen sind auch albern. Ist nicht das erste Prozessor-Feature was abgeschaltet/umgangen werden musste, weil etwas nicht funktionierte. Sowohl Intel als auch AMD (http://www.tomshardware.de/AMD-Barcelona-TLB-Fehler,news-240233.html) hatten schon diverse krasse Bugs in ihren CPUs, die nach dem fix Performance-Einbußen brachten. Auch diverse SSDs mussten nachträglich um Performance-Features erleichtert werden, weil sie nicht funktionierten. Wir erinnern uns auch gerne noch an den AMD Ryzen "Compiler-Bug" der einen CPU-Austausch erfordert... oder eben Intels TSX Bug...

Das ganze Thema ist im Grunde eine normale Sicherheitslücke. Die wird gefixt mit ihren Auswirkungen. Den Einen trifft es mehr, den Anderen weniger. Bin auch gespannt wie stark der Performance-Hit in Real-World Anwendungen dann so ist. Aber die 50% sind Micro-Benchmarks.

gravitationsfeld

2018-01-02, 19:48:31

Dein Astroturfing kannst du bleiben lassen. Der Overhead wird messbar sein bei Datenbank-Anwendungen und deutlich ueber 5% liegen.

Ganon

2018-01-02, 19:50:12

Dein Astroturfing kannst du bleiben lassen. Der Overhead wird messbar sein bei Datenbank-Anwendungen und deutlich ueber 5% liegen.

Als wenn ich irgendwas anderes behauptet habe :ugly:

gravitationsfeld

2018-01-02, 20:23:13

Du versuchst die ganze Zeit zu relativieren.

Ganon

2018-01-02, 20:49:00

Du versuchst die ganze Zeit zu relativieren.

Und Andere versuchen hier gerade ein Super GAU daraus zu machen. Ich bin in dem Umfeld tätig. Vor Sicherheits-GAU kann ich gerade nur schmunzeln bei all den Lücken in all der Hard- und Software die letzten Jahre. Performance-GAU muss sich erst zeigen, wie gesagt... abseits von Edge-Cases. I/O-lastiges Datawarehousing hat vielleicht ein paar relevante Messwerte dann. Bei 08/15 WebApps ist es relativ egal ob die Query 1ms oder 5ms läuft, wenn der fette App-Stack oben drauf eh noch mal 400ms hinzufügt.

Skysnake

2018-01-02, 21:16:51

Also für HPC könnte das schon ein ziemlich böser Bug sein.

Aber nicht nur da. Auch Datenbanken und vor allen Filesysteme werden darunter wohl ziemlich Böse leiden.

Gerade Filesysteme, also meta daten Operationen sind oft schon jetzt ein ziemliches Problem. Da tun selbst 5% ziemlich weh, wobei es wohl sehr wahrscheinlich deutlich mehr sein können.

Also das könnte echt noch interessant werden in den nächsten Tagen.

Auch bei Games erwarte ihr eher höhere Verluste.

Nakai

2018-01-02, 21:18:01

Anscheinend sind auch AMDs betroffen. Ein Kollege von mir der im Bereich Hypervising tätig ist, meinte dass auch ARM64 davon betroffen ist. Da wird auch einiges noch unter Verschluss gehalten.

Wake

2018-01-02, 21:30:06

ARM64 wurde ja schon bestätigt:
Just in case there are any smug ARM-based readers out there, it's worth noting that there is an equivalent patch set for arm64 in the works. (https://lwn.net/Articles/740393/)

AMD wäre aber neu.

gravitationsfeld

2018-01-02, 21:31:15

LadyWhirlwind

2018-01-02, 21:37:25

ARM64 wurde ja schon bestätigt:
AMD wäre aber neu.

AMD processors are not subject to the types of attacks that the kernel
page table isolation feature protects against. The AMD microarchitecture
does not allow memory references, including speculative references, that
access higher privileged data when running in a lesser privileged mode
when that access would result in a page fault.

Quelle: https://lkml.org/lkml/2017/12/27/2

Ganon

2018-01-02, 21:40:07

ARM64 wurde ja schon bestätigt

Man muss jetzt aber unterscheiden, ob es ein Flag für weiteres Security-Hardening ist oder ob es (wie jetzt bei Intel) "Pflicht" ist, weil sonst eine Sicherheitslücke offen ist.

Flags für höhere Sicherheit mit teilweise großen Performance-Einbußen bis hin zur kompletten "Unbrauchbar-Machung" von Dingen wie normalen Just-In-Time Compilern ist alles da. Wird in der Regel nur nicht eingeschaltet.

Wake

2018-01-02, 21:44:09

@LadyWhirlwind:
Habe ich auch schon gelesen, bezogen auf Nakais Kommentar (oder Kollegen?) wärs daher überraschend weil ja AMD explizit davon ausgenommen wurde.

Nakai

2018-01-02, 22:02:43

Warten wir mal ab. Ich hoffe dass AMD nur cht betroffen ist. Nein Kollege meinte, dass es auch AMD betrifft. Aber das passt nicht zur Aussage von AMD.

LadyWhirlwind

2018-01-02, 22:21:10

Warten wir mal ab. Ich hoffe dass AMD nur cht betroffen ist. Nein Kollege meinte, dass es auch AMD betrifft. Aber das passt nicht zur Aussage von AMD.

AMD ist insoweit betroffen, dass die Fixes wenn sie auf einem AMD System aktiv sind, auch dort zu einer Performanceeinbusse führen.

Bis jetzt war eigentlich nur davon zu lesen, dass Intel betroffen ist und das für ARM64 auch entsprechende Patches vorbereitet werden, wobei diese auch präventiv sein könnten.

Sorgen mache ich mir hauptsächlich um die Datenbankserver bei unseren Kunden.

Nakai

2018-01-02, 22:30:34

AMD ist insoweit betroffen, dass die Fixes wenn sie auf einem AMD System aktiv sind, auch dort zu einer Performanceeinbusse führen.

Bis jetzt war eigentlich nur davon zu lesen, dass Intel betroffen ist und das für ARM64 auch entsprechende Patches vorbereitet werden, wobei diese auch präventiv sein könnten.

Sorgen mache ich mir hauptsächlich um die Datenbankserver bei unseren Kunden.

Also AMD ist wohl nicht betroffen. Alle Vendors werden derzeit blackgelistet. Jeder Vendor muss sich selber whitelisten. Für AMD kommt wohl ein Patch zum whitelisten rein.
Mal gucken wie sich das auf die Zusammensetzung der Serversysteme auswirkt.

hmmm

2018-01-02, 22:35:08

Warten wir mal ab. Ich hoffe dass AMD nur cht betroffen ist. Nein Kollege meinte, dass es auch AMD betrifft. Aber das passt nicht zur Aussage von AMD.
AMD ist nicht betroffen, nachdem das rumpatchen begonnen hatte, stellte AMD schon inoffiziell klar, dass man nicht betroffen sei. Die Reaktion kam für AMD relativ schnell, glaube denen ist schon das Herz in die Hose gerutscht.

Ganon

2018-01-02, 22:52:05

Ja wie ich sagte. Auf der einen Seite haben wir das Sicherheitsfeature "Kernel page-table isolation" und auf der anderen Seite den Bug in den Intel CPUs.

"Kernel page-table isolation" ist auch ohne Hardware-Bug ein sinnvolles hardening-feature, kostet jedoch Leistung (wie so viele Sicherheits-Features). Darum ist das prinzipiell erst mal abgeschaltet.

Nun haben wir aber buggy x86-CPUs, darum wurde erst mal global für alle x86er ein Flag "X86_BUG_CPU_INSECURE" gesetzt. Dieser Flag ist ein Flag, der wiederum das "Kernel page-table isolation" Feature (X86_FEATURE_PTI) einschaltet.

AMD kam nun (https://lkml.org/lkml/2017/12/27/2) und sagte, dass ihre Prozessoren nicht betroffen sind und hat eine simple Abfrage im Stil von "if vendor != AMD" davor gesetzt. Was Microsoft jedoch macht ist aber nicht ersichtlich, da Closed-Source, aber vermutlich läuft es hier dann ähnlich.

Also im Prinzip generell eine andere Auslegung: Der Patch fixt nicht den TLB Bug in den Intel CPUs, sondern der Patch schaltet eine allgemeine Sicherheitsfunktion im Kernel standardmäßig ein, damit der Bug keine Auswirkungen hat. Also um das mal zusammenzufassen. D.h. nur weil jemand KPI für ARM AArch64 implementiert, heißt es nicht, dass die CPUs auch buggy sind.

Weiterhin kann man mittels Kernel-Boot-Paramter pti=off den Kram jederzeit manuell abschalten, falls die Performance-Einbußen doch zu heftig sein sollten. Muss man nur die Sicherheitsprobleme in Betracht ziehen. Da muss Intel nun durch :ugly:

Nakai

2018-01-02, 22:52:26

@hmmm:
Siehe Posting davor.

gurgelhals

2018-01-02, 23:22:09

Hi,

ich bin der Kollege von Nakai.

Kurzes Wrap-up:
Im Linux Kernel wird seit Wochen (gefühlt) panisch an den KPTI Patches geschrieben (Kernel Page Table Isolation). Das ist ein massiver infrastruktureller Eingriff in den Linux Kern der eigentlich unnötig scheint, und nur großen Performanceimpact mit sich bringt. Als ob das nicht genug wäre, behauptet Linus diese Patches auch auf alte Kernelversionen zurück portieren zu wollen, was eigentlich ein totales No-Go im Kernel ist. Es dürfen nur kleine Fixes zurück portiert werden, keine Features und schon erst recht nicht invasive Infrastruktureingriffe. Also irgend einen triftigen Grund muss das haben. [5]

Jetzt fuchtelt aber wohl auch Windows wild an verwandten Infrastrukturteilen (ähnlich KAISER Patches) rum [1].

Hintergrund
Bislang haben sich Userspace und Kernel die selbe Pagetable geteilt. Der Kernel war im Userspace eingeblendet, aber natürlich nicht zugreifbar (User/Supervisor Bit in PTEs). Durch KPTI wird der Kern jetzt im Userspace voll ausgeblendet, und muss beim Kontextwechsel sich somit erst einblenden, was einen kostenintensiven TLB-Flush impliziert. [5] Bei jedem Kontextwechsel, also Syscall / Interrupt findet also ein voller PT-Wechsel mit TLB-Flush statt. Und das kommt *ziemlich* häufig vor.

Das will man eigentlich nicht, außer man hat ein Problem mit dem Design der Prozessorarchitektur. Die Begründung hinter den Patches ist etwas schleierhaft, und wird (finde ich) relativ flott durchgewunken. Die Patches haben KPTI per-se für alle x86 Systeme aktiviert, AMD hat inzwischen einen Patch geschickt, welcher es für alle ihre Prozessoren deaktiviert [4].

Als Opt-In Hardeningfeature für hochkritische Systeme kann man das verargumentieren. Da es aber ein Opt-Out für nicht AMD-Prozessoren zu werden scheint muss einen sehr guten Grund haben. Die Strategie ist, dass erst mal alle geblacklistet werden, und die Vendors dann einen Patch + Begründung schicken sollen mit der Argumentation warum sie nicht betroffen sind. Vernünftige Vorgehensweise.

Was jetzt aber wirklich los ist, ist bislang noch weitgehend unbekannt. Ich denke aber, dass die Coreentwickler informiert sind, und /irgendwas/ los sein muss, weil man so eine Änderung nicht will, und schon dreimal nicht akzeptiert wird. Bleibt vermutlich also nur ein massiver Hardware Bug in Intel-x86, welcher demnächst vermutlich veröffentlicht wird (Responsible Disclosure).

Andere sagen, dass man mal den Ball flach halten sollte [6] [7]. Nichtsdestoweniger wäre ein Bug der das aktivieren von KPTI auf Intel-x86 per Default (!) erforderlich macht für Intel ein großer Schlag ins Gesicht.

Am 34C3 konnte wohl ASLR über Javascript (!!) ausgehebelt werden [2]. AMD und ARM sind betroffen. Die Gruppe die das Veröffentlicht hat codete auch an der KAISER Patches rum. Spannend.

Der Kerl hier [3] munkelt mal fröhlich rum, und orakelt worst-case Szenarien (lesenswert der Artikel):
- Privilege Escalation von Hypervisoren (kompletter Servermarkt betroffen)
- ASLR aushebeln über Javascript (Consumer Markt)

Wie auch immer, Popcorn bereit halten. Da rollt glaube ich was an die nächsten Tage/Monate. Und ein paar Intel Jungs haben gerade Schlafdefizit ;-)

Reddit: [8]

[1] https://twitter.com/aionescu/status/930412525111296000
[2] https://media.ccc.de/v/34c3-9135-aslr_on_the_line
[3] http://pythonsweetness.tumblr.com/post/169166980422/the-mysterious-case-of-the-linux-page-table
[4] https://lkml.org/lkml/2017/12/27/2
(https://lkml.org/lkml/2017/12/27/2)
[5] https://lwn.net/Articles/741878/ (Link geht erst in ein paar Tagen)
[6] https://twitter.com/grsecurity/status/947147105684123649
[7] http://blog.fefe.de/?ts=a4b423a5
[8] https://www.reddit.com/r/sysadmin/comments/7nl8r0/intel_bug_incoming/

LadyWhirlwind

2018-01-02, 23:32:39

Linux Kernel 4.14.11 ist da mit Patch:
https://cdn.kernel.org/pub/linux/kernel/v4.x/ChangeLog-4.14.11

@gurgelhals danke und willkommen im 3dc

PrivateCeralion

2018-01-02, 23:35:30

@gurgelhals

Vielen Dank für den informativen Text und Willkommen im 3d-Center :)

gravitationsfeld

2018-01-02, 23:39:38

Linux Kernel 4.14.11 ist da mit Patch:
https://cdn.kernel.org/pub/linux/kernel/v4.x/ChangeLog-4.14.11

@gurgelhals danke und willkommen im 3dc
Ich hab das diff gecheckt und in dem Kernel ist die Mitigation definitiv auch auf AMD aktiviert. Ich hoffe, dass sich das bald aendern wird.

Wollten wohl kein Risiko eingehen.

Gorkon

2018-01-02, 23:45:00

Gibt auch schon nen ersten Benchmark mit PostgreSQL > https://lkml.org/lkml/2018/1/2/678

~ 7% Leistungsverlust mit PTI

Geht ja noch...mal schauen, wie andere SW reagiert.

Ganon

2018-01-02, 23:49:48

Ich hab das diff gecheckt und in dem Kernel ist die Mitigation definitiv auch auf AMD aktiviert. Ich hoffe, dass sich das bald aendern wird.

Jop.

setup_force_cpu_cap(X86_FEATURE_ALWAYS);

/* Assume for now that ALL x86 CPUs are insecure */
setup_force_cpu_bug(X86_BUG_CPU_INSECURE);

fpu__init_system(c);

Wobei Kernel 4.14 vermutlich noch niemand im entsprechenden Umfeld einsetzt. Interessant werden Backports zu noch älteren LTS-Kerneln, welche in CentOS, Debian und Co. zum Einsatz kommen.

Am 34C3 konnte wohl ASLR über Javascript (!!) ausgehebelt werden [2]. AMD und ARM sind betroffen.

Dazu sei gesagt, dass "ASLR aushebeln" alleine erst mal keine Sicherheitslücke an sich ist, sondern nur den Weg öffnet andere Sicherheitslücken zu benutzen. Darum schrieb ja auch fefe, dass man versuchen sollte seine Software sicher zu machen, statt sich auf solche Sicherheiten zu verlassen.

Ganon

2018-01-02, 23:56:21

Gibt auch schon nen ersten Benchmark mit PostgreSQL > https://lkml.org/lkml/2018/1/2/678

Die Antwort darauf von Linus hat ein paar mehr Details:

Yeah, that's actually pretty much in line with expectations.

Something around 5% performance impact of the isolation is what people
are looking at.

Obviously it depends on just exactly what you do. Some loads will
hardly be affected at all, if they just spend all their time in user
space. And if you do a lot of small system calls, you might see
double-digit slowdowns.

> This isn't a complaint, I just thought it might be useful
> information. If it helps for anything/anybody, I'm happy to run
> additional benchmarks / provide additional information.

Note that it will depend heavily on the hardware too. Older CPU's
without PCID will be impacted more by the isolation. And I think some
of the back-ports won't take advantage of PCID even on newer hardware.

Linus

Ergo: 7% auf Skylake mit Kernel 4.14. Muss also kein Regelfall sein. Andere CPU, anderer Kernel, anderes Ergebnis.

gurgelhals

2018-01-02, 23:58:57

Dazu sei gesagt, dass "ASLR aushebeln" alleine erst mal keine Sicherheitslücke an sich ist, sondern nur den Weg öffnet andere Sicherheitslücken zu benutzen. Darum schrieb ja auch fefe, dass man versuchen sollte seine Software sicher zu machen, statt sich auf solche Sicherheiten zu verlassen.

Ja, das ist absolut korrekt. Der Punkt ist nur, dass das die selbe Gruppe ist wie die Autoren der KAISER Patches. Denk die haben da noch was in der Hinterhand. ASLR aushebeln in Verbindung mit einem TLB-Bug wird dann schon spannender.

maguumo

2018-01-03, 01:25:33

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

bbott

2018-01-03, 01:33:51

Und Andere versuchen hier gerade ein Super GAU daraus zu machen. Ich bin in dem Umfeld tätig. Vor Sicherheits-GAU kann ich gerade nur schmunzeln bei all den Lücken in all der Hard- und Software die letzten Jahre. Performance-GAU muss sich erst zeigen, wie gesagt... abseits von Edge-Cases. I/O-lastiges Datawarehousing hat vielleicht ein paar relevante Messwerte dann. Bei 08/15 WebApps ist es relativ egal ob die Query 1ms oder 5ms läuft, wenn der fette App-Stack oben drauf eh noch mal 400ms hinzufügt.

Wann hatte AMD oder Intel einen solch gravierenden Bug über soviel Genrationen mitgeschleift?! Vor allem weil die CPUs sehr ähnlich sind und Intel fällt es nicht auf. Bei AMD fällt mir nur der Barcelona TBL Bug auf, den AMD:
a) selbst gefunden
b) kruz vor/nach den Lauch gefunden
c) schnell gefixt hat.

Der TBL Bug der bei Intel kurze Zeit später aufdeckte wurde, fand hingegen kaum Beachtung und ist fast vergessen, wobei dieser ähnlich Gravierend war.

Ich hoffe das dies AMDs Epyc und Ryzen beflügeln wird und AMD Geld in die Kassen spült für die weiter Entwicklung von CPUs und GPUs :P

gurgelhals

2018-01-03, 02:14:07

Wann hatte AMD oder Intel einen solch gravierenden Bug über soviel Genrationen mitgeschleift?!

https://de.wikipedia.org/wiki/Pentium-F00F-Bug

Der ist aber schon lange nicht mehr aktuell, wurde aber Jahre rumgeschleift.

Die Phoronix Benchmarks sind nicht überraschend. Video Decoding und Compiling rechnet quasi nur im Userspace, macht lediglich ab und an Bulk-IO. Das fällt nicht ins Gewicht. KPTI trifft Prozesse mit hoher I/O Last, und Prozesse welche kurze (und deterministische) Reaktionszeiten brauchen.

Aus Consumer-Sicht wäre beispielsweise ein Benchmark eines Browsers interessant. Ein Browser macht während er lebt so ziemlich alles durch, was aus I/O-Sicht ins Gewicht fällt: Netzwerk, Grafik, Disk I/O, Forks, Zugriff auf periphäre Geräte, ... Aber da interessieren 5% auch nur dann, wenn es als Nutzer spürbar wird.

Aus Server-Sicht könnten Netzwerkshares interessant werden. Trivialerweise könnte ein FTP-Server Benchmark schon aufschlussreich sein.

Und natürlich die Cloud, und überall dort wo rumvirtualisiert wird. Paravirtualisierung macht zwar schon vieles besser, aber VM-Instanzen stehen üblicherweise unter hoher I/O Last.

Exxtreme

2018-01-03, 08:16:15

https://www.phoronix.com/scan.php?page=article&item=linux-415-x86pti&num=2
Postgres verliert sau viel. Das ist echt doof.

Ganon

2018-01-03, 08:25:00

Wann hatte AMD oder Intel einen solch gravierenden Bug über soviel Genrationen mitgeschleift?!

Wie ich schon sagte, ist das Lustige an der Geschichte, dass das Sicherheitsproblem auf einen Hardware-Bug zurückzuführen ist. Aber die Tatsache, dass nun Millionen von Servern betroffen sind aufgrund jahrealter Bugs irgendwo, das ist nun echt keine Neuheit. Hat man nicht nur gefühlt jedes Jahr 1-3 mal.

Der Performance-Impact abseits von Micro-Benchmarks bleibt abzuwarten. Zumindest 7% bei PostgreSQL mit Kernel 4.14 auf Skylake ist ja von "Der Overhead wird messbar sein bei Datenbank-Anwendungen und deutlich ueber 5% liegen." nicht so dramatisch wie behauptet. Im Gegenzug hast du in den neusten PostgreSQL-Versionen teilweise Speedups von x mal CPU, aufgrund diverser Multi-Threading-Optimierung. Hier hilft den meisten vermutlich einfach nur ein Upgrade auf PostgreSQL 9 oder 10.

Vermutlich sind die Haupt-Leidtragenden die VM Anbieter hier oder Leute die auf uralten LTS-Versionen von Linux kleben. Davon haben vermutlich auch nur ein Bruchteil wirkliche Performance-Erwartungen.

Ein anderer Großteil der Server wird das Update überhaupt gar nicht erst bekommen.

Ich hoffe das dies AMDs Epyc und Ryzen beflügeln wird und AMD Geld in die Kassen spült für die weiter Entwicklung von CPUs und GPUs :P

So sehr ich mir wünsche, dass Intel etwas Konkurrenz bekommt.... aber AMD hat sich die letzten Monate/Jahre auch nicht gerade mit Ruhm bekleckert. Du brauchst dir nur durchlesen was deren AGESA Updates alles so fixen und wir haben einen Bug, der nur durch CPU-Tausch behoben werden kann.

Treu nach dem Spruch "Nichts wird so heiß gegessen wie es gekocht wird", werden die Auswirkungen auf den CPU Markt meiner Meinung nach relativ gering sein.

Und wenn es nach mir geht dürfen die großen Server-Firmen auch gerne in OpenSource Hardware im Stil von OpenPOWER oder RISC-V investieren. Wird nicht passieren, klar, aber diese ständige Abhängigkeit von effektiv einem Anbieter nervt mich schon sehr lange.

Pirx

2018-01-03, 08:55:11

Wie ich schon sagte, ist das Lustige an der Geschichte, dass das Sicherheitsproblem auf einen Hardware-Bug zurückzuführen ist. Aber die Tatsache, dass nun Millionen von Servern betroffen sind aufgrund jahrealter Bugs irgendwo, das ist nun echt keine Neuheit. Hat man nicht nur gefühlt jedes Jahr 1-3 mal....
Wann wurde denn das letzte mal in so einem Zusammenhang solch ein Aufwand betrieben um einen Fehler softwareseitig zu umschiffen? Wann waren das letzte mal Generationen von CPUs eines Herstellers von solch einem nicht trivialen Fehler betroffen? (Der f00f trat ja nur beim P5 und P5 MMX auf)

Daß es auch hier anscheinend aufgrund der schieren Größe und des gewohnheitsmäßig gegebenen Kredits an Intel nicht zu größeren Wellenbewegungen kommen wird, schön und gut und soweit klar, aber hier interessiert doch eher _deine_ Meinung zum konkreten Problem und nicht, wie deiner Meinung nach andere (nicht) reagieren könnten.

edit: First and foremost, a glaring error: the linked CCC talk had absolutely nothing to do with the group that originated the KAISER patches... usw. http://pythonsweetness.tumblr.com/post/169217189597/quiet-in-the-peanut-gallery

Ganon

2018-01-03, 09:09:10

Wann wurde denn das letzte mal in so einem Zusammenhang solch ein Aufwand betrieben um einen Fehler softwareseitig zu umschiffen?

Vermutlich in der Form noch nicht dagewesen, ja. Aber hier haben wir auch ein fixbares Problem. Nach Rowhammer kräht auch kein Hahn mehr, auch wenn das Problem weiterhin sehr wohl existiert. Kann nur keiner was gegen machen. Intel hat ein Patent für Technologien gegen Rowhammer. Keine Ahnung wie da der Umsetzung-Grad ist. edit: Und KASLR gegen Rowhammer ist auch kein "kleiner" Fix gewesen, wenn es dann ein Fix ist. Siehe "ASLR aushebeln per JavaScript".

aber hier interessiert doch eher _deine_ Meinung zum konkreten Problem

Echt? Tut sie das? Aber gut, die habe ich bereits gegeben: AMD hat genauso Bugs in ihren CPUs gehabt, die zwar kein Sicherheitsproblem in der Form waren, aber zu instabilen Systemen führen. Somit ist für mich AMD keine grundlegend andere Alternative (auch wenn ich mir wie gesagt ein stärkeres AMD wünsche, schon alleine aus Konkurrenz-Sicht). Niemand weiß was noch so für Bugs in AMD und Intel CPUs oder deren Nebenchips Intel ME und AMD PSP so schlummern.

Mein allgemeiner Wunsch(-Traum): Weniger Fokussierung auf Intel Plattformen. Mehr Investitionen in Open Source Hardware und weitere Software-Optimierung für Non-x86 Hardware.

=Floi=

2018-01-03, 09:15:42

Also für HPC könnte das schon ein ziemlich böser Bug sein.

Also das könnte echt noch interessant werden in den nächsten Tagen.

Auch bei Games erwarte ihr eher höhere Verluste.

Man kann die systeme ja trennen und dann könnte man weiterhin die schnellen kernel für das rechnen benützen und die gefixten kernel für die sicherheitsrelevanten systeme?!

Pirx

2018-01-03, 09:19:28

...
Echt? Tut sie das? Aber gut, die habe ich bereits gegeben: AMD hat genauso Bugs in ihren CPUs gehabt, die zwar kein Sicherheitsproblem in der Form waren, aber zu instabilen Systemen führen. Somit ist für mich AMD keine grundlegend andere Alternative (auch wenn ich mir wie gesagt ein stärkeres AMD wünsche, schon alleine aus Konkurrenz-Sicht). ...
Na klar, du scheinst dich ja recht gut auszukennen.
Ich sehe es grundsätzlich auch so, wobei im konkreten Fall, wenn AMD wirklich nicht betroffen sein sollte, hier inbesondere EPYC schon ein gewichtiges Argument ggü. Xeon auf seiner Seite hätte. Aber bestimmt wird auch in AMDs CPUs noch so einiges schlummern.

Ganon

2018-01-03, 09:26:44

Man kann die systeme ja trennen und dann könnte man weiterhin die schnellen kernel für das rechnen benützen und die gefixten kernel für die sicherheitsrelevanten systeme?!

Wenn man zur Ausnutzung des Bug eine Shell auf dem Server braucht, dann kann man durchaus auf Backend-Systemen KPI abschalten. Aber wie der Bug nun im Detail ist, ist ja noch nicht bekannt.

wenn AMD wirklich nicht betroffen sein sollte, hier inbesondere EPYC schon ein gewichtiges Argument ggü. Xeon auf seiner Seite hätte.

Klar, aber hier greift wieder das was ich sagte: Keiner wird wegen Performance-Einbußen von ein paar % seine scheißteure Server-Hardware wegschmeißen und auf AMD wechseln. Es mag für Neuanschaffungen in Betracht gezogen werden, aber hier liefert Intel vermutlich auch irgendwann ein Hardware-Fix. In Randbereichen werden vermutlich ein paar (alte) Server ausgetauscht, aber das wird AMD nicht plötzlich zu 50% Marktanteil im Server-Bereich befördern.

LadyWhirlwind

2018-01-03, 09:43:30

So komplex wie heutige CPUs sind, sind keine fehlerfrei. Anders ist diesesmal nur, dass es grössere Auswirkungen hat als in vielen anderen Fällen. Wenn du heute kaufst, kannst du nie sicher sein, dass du nicht morgen ein ähnliches Problem hast.

Grössere Kunden die unglücklich sind, wird Intel auf die nächste Bestellung eine "grosszügige" Gutschrift anbieten.

Gibts schon informationen darüber wie stark Maschienen mit mehrern VMs davon betroffen sind? Reicht es aus wenn das Host-System aktualisiert wird?

bbott

2018-01-03, 09:47:52

Tobalt

2018-01-03, 10:16:05

hmmm

2018-01-03, 10:23:38

...
Was du da machst ist unseriös.
Es gibt mehr als nur PostgreSQL, es laufen oft mehr als nur eine DB, hier wurde der DiskIO/NetIO/... total vernachlässigt, AMDs "fertigungs Problem" ist 0 vergleichbar mit Intels offensichtlichem "fail at design" usw usw

Exxtreme

2018-01-03, 10:40:48

pilzsammler2002

2018-01-03, 10:44:24

Ist es wirklich so das DirectX mehr Syscalls macht als Vulkan oder Opengl?

Könnte der Bug also dafür sorgen dass sich vllt Lowlevel noch schneller durchsetzt?

Ganon

2018-01-03, 10:44:38

Laienfrage:

derzeit wird der bug also nicht umgangen. alle prozessoren sind schnell aber intels teilweise unsicher ?

soweit richtig?

durch den fix würden die unsicheren prozessoren dann sicher aber langsamer?

sobald intel in neuen Generationen den hardware bug repariert käme man wieder zum status quo ?

Durch den _aktuellen_ Fix werden _alle_ x86 Prozessoren unter Linux langsamer. Die Ausnahme von AMD befindet sich aktuell nur als Mail im Postfach diverser Leute, aber nicht im Kernel Code.

Man merkt, dass der Fix schnell kommen musste. Langfristig wird man vermutlich, wie bei so vieler Hardware, das ganze als CPU Hardware-Bug Datenbank weiterführen und dann ist es so wie du sagst. Aktuell aber noch nicht.

Was du da machst ist unseriös.
Es gibt mehr als nur PostgreSQL, es laufen oft mehr als nur eine DB, hier wurde der DiskIO/NetIO/... total vernachlässigt, AMDs "fertigungs Problem" ist 0 vergleichbar mit Intels offensichtlichem "fail at design" usw usw

Du musst dir einfach nur die weiteren hier geposteten Links durchlesen und auch das was ich schreibe ;) Wenn ein TPCH-Like Benchmark unter PostgreSQL sagt "7%", dann ist das näher am Real-World Szenario als "ich rufe eine Million mal in der Sekunde "du -h" auf, oder rufe wie einer Irrer "SELECT 1" in der Datenbank auf.

Und du darfst gerne weitere Datenbanken benchmarken (mache dich auf Klagen gefasst). Mich persönlich interessiert nur PostgreSQL, da ich nichts anderes im Großeinsatz habe. Aber SQL-Datenbanken funktionieren im Kern alle ähnlich.

Angiesan

2018-01-03, 10:45:37

Hallo liebe Experten,

ich habe die einzelnen Berichte und natürlich die Ausführungen hier gelesen.
Nur reicht mein sehr begrenztes Fachwissen nicht aus, um die möglichen Auswirkungen für mein System wirklich zu verstehen.
Ich habe verstanden, dass es unter verschiedenen Szenarien durchaus hoch relevant ist. Nur wie "schlimm" ist es wirklich, nach der Einschätzung der Wissenden, für einen Ottonormaluser wie mich.
Die geballte Anzahl an Fachausdrücken bringt mich hier nicht wirklich weiter und ich kann in diesem Thema nicht unterscheiden zwischen Shitstorm und wirklicher Bedrohungslage. Das bringt unsere digitale Welt leider ebenso mit sich.

Verbaut ist eine Intel CPU des Typs Xeon E3 1230 V3 die ja nun mal betroffen ist.
Als Betriebssystem kommt Win 10 64 Bit Pro zum Einsatz und der Rechner wird aktuell zum Arbeiten (auch mit sensiblen Daten) benutzt. Die üblichen Schutzmaßnahmen wie Virenscanner, Firewall und HW Maßnahmen die mir empfohlen wurden sind installiert bzw. in Benutzung, regelmäßige Sicherungen verstehen sich von selbst.

Gipsel

2018-01-03, 10:45:50

Am 34C3 konnte wohl ASLR über Javascript (!!) ausgehebelt werden [2]. AMD und ARM sind betroffen. Die Gruppe die das Veröffentlicht hat codete auch an der KAISER Patches rum. Spannend.

Der Kerl hier [3] munkelt mal fröhlich rum, und orakelt worst-case Szenarien (lesenswert der Artikel):
- Privilege Escalation von Hypervisoren (kompletter Servermarkt betroffen)
- ASLR aushebeln über Javascript (Consumer Markt)
Da ASLR ja sowieso nur ein Notnagel ist und für sich alleine Angriffe nur schwieriger, aber nicht unmöglich macht, würde nur für das Aushebeln von ASLR (wofür es sowieso etliche Angriffsmöglichkeiten gibt) wohl nicht so ein Aufstand gemacht. Auch mit ausgehebeltem ASLR ist immer noch eine zusätzliche Lücke irgendwo im Kernel notwendig, um irgendwas damit anzufangen (wenn man sich nicht auf das halb-zufällige Bitflippen im DRAM per Rowhammer zurückzieht). Deswegen, und auch weil AMDs-Statement zu ihrem Patch-Vorschlag (der KPTI auf AMD-Systemen wieder deaktiviert) explizit spekulative Speicherreferenzen erwähnt, könnte da mehr dran sein. Es ist ja bekannt, daß intel-CPUs Daten spekulativ laden können, und dabei die Zugriffsrechte erst mal nicht gecheckt werden (sondern erst beim Commit der Instruktion wird dann die entsprechende Exception geworfen und die eventuell nachfolgenden spekulativ ausgeführten Instruktionsergebnisse verworfen). Dabei können durchaus auch mehrere Operationen nach dem Ladevorgang schon mal spekulativ ausgeführt werden (und dabei eben mit Daten arbeiten, die eigentlich nicht erreichbar sein sollten). Intel CPUs spekulieren also recht aggressiv. Bisher schienen Experimente darauf hinzudeuten, daß man so nicht direkt an die so geladenen Daten (unter Umgehung des Zugriffsschutzes) herankommt (weil die Ergebnisse später verworfen werden und nicht in den Architektur-Registern landen) *. Aber falls sich das geändert hat und man das doch irgendwie austricksen kann (weil z.B. die entsprechenden Bits in irgendwelchen Cornercases nicht richtig gecheckt werden), dann ist die Aufregung verständlich. Und falls das nicht nur auf das Lesen zutreffen sollte und sich damit sogar direkt Kernel-Speicherbereiche schreiben lassen würden (oder die entsprechenden Einträge der Pagetables, womit man sich selber alle Rechte einräumen kann), dann ist die Kacke aber richtig am Dampfen.
AMDs Statement dagegen scheint zu sagen, daß man prinzipiell nicht über Page-Faults hinaus spekuliert, dieses spezielle Problem also nicht vorkommen kann.

*: https://cyber.wtf/author/andersfogh1974/
While I did set out to read kernel mode without privileges and that produced a negative result, I do feel like I opened a Pandora’s box. The thing is there was two positive results in my tests. The first is that Intel’s implementation of Tomasulo’s algorithm is not side channel safe. Consequently we have access to results of speculative execution despite the results never being committed. Secondly, my results demonstrate that speculative execution does indeed continue despite violations of the isolation between kernel mode and user mode.

This is truly bad news for the security. First it gives microarchitecture side channel attacks additional leverage – we can deduct not only information from is actually executed but also from what is speculatively executed. It also seems likely that we can influence what is speculative executed and what is not through influencing caches like the BTB see Dmitry Evtyushkin and Dmitry Ponomarev [5] for instance.It thus add another possibility to increase the expressiveness of microarchitecture side channel attacks and thus potentially allow an attacker even more leverage through the CPU. This of cause makes writing constant time code even more complex and thus it is definitely bad news.

Also it draws into doubt mitigations that rely on retirement of instructions. I cannot say I know how far that stretches, but my immediate guess would be that vmexit’s is handled on instruction retirement. Further we see that speculative execution does not consistently abide by isolation mechanism, thus it’s a haunting question what we can actually do with speculative execution.

Skysnake

2018-01-03, 10:48:09

Man kann die systeme ja trennen und dann könnte man weiterhin die schnellen kernel für das rechnen benützen und die gefixten kernel für die sicherheitsrelevanten systeme?!
Nein kann man nicht. Die Systeme haben ja alle auf den gleichen storage Zugriff. Und da liegen eben die Daten der Leute.

Für reine Forschungsysteme auf denen auch nichts läuft was der Geheimhaltung unterliegt etc. Eventuell möglich, aber unwahrscheinlich. Vor allem wird die Anzahl s8lcher Systeme komplett vernachlässigbar sein.

Fast alle Systeme sind halt in einem Mischbetrieb, der hohe Security Anforderungen bedeutet

Freestaler

2018-01-03, 11:31:39

Was du da machst ist unseriös.
Es gibt mehr als nur PostgreSQL, es laufen oft mehr als nur eine DB, hier wurde der DiskIO/NetIO/... total vernachlässigt, AMDs "fertigungs Problem" ist 0 vergleichbar mit Intels offensichtlichem "fail at design" usw usw

Ja, er ist offensichtlich stark am relativieren was wie wo nun betroffen sein soll. Warum das auch immer der Fall ist bei ihm. Wobei fairerweise, Weltuntergang ist jetzt noch nicht.(ich weiss, ich relativiere auch) Generell warte ich noch auf das Statement von Intel, ich hab noch die Hoffnung das dies doch noch per Workaround mit MicroCode ohne die Einbussen geht. So Langsam nach 2x Intel ME (sind wir noch immer dran mit 200 Servern und 1300 Cients) nerfst echt gerade.

*Hust* das Fertigungproblem bzw. der CompilerBug betrifft sowieso nicht die EPYC oder Threadripper Reihe sondern die ersten Desktops CPU Ryzen, keine Server oder Workstation CPU's. Ps: nerft homeuser trotzdem, ichweiss..

Skysnake

2018-01-03, 12:56:21

Also laut CB werden metadaten Operationen auf Files um 28% langsamer.

Das ist echt heftig viel. Or allem weil metadaten Operationen bei großen Filesysteme eh immer ein Problem sind.

Wenn AMD da wirklich nicht betroffen ist könnte das für Filesystem Server ein klarer Vorteil für AMD sein.

Wird die nächsten Wochen aber sicherlich spannend. Metadaten Operationen pro Sekunde sind eigentlich in jeder Abnahme eines Filesystems drin. Und die zu erhöhen ist nicht billig! Wenn überhaupt möglich innerhalb eines Filesystems.

Da werden wir wohl viel Nachbenchen müssen. Ich kann mir aber kaum vorstellen, dass das keine Probleme nach sich zieht.

Zwischen Vergabe und Abnahme liegen ja normal recht lange Zeiträume. Und der eine e oder andere Kunde lässt dich das Tuch Millionen System auch wieder abbauen wenns nicht in vereinbarte Leistung bringt...

Das könnte noch echt "lustig" werden

Ganon

2018-01-03, 13:18:09

Ja, er ist offensichtlich stark am relativieren was wie wo nun betroffen sein soll. Warum das auch immer der Fall ist bei ihm.

Weil es jetzt schon Leute gibt, die Anfangen ihre Updates sinnloser Weise zu unterbinden, weil ihnen jemand erzählt er verliere durch das Update 30% Performance. Das obwohl der Performance-Verlust im Desktop-Bereich sogar noch unter den 5% Regelfall fällt.

Alles nur, weil Leute ständig nur Überschriften Lesen und nicht mal wissen wo eigentlich das Problem liegt.

*Hust* das Fertigungproblem bzw. der CompilerBug betrifft sowieso nicht die EPYC oder Threadripper Reihe sondern die ersten Desktops CPU Ryzen

*hust* Zuerst entdeckt auf Build-Servern diverser Projekte.

deekey777

2018-01-03, 13:22:24

Freestaler

2018-01-03, 13:25:46

Weil es jetzt schon Leute gibt, die Anfangen ihre Updates sinnloser Weise zu unterbinden, weil ihnen jemand erzählt er verliere durch das Update 30% Performance. Das obwohl der Performance-Verlust im Desktop-Bereich sogar noch unter den 5% Regelfall fällt.

Alles nur, weil Leute ständig nur Überschriften Lesen und nicht mal wissen wo eigentlich das Problem liegt.

*hust* Zuerst entdeckt auf Build-Servern diverser Projekte.

Servern mit Ryzen CPU der ersten Tage, Thread geil? Also vermutlich auch kein ECC Ram? Billig statt Günstig? Wie war das nochmals, never USE Rev 1.0 egal ob HW oder SW in der Produktion, ausser es geht um Himmels willen nicht anders.. Oder kurz, das Risiko müsste eigentlich allen klar gewesen. Wenn nicht, weiss ich nicht was er an nem "Server" macht.

Und ja, die Leute springen mal wieder im Kreis..

Ganon

2018-01-03, 13:31:40

Servern mit Ryzen CPU? Billig statt Günstig? Und ja, die Leute springen mal wieder im Kreis..

Klar. Commodity Hardware im Server Umfeld ist nicht erst seit gestern in Mode. Weiterhin ist es unsinnig für einen Build-Server sich Server-Hardware anzuschaffen. Guck dir auch mal an was Anbieter wie Hetzner so im Angebot haben: https://www.hetzner.de/dedicated-rootserver

Großteils Core i und Ryzen. Auch Xeon und Epyc ja, aber nicht nur.

Aber gut, das ist OT und hat damit relativ wenig zu tun.

edit: Und siehst'e... jetzt bist du die Person die anfängt zu relativieren.... ist ganz einfach, nicht? ;)

LadyWhirlwind

2018-01-03, 13:43:06

Klar. Commodity Hardware im Server Umfeld ist nicht erst seit gestern in Mode. Weiterhin ist es unsinnig für einen Build-Server sich Server-Hardware anzuschaffen. Guck dir auch mal an was Anbieter wie Hetzner so im Angebot haben: https://www.hetzner.de/dedicated-rootserver

Großteils Core i und Ryzen. Auch Xeon und Epyc ja, aber nicht nur.

Aber gut, das ist OT und hat damit relativ wenig zu tun.

Es spricht auch nichts gegen solche Systeme, wenn man weiss worauf man sich einlässt.

Was man sich allerdigns gut überlegen sollte ist eine neuentwickelte Plattform einzusetzen, ohne tests zu haben, die bestätigen, dass das was man mit dem System tun will, auch funktioniert. Ebenso war mit häufigen Bios-Updates zu rechnen.

Skysnake

2018-01-03, 13:53:06

Und wenn der Patch dennoch installiert wird, Performance-Einbußen?
Wie gesagt der Patch installiert werden, ansonsten heißt das oft, dass das System ansonsten offline geht.

Gerade 2017 war im Enterprise Bereich teilweise schon hässlich mit den vielen ernsten Patches die gemacht werden mussten.

Und bei nem System mit mehreren tausend Servern auf dem große Jobs laufen ist das schon hässlich. Da haste jeweils nen halben Tag downtime am Ende. Das geht richtig ins Geld...

Bei einer alten Arbeit hatten wir das 3 oder 4 mal in 2017. Das war echt hässlich

Ganon

2018-01-03, 14:12:59

Kennt man ja von anderen Kernel und Hypervisor Lücken: Amazon und Microsoft hatten schon frühzeitig Reboots angekündigt ( von Heise (https://www.heise.de/security/meldung/Massive-Luecke-in-Intel-CPUs-erfordert-umfassende-Patches-3931562.html) ):

https://social.msdn.microsoft.com/Forums/azure/en-US/1949c2df-9fb1-4978-b41c-59ee22d98bde/january-10th-2018-planned-virtual-machine-maintenance-reboot-strategy?forum=WAVirtualMachinesforWindows

https://twitter.com/jschauma/status/941447173245370368

Gipsel

2018-01-03, 14:17:32

Pirx

2018-01-03, 14:20:40

Ein ordentliches Feuer produziert eigentlich gar nicht sooo viel Rauch.;)

Dino-Fossil

2018-01-03, 14:26:42

https://www.techpowerup.com/240187/amd-struggles-to-be-excluded-from-unwarranted-intel-vt-flaw-kernel-patches

dllfreak2001

2018-01-03, 14:40:03

AMD ist bei den Linuxern ja auch nicht so beliebt.
Verwundert also nicht warum man da keinen Unterschied machen. Kann ja nicht sein, was nicht sein darf. ;)

Skysnake

2018-01-03, 14:41:06

Es gibt zumindest schon mal viel Rauch, inzwischen schreibt sogar SpOn darüber (http://www.spiegel.de/netzwelt/gadgets/intel-prozessoren-sicherheitsluecke-koennte-pc-ausbremsen-a-1185969.html). Mal sehen wieviel Feuer das am Ende ist.
Ich würde sagen nicht wenig, einfach weil die Performance Verluste genau da auftreten wo man eh schon zu wenig davon hat.

Also das metadaten Geraffel sehe ich echt als kritisch an, einfach weil es da keine einfachen Lösungen dafür gibt...

registrierter Gast

2018-01-03, 14:45:49

AMD ist bei den Linuxern ja auch nicht so beliebt.
Verwundert also nicht warum man da keinen Unterschied machen. Kann ja nicht sein, was nicht sein darf. ;)

Dort steht doch lediglich, dass AMD erst mal triftige Beweise liefern soll, dass deren Prozessoren nicht von dem Bug betroffen ist. So lange dies nicht geschieht, bleibt der Patch auch für sie vorerst aktiv.

Finde ich ein legitimes Vorgehen.

steve.it

2018-01-03, 14:53:40

Im Heise-Forum spekulieren mehrere, ob macOS überhaupt betroffen ist (z.B. (https://www.heise.de/forum/heise-Security/News-Kommentare/Massive-Luecke-in-Intel-CPUs-erfordert-umfassende-Patches/Re-Apple-Macs-werden-im-Artikel-nicht-erwaehnt/posting-31620494/show/)).

Vermutlich ist macOS genauso betroffen.

Exxtreme

2018-01-03, 14:58:29

StefanV

2018-01-03, 14:59:52

Es gibt zumindest schon mal viel Rauch, inzwischen schreibt sogar SpOn darüber (http://www.spiegel.de/netzwelt/gadgets/intel-prozessoren-sicherheitsluecke-koennte-pc-ausbremsen-a-1185969.html). Mal sehen wieviel Feuer das am Ende ist.
nicht ganz zum Thema, irgendwie aber doch:
https://www.fool.com/investing/2017/12/19/intels-ceo-just-sold-a-lot-of-stock.aspx

Der hatte fast 500k an Aktien.
Hat aber alles verkauft, was nicht benötigt wird, um CEO zu bleiben. Jetzt hat er exakt 250k, die für den Job benötigt werden.

Jetzt, etwa 2 wochen später, würde man vermuten, dass er davon wusste. Und dass das ganze ein echt großes Problem ist.

Armaq

2018-01-03, 15:12:12

nicht ganz zum Thema, irgendwie aber doch:
https://www.fool.com/investing/2017/12/19/intels-ceo-just-sold-a-lot-of-stock.aspx

Der hatte fast 500k an Aktien.
Hat aber alles verkauft, was nicht benötigt wird, um CEO zu bleiben. Jetzt hat er exakt 250k, die für den Job benötigt werden.

Jetzt, etwa 2 wochen später, würde man vermuten, dass er davon wusste. Und dass das ganze ein echt großes Problem ist.
Ja, das ist die richtige Schlussfolgerung. Er geht davon aus, dass das Intel extrem schwächt. Ganz einfach. Ich hoffe die Börsenaufsicht schaut genau hin.

Auch ist zu hoffen, dass AMD berücksichtigt wird in den Patches. Wir brauchen keinen Server Benchmark mehr machen, wenn Intel durch die Bank 30% verliert oder ähnliches.

Ganon

2018-01-03, 15:29:51

Windows-Benchmarks von Hardwareluxx: https://www.hardwareluxx.de/index.php/news/hardware/prozessoren/45319-intel-kaempft-mit-schwerer-sicherheitsluecke-im-prozessor-design.html und Computerbase: https://www.computerbase.de/2018-01/intel-cpu-pti-sicherheitsluecke/

Schnoesel

2018-01-03, 15:39:26

Was hat das jetzt eigentlich für einen Sinn ein Spiel in UHD zu testen also im absoluten GPU Limit?

Zum Thema: Da ja keiner so richtig genau weiß was jetzt eigentlich Sache ist, da ja der Großteil der Infos weiterhin unter Verschluss zu sein scheint, kann man hier doch eh noch keine Aussagen zu etwaigen Auswirkungen treffen oder irre ich mich?

DrumDub

2018-01-03, 15:53:03

oha .. gibts da eventuell nen zusammenhang?

Intel's CEO Just Sold a Lot of Stock (19.12.17) (https://www.fool.com/investing/2017/12/19/intels-ceo-just-sold-a-lot-of-stock.aspx)

labecula

2018-01-03, 15:54:43

Hm, ich bin ja bei weitem noch nicht mit dem Thread hier durch. Habe es aber schon auf Heise gelesen. wenn der Patch wirklich ab 5% Leistung frisst, ist das selbst für einen älteren Gaming PC mit Sandy i5 oder i7 nicht gerade witzig. die Frage wird sein, ob der Patch von Microsoft dann optional oder zwingend ist. Bei Letzterem, was ich befürchte, würde ich dann meinen Gaming PC lieber komplett gegen die kommenden Updates sperren bevor ich sowas auf ihn darauflasse.

Timbaloo

2018-01-03, 15:54:47

oha .. gibts da eventuell nen zusammenhang?

Intel's CEO Just Sold a Lot of Stock (19.12.17) (https://www.fool.com/investing/2017/12/19/intels-ceo-just-sold-a-lot-of-stock.aspx)
Dann wäre er extrem dumm.

Bei Letzterem, was ich befürchte, würde ich dann meinen Gaming PC lieber komplett gegen die kommenden Updates sperren bevor ich sowas auf ihn darauflasse.
Das ist auch nicht gerade klug.

maguumo

2018-01-03, 15:59:04

davidzo

2018-01-03, 16:17:40

Das Märchen, dass ECC- oder Registered ECC-RAM irgendwie nennenswert Performance kostet, stirbt einfach nicht aus: https://www.techspot.com/article/845-ddr3-ram-vs-ecc-memory/
Das Problem ist ein anderes, ECC Ram ist meist einfach nicht in den höheren Speedklassen verfügbar.

Egal wie klein der Performance Hit jetzt wird, die Öffentlichkeitsarbeit von Intel ist mies. Wenn es wie zu erwarten für normale Desktop User nur vernachlässigbare Einschränkungen gibt hätten sie lieber ein Statement raushauen sollen anstatt das über einen Kernel Patch leaken zu lassen. "Normale" Journalisten stürzen sich gerade wie Aasgeier auf die "bis zu 30%" die auf irgendeiner Schätzung eines Bloggers beruhen.
Intel ist in einem Responsible Disclosure Verfahren mit allen großen Softwareherstellern/VIP-Kunden. Solange das läuft und die patches noch nicht draußen sind wird man sich hüten mit Journalisten zu sprechen.

Die beißen sich jetzt bestimmt gerade in den Arsch dass das ganze über den Python Sweetness Blog schonmal vorher unter die Lupe genommen wurde und jetzt schon hohe Wellen schlägt, wo das Verfahren noch nicht abgeschlossen ist.

Das war garantiert nicht so geplant, denn noch ist nicht alle Software ausgeliefert. Microsoft wird erst nächste Woche Dienstag liefern und von Apple weiß man wie immer noch gar nichts.

gurgelhals

2018-01-03, 16:24:44

Egal wie klein der Performance Hit jetzt wird, die Öffentlichkeitsarbeit von Intel ist mies. Wenn es wie zu erwarten für normale Desktop User nur vernachlässigbare Einschränkungen gibt hätten sie lieber ein Statement raushauen sollen anstatt das über einen Kernel Patch leaken zu lassen. "Normale" Journalisten stürzen sich gerade wie Aasgeier auf die "bis zu 30%" die auf irgendeiner Schätzung eines Bloggers beruhen.

Das stimmt nicht. Hier les mal: https://en.wikipedia.org/wiki/Responsible_disclosure

Wenn das ein zero-day exploit sein sollte, dann ist es absolut korrekt erst mal tunlichst die Klappe zu halten, anstatt das rauszuposaunen. Warten bis die Fixes da sind.

Gerade die Kernelpatches halten sich in ihrer Formulierung zurück -- vermutlich nicht grundlos.

Menace

2018-01-03, 16:25:40

Dort steht doch lediglich, dass AMD erst mal triftige Beweise liefern soll, dass deren Prozessoren nicht von dem Bug betroffen ist. So lange dies nicht geschieht, bleibt der Patch auch für sie vorerst aktiv.

Finde ich ein legitimes Vorgehen.

Wieso muss dass AMD beweisen? Musste das intel auch beweisen im umgedrehten Fall?

Rolsch

2018-01-03, 16:27:27

Man weiß ja auch gar nicht ob das alles ausreicht oder obs noch viel schlimmer kommt. Klarheit über den Bug gibt es ja noch nicht.

Slipknot79

2018-01-03, 16:27:36

Tests von Hardwareluxx in Spielen:
0%

K passt, Thema abgehakt. :redface:

maximus_hertus

2018-01-03, 16:38:44

Tests von Hardwareluxx in Spielen:
0%

K passt, Thema abgehakt. :redface:

Gibt es einen Link? Also ein Test mit Frametimes / Percentile?

Ganon

2018-01-03, 16:43:25

Wieso muss dass AMD beweisen? Musste das intel auch beweisen im umgedrehten Fall?

Eigentlich ist der Fall ganz einfach:

Many x86 CPUs leak information to user space due to missing isolation of
user space and kernel space page tables. There are many well documented
ways to exploit that.

The upcoming software migitation of isolating the user and kernel space
page tables needs a misfeature flag so code can be made runtime
conditional.

Add the BUG bits which indicates that the CPU is affected and add a feature
bit which indicates that the software migitation is enabled.

Assume for now that _ALL_ x86 CPUs are affected by this. Exceptions can be
made later.

Aka: Erst mal Tür zu und dann nach und nach gucken wer rein darf. Ihr dürft auch gerne eine Intel-Verschwörung dahinter sehen, die AMD benachteiligen will, weil AMDs Patch noch nicht enthalten ist. Ist euch überlassen :)

gravitationsfeld

2018-01-03, 16:48:19

https://twitter.com/brainsmoke/status/948561799875502080

Timbaloo

2018-01-03, 16:53:08

Das könnte eine lange Woche werden bis Dienstag...

gravitationsfeld

2018-01-03, 16:54:06

Das Problem ist ein anderes, ECC Ram ist meist einfach nicht in den höheren Speedklassen verfügbar.
Da gibt's keinen technischen Grund dafuer. Der einzige Unterschied von ECC-RAM-DIMMs ist dass es 72 statt 64 Datenleitungen samt weiterer Speicherchips gibt (Z.B. 9 statt 8). Wenn ECC sich am PC durchsetzten wuerde, dann gaebe es sofort Crazy-Bling-Bling-Cool-Overclocker-RAM mit ECC.

Ganon

2018-01-03, 17:01:39

ArchLinux liefert Kernel 4.14.11 im testing übrigens mit AMD-Patch aus: https://git.archlinux.org/svntogit/packages.git/tree/trunk?h=packages/linux

labecula

2018-01-03, 17:07:49

Es ist zwangsläufig auch betroffen und die Fixes werden genau so aussehen mit den gleichen Konsequenzen.

was auf älteren Systemen, die ja an sich recht langlebig sind, deutlich merkbar sein könnte. besonders auch was z.b. Auf MacBooks mit Akkubetrieb los sein wird... leider wird man dort jegliche Updates nur schwer unterbinden können. :mad::mad:

gravitationsfeld

2018-01-03, 17:12:37

ArchLinux liefert Kernel 4.14.11 im testing übrigens mit AMD-Patch aus: https://git.archlinux.org/svntogit/packages.git/tree/trunk?h=packages/linux
Ich bin echt frustriert, dass es keine Diskussion zu dem AMD-Patch auf LKML gab. Wahrscheinlich gibt es ein Embargo. Mein Popcorn liegt bereit.

Kann sein, dass AMD selber nicht weiss, dass sie irgendwie anders doch betroffen sind. Die Commit-Message hat ja auch "exploitable in various ways" angedeutet.

Es ist zwangsläufig auch betroffen und die Fixes werden genau so aussehen mit den gleichen Konsequenzen.
Bist du sicher? Ich hab irgendwie im Hinterkopf, dass Mac OS schon immer verschiedene Page Tables fuer User- und Kernel-Space hatte.

Edit: Scheint so, als waere der 64-Bit-OS-X-Kernel auch betroffen.

Ganon

2018-01-03, 17:16:26

Wenn ECC sich am PC durchsetzten wuerde

Wobei DDR4 mit Write CRC zumindest eine kleine Form von Prüfung der Daten hat. Das macht ECC nicht mehr ganz sooooo wichtig, ist aber natürlich noch mal ganz was anderes.

Ich bin echt frustriert, dass es keine Diskussion zu dem AMD-Patch auf LKML gab. Wahrscheinlich gibt es ein Embargo. Mein Popcorn liegt bereit.

Zumindest aus dem Phoronix-Forum hat einer eine Mecker-Mail geschickt/verlinkt: https://lkml.org/lkml/2018/1/3/179 :D Aber ich vermute ebenfalls Embargo.

Ex3cut3r

2018-01-03, 17:18:00

Ist bitter für Gaming Systeme welche schon etwas älter sind, einen 7700k kratz es nicht wirklich.

https://abload.de/img/unbenanntf8owo.png

Freestaler

2018-01-03, 17:24:18

Ist bitter für Gaming Systeme welche schon etwas älter sind, einen 7700k kratz es nicht wirklich.

https://abload.de/img/unbenanntf8owo.png

Das war nun der 7700K @4,8 mit DDR 3866.. nehme ich an, weil nur verweis auf diesen Artikel fürs Testsystem drin ist.

https://www.computerbase.de/2017-11/cpu-aufruesten-benchmarks-test/2/#diagramm-assassins-creed-origins-1920-1080

Mal gucken wie es da mit non OC Systemen aussieht die eher im CPU Limit sind und dann mit Aver. FPS bzw. 1% Werte gebencht werden. Das bildet dann ja eher auch die Zukunft der neuer CPU ab. Evtl sehe wir ja benchs auch noch in 720P..

Ex3cut3r

2018-01-03, 17:28:26

Ja, ich denke mal um so älter das System umso mehr verliert man. :(

labecula

2018-01-03, 17:31:09

Ist bitter für Gaming Systeme welche schon etwas älter sind, einen 7700k kratz es nicht wirklich.

https://abload.de/img/unbenanntf8owo.png

Das ist eben die Frage. Wie wirkt es sich z.b. auf einen 2600 aus?

Armaq

2018-01-03, 17:31:57

Ihr CEO hat sicher nicht aus Cashflow Mangel alle Aktien verkauft. Er sagte auch kürzlich etwas von Intel darf nicht mehr so bequem sein...

Ich bin gespannt was unsere Techniker dazu sagen, lustig ist das für Firmen die viel Virtualisierung einsetzen nicht.

labecula

2018-01-03, 17:44:18

ganze Farmen und Cluster werden ja nicht zuletzt, abseits von der Performance, auch einiges an Extra Energie einsetzen müssen. Das dürfte dann Energiekosten und Beseitgung von Abwärme auch nicht gerade optimieren...

Bucklew

2018-01-03, 17:45:08

Ich bin gespannt was unsere Techniker dazu sagen, lustig ist das für Firmen die viel Virtualisierung einsetzen nicht.
Nicht nur für die, siehe hier:
https://plus.google.com/+KristianK%C3%B6hntopp/posts/Ep26AoAZxxd

MoneyQuote:
My 2018 hardware budget just caught fire. More cores, more power, more cooling and more floor space.

mocad_tom

2018-01-03, 17:58:37

In Docker Container gibt es das Feature virtio

In Mainboards gibt es SR-IOV und VT-d
https://www.thomas-krenn.com/de/wiki/Virtualisierungsfunktion_SR-IOV_aktivieren

Ich vermute hier liegt der Hase im Pfeffer.

Und das ist auch der Grund, warum man bei NVMe was benchen kann.

Bei Postgres hat man ja schon gebencht, dass man bis zu 30% an performance verlieren kann. Allerdings hat man nicht dazugeschrieben, wie diese 30% zustandekommen.

https://twitter.com/AndresFreundTec/status/948321803092443136

Die 16 Clients in dem Twitter-Post sind wahrscheinlich 16 separate Docker.
Darin je ein Postgres.
Und weil hier ständig Context-Switches gemacht werden, die VT-d beschleunigen könnte (VT-d muss aber weggepatched werden) ergibt sich ein derart hoher Performance-Einbruch.

Für VT-d gibt es derzeit zwei gute Einsatzgebiete:
Host stellt seinen Gästen mehrere Queues für den Zugriff auf NVMe zur Verfügung.
Host stellt seinen Gästen mehrere Queues für den Zugriff auf Netzwerkkarte Verfügung.

Damit VT-d aktiv ist braucht man:
Mainboard mit VT-d
CPU mit VT-d
Samsung NVME-SSD mit passendem Treiber
Intel-10Gbit-Netzwerkkarte mit Multiqueue-Support.
Und Betriebssystem-Support.

Meine Vermutung:
Der Grund warum man in Win10 bei NVMe in einem normalen Desktop-Setup etwas benchen kann liegt MMn daran, dass man für den Prozesswechsel eine Technologie eingesetzt hat, die eigentlich für die Virtualisierung gedacht war.

Der Grund warum man nicht auf AMD-CPUs achten muss, liegt daran weil eine AMD-CPU + AMD-Mainboard diese Kontext-Switches überhaupt nicht beschleunigen kann.

Wie kann also ein Proof of Concept aussehen?
https://twitter.com/brainsmoke/status/948561799875502080

Brainsmoke schreibt noch nichts dazu.
Er hat aber auf dem CCC einen Talk über den ASLR-Bug gehalten.
Meiner Meinung nach kann man vom Gast aus auf den Wirt hingreifen.
Ich denke, dass man mit einer bestimmten Abfolge von bestimmten Befehlen ganz schön Schaden anrichten kann.

Das ist aber etwas, dass die Cloud betrifft.
Azure, Amazon und andere Cloudanbieter haben bereits Termine für forcierte Neustarts rumgereicht.
https://twitter.com/jschauma/status/941447173245370368

Mal schauen, ob Kim Jong-Un einen zweiten roten Button hat.
Nicht der, der die Atom-Bombe zündet, sondern der rote Button, der Netflix ausknipst ;D

G3cko

2018-01-03, 18:00:25

Klasse, also der zweite Performance-Bug in meinem Haswell-E...
https://www.computerbase.de/2014-08/intel-deaktiviert-tsx-haswell-per-microcode/

DrumDub

2018-01-03, 18:02:32

Ihr CEO hat sicher nicht aus Cashflow Mangel alle Aktien verkauft. Er sagte auch kürzlich etwas von Intel darf nicht mehr so bequem sein... eben.

Ich bin gespannt was unsere Techniker dazu sagen, lustig ist das für Firmen die viel Virtualisierung einsetzen nicht. darum geht es ja. gamer oder privatanwender betrifft der bug ja nicht wirklich.

Ganon

2018-01-03, 18:03:01

Die 16 Clients in dem Twitter-Post sind wahrscheinlich 16 separate Docker.

Vermutlich sind eher 16 Connections gemeint. PostgreSQL arbeitet in dem Bereich eh mit Prozessen ist also vollkommen egal wo die alle liegen.

dllfreak2001

2018-01-03, 18:03:56

Dort steht doch lediglich, dass AMD erst mal triftige Beweise liefern soll, dass deren Prozessoren nicht von dem Bug betroffen ist. So lange dies nicht geschieht, bleibt der Patch auch für sie vorerst aktiv.

Finde ich ein legitimes Vorgehen.

Nein. Das Kernelteam soll erstmal nachweisen, dass der Bug auch bei AMD besteht. So spart man sich einfach nur Arbeit.

gravitationsfeld

2018-01-03, 18:05:29

Klasse, also der zweite Performance-Bug in meinem Haswell-E...
https://www.computerbase.de/2014-08/intel-deaktiviert-tsx-haswell-per-microcode/
Meh, TSX benutzt eh keine Software. Das ist nicht wirklich vergleichbar.

Nein. Das Kernelteam soll erstmal nachweisen, dass der Bug auch bei AMD besteht. So spart man sich einfach nur Arbeit.
Kann ja sein, dass sie wissen, dass es auch auf AMD exploitable ist. ARM-CPUs sind ja auch betroffen. Selbst wenn man auf AMD "nur" ASLR aushebeln kann mit einem Timing-Sidechannel werden sie den Patch wohl nicht akzeptieren.

Rabiata

2018-01-03, 18:07:02

Da gibt's keinen technischen Grund dafuer. Der einzige Unterschied von ECC-RAM-DIMMs ist dass es 72 statt 64 Datenleitungen samt weiterer Speicherchips gibt (Z.B. 9 statt 8). Wenn ECC sich am PC durchsetzten wuerde, dann gaebe es sofort Crazy-Bling-Bling-Cool-Overclocker-RAM mit ECC.
Was außerdem noch eine Rolle spielt, ist die Unlust der Mainboardhersteller ECC auf breiter Front zu unterstützen (bei AMD, auch wenn einzelne Boards ECC unterstützen), oder bei Intel der Umstand, daß explizit ein 100 Euro teurerer "Server"-Chipsatz benötigt wird (4Kern Xeons).

Zurück zum eigentlichen Thema:
Kurzfristig (in den nächsten Wochen) erwarte ich keine großen Auswirkungen auf die Verkäufe. Die Leute die hier mitlesen sind eher nicht der Massenmarkt, und Computermagazine machen eher selten Nachtests für Hard-und Software die sie bereits reviewt haben.

Wenn der Performancehit jedoch zum Release von Ryzen 2 noch besteht, wird er sich in den Vergleichstests auswirken und AMD besser dastehen lassen. Das ist der Punkt an dem es Intel wehtun könnte (schadenfrohes :biggrin:).

PrivateCeralion

2018-01-03, 18:19:26

Das bekommen alle mit. Stand eben sogar in Frankfurt an der S Bahn Station auf dem Nachrichten Screen.

mocad_tom

2018-01-03, 18:42:11

Vermutlich sind eher 16 Connections gemeint. PostgreSQL arbeitet in dem Bereich eh mit Prozessen ist also vollkommen egal wo die alle liegen.

Das Zauberwort ist "readonly tpch-like"
Das ist ein Multi-Tenant-Setup.
Wenn das Verhalten so leicht "herauskitzelbar" wäre dann hätten wir heute schon von 10 Computer-Journalisten Benchmark-Ergebnisse.

Bei Phoronix auch kein Wort zur verwendeten Kiste.
Dass da keine Alarm-Glocken angehen?

Ganon

2018-01-03, 18:46:58

Bei Phoronix auch kein Wort zur verwendeten Kiste.

Huh? Auf der ersten Seite steht doch alles? Und lies mal bitte was hier: https://www.postgresql.org/docs/10/static/pgbench.html mit "clients" gemeint ist ;)

x-force

2018-01-03, 18:49:01

nachdem was man an spielebenchs findet, prophezeie ich durschnittlich 10% verlust im ordentlichen cpu limit. leider haben cb und hw luxx kein cpu limit getestet.

sobald da etwas unter win 8.1 verfügbar ist, werde ich das selbst testen.

Ganon

2018-01-03, 18:51:48

Linux wird den AMD-Patch wohl aufnehmen: https://www.phoronix.com/scan.php?page=news_item&px=Linux-Tip-Git-Disable-x86-PTI

Armaq

2018-01-03, 18:52:55

Ich habe zu wenig Ahnung um das einzuschätzen, aber es liest sich für mich erstmal desaströs. Intel verkauft an Cloud Anbieter in Zukunft nicht mehr viel ...

Freestaler

2018-01-03, 19:02:50

Ich habe zu wenig Ahnung um das einzuschätzen, aber es liest sich für mich erstmal desaströs. Intel verkauft an Cloud Anbieter in Zukunft nicht mehr viel ...

Wieso? Die wollen jetzt einfach 10% Rabatt, da Leistung für Geld wieder passt. Und vermutlich trifft man sich irgendwo (also die VIP Kunden) alle anderen Zahlen wie bisher..

Interessanter wird es mM. bei Ausschreibungen, da alle Werte wie z.B. Perf/Watt nicht mehr stimmen bzw. sich evtl. nun ändern. Wenns zuvor schon Knapp war, wirts jetzt brisant.

r-or

2018-01-03, 19:03:46

Was auch interessant wäre, wie lang evl. Intel davon schon weiß... das werden wir wohl erfahren, je nachdem wie lange sie brauchen einen Hardware-Fix zu bringen

fondness

2018-01-03, 19:04:05

Hat eigentlich jemand technische Hintergründe was AMD auf Hardware-Ebene anders macht? Finde ich schon interessant, einen Bug, den Intel seit fast 8 Jahren mitschleppt und selbst ARM offenbar warum auch immer übernommen hat.

Was such interessant wäre, wie lang evl. Intel davon schon weiß... das werden wir wohl erfahren, je nachdem wie lange sie brauchen einen Hardware-Fix zu bringen

Sie wissen davon solange, solange die Linux Kernel Driver Engineers brauchen um den Fix zu implementieren / zu pushen. :D
Es wäre viel zu riskant, das zurück zu halten und zu riskieren, dass es womöglich jemand anderer bemerkt bevor die entsprechenden Fixes fertig sind.

LadyWhirlwind

2018-01-03, 19:05:14

Wieso? Die wollen jetzt einfach 10% Rabatt, da Leistung für Geld wieder passt. Und vermutlich trifft man sich irgendwo (also die VIP Kunden) alle anderen Zahlen wie bisher..

Interessanter wird es bei Ausschreibungen, da alle Werte wie Perf/Watt nicht mehr stimmen bzw. sich evtl. nun ändern. Wenns zuvor schon Knapp war, wirts jetzt brisant.

Wenn die Systeme noch nicht abgenommen sind, kann das ganz schln teier werden. Pech hat auch wer solche Werte in den SLAs drin stehen hat oder wer rückwirkend darauf verpflichtet werden kann.

Rolsch

2018-01-03, 19:21:30

Hat eigentlich jemand technische Hintergründe was AMD auf Hardware-Ebene anders macht? Finde ich schon interessant, einen Bug, den Intel seit fast 8 Jahren mitschleppt und selbst ARM offenbar warum auch immer übernommen hat.

Sie wissen davon solange, solange die Linux Kernel Driver Engineers brauchen um den Fix zu implementieren / zu pushen. :D

Womöglich schießt die Intel Prefetch Architektur unter bestimmten Umständen übers Ziel hinaus und macht dem Userspace Sachen möglich wo Hacker nur träumen können. Wenns schlecht läuft benötigt die gesamte Intel Architektur ein Redesign, man wird sehen wie lange es dauert bis besseres Silizium kommt.

Bei AMD ist angeblich (zurecht) Schluss wenn Code den Privileged Test nicht besteht, bei Intel ging man da womöglich wegen Performance etwas weiter. Also man hat alles mögliche ausgeführt und im Unprivileged Fall dann später verworfen, oder eben womöglich auch nicht.

Freestaler

2018-01-03, 20:28:24

Wenn die Systeme noch nicht abgenommen sind, kann das ganz schln teier werden. Pech hat auch wer solche Werte in den SLAs drin stehen hat oder wer rückwirkend darauf verpflichtet werden kann.

Pech hat wer solche Werte in der SLA hat und nicht bis ins letzte Detail festgehalten hat, wann wie wo was gemessen wird. ;-)

Offensichtlich gibts ja bei dem performance Verlust des Workaround Unterschiede, je nach dem ob INVPCID/PCID supported wird oder nicht. Hat der wer ne schlaue Liste bereits gefunden vor allem mit den Xeon Modell und deren "revisionen"?

dechosen

2018-01-03, 20:31:17

Hmmm, bei arstechnica (https://arstechnica.com/gadgets/2018/01/whats-behind-the-intel-design-flaw-forcing-numerous-patches/) wird spekuliert, dass es CPUs ab der Pentium Pro Reihe betreffen könnte. :freak:

Again it's not entirely clear, but indications are that every Intel chip with speculative execution (which is all the mainstream processors introduced since the Pentium Pro, from 1995) can leak information this way.

BBig

2018-01-03, 20:35:17

AMD ist bei den Linuxern ja auch nicht so beliebt.
Verwundert also nicht warum man da keinen Unterschied machen. Kann ja nicht sein, was nicht sein darf. ;)

*Hust*, bitte?
Ich bin Linuxer und ich preferiere schon ewig AMD. Was die mit der Offenlegung der GraKa-Treibern und Mainling gezeigt habe, super!
( Und Intel hat sich mit Braswell z.B. bei Linuxern nicht gut getan!)

Oder frag doch mal aufkrawall @ unser forum (https://www.forum-3dcenter.org/vbulletin/showthread.php?p=11592361#post11592361):

Hab gerade eine RX 560 drin: Es läuft quasi alles und das einwandfrei.
-Karte scheint sich sauber rauf und runter zu takten
-75Hz Monitor-OC via Custom-Edid gehen
-ruckel- und tearingfreies X11-Compositing via Compton (0 Einbruch bei neu gezeichneten Fenstern)
-ruckelfreies Scrollen in Firefox
-OGL geht ordentlich, etwa für wine-staging-nine
-RadV ist in SS: Fusion schneller als OGL und macht keine Grafikfehler (leider hat das Spiel miese Frametimes mit Vulkan/OGL)
-OpenCL geht via amdgpu-pro-Paket aus dem AUR, das zu amdgpu kompatibel ist (folding@home läuft, habe ~140k ppd laut linuxforge-Rechner)
-mpv zeigt mit nicht zu aggressiven Einstellungen keinerlei Ruckeln

KWin X11-Compositing verursacht leider genau wie mit Intel Ruckler in Firefox, ziemlich enttäuschend von KDE Plasma. Im Gegensatz zu Intel zeigt AMD allerdings kein Ruckeln in mpv ohne Compositor, irgendwas ist da bei Intel unschön regressed.

Kurzum: Mit recht aktueller Radeon hab ich bislang die beste Linux-Erfahrung. Läuft gerade sogar besser als Windows, wo das Powermanagement im Treiber absolut bescheuert eingestellt ist (und ist nicht lösbar übers Treiber-UI...).

Todo unter Linux bleiben jetzt noch manuelle Lüfterkurve und Undervolting.

===

@ topic:

Nachdem ich nun verstanden habe, worum es geht und auch die ersten Performance-Tests gesehen habe, ist es für Rechenzentren der Super-GAU. :eek:
Nicht nur, dass die fehlende Leistung ausgeglichen werden muss, auch der ganze Patch- und Verwaltungsaufwand.

Ja, als Home-User, denke ich, fällt das kaum auf; wobei man auch sagen muss, für Gamer *könnte* das schon ins Gewicht fallen, gerade wenn man Preis-Performance kauft.

Und einen eigenartigen Beigeschmack hat CEOs Brian Krzanichs Verkauf seiner Intel Aktien auf alle Fälle; auch den Kernel "still und heimlich" selbst mit -rc5 zu patchen läßt nichts Gutes hoffen.

deekey777

2018-01-03, 20:38:09

Sind eigentlich Atomare betroffen (Silvermont, Goldmont, Airmont)?

mocad_tom

2018-01-03, 20:48:05

Seite 6:
http://routebricks.org/papers/rb-sosp09.pdf
"Multi-queue NICs are essential"

Seite 11:
http://people.csail.mit.edu/nickolai/papers/boyd-wickizer-scaling.pdf
Postgres

Gorkon

2018-01-03, 21:03:20

Sind eigentlich Atomare betroffen (Silvermont, Goldmont, Airmont)?
#NASGate? :freak: Das wäre natürlich auch noch massiv ungeil...

CompuJoe

2018-01-03, 21:12:21

Ja die Atom sind auch betroffen.

Wenn ich den Typ vorhin in einem Stream richtig verstanden habe bis zurück zum Yonah von 2006, also alles was sich Core nennt und dessen Ableger.
Mache sagen sogar noch weiter zurück.

Gipsel

2018-01-03, 21:15:54

Hat eigentlich jemand technische Hintergründe was AMD auf Hardware-Ebene anders macht?AMD CPUs machen offenbar keine spekulative Ausführung von Instruktionen über einen Pagefault hinaus (der ausgelöst wird, wenn man auf Adressen zugreifen will, an die man eigentlich nicht ran darf), intel schon. Gibt offenbar bereits ein Proof of Concept (gravitationsfeld hat drauf verlinkt), womit man (recht langsam, aber immerhin) durch eine Kombination von spekulativer Ausführung und Timing Attacke von beliebigen Kernel-Adressen lesen kann. Das funktioniert vermutlich ganz ähnlich zu den Versuchen von Anders Fogh vom Juli 2017 (war hier schon mal verlinkt (https://www.forum-3dcenter.org/vbulletin/showthread.php?p=11592879#post11592879)), nur noch ein wenig erfolgreicher.

Linmoum

2018-01-03, 21:25:55

Intel hat sich nun dazu geäußert.
Intel and other technology companies have been made aware of new security research describing software analysis methods that, when used for malicious purposes, have the potential to improperly gather sensitive data from computing devices that are operating as designed. Intel believes these exploits do not have the potential to corrupt, modify or delete data.
https://newsroom.intel.com/news/intel-responds-to-security-research-findings/

Und
However, Intel is making this statement today because of the current inaccurate media reports.
das darf man jetzt in welche Richtung verstehen? :freak:

labecula

2018-01-03, 21:33:04

Zumindest in den USA dürfte auf Intel eine ziemliche Klagewelle zurollen.

Boris

2018-01-03, 21:33:19

Intel hat sich nun dazu geäußert.

https://newsroom.intel.com/news/intel-responds-to-security-research-findings/

Und

das darf man jetzt in welche Richtung verstehen? :freak:
Erstmal abwarten was in den nächsten Tagen/Wochen noch so kommt.

Pirx

2018-01-03, 21:41:03

Intel believes its products are the most secure in the world...
einfach nur lol

Boris

2018-01-03, 21:49:21

Die Aktie wurde auch gut eingebremst... sollte man beobachten. :)

Ganon

2018-01-03, 22:23:23

einfach nur lol

Interessanter ist der Absatz:

Recent reports that these exploits are caused by a “bug” or a “flaw” and are unique to Intel products are incorrect. Based on the analysis to date, many types of computing devices — with many different vendors’ processors and operating systems — are susceptible to these exploits.

Also der Intel TLB Bug mag zwar Intel Only sein, aber es scheint da noch die ein oder andere Lücke mehr zu geben. Zumindest klingt es so. Bleibt spannend ^^

Lehdro

2018-01-03, 22:28:00

Interessanter ist der Absatz:

Also der Intel TLB Bug mag zwar Intel Only sein [...]
Und damit ist Intel gestorben was die Aussage angeht: Dieser Fehler ist Intel spezifisch und sie geben ihn nichtmal zu, nein, sie sagen alle haben einen Fehler. Aber hey:" Intel believes these exploits do not have the potential to corrupt, modify or delete data." Na wenn Intel das sagt...da hat wohl niemand nen Fehler gemacht.

Diese Aussage ergibt null Sinn, außer man möchte von sich selber ablenken.

Denniss

2018-01-03, 22:28:30

Vermutlich haben die ihren TLB-Bug und sie Umgehung/Aushebelung von ASLR in einen Topf ... ääh Newsmeldung geworfen.

Spasstiger

2018-01-03, 22:30:29

Die Aktie wurde auch gut eingebremst... sollte man beobachten. :)
Deshalb hat Intel-CEO Brian Krzanich "in weiser Voraussicht" bereits im November den maximal möglich Anteil seiner Intel-Aktien verkauft: https://www.fool.com/investing/2017/12/19/intels-ceo-just-sold-a-lot-of-stock.aspx.

Pirx

2018-01-03, 22:30:58

also kein Fehler, der seit Jahren in den Intel-CPUs steckt? Ähm, ich hoffe für Intel, daß sich ein Anwalt das Statement vorher angeschaut hat.

Lehdro

2018-01-03, 22:31:59

Vermutlich haben die ihren TLB-Bug und sie Umgehung/Aushebelung von ASLR in einen Topf ... ääh Newsmeldung geworfen.
This! Und schön auf alle Verteilen den Schmutz. Hoffentlich bekommen sie dafür ihr Fett weg - das ist einfach nur dreist und hat Gründe warum deren "Mitteilung" Absichtlich nicht das Kind beim Namen nennt: Sie reden von ASLR und alle Welt redet zu recht von dem TLB Fuckup.

Linmoum

2018-01-03, 22:34:18

Vielleicht ja auch: "Es gibt keinen Designfehler oder ähnliches, es läuft alles wie gewollt. Konnte ja keiner ahnen, dass wir da plötzlich 'ne massive Sicherheitslücke entdecken." :P

Menace

2018-01-03, 22:41:49

Also der Intel TLB Bug mag zwar Intel Only sein, aber es scheint da noch die ein oder andere Lücke mehr zu geben. Zumindest klingt es so. Bleibt spannend ^^

Also doch intel only. Dachte bei AMD wäre es auch so? Hast Du Dich nicht so geäußert?

Und auch interessant, dass nochmals von Dir betont wird, dass ja irgendwer vielleicht auch irgendwas noch gemacht hat. Ist das subtiler Whataboutism oder verstehe ich Dich komplett falsch?

Ganon

2018-01-03, 22:44:28

also kein Fehler, der seit Jahren in den Intel-CPUs steckt? Ähm, ich hoffe für Intel, daß sich ein Anwalt das Statement vorher angeschaut hat.

Es deutet zwar vieles darauf hin, dass es ein Fehler ist, besonders die Aussage eines AMD-Mitarbeiters auf der Kernel Mailing Liste und der beschriebene Effekt wurde ja auch schon nachgestellt, aber die grundlegende Ursache ist immer noch eine Vermutung.

Also solange der endgültige Security-Bericht nicht da ist, würde ich mit Pauschalaussagen und Behauptungen noch warten. Erst danach kann man dann loslegen, wie auch immer das Ergebnis ist.

Es ist halt immer noch fraglich, warum erst mal alle x86er geblockt wurden und die Rolle von ARM64 ist hier auch noch tief im Nebel. Es kann das ASLR Problem sein, vielleicht ist es aber noch mehr? Möglich ist es. Vielleicht wurde bisher bei all dem Krach bisher ein weiteres Problem noch übersehen...

Also doch intel only. Dachte bei AMD wäre es auch so? Hast Du Dich nicht so geäußert?

Und auch interessant, dass nochmals von Dir betont wird, dass ja irgendwer vielleicht auch irgendwas noch gemacht hat. Ist das subtiler Whataboutism oder verstehe ich Dich komplett falsch?

Sorry, aber was? Ich verstehe gerade nicht was du gerade meinst.

LadyWhirlwind

2018-01-03, 22:49:04

So wie ich KPTI verstanden habe, reduziert das allgmein die Angriffsfläche, auch unabhängig von TLB-Bug, Was grundsätzlich ja für alle Hersteller etwas gutes ist. Es muss nicht gesagt sein, dass es nicht auch in AMD und ARM CPUs Fehler gibt, die einen Angriff ermöglich und die durch KPTI effektiv verhindert werden können.

Ich vermute, dass will uns Intel auch mit seiner Pressemitteilung sagen.

Menace

2018-01-03, 22:49:54

Ich finde, Du relativierst hier ziemlich häufig zu Gunsten von intel und zu ungunsten von AMD und anderen.

Von welchen Prozessoren ist es bisher bekannt, dass sie einen TLB-Bug haben?

LadyWhirlwind

2018-01-03, 22:58:27

Ganon

2018-01-03, 23:00:24

Ich finde, Du relativierst hier ziemlich häufig zu Gunsten von intel und zu ungunsten von AMD und anderen.

Ich relativiere in die Richtung, dass das Performance-Problem für den Normalanwender quasi nicht existiert. Ich hab jetzt schon oft genug (nicht nur hier) gelesen, dass Leute anfangen wollen ihre Updates abzuschalten, weil sie keine >30% Performance-Verlust haben wollen. Und das ist einfach alberne Panik-Mache und richtet nur Schaden an aufgrund einer Ursache die gar nicht da ist.

Mir ist dabei doch der Hersteller vollkommen egal.

Von welchen Prozessoren ist es bisher bekannt, dass sie einen TLB-Bug haben?

TLB-Bugs gab es schon. Einige konnten mit Microcode-Updates gefixt werden, andere sorgten für eine TLB-Abschaltung. Sowohl bei Intel als auch bei AMD. Allgemein sind CPU-Bugs keine Seltenheit.

Complicated

2018-01-03, 23:05:29

Und damit ist Intel gestorben was die Aussage angeht: Dieser Fehler ist Intel spezifisch und sie geben ihn nichtmal zu, nein, sie sagen alle haben einen Fehler. Aber hey:" Intel believes these exploits do not have the potential to corrupt, modify or delete data." Na wenn Intel das sagt...da hat wohl niemand nen Fehler gemacht.

Diese Aussage ergibt null Sinn, außer man möchte von sich selber ablenken.
Doch sie ergibt Sinn, vor allem im Hinblick auf mögliche Klagen:
Zum einen wird klar gestellt, dass es eine Sicherheitslücke ist und kein Hardwarefehler der ein falsches Rechenergebnis produziert oder Daten verfälscht oder beschädigt. Das stimmt soweit auch. Erst wenn ein Mensch sich durch die Sicherheitslücke Zugang verschafft, sind Daten bedroht.

Und zum anderen wird darauf hingewiesen, dass es viele Sicherheitslücken auch bei allen anderen Herstellern gibt die mit "solchen Exploits" auch kämpfen müssen und Patches raus bringen.

Die Haftung für eine Sicherheitslücke liegt eher bei Software oder ist besser gesagt eher nicht so klar. Zumindest wird der Hardwarehersteller sehr schwer haftbar gemacht von einem Gericht wenn die die Performance niedriger ist aus Sicherheitsgründern. Das hat man oft schon wenn AES Verschlüsselung genutzt wird auf Festplatten.

Hat eigentlich jemand technische Hintergründe was AMD auf Hardware-Ebene anders macht?
AMD CPUs machen offenbar keine spekulative Ausführung von Instruktionen über einen Pagefault hinaus (der ausgelöst wird, wenn man auf Adressen zugreifen will, an die man eigentlich nicht ran darf), intel schon.
Ergänzend die Stelle bei arstechnica zu dem Aspekt:
https://arstechnica.com/gadgets/2018/01/whats-behind-the-intel-design-flaw-forcing-numerous-patches/
Intel processors, specifically—though not AMD ones (https://lkml.org/lkml/2017/12/27/2)—allow speculative execution of ring 3 code that writes to ring 0 memory. The processors do properly block the write, but the speculative execution minutely disturbs the processor state, because certain data will be loaded into cache and the TLB in order to ascertain whether the write should be allowed. This in turn means that some operations will be a few cycles quicker, or a few cycles slower, depending on whether their data is still in cache or not. As well as this, Intel's processors have special features, such as the Software Guard Extensions (SGX) introduced with Skylake processors, that slightly change how attempts to access memory are handled. Again, the processor does still protect ring 0 memory from ring 3 programs, but again, its caches and other internal state are changed, creating measurable differences.

Kriton

2018-01-03, 23:06:06

Die Stellungnahme von Intel ist aber mal echt...

Recent reports that these exploits are caused by a “bug” or a “flaw” and are unique to Intel products are incorrect.

Sie verknüpfen mehrere Dinge um dann zu sagen, dass es (die Gesamtheit) falsch ist. Wie schon gesagt spielen sie damit vielleicht auf ASLR an, sie sprechen ja von "exploits" also plural. Wenn ich das richtig gelesen habe ist das ja eher das Thema, das auch ARM betrifft. Mental kommt natürlich leicht an, dass es zum einen alle betrifft und 2. eigentlich keine bugs sind.

Based on the analysis to date, many types of computing devices — with many different vendors’ processors and operating systems — are susceptible to these exploits.

Das wäre nur logisch, wenn ARM betroffen ist. Nichts Neues also.

Intel is committed to product and customer security and is working closely with many other technology companies, including AMD, ARM Holdings and several operating system vendors, to develop an industry-wide approach to resolve this issue promptly and constructively. Intel and other vendors had planned to disclose this issue next week when more software and firmware updates will be available.

Hier suggerieren sie, dass AMD ebenfalls betroffen ist, wobei sie eigentlich nur sagen, dass man miteinander redet, aber diese inhaltliche Trennung ist bei vielen Lesern/Redakteuren scheinbar zuviel verlangt.

Man sieht das sehr schön bei den amerikanischen Seiten: Schreiben viele, dass es nicht intel-spezifisch ist und die Aktienmärkte reagieren entsprechend. Unglaublich wie die Lesekompetenz in Bezug auf Unternehmensmarketing ist...:facepalm:

Juristisch werden sie wohl damit durchkommen, sie sagen ja nichts Falsches. Sie sind lediglich (erfolgreich) manipulativ.

Und seit wann haben wir in der Überschrift dieses Threads eigentlich 5% Performance Einbuße stehen? Das war am Anfang nicht da, wenn ich nicht irre und passt auch nicht zum OP.

Ganon

2018-01-03, 23:06:34

Apple hat scheinbar das Problem (zumindest teilweise) in 10.13.2 gefixt und es folgt wohl mehr in 10.13.3: https://www.macrumors.com/2018/01/03/intel-design-flaw-fixed-macos-10-13-2/

Lehdro

2018-01-03, 23:08:22

Erst wenn ein Mensch sich durch die Sicherheitslücke Zugang verschafft, sind Daten bedroht.
Angeblich kann man ja Daten _auslesen_, genau das was Intel so ziemlich auslässt in Ihrem Statement. Da steht schließlich nur was von "corrupt, modify and delete". Und nun?

Linmoum

2018-01-03, 23:10:27

Die Tatsache das bei Linux standardmässig davon ausgegangen wird, dass alle Hersteller betroffen sind, legt den verdacht nahe, das man hier ein grundsätzliches Problem sieht, das man kpti beheben will.
Würde man ein grundsätzliches Problem sehen, dann würde man allerdings eher nicht den entsprechenden AMD-Patch in Betracht ziehen. Der wird allerdings für Linux kommen.

While at the moment with the mainline Linux kernel Git tree AMD CPUs enable x86 PTI and are treated as "insecure" CPUs (https://www.phoronix.com/scan.php?page=news_item&px=x86-PTI-EPYC-Linux-4.15-Test), the AMD patch for not setting X86_BUG_CPU_INSECURE will end up being honored.
https://www.phoronix.com/scan.php?page=news_item&px=Linux-Tip-Git-Disable-x86-PTI

Unicous

2018-01-03, 23:11:14

@Ganon

Quasi nicht existiert. Beweis durch Behauptung?:confused:

Du weißt doch noch gar nicht ob es nicht Anwendungen gibt, die betroffen sein könnten. Ich finde man sollte in beide Richtungen mal die Füße still halten.

Die gesamte Tragweite ist noch nicht greifbar, es könnte ein Sturm im Wasserglas sein, es könnte sich auch zu einem Tropensturm mutieren.
Zu dieser Zeit schon aufgrund sehr dünner Informationslage Schlussfolgerungen zu ziehen, weil hier und da mal ein Benchmark gefahren wurde finde ich jedenfalls unangebracht.

btw. AMD hat schon auf Intels Statement reagiert. Das artet also zunehmend in eine soap opera aus. :popcorn:

AMD rebukes Intel, says flaw poses 'near-zero risk' to its chips (https://www.cnbc.com/2018/01/03/amd-rebukes-intel-says-flaw-poses-near-zero-risk-to-its-chips.html)

To be clear, the security research team identified three variants targeting speculative execution. The threat and the response to the three variants differ by microprocessor company, and AMD is not susceptible to all three variants. Due to differences in AMD's architecture, we believe there is a near zero risk to AMD processors at this time.

https://memegenerator.net/img/images/600x600/16120736/big-bag-of-popcorn.jpg

berhan

2018-01-03, 23:11:18

Gibt auch schon einen Wikipediartikel.
https://en.wikipedia.org/wiki/Kernel_page-table_isolation

Und der von KAISER.
https://gruss.cc/files/kaiser.pdf

Achill

2018-01-03, 23:11:46

Complicated

2018-01-03, 23:12:49

@Lehdro
Wenn ein menschlicher Täter nötig ist, dann ist die Hardware nicht Schuld. Eine vor Gericht durchaus plausible Strategie. Ob das bei den Server Kunden eine Rolle spielt steht auf einem anderen Blatt Papier, wird sicherlich auch mit anderen Strategien angegangen.

Kriton

2018-01-03, 23:14:49

@Lehdro
Wenn ein menschlicher Täter nötig ist, dann ist die Hardware nicht Schuld. Eine vor Gericht durchaus plausible Strategie.

Jetzt pull ich mal einen Coda: Nein.

Armaq

2018-01-03, 23:15:27

Intel halt. Schön vermengen mit anderen Themen und bloß nicht klar sagen was Sache ist.

Ganon

2018-01-03, 23:15:39

Quasi nicht existiert. Beweis durch Behauptung?:confused:

Du weißt doch noch gar nicht ob es nicht Anwendungen gibt, die betroffen sein könnten. Ich finde man sollte in beide Richtungen mal die Füße still halten.

Nun, ich hab bisher immer noch kein Real-World Benchmark gesehen der mir die >30% Performance-Verlust zeigt. Und wie gesagt, ich rede gerade von Normalanwendern. Normalanwender die aus Angst vor Performance-Verlust sämtliche Updates abschalten wollen.

Du kannst mir gerne Beispiele zeigen wo der Normalanwender hier stark betroffen ist. Bisher sprechen so ziemlich alle Benchmarks dagegen.

Complicated

2018-01-03, 23:18:58

Es gibt ja noch ARM und VIA neben AMD und Intel. Es reicht schon wenn es auf ARM oder VIA auch zutrifft, dann ist Intels Aussage richtig... Sie haben ja nicht geschrieben, dass alle Prozessoren betroffen sind.

Ist erstmal eine legale Nebelkerze, imho bin ich mir sehr sicher, dass Intel weiß welche Prozessoren von der Konkurrenz betroffen sind und welche nicht.
Und ARM hat ja schon ähnliche Verwundbarkeit zugegeben inkl. Patches für:
http://fortune.com/2018/01/03/intel-kernel-security-flaw-amd/
ARM, which is owned by SoftBank Group, said in a statement: “ARM have been working with Intel and AMD to devise mitigation for a new method identified by security researchers that can exploit certain high-end processors, including ours…Software mitigation measures have already been shared with our partners. ARM takes all security threats seriously and we encourage individual users to ensure their software is up-to-date and always practice good security hygiene.”
AMD dazu wie auch zuvor schon geschrieben:
AMD said its chips were affected by some but not all of a series of related security exploits uncovered by researchers. AMD has already developed a simple software fix for its chips that will not impact PC performance, an AMD spokesman said. “Due to differences in AMD’s architecture, we believe there is a near zero risk to AMD processors at this time,” the company said in a statement. “We expect the security research to be published later today and will provide further updates at that time.”Ich glaube die bei AMD können sich derzeit nur schwer zurück halten, denn wenn man sich deren "simple Software fix" anschaut:
https://lkml.org/lkml/2017/12/27/2
AMD processors are not subject to the types of attacks that the kernel
page table isolation feature protects against. The AMD microarchitecture
does not allow memory references, including speculative references, that
access higher privileged data when running in a lesser privileged mode
when that access would result in a page fault.

Disable page table isolation by default on AMD processors by not setting
the X86_BUG_CPU_INSECURE feature, which controls whether X86_FEATURE_PTI
is set.
Du kannst mir gerne Beispiele zeigen wo der Normalanwender hier stark betroffen ist. Bisher sprechen so ziemlich alle Benchmarks dagegen.Die gibt es nicht. Bei Desktops/Notebooks/Tablets werden die Patches keine Rolle spielen bei der Performance. Bei Servern ist es ein Desaster. Wer hier über Normalanwender diskutiert ist sowieso völlig auf dem falschen Dampfer. Das wäre allerdings für Intel deutlich billiger geworden als dieser Vertrauensverlust im profitabelsten Sektor. Das prognostizierte 8% Wachstum können sie dieses Jahr abschreiben im Server Segment.

berhan

2018-01-03, 23:20:19

Problem dürfte schon länger bekannt sein.
https://cyber.wtf/2017/07/28/negative-result-reading-kernel-memory-from-user-mode/

LadyWhirlwind

2018-01-03, 23:22:44

Würde man ein grundsätzliches Problem sehen, dann würde man allerdings eher nicht den entsprechenden AMD-Patch in Betracht ziehen. Der wird allerdings für Linux kommen.

https://www.phoronix.com/scan.php?page=news_item&px=Linux-Tip-Git-Disable-x86-PTI

Weiss ich, ist eine Frage des Blickpunktes. Gehe ich erstmal davon aus, dass kein Fehler da ist und daher auch keine Gefahr besteht oder gehe ich erstmal davon aus, dass ein Fehler vorhanden sein könnte? Ersteres ist ziemlich blauäugig, daher macht es durchaus Sinn, dass man etwas unternimmt um die Folgen eines Fehlers zu mitigieren. Wenn jemand dann den Beweis antritt, dass er nicht betroffen ist, kann man ihn immer noch whitelisten.

Complicated

2018-01-03, 23:25:39

Jetzt pull ich mal einen Coda: Nein.
Du meinst es gab schon Gerichte die einen Hardware Hersteller für Sicherheitslücken verantwortlich gemacht haben, welche durch die Software geschlossen werden konnten? Würde mich sehr interessieren. Ansonsten wären inhaltsreichere Posts hilfreich bei komplexen Themen.

Linmoum

2018-01-03, 23:25:46

Slides von Intel zu der Diskussion

https://s21.q4cdn.com/600692695/files/doc_presentations/2018/Side-Channel-Analysis-Security.pdf

Ganon

2018-01-03, 23:29:34

Die gibt es nicht. Bei Desktops/Notebooks/Tablets werden die Patches keine Rolle spielen bei der Performance. Bei Servern ist es ein Desaster. Wer hier über Normalanwender diskutiert ist sowieso völlig auf dem falschen Dampfer.

Leider ist aber gerade eine ziemliche Panik unter Normalanwendern deswegen. Und hier muss man einfach mal auf die Bremse treten. Die Medien schreiben den Kram gerade alle so, als wenn demnächst alle Intel-CPUs nur noch halbe Leistung liefern. Dass Performance-Probleme nur in bestimmten Workloads auftreten und auch stark von der verwendeten Hardware abhängen sagt kaum einer.

Complicated

2018-01-03, 23:29:44

@Limonum
Jo...wie erwartet. OS Update, VMM Update und Firmware Update.

Unicous

2018-01-03, 23:32:24

@Ganon

Es wurde doch noch gar nicht in alle Richtungen untersucht. Bloß weil Larabel ein paar Gaming-Benchmarks laufen lässt oder CB ein paar unter Windows kann man doch daraus nicht konstatieren, der Normalanwender (wer auch immer DAS sein soll :rolleyes:) wäre nicht betroffen.

Bei solchen pauschalen Aussagen kann ich eigentlich nur stundenlang die Augen rollen. Es ist Tag 2 nachdem eine breitere Öffentlichkeit davon Kenntnis nehmen konnte und ob das Ende der Fahnenstange erreicht ist wissen wir nicht.

Jetzt schon zu konstatieren "Hier gibt es nichts zu sehen, bitte gehen sie weiter" ist nichts weiter als Beschwichtigungspolitik und bei dem was Intel in letzter Zeit abgezogen hat, was (Un-)Sicherheits-Features angeht, sollte man einfach mal den Ball flach halten.

Und zudem: Wen interessiert denn die Performance wenn potentiell Myriaden von Systemen gefährdet sind und entsprechend geupdatet werden müssen?
Als Beschäftigungstherapie für Systemadminstratoren sicherlich eine tolle Übung seitens Intel, ich denke aber dass die das etwas anders sehen.

gurgelhals

2018-01-03, 23:34:08

The rumored bugs in Intel (and beyond) processors have now been disclosed: they are called Meltdown and Spectre, and have the requisite cute logos. Stay tuned for more.

https://spectreattack.com/

Alter.

https://meltdownattack.com/meltdown.pdf
https://spectreattack.com/spectre.pdf

Meltdown breaks the most fundamental isolation between user applications and the operating system. This attack allows a program to access the memory, and thus also the secrets, of other programs and the operating system.

Spectre breaks the isolation between different applications. It allows an attacker to trick error-free programs, which follow best practices, into leaking their secrets. In fact, the safety checks of said best practices actually increase the attack surface and may make applications more susceptible to Spectre

Nakai

2018-01-03, 23:36:19

Unicous

2018-01-03, 23:40:03

At the moment, it is unclear whether ARM and AMD processors are also affected by Meltdown.

:rolleyes:

Ich finde in dem Zusammenhang auch diesen Satz aus der Intel pdf

Security researcher notified Intel, AMD, and ARM of a new side-channel analysis exploit

und diesen aus der Intel PM

Intel is committed to product and customer security and is working closely with many other technology companies, including AMD, ARM Holdings and several operating system vendors, to develop an industry-wide approach to resolve this issue promptly and constructively.

sehr interessant. Hört sich eher so an, als ob die researcher alle potentiell gefährdeten Architektur-"Inhaber" benachrichtigt hat (warum ist eigentlich z.B. MIPS nicht auch dabei? :uponder:) und Intel jetzt so tut, als wären sie auch betroffen und man würde mit ihnen "zusammenarbeiten".:wink:

berhan

2018-01-03, 23:40:17

Slides von Intel zu der Diskussion

https://s21.q4cdn.com/600692695/files/doc_presentations/2018/Side-Channel-Analysis-Security.pdf

Das Problem, dass auf Kernel-Daten im L1 cache im usermode zugegriffen werden kann dürfte jedoch nur INTEL haben.

Pinoccio

2018-01-03, 23:40:26

Google Project Zero: Reading privileged memory with a side-channel (https://googleprojectzero.blogspot.de/2018/01/reading-privileged-memory-with-side.html)

So far, there are three known variants of the issue:

Variant 1: bounds check bypass (CVE-2017-5753)
Variant 2: branch target injection (CVE-2017-5715)
Variant 3: rogue data cache load (CVE-2017-5754)

During the course of our research, we developed the following proofs of concept (PoCs):

- A PoC that demonstrates the basic principles behind variant 1 in userspace on the tested Intel Haswell Xeon CPU, the AMD FX CPU, the AMD PRO CPU and an ARM Cortex A57[2]. This PoC only tests for the ability to read data inside mis-speculated execution within the same process, without crossing any privilege boundaries.

- A PoC for variant 1 that, when running with normal user privileges under a modern Linux kernel with a distro-standard config, can perform arbitrary reads in a 4GiB range [3] in kernel virtual memory on the Intel Haswell Xeon CPU. If the kernel's BPF JIT is enabled (non-default configuration), it also works on the AMD PRO CPU. On the Intel Haswell Xeon CPU, kernel virtual memory can be read at a rate of around 2000 bytes per second after around 4 seconds of startup time. [4]

- A PoC for variant 2 that, when running with root privileges inside a KVM guest created using virt-manager on the Intel Haswell Xeon CPU, with a specific (now outdated) version of Debian's distro kernel [5] running on the host, can read host kernel memory at a rate of around 1500 bytes/second, with room for optimization. Before the attack can be performed, some initialization has to be performed that takes roughly between 10 and 30 minutes for a machine with 64GiB of RAM; the needed time should scale roughly linearly with the amount of host RAM. (If 2MB hugepages are available to the guest, the initialization should be much faster, but that hasn't been tested.)

- A PoC for variant 3 that, when running with normal user privileges, can read kernel memory on the Intel Haswell Xeon CPU under some precondition. We believe that this precondition is that the targeted kernel memory is present in the L1D cache.
AMD so halb betroffen.

/Edit: Sehe grade, der ist auch auf spectreattack.com verlinkt.

/Edit2: Exploiting Speculative Execution via JavaScript - zur Frage, ob auch Normaluser betroffen sind. Wenn eine Webseitew mit JS meine Geheimnisse aus dem RAM holen kann, dann ja wohl schon.

mfg

Ganon

2018-01-03, 23:40:26

Es wurde doch noch gar nicht in alle Richtungen untersucht. Bloß weil Larabel ein paar Gaming-Benchmarks laufen lässt oder CB ein paar unter Windows kann man doch daraus nicht konstatieren, der Normalanwender (wer auch immer DAS sein soll :rolleyes:) wäre nicht betroffen.

Bei solchen pauschalen Aussagen kann ich eigentlich nur stundenlang die Augen rollen. Es ist Tag 2 nachdem eine breitere Öffentlichkeit davon Kenntnis nehmen konnte und ob das Ende der Fahnenstange erreicht ist wissen wir nicht.

Und pauschal und ohne Grundlage Panik verbreiten ist jetzt besser oder wie? :ugly: Von >30% reden, obwohl das nur heftigen VM-Workloads und Micro-Benchmarks gezeigt werden kann? Auch das weiter verbreiten obwohl die Leute dahinter immer von "in der Regel 5%" reden und auch alle Benchmarks bisher genau das zeigen?

Sorry, aber pauschale Aussagen sind was anderes. Meine Aussagen basieren auf aktuellen Anwendungs-Benchmarks und nicht auf wilden Vermutungen und unrealistischen Micro-Benchmarks.

Ganon

2018-01-03, 23:41:43

AMD so halb betroffen.
mfg

Darum redet AMD vermutlich auch von "not all three" und "near zero" und nicht "wir sind absolut gar nicht betroffen".

/Edit2: Exploiting Speculative Execution via JavaScript - zur Frage, ob auch Normaluser betroffen sind. Wenn eine Webseitew mit JS meine Geheimnisse aus dem RAM holen kann, dann ja wohl schon.

Und genau darum sollten User die Updates einspielen und nicht mit abartig hohen Performance-Verlusten verängstigt werden.

Linmoum

2018-01-03, 23:42:27

Which systems are affected by Meltdown?
Desktop, Laptop, and Cloud computers may be affected by Meltdown. More technically, every Intel processor which implements out-of-order execution is potentially affected, which is effectively every processor since 1995 (except Intel Itanium and Intel Atom before 2013). We successfully tested Meltdown on Intel processor generations released as early as 2011. Currently, we have only verified Meltdown on Intel processors. At the moment, it is unclear whether ARM and AMD processors are also affected by Meltdown.

Which systems are affected by Spectre?
Almost every system is affected by Spectre: Desktops, Laptops, Cloud Servers, as well as Smartphones. More specifically, all modern processors capable of keeping many instructions in flight are potentially vulnerable. In particular, we have verified Spectre on Intel, AMD, and ARM processors.
What is the difference between Meltdown and Spectre?
Meltdown breaks the mechanism that keeps applications from accessing arbitrary system memory. Consequently, applications can access system memory. Spectre tricks other applications into accessing arbitrary locations in their memory. Both attacks use side channels to obtain the information from the accessed memory location.
Das wird noch lustig.

Complicated

2018-01-03, 23:48:16

Und zudem: Wen interessiert denn die Performance wenn potentiell Myriaden von Systemen gefährdet sind und entsprechend geupdatet werden müssen?
Als Beschäftigungstherapie für Systemadminstratoren sicherlich eine tolle Übung seitens Intel, ich denke aber dass die das etwas anders sehen.Eben und darüber muss berichtet werden. Den Schwachsinn mit Benchmarks die auch noch in FPS ihre Resultate ausspucken kann man sich erst einmal sparen. Redaktionen die in dieser Richtung berichten derzeit zeigen ihre Kompetenz sehr deutlich.

Ein Fehler mit Patch der vor allem I/O-lastige Anwendungen schwer abgestraft wird z.B. von CB mit einem Testverfahren gemessen das Zitat:
Die gewählten Benchmarks sind nicht von der Leistungsfähigkeit der SSD abhängig. davon überhaupt nicht abhängt - schön, dass sie keine Unterschiede messen in den Benchmarks - Problem nicht verstanden und Testsystem auf "beruhigen der Leser" eingestellt.

Hierbei bleibt vor allem der Aspekt bestehen was denn mit gängigen Kopierschutzsystemen hier passiert? Denuvo und VMProtect sind hier z.B. sehr I/O-Lastig mit ihren Virtuellen Maschinen:
http://vmpsoft.com/support/user-manual/introduction/what-is-vmprotect/
The crucial advantage of the virtualization method used in VMProtect is the fact that the virtual machine executing virtualized fragments of code is embedded into the resulting code of the protected application. Therefore, the app protected with VMProtect needs no third-party libraries or modules to function. VMProtect allows using several different virtual machines to protect different fragments of code of the same application resulting in even more complicated cracking process, because a hacker now has to analyze architecture of multiple virtual machines.

Und genau dieses eine Spiel, welches das nutzt war auch auffällig bei CB: Assassins Creed Origins

Nakai

2018-01-03, 23:49:00

Modern processors use branch prediction and speculative
execution to maximize performance. For example, if
the destination of a branch depends on a memory value
that is in the process of being read, CPUs will try guess
the destination and attempt to execute ahead. When the
memory value finally arrives, the CPU either discards or
commits the speculative computation. Speculative logic
is unfaithful in how it executes, can access to the victim’s
memory and registers, and can perform operations with
measurable side effects.
Spectre attacks involve inducing a victim to speculatively
perform operations that would not occur during
correct program execution and which leak the victim’s
confidential information via a side channel to the adversary.

Das ist ein richtig ernsthaftes Problem.

Linmoum

2018-01-03, 23:51:32

https://pbs.twimg.com/media/DSpmxcLUQAA2VRu.jpg:large
https://twitter.com/ryanshrout/status/948683677244018689

berhan

2018-01-03, 23:51:35

Und pauschal und ohne Grundlage Panik verbreiten ist jetzt besser oder wie? :ugly: Von >30% reden, obwohl das nur heftigen VM-Workloads und Micro-Benchmarks gezeigt werden kann? Auch das weiter verbreiten obwohl die Leute dahinter immer von "in der Regel 5%" reden und auch alle Benchmarks bisher genau das zeigen?

Sorry, aber pauschale Aussagen sind was anderes. Meine Aussagen basieren auf aktuellen Anwendungs-Benchmarks und nicht auf wilden Vermutungen und unrealistischen Micro-Benchmarks.

Ich glaub du hast das Problem nicht erkannt. Der Performance-Einbruch ist ja nur die Folge des Workaround. Kritisch ist derzeit das eine ausgeführte Maleware welche im Usermode läuft auf Daten im Kernel zugreifen kann. Und das betrifft alle x64 INTEL Prozessoren. Das Problem bleibt so lange bestehen bis halt ein Update des Betriebssystems kommt, welches dann mehr oder weniger große Performence-Einbrüche aufweist.

Ganon

2018-01-03, 23:56:50

Ich glaub du hast das Problem nicht erkannt. Der Performance-Einbruch ist ja nur die Folge des Workaround. Kritisch ist derzeit das eine ausgeführte Maleware welche im Usermode läuft auf Daten im Kernel zugreifen kann. Und das betrifft alle x64 INTEL Prozessoren. Das Problem bleibt so lange bestehen bis halt ein Update des Betriebssystems kommt, welches dann mehr oder weniger große Performence-Einbrüche aufweist.

Du, das ist mir klar. Ich weise nur darauf hin, dass die Performance-Panik-Mache nicht dazu führt, dass alle Nutzer das Update haben wollen, sondern dass die Leute das Update nicht haben wollen und somit ihre Systeme offen wie ein Scheunentor lassen.

Man muss den Leuten klar machen, was Sache ist und nicht "OMG INTEL WIRD JETZT BIS ZU 30% LAHMER!!!" rumbrüllen.

Nakai

2018-01-03, 23:57:28

Für den normale Heimanwender spielt das weniger eine Rolle. Für Datenbanken/Cloud Provider/etc... kann das ein großes Problem werden.
Falls ein Cloud Provider für seine Applikation ~5% Performanceeinbruch erwarten kann, dann wirkt sich das direkt auf die Serverinfrastruktur aus. Das heißt man bräuchte ~5% mehr Rechenleistung im System und man hat ~5% mehr Energieverbrauch.;D

Unicous

2018-01-03, 23:59:55

@Ganon

Du hast doch schon von Anfang an appeasement betrieben. Ich breche das mal auf "Es ist zwar ein (schwerer) Fehler, aber jeder macht mal (schwere) Fehler" herunter.:rolleyes:
Das Bugs und security flaws zu jeder Zeit und aller Orten existieren und gefixed werden ist keine neue Erkenntnis. Wenn aber kein Jahr vergeht in dem ein vermeintliches Sicherheitsfeature von Intel (oder jedweder anderen Firma) implementiert wird das am Ende des Tages das Produkt noch unsicherer macht sollte man irgendwann mal die coole Sonnenbrille abnehmen und etwas vorsichtiger mit seinen Aussagen werden.

Du erzählst hier was von Panikmache aber versuchst hier das genaue Gegenteil zu verbreiten. Dass die Medien sich nicht mit Ruhm bekleckern sollte (erstens nicht verwundern und zweitens) nicht darüber hinwegtäuschen, dass das nicht so einfach wegzudeuteln ist wie Intel es gerade versucht oder andere ins löchrige Boot zu ziehen.

Ich sagte bereits mehrfach, man sollte in beide Richtungen mal gepflegt durch die Hose atmen, denn noch sind wir am Anfang, du tust mMn schon so als wäre alles bereits "durchgestanden" und man echauffiert sich unnötig.:rolleyes:

edit:

@Ganon Wen interessieren denn bitte die Performanceeinbußen (durch einen potentiellen Fix) bei einem (weltweiten) Sicherheitsleck? :facepalm:

Ganon

2018-01-04, 00:08:33

Du hast doch schon von Anfang an appeasement betrieben. Ich breche das mal auf "Es ist zwar ein (schwerer) Fehler, aber jeder macht mal (schwere) Fehler" herunter.:rolleyes:

Nein, meine Aussage war, dass es auch nur ein weiterer schwerer Fehler ist, wie es 2017 mehr als einmal gegeben hat. Es waren auch Fehler dabei die auch dafür sorgten, dass Cloud und VM Anbieter ihre Server rebooten mussten. Die machten natürlich nicht die große Medien-Runde weil es eben kein Hardware-Problem dazu gab.

Du erzählst hier was von Panikmache aber versuchst hier das genaue Gegenteil zu verbreiten. Dass die Medien sich nicht mit Ruhm bekleckern sollte (erstens nicht verwundern und zweitens) nicht darüber hinwegtäuschen, dass das nicht so einfach wegzudeuteln ist wie Intel es gerade versucht oder andere ins löchrige Boot zu ziehen.

Du, jetzt zum dritten mal... es geht mir darum, dass ANWENDER das UPDATE ABLEHNEN weil ihnen erzählt wird ihr Computer wird jetzt >30% LANGSAMER!

@Ganon Wen interessieren denn bitte die Performanceeinbußen (durch einen potentiellen Fix) bei einem (weltweiten) Sicherheitsleck? :facepalm:

Rede ich chinesisch? Mir geht es darum, dass hier Angst vor dem Update gemacht wird, weil irgendwelche Performance-Einbußen an den Haaren herbeigezogen werden. Zu keiner Zeit habe ich hier das Sicherheitsproblem heruntergespielt.

In bisher _jedem_, wirklich ausnahmslos _jedem_ Forum wo über das Thema geredet wird, habe ich von Leuten gelesen, die das Update nicht haben wollen. Warum wollen sie es nicht haben? Weil ihnen jemand gesagt hat es senkt die Performance massiv. Dabei gibt es bisher keine Belege, dass dies (für den Normalanwender) der Fall ist.

gurgelhals

2018-01-04, 00:13:37

Sind Performanceeinbußen angesichts des Spectre-Exploits nicht völlig egal? Lest mal die Paper.

Meltdown bekommt man wenigstens per KPTI noch halbwegs in den Griff, Spectre zeigt grundlegende Designbugs von Prozessorarchitekture, die nicht fixbar sind.

Das macht mir _deutlich_ mehr Angst als 5% oder 50% Performanceimpact.

LadyWhirlwind

2018-01-04, 00:13:58

In bisher _jedem_, wirklich ausnahmslos _jedem_ Forum wo über das Thema geredet wird, habe ich von Leuten gelesen, die das Update nicht haben wollen. Warum wollen sie es nicht haben? Weil ihnen jemand gesagt hat es senkt die Performance massiv. Dabei gibt es bisher keine Belege, dass dies (für den Normalanwender) der Fall ist.

Lies mal bei Computerbase... da gibt es haufenweise Leute die den Patch nicht installieren wollen. Traurig aber wahr.

Ganon

2018-01-04, 00:17:26

Lies mal bei Computerbase... da gibt es haufenweise Leute die den Patch nicht installieren wollen. Traurig aber wahr.

In diversen Reddit-Threads werden sogar Aussagen in der Art "this will not affect your game performance that much" bis zur Löschung runter gevoted und Aussagen wie "time to stop updates" haben mehrstellige upvotes.

steve.it

2018-01-04, 00:22:24

Lies mal bei Computerbase... da gibt es haufenweise Leute die den Patch nicht installieren wollen. Traurig aber wahr.
Wundert mich leider nicht.
Es gibt genügend Leute, die schon "normale" Updates (z.B. bei iOS) nicht einspielen, wenn sie glauben oder wissen, dass dort etwas langsamer oder schlechter läuft. Dass aber auch häufig gar nicht so harmlose Sicherheitslücken gefixed werden, interessiert die nicht oder bekommen die nicht mit. Andere freuen sich sogar auf JailBreaks & Co :rolleyes:
Dann wundert mich so etwas auch hier nicht wirklich...
Ich z.B. wollte bei macOS noch eine Weile bei Sierra bleiben, da mir High Sierra und APFS noch zu sehr mit heißer Nadel gestrickt sind. Da ich aber nichts davon gelesen habe, dass die Geschichte hier auch noch von Apple bei älteren macOS-Versionen gefixed wird, werde ich updaten müssen.

Unicous

2018-01-04, 00:27:14

@Unicous

Hier macht niemand irgendjemandem Angst. Komm mal bitte runter.:rolleyes:

Und nochmal, warum hängst du dich so auf der Performance auf? Sollte das nicht zweitrangig sein?

Du sorgst dich um die armen "Normalanwender" die aus Angst vor Leistungseinbußen nicht updaten, im gleichen Atemzug behauptest du Normalanwender sind eh nicht betroffen (,was zu beweisen wäre:rolleyes:). Warum sollten diese Normalanwender überhaupt irgendwelche Ängste ausstehen wenn über kurz oder lang eh ein Windows Update kommt. Und Linux-User würde ich mal nicht unter die Kategorie Normalanwender verbuchen.

Und wenn es keine Leistungseinbußen gibt warum sagt Intel dann Folgendes On call, $INTC says it's working on hardware changes to limit the performance hit caused by the kernel security flaw. But only says the first products are due at some point this calendar year.
https://twitter.com/EricJhonsa/status/948682525584404480

Niemand ist in der Lage ein komplettes Bild von der Situation zu zeichnen oder die Tragweite aufzuzeigen, daher solltest auch du nicht so tun, als wäre das alles nicht so schlimm, man solle sich mal nicht so haben und das wird doch von den Medien eh nur künstlich aufgebauscht. Der Fakt allein, dass es bislang so gut wie keine Informationen gab und nach und nach erst Informationen zu Tage gefördert werden sollte doch klar machen, dass diese laut dir Panikmache, hausgemacht ist.

Es geht hier auch nicht um dich oder um mich es geht nicht um diese kleine Filterblase namens 3DCenter, es geht um viele Millionen Rechner die eventuell bzw. höchstwahrscheinlich betroffen sind.

Dass du dich über die Aussagen zu den Performanceeinbußen echauffierst anstatt das eigentliche und viel wichtigere Problem zu diskutieren... da kann ich nur noch den Kopf schütteln.

gravitationsfeld

2018-01-04, 00:28:04

https://memegenerator.net/img/images/600x600/16120736/big-bag-of-popcorn.jpg
;D

Ganon

2018-01-04, 00:32:08

Hier macht niemand irgendjemandem Angst. Komm mal bitte runter.:rolleyes:

Oh doch, verlasse mal das 3DC und schaue dich mal in anderen Foren um.

Und nochmal, warum hängst du dich so auf der Performance auf? Sollte das nicht zweitrangig sein?

Gerade das meine ich doch die ganze Zeit. Die Performance-Einbußen sollten vollkommen egal sein, aber jeder redet nur über die vielen Prozente die Intel jetzt langsamer wird. Aber scheinbar liest du gar nicht was ich schreibe, denn deine Aussagen passen überhaupt nicht zu dem was ich geschrieben habe.

Kriton

2018-01-04, 00:41:05

Du meinst es gab schon Gerichte die einen Hardware Hersteller für Sicherheitslücken verantwortlich gemacht haben, welche durch die Software geschlossen werden konnten? Würde mich sehr interessieren. Ansonsten wären inhaltsreichere Posts hilfreich bei komplexen Themen.

Das habe ich nicht gesagt, sondern dass Deine Aussage:

Wenn ein menschlicher Täter nötig ist, dann ist die Hardware nicht Schuld. Eine vor Gericht durchaus plausible Strategie.

falsch ist. Ich kann nachvollziehen, warum die beiden Aussagen für Dich synonym erscheinen, aber da beginnt bereits das Problem. Die Frage was (Zivil)Gerichte entscheiden ist abhängig von den Parteien (bzw. deren Vortrag) und nicht (nur) von den Tatsachen.

Unabhängig davon ein (stark vereinfachtes) Beispiel:

Gehen wir mal von einer Pflichtverletzung (das kann alles mögliche sein, z.B. auch die Nichterfüllung eines Umstands, den der Hersteller z.B. auf seiner Webseite genannt hat, auch wenn die Pflichtverletzung gar nicht dem Hersteller vorgeworfen wird, sondern z.B. dem Verkäufer) in einem Schuldverhältnis aus. Wenn die da ist, muss sich die Gegenseite exculpieren. Die Schuld wird also per Gesetz angenommen. D.h. nicht, dass kein anderer Verantwortlicher existieren darf, sondern, dass die Pflichtverletzung nicht adäquat kausal für den Schaden sein darf. Dein menschlicher Täter wäre insoweit z.B. potentiell relevant, als dass dies die Adäquanz der Kausalität zunichte machen könnte. Da mag es Szenarien geben, aber die Absolutheit Deiner Aussage ist schlicht falsch.

Das ist nur ein möglicher Ansatz.

Generell habe ich jetzt sehr wenig und sehr vereinfacht dargestellt.

Dafür habe ich jetzt vergleichsweise lange gebraucht, weil ich es adressatengerecht formulieren muss. Das ist halt üblicherweise nicht angemessen, wenn irgendeine unqualifizierte Aussage um die Ecke kommt (das klingt jetzt vermutlich härter als ich es meine: no pun intended) und als Wahrheit verkauft wird.

Unicous

2018-01-04, 00:43:46

@Ganon

Du siehst Gespenster oder ein paar "script-kiddies" die einen auf dicke Hose machen. Wenn du dir deswegen schon in die eigene Hose machst, dann stell dir mal vor, bei Intel hat man gerade einen Bug gefunden, der wohl so gut wie ALLE Chips des letzten Jahrzehnts betrifft und der damit Millionen von PCs potentiell unsicher macht.:eek:

Und jetzt stell dir mal vor, dass nicht alle zeitnah mit Updates versorgt werden. :eek: Und dann stell dir mal vor, dass (Sicherheits-)Behörden und andere kritische Unternehmen betroffen sein könnten und auch diese nicht gerade die schnellsten sind wenn es darum geht ihre System in Schuss und auf dem letzten Stand zu halten. Und jetzt kommt der Hammer.
Viele dieser System nutzen weiterhin Windows XP als Untersatz.:eek:

Du hast Angst vor ein paar unverbesserlichen Idioten, dabei gibt es deutlich schwerwiegendere Probleme als einen 12-jährigen Reddit-User.

Complicated

2018-01-04, 00:58:20

Ich z.B. wollte bei macOS noch eine Weile bei Sierra bleiben, da mir High Sierra und APFS noch zu sehr mit heißer Nadel gestrickt sind. Da ich aber nichts davon gelesen habe, dass die Geschichte hier auch noch von Apple bei älteren macOS-Versionen gefixed wird, werde ich updaten müssen.
MacOS hat es wohl seit Version 10.13.2 gefixed:
https://twitter.com/aionescu/status/948609809540046849

Dein menschlicher Täter wäre insoweit z.B. potentiell relevant, als dass dies die Adäquanz der Kausalität zunichte machen könnte. Da mag es Szenarien geben, aber die Absolutheit Deiner Aussage ist schlicht falsch.
Eindeutig ist, dass alleine das Vorhandensein einer Sicherheitslücke niemandem irgendeine rechtliche Handhabe gibt, solange keiner diese nutzt. Kein Täter, keine Anklage. Ansonsten wäre hier noch ein eventueller Sachmangel bei der Hardware zu finden, der aber nicht existiert sobald es einen Softwarepatch gibt der diesen behebt was einer Nachbesserung entspricht. Performance ist bei keinem Kauf garantiert, solange die Eckdaten der CPU stimmen mit denen geworben wurde: GHz, Kerne, Cache.

Ganon

2018-01-04, 01:07:58

Du siehst Gespenster oder ein paar "script-kiddies" die einen auf dicke Hose machen. Wenn du dir deswegen schon in die eigene Hose machst, dann stell dir mal vor, bei Intel hat man gerade einen Bug gefunden, der wohl so gut wie ALLE Chips des letzten Jahrzehnts betrifft und der damit Millionen von PCs potentiell unsicher macht.:eek:

Ist mir bewusst. Nebenbei betrifft eine kritische Lücke in Windows nahezu ebenso viele PCs. Eine kritische Lücke in Linux betrifft ebenso ein Großteil aller Server. Hatten wir 2017 ein paar mal schon. Übrigens ist die Lösung in allen Fällen identisch -> man spielt Updates ein.

Der Unterschied ist eben, dass der Fix für Meltdown eben etwas Performance kostet. Das ist nunmal der Preis dafür, wenn man sich auf einen Hersteller bzw. eine Plattform versteift. Sollte man allgemein nicht tun, hat man aber getan. Die Rechnung kommt jetzt.

Ich kritisiere schlicht die Art und Weise wie (hier) mit vorliegenden Informationen umgegangen wird und statt sich auf bisher vorliegenden Fakten zu beziehen einfach irgendwas an den Haaren herbeigezogen wird. Man sieht es ja... die Versteifung auf den Intel TLB Bug lässt den zweiten Part des Problems, nämlich Spectre auch irgendwie gerade untergehen, meinst du nicht? Denn das gesellt sich gerade in die Richtung Rowhammer.

Und jetzt stell dir mal vor, dass nicht alle zeitnah mit Updates versorgt werden. :eek: Und dann stell dir mal vor, dass (Sicherheits-)Behörden und andere kritische Unternehmen betroffen sein könnten und auch diese nicht gerade die schnellsten sind wenn es darum geht ihre System in Schuss und auf dem letzten Stand zu halten. Und jetzt kommt der Hammer.
Viele dieser System nutzen weiterhin Windows XP als Untersatz.:eek:

Ungepatchte PCs mit veralteter Software sind unsicher... na so eine Neuigkeit.

gurgelhals

2018-01-04, 01:08:17

Meltdown in Action: https://www.youtube.com/watch?v=bReA1dvGJ6Y

Kriton

2018-01-04, 01:09:09

MacOS hat es wohl seit Version 10.13.2 gefixed:
https://twitter.com/aionescu/status/948609809540046849

Eindeutig ist, dass alleine das Vorhandensein einer Sicherheitslücke niemandem irgendeine rechtliche Handhabe gibt, solange keiner diese nutzt. Kein Täter, keine Anklage. Ansonsten wäre hier noch ein eventueller Sachmangel bei der Hardware zu finden, der aber nicht existiert sobald es einen Softwarepatch gibt der diesen behebt was einer Nachbesserung entspricht. Performance ist bei keinem Kauf garantiert, solange die Eckdaten der CPU stimmen mit denen geworben wurde: GHz, Kerne, Cache.

Deswegen sagte ich einfach nur: Nein.

Du hast ein grundlegendes Mißverständnis (allein, dass ich allein vom Zivilrecht rede, während Du mit Strafrechtsterminologie kommst um dann wieder in das Zivilrecht zu wechseln - im selben Satz). Aber anstatt hinzunehmen, dass Du irrst (nicht, dass Du auf meine inhaltlichen Aussagen auch nur Bezug genommen hättest), versuchst Du Deine Behauptung zu retten (und sie ist nicht zu retten).

Ich muss das leider mal so deutlich sagen: Du weißt schlicht nicht wovon Du redest (Deine weiteren Aussagen sind in ihrer Absolutheit auch schlicht falsch). Und das Ganze auf einem sehr grundsätzlichem Level. Das ist nicht schlimm, Du teilst dieses Schicksal meiner Erfahrung nach mit sehr vielen Leuten (vermutlich auch die gegensätzliche Selbsteinschätzung), aber auf dieser Basis kann man nicht sinnvoll diskutieren, insbesondere nicht, wenn Du nicht mal auf das eingehst, was ich geschrieben habe (ich kann meinerseits auch nicht beurteilen, ob das mangelndes Verständnis ist, oder etwas anderes) und ich habe mir echt Mühe gegeben (und nicht unerheblich Zeit aufgewendet) um das laiengerecht darzustellen (wobei das mein Versagen sein mag, dass mir das nicht gelungen ist).

gurgelhals

2018-01-04, 01:11:33

https://twitter.com/misc0110/status/948706387491786752

Nakai

2018-01-04, 01:13:40

https://twitter.com/timgostony/status/948682862844248065

https://www.youtube.com/watch?v=bReA1dvGJ6Y

Aua.

Ganon

2018-01-04, 01:15:07

https://twitter.com/misc0110/status/948706387491786752

Cool :D Ich hoffe die Nachrichten-Seiten verbreiten sowas auch mal dann.

gurgelhals

2018-01-04, 01:17:50

Cool :D Ich hoffe die Nachrichten-Seiten verbreiten sowas auch mal dann.

Vorsicht. Ein Script, das ähnlichen Content produziert ist in vier Zeilen Shellcode gebaut. Ich will da Trolle mal nicht ausschließen.

Erst glauben, wenn reproduzierbarer Code vorliegt. Aber meine Intuition sagt mir, dass da was dran ist.

UPDATE: Das Video kommt vom Koautor des Papers. Auweia.

Linmoum

2018-01-04, 01:19:48

Kriton

2018-01-04, 01:21:29

So hätte ich das auch verstanden, aber ich wollte gerade dieselbe Frage stellen.

Nakai

2018-01-04, 01:21:58

Bezüglich Spectre: Trifft grundsätzlich alle Hersteller, aber AMD-CPUs sind nur unter "non-default Configurations" betroffen? Falscher Eindruck oder lese ich das in dem Whitepaper bzw. Blog von Project Zero richtig?

Ryzen wurde nicht getestet. Bulldozer hat das Problem. Beide nutzen eine ähnliche (Neuronale) BranchPrediction. Warum Ryzen nicht aufgelistet ist, kA. Evtl ist bei Ryzen das Problem eingegrenzt. Ich mache keine Aussage darüber.

Ansonsten...da ist die Kacke am Dampfen.;D

Linmoum

2018-01-04, 01:34:13

Stellungnahme von AMD

https://www.amd.com/en/corporate/speculative-execution

Unicous

2018-01-04, 01:39:14

[...]
Ich kritisiere schlicht die Art und Weise wie (hier) mit vorliegenden Informationen umgegangen wird und statt sich auf bisher vorliegenden Fakten zu beziehen einfach irgendwas an den Haaren herbeigezogen wird. Man sieht es ja... die Versteifung auf den Intel TLB Bug lässt den zweiten Part des Problems, nämlich Spectre auch irgendwie gerade untergehen, meinst du nicht? Denn das gesellt sich gerade in die Richtung Rowhammer.

Wie oft soll ich es denn noch sagen. Es gab/gibt (so gut wie keine) vorliegenden Fakten. Das ist alles im Laufe der letzten Tage kleckerweise ans Licht gekommen und du hängst dich an der Berichterstattung auf. Du machst dich wirklich lächerlich gerade. Intel hätte schon vorgestern reagieren können. Sie haben sich aber entsprechend Zeit gelassen um ein nichtssagendes Pamphlet unter der ungewaschenen Masse zu verbreiten, dass ja alles gar nicht stimmt und vor allem: die anderen ja auch!!!

Der "Bug" dürfte im Übrigen schon eine ganze Weile bekannt sein, denn Apple hat ihn schon Mitte Dezember gefixed und sehr wahrscheinlich war auch Intel frühzeitig im Bilde oder sich dessen gar schon bewusst. So wie ich das zwischen den Zeilen lese gab es ein klassisches Embargo und auch dann hat es Intel in der Zwischenzeit nicht geschafft vollumfänglich zu informieren. Es wäre genug Zeit gewesen mit full disclosure an die Presse zu treten. Stattdessen bekommen wir Salamihäppchen gereicht und einen security report mit Datum 03.01.2018.:freak: Sollte dir das nicht etwas zu denken geben. Ich würde dich normalerweise gerne bei deinen Kreuzzug gegen die Medien unterstützen aber selbst ich denke, dass unter den gegebenen Umständen klar sein sollte, dass sie auch nur mit den paar Häppchen arbeiten die sie gereicht bekommen bzw. die sie bei Reddit/Twitter/Foren infosec-community zusammenklauben können. Dass sich einige wenige Medien mal wieder nicht mit Ruhm bekleckern, clickbait ausliefern und damit ihre community ködern sollte doch bitte heutzutage nicht mehr verwundern. Dass sie "falschberichten" weil sie wie so gut wie jeder andere im Trüben fischen (müssen) ist hier ausnahmsweise mal nicht die Schuld der "Medien".

Ungepatchte PCs mit veralteter Software sind unsicher... na so eine Neuigkeit.

Dir ist schon klar, dass du gerade meinen gag "erklärt" hast, oder?:confused:

edit:

AMD, ARM und Intel wissen ("offiziell") seit dem 01.06.2017 Bescheid. Hatte ich irgendwie überlesen. Was soll man dazu noch sagen.

Kriton

2018-01-04, 01:45:53

Ryzen wurde nicht getestet. Bulldozer hat das Problem. Beide nutzen eine ähnliche (Neuronale) BranchPrediction. Warum Ryzen nicht aufgelistet ist, kA. Evtl ist bei Ryzen das Problem eingegrenzt. Ich mache keine Aussage darüber.

Ansonsten...da ist die Kacke am Dampfen.;D

Bei Intel haben sie doch auch nur mit Haswell getestet?

Linmoum

2018-01-04, 01:47:19

Der "Bug" dürfte im Übrigen schon eine ganze Weile bekannt sein, denn Apple hat ihn schon Mitte Dezember gefixed und sehr wahrscheinlich war auch Intel frühzeitig im Bilde oder sich dessen gar schon bewusst. So wie ich das zwischen den Zeilen lese gab es ein klassisches Embargo und auch dann hat es Intel in der Zwischenzeit nicht geschafft vollumfänglich zu informieren. Es wäre genug Zeit gewesen mit full disclosure an die Presse zu treten. Stattdessen bekommen wir Salamihäppchen gereicht und einen security report mit Datum 03.01.2018.:freak:
Bei Google Project Zero wird relativ genau beschrieben, wann man die Hersteller informiert hat:
Variants of this issue are known to affect many modern processors, including certain processors by Intel, AMD and ARM. For a few Intel and AMD CPU models, we have exploits that work against real software. We reported this issue to Intel, AMD and ARM on 2017-06-01 [1].

[1] This initial report did not contain any information about variant 3. We had discussed whether direct reads from kernel memory could work, but thought that it was unlikely. We later tested and reported variant 3 prior to the publication of Anders Fogh's work at https://cyber.wtf/2017/07/28/negative-result-reading-kernel-memory-from-user-mode/ (https://cyber.wtf/2017/07/28/negative-result-reading-kernel-memory-from-user-mode/).
https://googleprojectzero.blogspot.de/2018/01/reading-privileged-memory-with-side.html

Letzteres ist vom 28. Juli 2017. Spätestens da war also auch "Meltdown" bekannt.

Nakai

2018-01-04, 01:52:23

Bei Intel haben sie doch auch nur mit Haswell getestet?

Bezüglich Meltdown ist Skylake auch betroffen.

Unicous

2018-01-04, 02:00:06

@Linmoum

Ja, ich hatte wie gesagt überlesen, dass sie ein Datum genannt haben, aber Intel hätte spätestens seit Ende Juli wissen können/müssen und wahrscheinlich auch gewusst, dass sie von Meltdown explizit betroffen sind.

Genug Zeit um sich "vorzubereiten". Stattdessen gibt es diese half-assed pm, die zudem auch noch maximale Konfusion erzeugt Unwahrheiten und Halbwahrheiten verbreitet und das unter dem Vorwand die Öffentlichkeit wegen der Falschberichterstattung zu informieren. Sie meinten wohl eher desinformieren.

Wie gesagt, das wird mMn noch deutlich interessanter und ist meiner Meinung nach die Spitze des Eisbergs. Die Kommentare der Autoren bzw. des Umfeldes auf Twitter lässt das auch schon erahnen. Ich würde an eurer Stelle in eine Popcorn-Maschine investieren.:up::popcorn:

Nakai

2018-01-04, 02:01:40

https://twitter.com/lavados/status/948716579801493506

Drittauthor

€: Popcorn-Maschine ist angebracht...

berhan

2018-01-04, 02:09:36

Bezüglich Meltdown ist Skylake auch betroffen.

Hab jetzt das Withepaper von Spectre durch.
Im Prinzip sprechen wir von zwei Bugs.

Meltdown welche nur Intel CPUs betrifft. Und auch nur dieser wurde mit KPTI gefixt. Und der Fix hat mehr oder weniger Leistungseinbußen.

Spectre betrifft nicht nur Intel sondern auch ARM, Samsung und AMD. Und so wie ich es verstanden habe kann damit auf den Speicherbereich von anderen Prozessen gelesen werden. Derzeit kein fix verfügbar.

Warum beide Bug gleichzeitig auftauchen liegt vermutlich daran, das Beide von der TU Graz erforscht wurden und KPTI (KAISER) auch dort erstellt wurde.

kruemelmonster

2018-01-04, 02:12:49

Das Windows 10 Update inkl KPTI ist (zumindest für die v1709) online: https://www.catalog.update.microsoft.com/Search.aspx?q=KB4056892

Nakai

2018-01-04, 02:18:57

Hab jetzt das Withepaper von Spectre durch.
Im Prinzip sprechen wir von zwei Bugs.

Meltdown welche nur Intel CPUs betrifft. Und auch nur dieser wurde mit KPTI gefixt. Und der Fix hat mehr oder weniger Leistungseinbußen.

Spectre betrifft nicht nur Intel sondern auch ARM, Samsung und AMD. Und so wie ich es verstanden habe kann damit auf den Speicherbereich von anderen Prozessen gelesen werden. Derzeit kein fix verfügbar.

Warum beide Bug gleichzeitig auftauchen liegt vermutlich daran, das Beide von der TU Graz erforscht wurden und KPTI (KAISER) auch dort erstellt wurde.

Ja, das sind zwei "Probleme".

Meltdown tritt nur bei den Intels auf.

Spectre wohl überall wo eine spekulative Branch Prediction verwendet wird.

Eine spekulative Branch Prediction selektiert bereits einen Codepfad, welcher gar nicht betreten werden darf. Dadurch werden bereits Daten in den Prozessor geladen, welche gar nicht "berührt" werden dürfen.
Jegliche Branches erzeugen ein Pipeline-Stalling, welches eben durch spekulative Branch Prediction asugemerzt werden. Die Daten die dabei schon "vorzeitig" in die Pipeline geladen werden, dürften aber gar nicht angetastet werden.

Das ist ein ziemlich fettes Problem.

€:
Die nächsten Tage/Wochen werden interessant. Das ist imo einer der schlimmsten "Bugs", die jemals identifiziert wurden.