Downfall-Angriff

 (downfall.page)
1 Punkte von GN⁺ 2023-08-09 | 1 Kommentare | Auf WhatsApp teilen
  • Eine Schwachstelle CVE-2022-40982 in Intel-Prozessoren, die weit verbreitet in privaten und Cloud-Computern eingesetzt werden, ermöglicht es, Daten anderer Nutzer zu stehlen, die denselben Computer gemeinsam nutzen
  • Der Kern der Schwachstelle besteht darin, dass der Gather-Befehl während der spekulativen Ausführung Inhalte der internen Vektorregisterdatei im Zuge einer Speicheroptimierung offenlegt
  • Der Angriff wird mit den Techniken GDS und GVI umgesetzt; die Demo zeigt dabei Leaks über Isolationsgrenzen hinweg, darunter AES-Schlüssel, Linux-Kernel-Daten und das Überwachen druckbarer Zeichen
  • Betroffen sind Intel Core-Prozessoren von der 6. Generation Skylake bis zur 11. Generation Tiger Lake; auch Cloud-Nutzer können betroffen sein, ohne selbst ein Intel-Gerät zu besitzen
  • Das Microcode-Update von Intel blockiert die transienten Ergebnisse von Gather, aber einige Workloads können nach der Aktivierung der Gegenmaßnahme einen Overhead von bis zu 50 % haben

Die von Downfall angegriffene Schwachstelle

  • Downfall zielt auf eine kritische Schwäche aktueller Prozessoren ab, die in Personal Computern und Cloud-Computern eingesetzt werden
  • Diese Schwachstelle wird durch CVE-2022-40982 identifiziert
  • Dadurch kann auf Daten anderer Nutzer zugegriffen und diese gestohlen werden, wenn sie denselben Computer gemeinsam nutzen
    • Eine bösartige App aus dem App Store könnte sensible Informationen wie Passwörter, Verschlüsselungsschlüssel, Bankdaten, private E-Mails und Nachrichten stehlen
    • In der Cloud könnte ein bösartiger Kunde die Daten und Zugangsdaten anderer Kunden stehlen, die sich denselben Cloud-Computer teilen

Technische Ursache der Schwachstelle

  • Die Speicheroptimierungsfunktion von Intel-Prozessoren legt interne Hardware-Register unbeabsichtigt gegenüber Software offen
  • Nicht vertrauenswürdige Software kann auf Daten anderer Programme zugreifen, auf die sie eigentlich keinen Zugriff haben sollte
  • Der Gather-Befehl, der verstreute Daten im Speicher schneller lesen soll, leakt während der spekulativen Ausführung Inhalte der internen Vektorregisterdatei
  • Zur Ausnutzung werden Gather Data Sampling (GDS) und Gather Value Injection (GVI) verwendet
  • Technische Details sind im Downfall-Paper zusammengefasst

In Demos bestätigte Leak-Fälle

  • Die Downfall-Demo zeigt, dass sensible Daten über verschiedene Isolationsgrenzen hinweg abfließen können
    • Video 7: Diebstahl von 128-bit- und 256-bit-AES-Schlüsseln anderer Nutzer
    • Video 8: Diebstahl beliebiger Daten aus dem Linux Kernel
    • Video 9: Überwachung druckbarer Zeichen

Betroffene Systeme und Angriffsbedingungen

  • Betroffen sind Computing-Geräte auf Basis von Intel Core-Prozessoren von der 6. Generation Skylake bis zur 11. Generation Tiger Lake
  • Eine umfassendere Liste betroffener Prozessoren soll in Intels Liste betroffener Prozessoren bereitgestellt werden
  • Auch ohne ein physisches Intel-basiertes Gerät können Cloud-Nutzer betroffen sein
    • Intel hat einen Marktanteil von über 70 % im Servermarkt
  • Angreifer können es auf hochwertige Zugangsdaten wie Passwörter und Verschlüsselungsschlüssel absehen
  • Der Diebstahl von Zugangsdaten kann über eine Verletzung der Vertraulichkeit hinaus zu weiteren Angriffen führen, die Verfügbarkeit und Integrität von Systemen beeinträchtigen
  • GDS ist vergleichsweise leicht in reale Angriffe umzusetzen
    • Die Entwicklung eines End-to-End-Angriffs zum Diebstahl von Verschlüsselungsschlüsseln aus OpenSSL dauerte zwei Wochen
    • Angreifer und Opfer müssen sich lediglich denselben physischen Prozessorkern teilen
    • In modernen Computern mit präemptivem Multitasking und simultanem Multithreading kommt eine solche gemeinsame Nutzung häufig vor

Isolationsgrenzen, SGX und Browser-Auswirkungen

  • Downfall betrifft auch gängige Isolationsgrenzen
    • Virtuelle Maschinen
    • Prozesse
    • User-Kernel-Isolation
  • Intel SGX ist ebenfalls betroffen
    • Intel SGX ist eine Hardware-Sicherheitsfunktion in Intel-CPUs zum Schutz von Nutzerdaten vor bösartiger Software
  • Eine Remote-Ausnutzung über Webbrowser ist theoretisch möglich
    • Um in der Praxis einen erfolgreichen Angriff im Browser zu demonstrieren, sind jedoch zusätzliche Forschung und Engineering-Arbeit nötig

Expositionsdauer und Schwierigkeit der Erkennung

  • Nutzer waren dieser Schwachstelle mindestens 9 Jahre lang ausgesetzt
    • Die betroffenen Prozessoren existieren seit 2014
  • Downfall-Angriffe sind schwer zu erkennen
    • Ihr Ausführungsverhalten ähnelt größtenteils normalen Anwendungen
    • Theoretisch ließe sich ein System bauen, das mit Hardware-Performance-Countern ungewöhnliches Verhalten wie übermäßige Cache-Misses erkennt
    • Übliche kommerzielle Antivirensoftware kann diesen Angriff nicht erkennen

Gegenmaßnahmen und Performance-Overhead

  • Intel hat ein Microcode-Update veröffentlicht
    • Dieses Update blockiert die transienten Ergebnisse des Gather-Befehls
    • Es verhindert, dass Angreifercode die aus Gather stammenden spekulativen Daten beobachten kann
  • Der Overhead der Gegenmaßnahme hängt davon ab, ob Gather im kritischen Ausführungspfad eines Programms vorkommt
  • Laut Intel können einige Workloads einen Overhead von bis zu 50 % erfahren
  • Es ist nicht sicher, die Gegenmaßnahme zu deaktivieren, nur weil ein Workload Gather nicht direkt verwendet
    • Moderne CPUs nutzen Vektorregister zur Optimierung allgemeiner Aufgaben wie Speicherkopien und Registerinhaltswechsel
    • In diesem Prozess können Daten durch nicht vertrauenswürdigen Code abfließen, der Gather missbraucht

Offenlegungszeitplan und Reproduktionscode

  • Für diese Schwachstelle galt fast ein Jahr lang ein Embargo
  • Sie wurde Intel am 24. August 2022 gemeldet
  • Downfall wurde am 9. August 2023 auf der BlackHat USA und am 11. August 2023 beim USENIX Security Symposium vorgestellt
  • Reproduktionscode ist im GitHub POC veröffentlicht

Worauf andere Prozessorentwickler achten sollten

  • Auch andere Prozessoren besitzen gemeinsam genutzte SRAM-Speicher wie Hardware-Registerdateien und Fill Buffers innerhalb des Kerns
  • Hersteller sollten gemeinsam genutzte Speichereinheiten sorgfältiger entwerfen, damit keine Daten zwischen unterschiedlichen Sicherheitsdomänen abfließen
  • Es sollte mehr in Sicherheitsverifikation und Tests investiert werden

Name und verwandte Schwachstellen

  • Der Name Downfall bezieht sich darauf, dass die grundlegenden Sicherheitsgrenzen der meisten Computer zum Einsturz gebracht werden
  • Downfall kann als Nachfolger früherer CPU-Datenleck-Schwachstellen wie Meltdown und Fallout gesehen werden
  • In diesem Verlauf umgeht Downfall frühere Gegenmaßnahmen erneut

Empfehlungen der Anbieter und technische Dokumentation

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2023-08-09
Meinungen auf Hacker News

  • Es fühlt sich merkwürdig an, dass externe Forschende auch nach den ersten Spectre-Angriffen weiterhin ähnliche Angriffe finden und die Chip-Hersteller sie erst später patchen.
    Im Prinzip müssten die Chip-Hersteller die besten Voraussetzungen haben: Sie sind Experten für spekulative Ausführung, kennen das Verhalten ihrer Chips genau und verfügen über Verifikations-Suites, Simulatoren und sogar maschinenlesbare interne Spezifikationen.
    Externe Forschende müssen dagegen eine Blackbox untersuchen und mit deutlich schlechteren Quellen wie Patenten Reverse Engineering betreiben; trotzdem finden Einzelpersonen oder externe Gruppen selbst Jahre später noch solche Schwachstellen.
    Vor Spectre mag man solche Angriffsvektoren nicht bedacht haben, aber nachdem der allgemeine Mechanismus bekannt war, hätten die Chip-Hersteller doch ihre klügsten Leute zusammentrommeln und sagen müssen: „Durchkämmt alles und findet weitere Spectre-artige Angriffe.“
    Vielleicht wissen sie das alles schon, begraben es aber in der Hoffnung, dass es nicht öffentlich wird, um Gesichtsverlust und Performance-Einbußen zu vermeiden.

    • Es könnte Survivorship Bias sein. Wir wissen nicht, wie viele Spectre-artige Bugs gepatcht wurden, ohne je öffentlich zu werden.
    • Diese Argumentation fühlt sich unangenehm an. Mit derselben Denkweise könnte man auch einem Programmierer, der zweimal einen Fehler bei der Speichersicherheit gemacht hat, nicht einfach menschliches Versagen, sondern böse Absicht unterstellen.
      Wenn etwas von Milliarden Menschen genutzt wird, werden diese vermutlich mehr Probleme, Defekte und Exploits finden als die Hersteller selbst. Allein die Existenz solcher Probleme stützt oder widerlegt keine weitergehenden Schlüsse über die Gründe dafür.
    • Eine Möglichkeit, die noch niemand genannt hat: Chip-Anbieter investieren vielleicht deshalb nicht viel Zeit in die Suche danach, weil es in der Praxis gar nicht so wichtig ist.
      Sicherheitsforschende haben einen Anreiz, etwas zu finden, um sich einen Ruf aufzubauen. Häufig stellen sie Dinge als weltbewegende Sicherheitslücken dar, obwohl sie für reale Angreifer kaum Bedeutung haben.
      Wurden Angriffe über spekulative Ausführung jemals in realen Umgebungen gefunden? Vielleicht nicht. Dann gibt es für Chip-Anbieter wenig Grund, enorme Summen dafür auszugeben.
      Reale Kunden nehmen keinen Schaden, außer wenn externe Forschende Maßnahmen erzwingen und dadurch neuer Microcode veröffentlicht wird, der die Performance senkt.
      Auffällig ist auch, dass die Gegenmaßnahmen für solche Angriffe immer mit einem Abschalter versehen sind. Das ist bei Sicherheitsfixes nicht die übliche Form, liegt aber oft daran, dass diese Angriffe nicht besonders wichtig sind.
      Software, die auf demselben physischen Core oder derselben physischen CPU läuft, hat entweder dasselbe Vertrauensniveau oder ist so stark sandboxed, dass sie den Angriff nicht ausführen kann.
    • Vielleicht ist es ein Fall von Kernighans Debugging-Gesetz: „Jeder weiß, dass Debugging doppelt so schwer ist wie das ursprüngliche Schreiben eines Programms. Wenn man also beim Schreiben so clever wie möglich war, wie soll man es dann jemals debuggen?“
      Intel baut seine Chips zweifellos „so clever wie möglich“, und damit sind sie per Definition nicht vollständig debugbar.
    • Aus Sicht eines CPU-Ingenieurs: Spectre hat einen Informationsabflusskanal offengelegt, den man zuvor nicht als verwundbar betrachtet hatte. Deshalb folgten neue Exploits, in deren Zentrum eine neue Idee stand, auf der andere weiter aufgebaut haben.
      Wichtig ist auch: Das sind keine Bugs. Das Design funktioniert wie beabsichtigt. Man verstand, dass die Performance einer CPU davon abhängt, welcher Code zuvor ausgeführt wurde, und akzeptierte das, weil die Kosten der Alternativen bei Energieverbrauch, Performance und Fläche als zu hoch galten. Das ist Engineering: Alternativen abwägen und auswählen.
      In diesem Fall wurden CPUs schnell genug, dass ein kleiner Bruchteil eines Bits pro Iteration zu angreifbarer Bandbreite wurde; aber die Branche musste es erst von jemandem demonstriert bekommen, um es zu verstehen. Das hat die Engineering-Abwägung verändert.

  • Der Intel-Paper-Link ist tot; der korrekte Link scheint dieser zu sein: https://www.intel.com/content/www/us/en/developer/articles/t...
    Als allgemeiner Hinweis: Gibt es wirklich noch viele Clouds, die Workloads verschiedener Nutzer auf demselben physischen Core ausführen? Ich dachte, die meisten hätten vor einigen Jahren ihre Scheduler geändert, um Cross-Domain-Leaks zwischen Hyperthreads zu verhindern
    Die Behauptung, das betreffe alle Nutzer des Internets, wirkt wie eine starke Übertreibung. Ich habe auch keinen browserbasierten Exploit gesehen, und selbst wenn es einen gäbe, würde er wohl nur eine winzige Zahl gezielt angegriffener Nutzer betreffen. Seit Spectre sind viele Jahre vergangen; ich frage mich, ob in der Praxis je Angriffe über spekulative Ausführung entdeckt wurden
    Interessanter ist, dass sich solche Bugs in der spekulativen Ausführung offenbar weiterhin per Microcode patchen lassen. Als sie erstmals auftauchten, gab es die Sorge, man müsse physische Chips in großem Umfang entsorgen und ersetzen; aber war das jemals tatsächlich nötig?
    Soweit ich weiß, ließen sich alle Bugs mit einer Kombination aus Software- und Microcode-Änderungen entschärfen, teils mit gewissen Performance-Kosten. Keiner der Bugs erforderte neues Silizium. Eine Ausnahme wären Fälle wie frühe AMD-SEV-Versionen, die tatsächlich nicht patchbar ausgebrochen werden konnten

    • Abseits der großen Clouds wie AWS/GCP/Azure gibt es enorm viele VPS-Anbieter, und dort lautet die Antwort: „Ja“. Selbst Anbieter, die „dedizierte“ Cores verkaufen, meinen damit oft eigentlich nur unbegrenzte CPU-Nutzung
    • Spectre-Angriffe mussten im Kernel gepatcht werden und haben Intel-CPUs deutlich ausgebremst: https://www.notebookcheck.net/Spectre-v2-mitigation-wreaks-h...
    • Sind nicht gerade die t-Instanzen von AWS für genau so etwas gedacht? Ich hatte verstanden, dass sie auf Core-Ebene „geteilt“ werden; andernfalls gäbe es keinen Grund für Konzepte wie ein CPU-Credit-Guthaben
    • Ich denke, die meisten, vielleicht fast alle Cloud-VMs bekommen dedizierte Cores
      Natürlich gibt es auch geteilte Varianten wie die T-Serie von AWS, und andere Clouds dürften Ähnliches haben, aber ich nehme an, dass man zusätzliche „Flushes“ zwischen Nutzern einbauen kann, um Leaks zwischen Tenants zu verhindern
      Natürlich sind Leaks zwischen Prozessen innerhalb eines einzelnen Tenants ein Problem, ob in der Cloud oder on-premises; letztlich muss man entscheiden, wie sehr man darauf vertraut, dass Prozesse auf der eigenen Maschine nicht bösartig werden
    • Dass es potenziell „alle im Internet“ betrifft, wurde gesagt, weil die meisten Server verwundbar sind

  • Code aus unterschiedlichen Sicherheitsdomänen auf demselben physischen Prozessorkern auszuführen, scheint nicht zuverlässig machbar zu sein, und wir sollten damit wohl aufhören
    Die üblichen Fälle sind im Grunde nur zwei: VMs und JavaScript
    VMs müssen aufgegeben werden. Bestimmte Cores müssen bestimmten VMs oder zumindest bestimmten Kunden dediziert zugewiesen werden
    JavaScript ist etwas schwieriger
    In keinem Fall sollte man im Normalfall Performance opfern

    • Bei JavaScript klingt „lasst es einfach sein“ vernünftig
    • Darin steckt eine Marketingchance, Multicore wieder in den Vordergrund zu rücken. Die meisten Workloads haben beim Hinzufügen weiterer CPU-Cores inzwischen den Punkt abnehmender Erträge erreicht, aber wenn die Schlussfolgerung lautet, dass man mehr Cores braucht, um mehr gleichzeitige Prozesse oder Browser-Tabs sicher auszuführen, könnten 128-Core-Laptop-Chips auftauchen
    • Ich frage mich schon seit einiger Zeit, ob es sinnvoll wäre, die CPU in eine „IOPU“ und eine „SPU“ aufzuteilen
      Die IOPU würde die übrige Hardware des Systems koordinieren und müsste nicht besonders leistungsfähig sein
      Die SPU wäre auf schnell laufenden skalaren Code und verzweigungsreichen Code optimiert
      Die SPU bräuchte nur minimale Sicherheit, etwa um beim Laden aus dem RAM kein beliebiges Memory lesen zu können. Da immer nur ein Programm gleichzeitig läuft, wäre spekulative Ausführung kein Problem
      Auf meinem System gibt es nur wenige Programme, die viel Rechenleistung brauchen, und selbst dann nur sporadisch, sodass es auf der SPU wohl nicht viele Task-Wechsel gäbe
    • Genau. Dieses Modell hat seine Blütezeit hinter sich. Die Ära der Timesharing-Systeme von den 1960ern bis in die 1990er, als auf Unix-Systemen von Universitäten oder ISPs mehrere Nutzer Shell-Accounts hatten
      Solche CPU-Angriffe zeigen, dass sichere Timesharing-Systeme, bei denen Nutzer beliebigen Maschinencode ausführen, nicht mehr realistisch sind
      Timesharing wird dort weiter bestehen, wo man einander vertraut, etwa wenn Mitarbeitende desselben Projekts eine Build-Maschine teilen
    • Es ist ein bisschen wie mit dem zweiten Hauptsatz der Thermodynamik, bevor die statistische Mechanik kam und ihn erklärte. Er mag analytisch und philosophisch nicht fest gegründet gewesen sein, aber experimentell war er so robust, dass jeder, der das Gegenteil verkaufen wollte, äußerst verdächtig wirkte
      Die Vorstellung, man könne verhindern, dass zwei auf einem Computer ausgeführte Programme einander ausspähen, ist auf einem ähnlichen Niveau

  • Intel-Sicherheitshinweis: https://www.intel.com/content/www/us/en/developer/articles/t...
    Linux-Kernel-Merge: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...

  • Dass nur bis zur 11. Generation betroffen ist, lässt mich zweifeln, dass Intel zum Zeitpunkt der Offenlegung dieser Schwachstelle noch früh genug dran war, um sie in der 12. Generation gezielt zu beheben. Vielleicht wurde sie also zufällig mitbehoben, als etwas anderes geändert wurde.
    Im Paper steht: „Intel hat erklärt, dass neuere CPUs wie Alder Lake, Raptor Lake und Sapphire Rapids nicht betroffen sind. Das scheint allerdings eher ein Nebeneffekt der deutlich veränderten Architektur zu sein als eine Sicherheitsmaßnahme.“
    Am Ende wurde es also zufällig behoben, oder zumindest funktioniert dieser konkrete Exploit nicht mehr.

    • Mikroarchitektur-Verhalten ändert sich von Generation zu Generation, und damit ändern sich auch die Nebenwirkungen. Dass man zufällig ein Problem behebt oder zufällig ein neues schafft, passiert relativ häufig.

  • Laut FAQ waren Nutzer mindestens 9 Jahre lang dieser Schwachstelle ausgesetzt, weil betroffene Prozessoren seit 2014 existierten.
    Erstaunlich ist, dass so eine Schwachstelle jahrelang unbemerkt bleiben kann, es dann aber nur zwei Wochen dauert, bis jemand einen Exploit codet.

    • Die Zeit zum Finden der Schwachstelle war vermutlich von Anfang an deutlich länger als zwei Wochen.
    • Dass sie veröffentlicht wurde, bedeutet nur, dass ein White-Hat- oder Grey-Hat-Forscher die Schwachstelle entdeckt hat. Ob und wie oft in der Zwischenzeit weniger gewissenhafte Akteure denselben Fehler ausgenutzt haben, lässt sich nicht wissen.
    • Sehr wahrscheinlich basiert die Arbeit auf früheren Exploits.

  • Siehe auch den LWN-Artikel: https://lwn.net/Articles/940783/
    Unter Linux wird als Gegenmaßnahme für dieses Problem auf CPUs ohne aktualisierten Microcode AVX vollständig deaktiviert. Nach meinem Maßstab ist das ziemlich drastisch und dürfte deutlich spürbar sein. Jetzt möchte ich herausfinden, ob ich aktualisierten Microcode bekommen kann.

    • Die Deaktivierung von AVX gilt nur, wenn gather_data_sampling=force verwendet wird. Standardmäßig bleibt AVX aktiv, und das System wird als verwundbar markiert.
      Aus https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin... geht hervor:
      Wenn gather_data_sampling=force angegeben wird, wird, sofern möglich, die Microcode-Gegenmaßnahme verwendet; auf betroffenen Systemen, deren Microcode nicht so aktualisiert wurde, dass diese Gegenmaßnahme enthalten ist, wird AVX deaktiviert.
      Zur Einordnung: Ich arbeite bei Intel an Linux. Es ist gut möglich, dass ich die Dokumentation und Changelogs, die Leute verwirren, geschrieben oder überarbeitet habe.
    • [ 0.000000] microcode: updated early: 0x27 -> 0x28, date = 2019-11-12
      Ich nutze Haswell. Gibt es eine Liste, welche CPUs aktualisierten Microcode erhalten? Schade.
    • Möglicherweise ist es nicht der Standardwert. Nur anhand des Textes ist das nicht ganz eindeutig.

  • Erwähnenswert ist auch, dass GCP dieses Problem gepatcht hat: https://cloud.google.com/support/bulletins#gcp-2023-024

    • Angrenzende Teams in London, die als Google-Cloud-(GCE-)SREs arbeiten, haben die Patches rechtzeitig ausgerollt und heute die Donuts bekommen, die sie definitiv verdient haben.
    • Die entsprechende AWS-Mitteilung: https://aws.amazon.com/security/security-bulletins/AWS-2023-...
      Daten und Instanzen von AWS-Kunden sind von diesem Problem nicht betroffen, und Kunden müssen nichts unternehmen.
      AWS hat eine Infrastruktur entworfen und implementiert, die Schutz vor dieser Problemklasse bietet. Amazon-EC2-Instanzen, einschließlich Lambda, Fargate und anderer von AWS verwalteter Compute- und Container-Services, schützen Kundendaten durch Microcode- und softwarebasierte Gegenmaßnahmen vor GDS.

  • Der Performance-Einbruch ist enorm. Es werden bis zu 50 % behauptet, und 70 % der aktuellen Intel-Prozessoren sollen betroffen sein.

    • „In den internen Performance-Tests von Red Hat zeigten die schlimmsten Microbenchmarks eine starke Verlangsamung. Realistischere Anwendungen, die Vector Gather nutzen, zeigten jedoch nur Verlangsamungen im niedrigen einstelligen Prozentbereich.“
      https://access.redhat.com/solutions/7027704
      Die Performance-Auswirkungen beschränken sich auf Anwendungen, die die von Intel Advanced Vector Extensions (AVX2 und AVX-512) bereitgestellten Gather-Instruktionen sowie die CLWB-Instruktion verwenden. Die tatsächliche Performance-Auswirkung hängt davon ab, wie stark eine Anwendung diese Instruktionen nutzt.
      Wenn Nutzer nach einer gründlichen Risikoanalyse entscheiden, die Gegenmaßnahmen abzuschalten, etwa weil das System nicht mandantenfähig ist und keinen nicht vertrauenswürdigen Code ausführt, können sie die Gegenmaßnahmen deaktivieren.
      Nach dem Einspielen der Microcode- und Kernel-Updates kann man die Gegenmaßnahme abschalten, indem man gather_data_samping=off zur Kernel-Kommandozeile hinzufügt. Alternativ kann man mit mitigations=off alle Gegenmaßnahmen gegen spekulative CPU-Ausführung, einschließlich GDS, deaktivieren.
    • Bezieht sich dieser Overhead von 50 % auf die „Gather“-Instruktion? Wenn ja, dann ergibt sich bei einem Workload, in dem 10 % der Instruktionen Gather sind, insgesamt ein Overhead von 5 %.
    • Die Formulierung lautet: „Einige Workloads können bis zu 50 % Overhead erfahren.“ Wenn dort einige Workloads steht, dürfte der Performance-Einbruch selten sein.
    • Der fehlende zentrale Kontext ist: „Es hängt davon ab, ob Gather im kritischen Ausführungspfad des Programms liegt.“
    • Das ist ähnlich, wie wenn man „bis zu 70 % Rabatt“ sieht und denkt, es sei ein riesiger Sale. Manchmal gibt es im ganzen Laden nur etwa zwei Artikel mit 70 % Rabatt.
      „Bis zu“-Behauptungen sollte man immer mit Skepsis betrachten.

  • Im NES steckte ein Chipsatz, in dem ein kompletter 6502 begraben war, und für den Preis einer Pizza kann man einen Rockchip-ARM-Chip kaufen, der gemischte Kerne auf dem Die hat. Vielleicht müssen Chip-Hersteller nicht jeden Edge Case für immer lösen, und könnten diese Abmilderung von Seitenkanalangriffen an uns zurückgeben, die wir die Chips verschlingen.
    Statt SMT zu einer Alles-an-oder-alles-aus-Entscheidung zu machen: Wie wäre es, nicht vertrauenswürdigen Code auf die „schlechten Kerne“ zu schicken und Kunden „beweisen“ zu lassen, dass er auf Kerne mit SMT hochgestuft werden darf?
    Niemand will einen Chip kaputtmachen, auf dem extrem kritische Payroll-Jobs laufen, bei denen niemand etwas anderes aufs Board setzen kann. Aber dazu gezwungen zu werden, Dinge zu taggen, die sicher unter SMT laufen dürfen, und andernfalls an sicherere Kerne gebunden zu werden, wäre in Ordnung.
    Ein Praktikant, der überhaupt keine Ahnung hat, was das ist, könnte bei der Suche lernen, worum es bei diesem Angriffsvektor wirklich geht, und einen Abwehrplan ausarbeiten.
    Bin ich der Komische?

    • Ich sehe das als Marktproblem.
      Performance-Kerne × Effizienz-Kerne sind möglich.
      Aber niemand wird derjenige sein wollen, der vertrauenswürdige Kerne × „schlechte“ nicht vertrauenswürdige Kerne vorschlägt. Egal wie viele Vorteile es hat, es wird im Diskurs von „das schürt Verunsicherung“ untergehen. So ist das Leben.