News Intel/ARM/AMD: Sicherheitslücken Meltdown & Spectre V1, V2 etc. (Links in Post 1)

Ich bin schon fast für Verkaufsverbot inkl. kräftiger Entschädigungszahlung bei dieser Verantwortungslosigkeit bei Intel.
Es wird hier nachwievor schöngeredet.
 
Letzter Satz des Artikel von golem.de :
Bei AMD- und AMD-Chips klappt Load Value Injection nicht, bei Intel braucht es Hardware-Anpassungen. Der CPU-Hersteller wusste seit April 2019 davon

Intel war der Fehler Per Load Value Injection seit 11 Monaten bekannt und hat den Forschern ein Embargo verpasst?
Warum dauert das so lange?

In diesem Zusammenhang von Bedeutung ist folgende Seite, welche im golem Artikel verlinkt ist:

LVI - Hijacking Transient Execution with Load Value Injection
 
Autsch. Jetzt ist Hirnschmalz gefragt um andere Wege der Mitigation zu schaffen wo die Leistung nicht so extrem wegbricht.
 
Neues von der LVI Mitigation-Front:
https://www.phoronix.com/scan.php?page=article&item=llvm-intel-lvi&num=2

Mit Optimierungen schafft man es den Worst Case Einbruch je nach Softwarefall auf 30-50% zu beschränken. In vielen Fällen landet man sogar bei 0 bzw. sehr wenig.

Im Mittel, wobei ich finde das dies hier nicht sehr aussagekräftig ist da absolut "fall" abhängig" landet man bei ~9%.

Allerdings eben im Mittel der Fällte von ~0% mit den Fällen ~30-50%.
 
Nochmal mehr Benches von Phoronix zum Impact dieser Compiler-Patchs für LVI:
https://www.phoronix.com/scan.php?page=article&item=intel-cxlr-lvi&num=5

Ca ~20% mittlerer Verlust auf Cascade Lake CPUs. Aber da es Compiler Patches sind, müsste sich dies auch auf ALLE anderen CPUs auswirken, also auch auf AMD, sollte diese Form von "Patch" breit ausgerollt werden. (Intel empfiehlt dies nicht).
Ich persönlich fände eine mehr spezifische Antwort hier auch besser und solange die nicht gefunden ist, wäre ich für ein nicht-allgemeines Ausrollen solcherart Patches. Zuviel Kollateralschaden auf eigentlich sicheren Systemen.
 
Die Mitigation besteht aus LFENCE Instruktionen rund um Intels SGX/TSX Befehle. AMD ist hiervon nicht betroffen, da dies ja keine Verwendung findet auf deren SKUs.
Daher haben auch die Compiler-Änderungen keinen Einfluß auf AMD-SYstemen.
Die bessere Mitigation für LVI aus Performancesicht wäre SGX und TSX abzuschalten. Nur das ist halt nicht in jedem Usecase möglich. Wo Sicherheit wichtig ist bleibt eigentlich nur noch ein Epyc-System, denn man müsste sowieso Hardware nach kaufen um die selben Ressourcen für die Anwender bereit stellen zu können. TSX und SGX konnten sich auch wegen anderen Problemen bisher nicht wirklich breit durchsetzen. Zumal TSX seit Zombieload v2 auch von Intel nur mit abschalten mitigiert werden kann.
https://software.intel.com/security...ation-extensions-intel-tsx-asynchronous-abort
[h=2]CPUs That Do Not Require Additional Mitigations[/h] There are three types of processors that do not require additional mitigations.

  1. CPUs that do not support Intel TSX are not affected[SUP]3[/SUP].
  2. CPUs that enumerate IA32_ARCH_CAPABILITIES[TAA_NO] (bit 8)=1 are not affected.
  3. CPUs that support Intel TSX and do not enumerate IA32_ARCH_CAPABILITIES[MDS_NO] (bit 5)=1 do not need additional mitigations beyond what is already required to mitigate MDS.

[h=2]Footnotes
[/h]
  1. Intel TSX support is indicated by CPUID.07h.EBX.RTM (bit 11) set to 1 and CPUID.07h.EBX.HLE (bit 4) set to 1.
  2. CPUID.7.EDX[IA32_ARCH_CAPABILITIES supported]=0 or IA32_ARCH_CAPABILITIES[TAA_NO]=0.
  3. No Intel TSX support is indicated by CPUID.07h.EBX.RTM (bit 11) set to 0 and CPUID.07h.EBX.HLE (bit 4) set to 0.
 
Hmm, hab ich anders verstanden bzw. aus der Diskussion im Phoronix Forum mitgenommen.

Ich hatte das so verstanden, dass eben sehr viele zusätzliche LFENCE eingefügt werden, aber eben nicht nur rund um die TSX Sachen.
Schreibt auch Michael so:
https://www.phoronix.com/forums/for...intel-lvi-vulnerability?p=1169738#post1169738
" Originally posted by Raka555:I suppose if programs are compiled with these mitigations, they will run slow on all processors, regardless if they are known to be vulnerable or not ?
Antwort:
"Right there is no per-CPU ID handling. "
 
Das eine hat mit dem anderen ja nicht zwingend etwas zu tun. Es gibt kein CPU ID handling. Doch wenn eine CPU z.B kein TSX kann, dann ist sie von diesen Befehlen auch nicht betroffen. Der Compiler setzt die lfences in der Software, doch die CPU wird diesen Code ja nie abrufen, inkl. der zugehörigen Lfences. Solche Unterschiede bestehen ja auch über CPU-Generationen hinweg bei Intels eigenen CPUs. Wer kein AVX kann, nutzt ja z.B. SSE Code. Was machen denn AMD CPUs heute mit TSX und SGX Befehlen ohne diese Lfences? Sie führen den Code nicht aus. Warum sollten Sie dann die zugehörigen Lfences ausführen, welche der Compiler nun zufügt? CPU-ID handling ist hier schlicht nicht notwendig.
Die Lfences werden ja z.B. auch auf Intels CPUs nicht bei SSE Befehlen genutzt.

Wie kann ein Code der auf einer CPU nicht ausgeführt wird dann langsamer laufen?

Offiziell von Intel:
https://software.intel.com/security...ep-dive-load-value-injection#nonsgxmitigation
[h=2]LVI Mitigation for Non-SGX Environments[/h] Because malicious adversaries have limited ability to influence the paging behavior of victim processes to cause faults or assists in non-SGX environments, LVI is not a practical exploit in real-world non-SGX environments. Developers can mitigate potentially vulnerable code by inserting additional LFENCE instructions to block speculative activity or techniques like array index masking to prevent leaking data via covert channels. But because of the complexity of lining up all these conditions to successfully execute this method in a non-contrived scenario, software developers should carefully evaluate their environments and workloads before choosing to mitigate this.

[h=2]Enumeration[/h] An OS or VMM can discover their potential susceptibility to LVI stale data by determining whether the processor is affected by L1TF, MDS, TAA. In particular, processors with the combination of the three following properties are not affected by LVI stale data:


  • Enumerates RDCL_NO (AMD kein Meltdown)
  • Enumerates MDS_NO (AMD kein MDS)
  • Either enumerates TAA_NO, or does not support Intel TSX, or has disabled TSX/RTM using IA32_TSX_CTRL (AMD kein TSX)
On processors that are affected by TAA but not by MDS, software that does not use loads within an Intel TSX region cannot be impacted by LVI stale data.

Intel SGX usage may need an alternative mechanism to detect whether the CPU is affected by LVI, as it does not trust the OS. Through Intel SGX remote attestation, a relying party can examine the remote attestation evaluation status code and tell whether the remote attestation request is from a platform affected by LVI (LVI stale data and/or LVI zero data). Refer to the Relying Parties section for details.
 
Ah - Danke für die Erläuterung. Das war mir in der Tat so nicht klar !

Dann ist es ja wirklich doch "Intel" spezifisch und kostet AMD rechner keine Leistung.
 
Gerne :)
Hier zur Vervollständigung noch das Enumerator-Prinzip in Code:
https://de.wikipedia.org/wiki/Iterator#C#_und_andere_.NET-Sprachen
Iteratoren im .NET-Framework werden als Enumeratoren bezeichnet und von der Schnittstelle IEnumerator repräsentiert. IEnumerator stellt eine Funktion namens MoveNext() zur Verfügung, die jeweils zum nächsten Element der Menge geht und anzeigt, wenn das Ende erreicht ist, sowie eine Eigenschaft namens Current, um den Wert des aktuellen Elementes zu erhalten. Des Weiteren wird eine optionale Reset()-Funktion angeboten, um an den Anfang zurückzukehren. Der Enumerator gibt als Initialisierungswert einen speziellen Wert zurück, der den Anfang markiert. Aus diesem Grund ist es nötig, nach der Initialisierung MoveNext() auszuführen. Enumeratoren werden typischerweise von einer GetEnumerator() Funktion zurückgegeben, welche einem Objekt zugehörig ist, das die IEnumerable-Schnittstelle implementiert. Der foreach-Befehl in C# operiert allerdings auf jeder solchen Funktion, selbst wenn diese nicht von einem Objekt stammt, welches die IEnumerable-Schnittstelle implementiert. Das folgende Beispiel zeigt eine simple Verwendung von Iteratoren in C# 2.0:

Code:
// explizite Version
IEnumerator<MyType> iter = list.GetEnumerator();
while (iter.MoveNext())
    Console.WriteLine(iter.Current);

// implizite Version
foreach (MyType item in list)
    Console.WriteLine(item);
C# 2.0 unterstützt ebenfalls Generatoren: Eine Funktion, welche als IEnumerable (oder auch IEnumerator) zurückkehrt, aber den Befehl yield return dabei benutzt, wird vom Compiler automatisch in eine neue Klasse umgewandelt, welche die angemessene Schnittstelle implementiert.
 
Zuletzt bearbeitet:
Dass der Fix in neue Chipsätze integriert wird, heißt, dass die CPUs unverändert weiter produziert werden können.
Die CPU-only Lösung ist damit gescheitert. Was macht man dann zum Beispiel mit Systemen, in denen der SoC alles regeln muss?
 
Es gibt wieder einen neuen Test zum Mitigation impact von Phoronix:
https://www.phoronix.com/scan.php?page=article&item=ubuntu2004-server-mit&num=7
"When taking the geometric mean of the 42 benchmarks ran for this server-focused comparison, the Xeon E5 Haswell and Xeon E3 Kabylake servers each saw a 12% hit to its performance in the range of tested server-minded mostly real-world workloads, the Xeon Scalable Skylake server saw a 11~12% hit as well, and the Xeon Scalable Cascade Lake Refresh with its hardware mitigations saw a 5% hit to the performance still from the out-of-the-box mitigations. The AMD EPYC Rome server with its hardware mitigations saw a 5% impact as well from this "mitigations=off" comparison focused on Ubuntu 20.04 Server."

Cascade Lake scheint hier tatsächlich irgendwas "intern" besser zu lösen und verliert nur wenig Leistung im Mittel.
Seltsam finde ich, daß die EPYCs hier genausoviel einbüßen wie Cascade Lake - ob die Einstellungen die CPUs zu diskriminieren hier alle korrekt funktionieren ?

Ebenfalls bemerkenswert, Haswell steht insgesamt nicht schlechter da als Skylake und die anderen neueren CPUs. Obwohl man ja teilweise gedacht hat es würde die älteren Archs noch viel schlimmer treffen...oder sind hier evtl. doch nicht ALLE Mitigations genauso aktiv wie bei Skylake ? Ich blick bei den vielen Variablen in den Testsetups mittlerweile nicht mehr 100% durch :-).
 
So wie ich das gelesen habe schaltet "mitigation=off" alle Mitigationen ab, nicht nur die spezifischen für die neuen Lücken.

Edit:
In den Kommentaren stellt Michael klar:
These are the default mitigations for where AMD is relevant/exposed (or where they otherwise apply a default on AMD CPUs). It was at defaults vs. all off, with not turning any extra "on".
 
Ich kann nur hoffen diese Lücke wird in USB 4.0 per default geschlossen. Der DMA Zugriff sollte extern grundsätzlich nicht möglich sein. Das hat schon Firewire das Genick gebrochen. laut Intel lässt es sich mitigieren.
Windows: https://docs.microsoft.com/en-us/wi...tection/kernel-dma-protection-for-thunderbolt
Non-Windows: https://thunderbolttechnology.net/security/Thunderbolt 3 and Security.pdf

Nur sind Geräte leider erst ab 2019 damit kompatibel - nennt sich Thunderclap: https://software.intel.com/security-software-guidance/insights/more-information-thunderclap
 
Ich frage mich ob Spectre/Meltdown und Co ausgenutzt wurden um diese Attacken zu fahren:
https://www.spiegel.de/netzwelt/web...roffen-a-7d9403b9-c7ea-4f84-a9d7-17bbdff3a954

Im Fall von NEMO haben die Angreifer sich über einen gekaperten Nutzerzugang Zugriff verschafft und auf noch unbekanntem Wege ihre Nutzungsrechte auf dem System ausgeweitet, bis sie "Root-Privilegien" hatten und damit nach Belieben schalten und walten konnten. Dann begannen sie damit, weitere Zugangsdaten anderer Nutzer über die ausgehenden SSH-Verbindungen abzufangen.

Man hat also zufällig einen Schlüssel bekommen (z.B. in dem man sich als user registriert hat) und hat dann vermittels eingeschleustem Code Spectre genutzt um andere Schlüssel und passwörter zu erhalten bis hin zum root passwort...?

Denkbar ? Möglich ? Oder eher was anderes ?
 
Zurück
Oben Unten