Archiv verlassen und diese Seite im Standarddesign anzeigen : Diskussion zu: Hardware- und Nachrichten-Links des 26. Februar 2020
Leonidas
2020-02-27, 07:54:09
Link zur News:
https://www.3dcenter.org/news/hardware-und-nachrichten-links-des-26-februar-2020
Complicated
2020-02-27, 09:20:21
Derzeit hat Intel in dieser Frage (seit der Skylake-Architektur) nur sein Feature "Software Guard Extensions" (SGX) aufzubieten, welches allerdings in seiner Anwendung limitiert ist und daher auch kaum genutzt wird.
Es wird nicht genutzt weil es eigene Sicherheitslücken hat. Daher deaktiviert man es am besten by default. Siehe Undervoltinglücke "Plundervolt".
https://www.heise.de/security/meldung/Intel-flickt-Plundervolt-und-zahlreiche-weitere-Sicherheitsluecken-4611068.html
Oder diese ohne Fix:
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-0123
https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00220.html
FlashBFE
2020-02-27, 09:52:04
Speicherverschlüsselung ist eigentlich eher eine Notlösung, denn der große Negativpunkt wird hier gar nicht erwähnt: Verschlüsselung braucht Rechenleistung. Und bei dem Datenverkehr im RAM ist das gar nicht wenig. Selbst, wenn man dafür eine transparente eigene Logik integriert, verbrät die (außer den Transistoren) natürlich auch Energie. Sie belastet also mindestens das Leistungsbudget des Prozessors, was indirekt an der TDP-Grenze zu Performanceeinbußen führen könnte und in jedem Fall die Energieeffizienz reduziert.
Das Ziel müsste also eigentlich sein, Seitenkanalangriffe elegant über die Architektur (auch des RAMs) zu verhindern, ohne Performance oder Energie zu opfern.
Complicated
2020-02-27, 10:00:50
Schöne Theorie, die in der Praxis von Zen widerlegt ist. Verschlüsselung ist über eigene FFUs im Chip sehr gut implementiert.
https://sviko.com/t/how-memory-encryption-in-amd-epyc-7000-works-or-how-it-protects-your-cloud/82/6
I want to note that on such modern processors as AMD EPYC 7000 with an active energy saving system, 1-stream Redis gives a huge measurement error, and in our case, the inclusion of SME has always accelerated the operation of the system. Fortunately, in this test it is more important for us that there is no noticeable decrease in either get or SET operations when encryption is enabled.
https://sviko.com/uploads/default/original/1X/a64a1018b7c8028006ad97571b6c9517fefd9cd9.png
@Leonidas: Danke für den Link zu den Tests der Swift3. Aber irgendwas ist bei dem Test komisch.
Wurde in dem Test von Notebookcheck die Vega8 nun sowohl gegen 540X als auch gegen RX 540 getest? Das sind imho 2 "unterschiedliche" dedizierte Karten. Die 540X hat 64Bit, die RX 540 128Bit? Oder ist das bloß falsch beschriftet und es ist immer die RX540x nur einmal mit 3500U und einmal mit 2500U als Unterbau?
Redirion
2020-02-27, 10:40:07
ich bin sehr gespannt, wie die 2nd Generation Vega 8 im 4800U sich hier schlägt. AMD Smartshift ist das Stichwort zum Aufweichen der hier genannten TDP-Problematik.
Milchkanne
2020-02-27, 11:38:03
Schöne Theorie, die in der Praxis von Zen widerlegt ist. Verschlüsselung ist über eigene FFUs im Chip sehr gut implementiert.
In deinem Link wird aber nichts zum Stromverbrauch gesagt. Der wurde ja auch kritisiert. Höher wird er sein. Im Server wird das wahrscheinlich keine große Rolle spielen, auf Notebooks wahrscheinlich schon eher.
Gast Ritis
2020-02-27, 11:47:02
Notebookcheck kommt reichlich spät mit der Erkenntnis, eigentlich wartet ein Laptop-Gamer doch eher auf die 4000 Renoir Modelle, da wird alles komplett anders aussehen.
Ansonsten finde ich gerade bei Laptops und deren Gaming bzw. Grafik-Leistung kommt es auf Tests je Modell an. Der Teufel steckt da im Detail der Konfiguration durch den OEM. Sieht man ja auch an den Dauerlast-Tests in dem verlinkten Artikel.
Gast-LAZA
2020-02-27, 12:09:52
Ein wesentlicher Faktor bei der Betrachtung der beiden GraKas im NB fehlt:
Wie hoch ist der Aufpreis für die "echte" Karte?
Lohnt es sich wegen der 8%, wenn das NB als Arbeitsgeräte genutzt wird?
Complicated
2020-02-27, 12:27:30
Die TDP ist identisch und bei Vollast wird das Powerbudget voll ausgelastet. Im Gegensatz zu Intel stimmen die AMD Angaben, wie alle Tests mit Ryzen/TR/Epyc zeigen. Das muss dieser Bench nicht ebenfalls darstellen. Du hast selber ausgeführt, es bestünde die Gefahr, dass die Leistung geringer wird mit Verschlüsselung, weil das Powerbudget die CPU-Taktung reduzieren könnte durch die zusätzliche Verschlüsselung. Der Bench zeigt, dass dies nicht der Fall ist und dort keine Limitierung der Leistung statt findet.
Milchkanne
2020-02-27, 13:04:15
bei Vollast wird das Powerbudget voll ausgelastet
Ist das auch bei speicherintensiven Anwendungen der Fall?
FlashBFE
2020-02-27, 13:53:28
Schöne Theorie, die in der Praxis von Zen widerlegt ist. Verschlüsselung ist über eigene FFUs im Chip sehr gut implementiert.
https://sviko.com/t/how-memory-encryption-in-amd-epyc-7000-works-or-how-it-protects-your-cloud/82/6
https://sviko.com/uploads/default/original/1X/a64a1018b7c8028006ad97571b6c9517fefd9cd9.png
Du hast wohl deine eigene Quelle nicht richtig gelesen? Dein zitierter Text bezieht sich auf den Unterschied zwischen SME und TSME und da ist SME manchmal schneller, weil es nur Teile des RAMs verschlüsselt statt alles. Außerdem hast du ausgerechnet einen Datenbank-Benchmark auf einem 32-Kern-EPYC herausgesucht, der vollständig bandbreitenlimitiert ist und wahrscheinlich gar nicht an der TDP-Grenze des Prozessors kratzt. Weiter unten in deiner Quelle gibt es übrigens auch Benchmarks, wo bei der Verschlüsselung 5% bzw. sogar 15% Performanceverlust eintritt. Und es gibt leider weder eine Energiemessung noch eine Temperaturmessung bei diesen Benchmarks, um Verbrauchsunterschiede herauszuarbeiten.
Verschlüsselung kann noch so effizient implementiert sein, es ist trotzdem zusätzlicher Rechenaufwand. Lohnen würde es sich nur, wenn es gleichzeitig mit blockweiser Datenkompression implementiert wird und so das Bandbreitenlimit gelockert werden könnte.
Die TDP ist identisch und bei Vollast wird das Powerbudget voll ausgelastet. Im Gegensatz zu Intel stimmen die AMD Angaben, wie alle Tests mit Ryzen/TR/Epyc zeigen. Das muss dieser Bench nicht ebenfalls darstellen. Du hast selber ausgeführt, es bestünde die Gefahr, dass die Leistung geringer wird mit Verschlüsselung, weil das Powerbudget die CPU-Taktung reduzieren könnte durch die zusätzliche Verschlüsselung. Der Bench zeigt, dass dies nicht der Fall ist und dort keine Limitierung der Leistung statt findet.
Das nächstens mal wenn ich über 80 in der 65er zohne fahre berufe ich mich auf AMD und behaupte meine auf dem Papier gemachte Angabe stimmt !
Complicated
2020-02-27, 17:38:48
Da im Text, den du zitierst, nichts über "OHNE Verschlüsselung" steht, ist das völlig irrelevant für mein Argument. Deine Behauptung, dass es mehr Leistung kostet ist in den Grafiken widerlegt, die Werte ohne Verschlüsselung enthalten. Da ich dabei auf die beste Leistung referenziere, ist ein schlechteres Ergebnis einer anderen Variante ebenfalls nicht relevant.
Verschlüsselung kann noch so effizient implementiert sein, es ist trotzdem zusätzlicher Rechenaufwand.Das behauptest du trotz verlinkter Quelle die das Gegenteil beweisst. Deine Gegenargumentation beinhaltet nichts aus der Quelle und lauter Vermutungen von dir ohne eine Quelle. Das Thema ist dann wohl durch, denke ich.
Der zusätzliche Rechenaufwand erfolgt durch die FFU, welche ansonsten nichts zu tun hat wenn Verschlüsselung nicht aktiv ist. Die Rechenleistung der CPU bleibt auf selbem Niveau wenn die FFU arbeitet oder aus ist.
MiamiNice
2020-02-27, 18:15:32
Natürlich verbraucht eine Verschlüsselung Leistung (Strom). Auch wenn die eigentliche Arbeitsleistung nicht beeinträchtigt ist, da andere Einheiten genutzt werden für den Vorgang, brauchst Du halt für die zusätzlichen Einheiten Saft, der im Extremfall der CPU fehlen kann, sprich sie taktet nicht so hoch da sie eher ins PL rennt. Und damit kostet eine Verschlüsselung im Endefekt auch Leistung in Form von Arbeitsleistung.
AMD bietet TSME seit der Zen-Architektur bei seinen Epyc-Prozessoren an – und im Zeitalter der CPU-Sicherheitslücken ergeben sich die Vorteile daraus faktisch von alleine – insbesondere Seitenkanal-Attacken sind gegenüber verschlüsseltem Speicher kaum noch zweckmäßig.
Was genau sollte jetzt Speicherverschlüsselung gegen Seitenkanalattacken bringen?
Der Clou an Seitenkanalattacken ist ja, dass man aus dem Verhalten des Prozessors innerhalb von zulässigem Code darauf schließt was er an anderer Stelle macht, auf die man eigentlich keinen Zugriff hätte.
Ich wüsste nicht wie da Speicherverschlüsselung in irgendeiner Weise helfen sollte, weil was Seitenkanalattacken schaffen ist es aus dem Verhalten des Prozessors auf die verarbeiteten Daten zu schließen, und zu diesem Zeitpunkt müssen diese in jedem Fall unverschlüsselt sein.
Das Einzige gegen was Speicherverschlüsselung wirklich helfen kann sind echte Hardwareangriffe, also Beispielsweise das einsprühen des RAM mit Kältespray, und anschließende Auslesen in einer anderen Maschine.
Ob das den Aufwand wirklich Wert ist? Das dürfte wohl eher selten der Fall sein.
Weil wie schon angemerkt wurde, selbst mit Hardwarebeschleunigung, auch wenn man das Ganze annähernd performanceneutral schafft (ein gewisser Latenznachteil dürfte wohl unumgänglich sein, selbst wenn die Ver/Entschlüsselung schnell genug ist um die Bandbreite nicht zu limitieren) braucht es in jedem Fall zusätzliche Energie.
Eventuell dürfte das noch interessanter werden, für Systeme die nicht flüchtigen Speicher wie Optane als RAM verwenden, da hier schließlich die potentielle Zeitbereich in dem ein Angriff stattfinden kann deutlich länger ist.
Dennoch handelt es sich hier in erster Linie um eine Maßnahme gegen physische Angriffe, und nicht gegen softwarebasierte Angriffe, selbst wenn als Nebeneffekt der eine oder andere erschwert werden würde.
Eldoran
2020-02-27, 18:34:47
Klar ist Verschlüsselung ein zusätzlicher Aufwand der Zeit und Energie kostet, allerdings ist das keine Software Implementation.... das läuft auf dem ARM Secure Processor mit entsprechenden ASIC für AES. Zumindest bei Naples hat AMD angegeben, dass es etwas Leistung kostet, da es die Latenz bei RAM Zugriff etwas erhöht, von TDP Limit Problemen ist mir nichts bekannt. Bei der ein paar Posts oberhalb geposten Link ist das beim letzten Bild zu sehen, es kostet 1ms. Im Normalfall liegt der Effekt aber bei niedrigen einstelligen Prozent Leistung.
Wenn man da den Energieverbrauch des RAM Interfaces im Vergleich nimmt, dürfte das ganze nicht mehr sonderlich auffallen. Es ist eben wie bei den ganzen Seiteneffekt Mitigations, es kosten eben vielleicht ein paar Prozent Leistung, aber es löste in paar Probleme - vor allem gerade die Physischen Angriffe auf das RAM sind damit weitgehend ausgeschaltet. Bisher auch praktisch die einzige echte Möglichkeit etwas gegen RAMBleed zu tun. Das ganze dürfte auch in Zukunft wichtiger werden, wenn non volatile RAM verbreiteter wird.
Complicated
2020-02-27, 21:28:56
Was genau sollte jetzt Speicherverschlüsselung gegen Seitenkanalattacken bringen?
Der Clou an Seitenkanalattacken ist ja, dass man aus dem Verhalten des Prozessors innerhalb von zulässigem Code darauf schließt was er an anderer Stelle macht, auf die man eigentlich keinen Zugriff hätte.
Ich wüsste nicht wie da Speicherverschlüsselung in irgendeiner Weise helfen sollte, weil was Seitenkanalattacken schaffen ist es aus dem Verhalten des Prozessors auf die verarbeiteten Daten zu schließen, und zu diesem Zeitpunkt müssen diese in jedem Fall unverschlüsselt sein.
Eine VM auf einem Hostsystem kann keine andere VM auf dem selben Hostsystem mit einem Seitenkanalangriff auslesen. Alles was z.B. über den CPU-Cache einen Seitenkanal-Angriff Cross-VM durchführen kann, erhält keine lesbaren Daten.
https://www.cs.unc.edu/~reiter/papers/2012/CCS.pdf
Oder RAMBleed:
https://www.cs.unc.edu/~reiter/papers/2012/CCS.pdf
Dein Argument geht davon aus, dass Pro CPU nur ein System läuft, das den RAM nutzt.
Leonidas
2020-02-28, 05:12:49
Wurde in dem Test von Notebookcheck die Vega8 nun sowohl gegen 540X als auch gegen RX 540 getest? Das sind imho 2 "unterschiedliche" dedizierte Karten. Die 540X hat 64Bit, die RX 540 128Bit? Oder ist das bloß falsch beschriftet und es ist immer die RX540x nur einmal mit 3500U und einmal mit 2500U als Unterbau?
Beide wurden getestet, ich habe aber nur gegen die 540X verglichen - weil nominell gleiche Rohleistung zur Vega 8.
Und ja, teilweise lief die 540X nur auf einer 2500U APU. Perfekt ist der Test sicherlich nicht.
Der Clou an Seitenkanalattacken ist ja, dass man aus dem Verhalten des Prozessors innerhalb von zulässigem Code darauf schließt was er an anderer Stelle macht, auf die man eigentlich keinen Zugriff hätte.
Und in diesem Fall müsste man ja dann faktisch nur verschlüsselten Müll auslesen - oder? Zumindest ist das meine Schlußfolgerung. Wenn ich hier falsch liege, wäre das natürlich blöd.
Und in diesem Fall müsste man ja dann faktisch nur verschlüsselten Müll auslesen - oder? Zumindest ist das meine Schlußfolgerung. Wenn ich hier falsch liege, wäre das natürlich blöd.
Generell nicht.
Es wäre denkbar, dass die eine oder andere spezielle Attacke damit abgefangen wird, aber eine Generallösung gegen Seitenkanalattacken ist es auf keinen Fall.
Die ALUs müssen ja zwangsweise mit entschlüsselten Daten rechnen alles andere wäre ja sinnlos. Irgendwo muss also die Entschlüsselung stattfinden, und innerhalb des Kerns befindet sich immer der Klartext.
Die meisten Seitenkanalattacken funktionieren ja so, dass man über ein Gadget Speicherzugriffe erzeugt, deren Adresse von irgendwelchen auszuspionierenden Nutzdaten abhängt und innerhalb des eigenen Prozesses dann aufgrund der Zugriffszeiten darauf schließt auf welche Speicheradresse zugegriffen wurde. Dabei ist Adresse = geleakte Daten.
Das passiert alles innerhalb des Kerns und muss damit zwangsweise mit entschlüsselten Daten passieren.
Daneben ist noch die Frage wann die Entschlüsselung passiert, schon vor dem Cache, in den Caches liegen dann schon entschlüsselte Daten, oder wirklich erst beim Read-Zugriff aus dem Cache. Wobei ich mir ehrlich gesagt nur vorstellen kann, dass die Entschlüsselung bereits im Speichercontroller erfolgt und im Cache dann Klartext steht.
Damit sollte sich der Energieverbrauch bei ausreichender Cache Hitrate auch in Grenzen halten, wenn wirklich jeder Zugriff auch im Cache entschlüsselt werden müsste, würde dieser doch deutlich steigen.
Die nächste Frage ist es wie viel verschiedene Schlüssel es gibt. Einen pro (Hardware) Prozessor? Oder einen pro darauf laufendem (virtuellen) System, oder gar einen pro Prozess.
Wobei das eigentlich gar keine so große Rolle spielen sollte, der Schlüssel sollte sowieso unauslesbar innerhalb der CPU gespeichert sein, und so lange es keine vernünftige Möglichkeit gibt aus einem Cipher-Plaintext-Pair auf den Schlüssel zu schließen, sollte das auf die Sicherheit keinen großen Einfluss haben.
An Rambleed habe ich jetzt nicht gedacht, das sollte man mit einer Speicherverschlüsselung durchaus verhindern können.
Also wie gesagt, einzelne Methoden der Seitenkanalattacken könnte man damit durchaus verhindern. Eine Generallösung ist das aber zu 100% nicht, und die meisten Seitenkanalattacken, insbesondere jene die nur in der CPU stattfinden und den RAM gar nicht brauchen sollten weiterhin funktionieren.
Leonidas
2020-02-28, 10:01:12
Ok, gut erklärt. Das würde bedeuten, nur Seitenkanalattacken auf den Speicher wären abgesichert.
Beide wurden getestet, ich habe aber nur gegen die 540X verglichen - weil nominell gleiche Rohleistung zur Vega 8.
Und ja, teilweise lief die 540X nur auf einer 2500U APU. Perfekt ist der Test sicherlich nicht.
Dann ist deine Tabelle falsch. Dort steht vorne RX 540 und nicht 540X. Die 14 Zolls Swifts mit 3000er APU haben tatsächlich alle nur die kastrierte 64Bit 540X.
Leonidas
2020-02-29, 02:54:15
In der Tabelle steht doch "Radeon RX 540X"? Stand schon immer so da.
vBulletin®, Copyright ©2000-2024, Jelsoft Enterprises Ltd.