News Spectre lebt: Seitenkanalangriffe auf AMD Ryzen und Intel Core möglich

[mae]

Ich habe auch nicht gesagt das ARM gegen side channel immun ist. Ich habe lediglich festgestellt dass die x86 big cores sehr auf µop Caches angewiesen sind, da variable instruction length decoder einfach riesig und kompliziert sind. Die sind daher nur 4-wide, ohne decoder recycling geht nicht nur power draw stark nach oben, sondern wird auch die pipeline superbreiter cores wie willow cove, golden cove, etc. nicht ausreichend gefüllt.

Interessanterweise haben sie sich bei Tremont mit der Begruendung "Power" gegen uop cache entschieden, und Tremont decodiert 2*3 Befehle pro Zyklus.

Das ARM cores meistens keinen µop cache brauchen liegt ja eben daran dass es keine fetteb cores sind wie die x86 "big-core" designs. Außerdem können die decoder für fixed instruction length ohnehin viel einfacher sein, viel weniger energie verbrauchen und große caches ohne vielen aufwand und großem power draw realisiert werden.

Sollte man meinen, aber tatsaechlich haben A77 und A78 einen uop-Cache. Hmm, eventuell, weil ARM soviele Befehlssaetze unterstuetzt, darunter das variabel breite Thumb2 (hat Apple das schon abgeschafft?).

Und Tremont ist ein small Core und noch dazu eine Krücke, das ist eher ein Argument pro µop-cache.

Ja, Tremont ist ein low-power core. Trotzdem demonstriert er, dass 6 AMD64-Befehle pro Zyklus decodiert werden koennen, ohne zuviel Strom zu brauchen. Inwieweit das ein Argument fuer den uop cache sein soll, musst Du erst erklaeren. Und was daran eine Kruecke sein soll, auch.

Zum K7, K8:

ja und IPC, effizienz-technisch weit abgeschlagen in 2021.

Unglaublich: Prozessoren aus 1999 (K7) und 2003 (K8) sind 2021 weit abgeschlagen. Damals waren sie mit ihrem Cache-Design aber auf der Hoehe der Prozessoren mit virtually-indexed physically-tagged L1-caches (das, was Du beschreibst). Und wenn groessere caches mit weniger Assoziativitaet so wichtig waere wie Du behauptest, wuerde diese Art von Cache-Design wieder kommen. Tatsaechlich scheint aber viel Assoziativitaet kein grosses Problem zu sein, wie man am 12-Wege-D-Cache von Ice Lake ff. sieht.

Das heißt dass mit pech jede menge zeug geladen wird welches man nicht braucht und nur in sonderfällen werden die 64kb gut ausgenutzt. Und die line size ist trotzdem 64byte.

Bei der gleichen Line size wird nichts zusaetzlich geladen, was nicht gebraucht wird. Was die Assoziativitaet beeinflusst, ist, was rausgeschmissen wird: Mit kleinerem Cache und geringerer Assoziativitaet werden eher Sachen rausgeschmissen, die in Kuerze noch einmal gebraucht werden. Da stand der K7 mit groesserem Cache gegen den Pentium III mit mehr Assoziativitaet. Na jedenfalls ist Dein Argument, dass hohe Assoziativitaet zuviel Strom braucht, und deswegen weniger Assoziativitaet verwendet werden sollte (und Du meinst, dafuer braeuchte man groessere Seiten; der K7 demonstriert, dass das nicht so ist).

Interessant! Das hat bei Cyrix aber andere Gründe dass die es nicht geschafft haben. Wie setzen die das um wenn die x86 ISA das nicht anbietet?

Ich hab's mir nicht naeher angeschaut, aber bei System-Level-Sachen wie Page Tables bauen die verschiedenen Hersteller durchaus optionale Erweiterungen ein (bekannt waren die PAE. Betriebssysteme, die die Erweiterung nicht kennen, funktionieren wie gehabt; und Betriebssysteme, die was damit anfangen koennen, haben einen Vorteil.

Ja, der cache unterstützt variable page sizes. Apple kann zwischen 64, 32, 16 und 4kb hin und her schalten und legt dann die jeweiligen ungenutzten blöcke schlafen. So nutzen sie immer die gesamte Assoziativität aus, anders wäre der zusammen 384kb große L1 Cache (größer als der Comet Lake L2 cache!) gar nicht möglich in einem Iphone-Power Budget.

Man findet ja nicht soviel ueber Apples CPUs, aber was ich so finden konnte, hat der A13 Firestorm 128K D + 128K I-cache, jeweils 8-Wege-assoziativ, und der A14 Lightning hat 128K D und 192 K I-cache, Assoziativitaet unbekannt. Naja, jedenfalls wenn der A13 mit 4KB-Seiten arbeitet, verwendet er virtually-indexed virtually-tagged wie der K7, oder er verwendet nur 32KB von jedem Cache.

Alle aktuellen ARM CPUs verwenden größere page sizes als 4KB und haben größere Caches mit geringerer assoziativität als aktuelle x86 CPUs.
[...]
ARM cpus bis zum A76, A77, A78 haben traditionell je 64kb I- und Data Cache mit lediglich 4-way Assoziativität. Das kostet weniger Diefläche und Energie, hat aber dank 16kb page size eine ähnlich gute vllt. sogar bessere hitrate.

Gerade einmal auf einem Raspi4 nachgeschaut, da gibt "pagesize" 4096 aus; ansonsten finde ich nicht viel ueber Seitengroessen. Naja, jedenfalls hatte schon der K7 (und davor der 21264) groessere L1-Caches mit geringerer Assoziativitaet als aktuelle AMD64-CPUs. Oben hast Du Dich veraechtlich drueber geaeussert, hier ist es auf einmal gut. Mir scheint, du misst mit zweierlei Mass.

Groessere Seiten machen die Hitrate nicht besser (aber erlauben es VIPT-Caches mit geringerer Assoziativitaet zu bauen).

 

[der Unzensierte]

Das frage ich mich gerade: Hilft das auch bei dieser Lücke?

Der Angriffsvektor ist der gleiche - zwei threads die auf einem Kern laufen und gemeinsamen Speicher nutzen. Also ja, auch hier sollte das abschalten von SMT die Türe zu machen können.

 

[jemandanders]

Die Universitäten von Virginia und Kalifornien, die an den Untersuchungen beteiligt waren, haben AMD und Intel bereits Mitte April von der Sicherheitslücke in Kenntnis gesetzt.

Hmm...
Ich dachte immer, das es zum guten Ton gehört, den betroffenen Herstellern ein halbes Jahr Zeit zu zugestehen um sich um eine Fehlerkorrektur / Entschärfung, zumindest bemühen zu können.

Wollen sich die Uni´s irgendwie hervorheben oder Wichtig machen?

 

[mae]

Hmm...
Ich dachte immer, das es zum guten Ton gehört, den betroffenen Herstellern ein halbes Jahr Zeit zu zugestehen um sich um eine Fehlerkorrektur / Entschärfung, zumindest bemühen zu können.

Wollen sich die Uni´s irgendwie hervorheben oder Wichtig machen?

Immer. Es geht um wissenschaftlichen (aber vielleicht auch weitergehenden) Ruhm. Gerade im Computer-Security-Bereich hat sich da ein Publicity-Theater etabliert, bei dem viele (auch an Unis) den Kopf schuetteln; man kann es aber auch so sehen, dass die Forscher Kontakt mit der Oeffentlichkeit halten, statt im stillen Kaemmerlein zu forschen.

Was den guten Ton betrifft, 3 Monate sind schon recht lang. Bei Spectre und Meltdown haben die Forscher mehr Zeit gegeben, weil das halt besonders schwerwiegend war und Mitigations an vielen Stellen erforderte, aber letztendlich wurde das Embargo kurz vor Ende der Frist gebrochen (es mussten ja auch mehr und mehr Leute von der Luecke erfahren, die halten nicht alle dicht), sodass die dann vorzeitig verlautbart haben. Und Intel und AMD haben trotz dieser langen Vorlaufzeit erst einige Zeit nach der Veroeffentlichung Microcode-Updates gebracht, die die Mitigations unterstuetzt haben; ich habe den Eindruck, dass die lange Sperrfrist bei den Hardwareherstellern nur den Schlendrian unterstuetzt hat; andererseits haben auch Softwarehersteller an Mitigations gearbeitet, und aus Linux-Kreisen hoerte man, dass das schon recht stressig war.

Zu dieser Luecke: Wenn Intel auf dem Standpunkt steht, dass die Gegenmassnahmen gegen bisherige Side-Channel-Attacks auch gegen diese Luecke helfen, und sie daher nichts machen muessen (und wenn AMD das auch so sieht), gibt's auch keinen Grund, das laenger hinauszuzoegern.

 

[jemandanders]

Ach stimmt ja, 90 Tage waren das wohl.
Was mich jetzt ein wenig wundert ist, dass AMD auch davon (in gleichem Ausmaß) betroffen sein soll.
Wenn ich das vor 2 3 Jahren richtig mitbekommen habe, haben die doch eigentlich eine ziemlich gut funktionierende Rechteverwaltung innerhalb der CPU, weswegen sie von den Seitenkanalattacken ja eher weniger bis nicht betroffen waren.
Tja, wie´s scheint ist niemand perfekt. Schade

 

[mae]

Was mich jetzt ein wenig wundert ist, dass AMD auch davon (in gleichem Ausmaß) betroffen sein soll.
Wenn ich das vor 2 3 Jahren richtig mitbekommen habe, haben die doch eigentlich eine ziemlich gut funktionierende Rechteverwaltung innerhalb der CPU, weswegen sie von den Seitenkanalattacken ja eher weniger bis nicht betroffen waren.

AMD-Prozessoren waren von Meltdown nicht betroffen (da liefert der spekulative load 0 oder so, wenn er nicht zugreifen darf), und bezueglich Spectre gab es von AMD nebuloese Aussagen, dass sie nicht glauben, dass man das bei ihnen ausnutzen kann. Die Side Channels gibt und gab es aber auch auf AMD (und ueberall sonst) und ich wuesste (im Gegensatz zu Spectre) auch nicht, wie man die schliessen koennte, ohne alle caches abzuschaffen und aehnlich drastische Massnahmen.

 

[psyabit]

Und die Firmenwagen sind BMWs, keine Autos?

Und wenn es dir darum gehen sollte das es ein Typ 1 Hypervisor ist: das ist Spectre egal, das ist das eigentlich fatale an diesen Lücken.

Hab wohl zu früh geschossen. Hab die Thematik nun kapiert, thx.

Ergänzung (5. Mai 2021)

Das erklär‘ mir jetzt bitte etwas genauer ...
Da bin ich gespannt.

Hab wohl zu früh geschossen. Hab die Thematik nun kapiert, thx.

Ergänzung (5. Mai 2021)

@psyabit

https://de.wikipedia.org/wiki/Xen

Hab wohl zu früh geschossen. Hab die Thematik nun kapiert, thx.

 

[davidzo]

Interessanterweise haben sie sich bei Tremont mit der Begruendung "Power" gegen uop cache entschieden, und Tremont decodiert 2*3 Befehle pro Zyklus.

Okay, da muss ich passen, du hast dich anscheinend deutlich mehr mit dem Thema beschäftigt als ich. Ich dachte die Atoms sind noch bei 3 wide decode wie mit Goldmont eingeführt. Btw, damals sind die Taktraten eher gefallen, power gleich geblieben zu Baytrail/Silvermont bzw. sogar angestiegen. Das muss nichts mit der 2-decode width zutun haben, aber irgendwas hat man gemacht was sich negativ auf den verbrauch auswirkt.

Anandtech scheibt übrigens dass der fehlende µop cache Flächengründe hat, nicht power.
Eine klassische Folge von Intels interner Marktsegmentierung die sie an den Punkt gebracht haben wo sie jetzt stehen.

Sollte man meinen, aber tatsaechlich haben A77 und A78 einen uop-Cache. Hmm, eventuell, weil ARM soviele Befehlssaetze unterstuetzt, darunter das variabel breite Thumb2 (hat Apple das schon abgeschafft?).

Eben, alle Arm Cortexs davor haben keinen.
Btw, der 1,5K mop$ vom A77 soll flächenmäßig 32kb/2way L1 entsprechen.

Ja, Tremont ist ein low-power core. Trotzdem demonstriert er, dass 6 AMD64-Befehle pro Zyklus decodiert werden koennen, ohne zuviel Strom zu brauchen. Inwieweit das ein Argument fuer den uop cache sein soll, musst Du erst erklaeren. Und was daran eine Kruecke sein soll, auch.

Tremont ist nicht ansatzweise in derselben Leistungs- und Effizienzklasse wie die Cortex As oder Apples Icestorm.
Tremont hat mit 2,8Ghz nah am Taktlimit schon Schwierigkeiten auch nur 50% der Leistung eines veralteten Skylakes (3,6Ghz) abzuliefern, Core for Core: https://www.servethehome.com/intel-pentium-silver-j5005-benchmarks-and-review/2/

Tatsaechlich scheint aber viel Assoziativitaet kein grosses Problem zu sein, wie man am 12-Wege-D-Cache von Ice Lake ff. sieht.

48/12 = 4k = pagsize. Zufall?

Man findet ja nicht soviel ueber Apples CPUs, aber was ich so finden konnte, hat der A13 Firestorm 128K D + 128K I-cache, jeweils 8-Wege-assoziativ, und der A14 Lightning hat 128K D und 192 K I-cache, Assoziativitaet unbekannt. Naja, jedenfalls wenn der A13 mit 4KB-Seiten arbeitet, verwendet er virtually-indexed virtually-tagged wie der K7, oder er verwendet nur 32KB von jedem Cache.

Apple arbeitet sowohl beim A13 und A14/M1 mit 16kb pagesize. Der A13 hat 8fach Assoziativität, der A14 I$ 12fach, beide haben riesige 128-byte cache lines.

Groessere Seiten machen die Hitrate nicht besser (aber erlauben es VIPT-Caches mit geringerer Assoziativitaet zu bauen).

Nicht nur dass, anscheinend hilft die nicht zu hohe Assoziativität oder die großen cache lines dabei die enorm geringe Latenz von 3cycles zu erreichen ohne das der power draw durch die decke geht.
Nvidia hat das bereits in extremer Form mit Carmel versucht. 64k, 4-way mit 1-2cycle latency.
Der Schlüssel ist wahrscheinlich darin die Compiler und Software zu kontrollieren. Der Fujitsu A64FX soll sogar 256byte Cache lines haben.

Intel Rocketlakes 48kb d-$ hat 5cycles, bei den 128k die beim M1 noch in den L1 passen bist du bei RKL aber schon längst im l2 und musst mit 13cycles leben. Ab da bist du dann beim M1 im schier gigantischen 12mb L2 mit nur 16 cycles, was schon dem L3 bei sunny cove entspricht (30-36cycles). Einen Teil holt Intel über höheren maximaltakt wieder rein, aber was kostet das an powerbudget?

 

[WinnieW2]

Tremont ist nicht ansatzweise in derselben Leistungs- und Effizienzklasse wie die Cortex As oder Apples Icestorm.
Tremont hat mit 2,8Ghz nah am Taktlimit schon Schwierigkeiten auch nur 50% der Leistung eines veralteten Skylakes (3,6Ghz) abzuliefern, Core for Core: https://www.servethehome.com/intel-pentium-silver-j5005-benchmarks-and-review/2/

Ein Pentium Silver J5005 basiert aber nicht auf der Tremont Architektur, sondern auf seinem Vorgänger Goldmont Plus (4-decode).
Intel bewirbt eine IPC-Steigerung um 30% beim Vergleich von Tremont zu Goldmont Plus.
Da müsste ein Pentium Silver J6005 mit einer Skylake CPU verglichen werden, aber soweit mir bekannt werden diese erst demnächst verkauft; es gibt also derzeit noch gar keine CPUs nur mit Tremont Kernen auf dem Markt.
Die einzige CPU in denen Tremont-Kerne genutzt werden ist Lakefield, als Little-Kerne.

 

[mae]

Anandtech scheibt übrigens dass der fehlende µop cache Flächengründe hat, nicht power.

Hmm, ich frage mich jetzt, woher ich das mit dem Verbrauch habe. Na jedenfalls scheint's bezueglich Verbrauch gut genug fuer einen Niedrig-Verbrauchs-Core zu sein.

Tremont ist nicht ansatzweise in derselben Leistungs- und Effizienzklasse wie die Cortex As oder Apples Icestorm.
Tremont hat mit 2,8Ghz nah am Taktlimit schon Schwierigkeiten auch nur 50% der Leistung eines veralteten Skylakes (3,6Ghz) abzuliefern, Core for Core: https://www.servethehome.com/intel-pentium-silver-j5005-benchmarks-and-review/2/

Wie WinnieW2 schreibt, hat der Pentium J5005 Goldmont+-Kerne, nicht Tremont. Tremont gibt's im Lakefield in einem ueberteuerten Samsung Galaxy Book S, scheint aber sonst noch nicht breit verfuegbar zu sein.

48/12 = 4k = pagsize. Zufall?

Nein, VIPT hat schon Vorteile. Aber wenn es ein entscheidender Vorteil waere, z.B 128KB mit z.B. 4-Wege-Assoiziativitaet zu haben, koennte man auch ohne. Bzw. umgekehrt, der Verbrauch hat sie nicht von 12-Wege-Assoziativitaet abgehalten.

Apple A13,A14

riesige 128-byte cache lines.

Interessant. Das ist etwas, wo dann mehr Daten in den Cache geladen werden, als dann gebraucht werden. Haette ich gerade bei einem auf niedrigen Verbrauch getrimmten Prozessor nicht erwartet.

Nicht nur dass, anscheinend hilft die nicht zu hohe Assoziativität oder die großen cache lines dabei die enorm geringe Latenz von 3cycles zu erreichen ohne das der power draw durch die decke geht.

Naja, 3 Zyklen bei 3.1GHz sind 0.97ns, 4 Zyklen bei 5.3GHz (Comet Lake) sind 0.75ns, die Latenz ist bei Intel also schon niedriger. Wobei sie bei Rocket Lake dann aehnlich wie beim A14 sind, und beim Tiger Lake etwas schlechter. Meine Theorie war ja, dass die 10nm von Ice Lake Intel zu den 5 Zyklen gebracht haben (weil die Signalgeschwindigkeit bei kleineren Prozessen abnimmt), und dann gingen sich halt in den 5 Zyklen~1ns 48KB cache aus; aber wenn Apple in 5nm auf 128KB in 1ns zugreifen kann, dann war meine Theorie wohl falsch.

Der Fujitsu A64FX soll sogar 256byte Cache lines haben.

Hat er, der ist aber auch fuer Supercomputer entworfen, die Software dort greift tendentiell mehr sequentiell auf die Daten zu, sodass sich die Balance der Vorteile und Nachteile hin zu groesseren Cache lines verschiebt als bei allgemeiner Software.

 

[WinnieW2]

Tremont gibt's im Lakefield in einem ueberteuerten Samsung Galaxy Book S, scheint aber sonst noch nicht breit verfuegbar zu sein.

Intel fertigt Tremont ausschliesslich in 10nm Strukturen, und die Fertigung in 10nm ist bislang im Segment der preiswerten CPUs nicht angekommen.
Von daher kann man derzeit noch keine CPUs nur mit Tremont-Kernen erwerben, was sich aber demnächst ändern wird.
Was Sicherheitslücken betrifft dürfte Tremont und vermutlich dessen Nachfolger Gracemont weniger davon betroffen sein. Zumal diese kein SMT / Hyperthreading implementiert haben. OoO-Befehlsausführung nutzen diese allerdings ebenfalls, mir ist nur unklar ob diese genauso unsicher ist bei Skylake u. deren Nachfolgern.