News Ryzen: AMD nutzt PCI-Treiber zur Manipulation von CPU-Funktionen

Bei den Hashes handelt es sich anscheinend um die Executables von folgenden Spielen (2 fehlen noch):

anthem.exe
AnthemTrial.exe
bfv.exe
bfvtrial.exe
destiny2.exe
doometernalx64vk.exe
factorio.exe
fallout76.exe
gameclient.exe
h1z1.exe
jwe.exe
league of legends.exe
modernwarfare.exe
overwatch.exe
r5apex.exe
rainbowsix.exe
warframe.x64.exe
 
  • Gefällt mir
Reaktionen: Tanzmusikus, Fak.Ufo, Thomaswww und 13 andere
ghecko schrieb:
Was mich interessiert: da es hier um Windows geht frage ich mich, ob sie diesen Hack auch in Linux untergebracht haben. Wovon ich erst mal nicht ausgehe. Interessant wäre jetzt um welche Anwendungen es geht und wie diese sich unter Wine/Proton verhalten würden, ohne diese "Optimierung".
Bei Linux kann der "User Space" also soetwas wie PowerShell (bzw. Bash) eigentlich nicht auf Kernel-Interfaces zugreifen mit denen MSR / CPU direkt manipuliert werden kann.
Bzw. der Zugriff muss über Konfigurationseinstellungen aktiviert werden (Entwickler/Debug Funktionen)

News: 06-2020: Linux-Filter-Tightening-MSRs
 
  • Gefällt mir
Reaktionen: Tanzmusikus, konkretor und ghecko
boxte30:Goas schrieb:
Genau das tut es. - Wenn 1 PS Zeile reicht, dann ist das billig.
Fuer unter linux mal folgenden befehl aus:

"sudo rm -rf /* --no-preserve-root"

Da ist dein System danach auch komplett kaputt. Das ist aber keine Sicherheitsluecke oder "billig", sondern normal, dass du mit entsprechenden Rechten viel Chaos anstellen kannst.
 
  • Gefällt mir
Reaktionen: .Snoopy., LukS, Benji21 und 16 andere
Hmm, destiny2 - war da nicht irgendetwas mit einer CPU Instruktion (RDRAND?), die nicht korrekt funktionierte und dadurch das Spiel zum Absturz brachte? Wenn ja, dann wird dieser Treiber wohl als Workaround verwendet - es war eventell schneller, diesen über Windows Update zu verteilen, als zu warten, bis neuer Microcode durch die Mainboardhersteller per Bios ausgerollt wird.
 
  • Gefällt mir
Reaktionen: Tanzmusikus und Celinna
Naja Performance Tuning ist per se nicht schlecht...
Gibt ja einige CPU Funktionen die sich auf so manche spiele negativ auswirken.
Und die ryzen 1000,2000 und 3000er hatten durch das chiplet Design ihre Kompatibilitätsproblemchen
Bei ryzen 5000 scheinen diese ja mittlerweile behoben zu sein

Einzig wie dies geschieht ist n bisschen fragwürdig... Andererseits würde es mich nicht wundern wenn Intel hier ähnlich agiert.
 
@Blackfirehawk die Performanceprobleme kamen vom Windows Scheduler, der nicht wusste, wie er die Threads eines Programmes aufteilen sollte, um die meiste Leistung (=bestimmte Threads teilen dieselbe L3 Cacheslice) rauszukitzeln. Als Workaround gab es dann "CPPC Preferred Cores". Ryzen 5000 hat das anders gelöst, indem man nun 8-Kern CCXes mit einem gemeinsamen L3 Cache hat - die Problematik tritt also nur noch beim 5900X und höher auf.

Für Linux gibt es alternative Scheduler (MuQSS,PDS, >BMQ< - sehr zu empfehlen für Gamer, auch mit Intel CPU), die besser mit so einem Aufbau umgehen können.
 
  • Gefällt mir
Reaktionen: Tanzmusikus und Termy
Jan schrieb:
[...]Versteckspiel lassen dennoch aufhören.
Naja, zumindest die Wortwahl finde ich hier fragwürdig. Zum Versteckspiel gehören zwei Dinge: Eine Person, die sucht, und eine Person, die versucht nicht gefunden zu werden.
Hat AMD aktiv Massnahmen ergriffen, um diese Funktion im PCI-Treiber zu verbergen? Z.B. durch Code-Obfuscation?
Nur weil die Funktion nicht dokumentiert ist, würde ich das nicht "verstecken" nennen. Sonst würde jede Menge Software "Versteckspiel" betreiben, weil irgendwelche Entwickler-Kommandos, die per Befehlszeile zum Debugging genutzt werden können, nicht dokumentiert sind.

Ich gehe davon aus, dass AMD seine Treiber als ein Paket sieht, die CPU implementiert ja schließlich selbst PCIe und man es dort einfach unterbringen konnte.
 
  • Gefällt mir
Reaktionen: Sester, Tanzmusikus, Thorque und 6 andere
Cyberpunk fehlt in der Liste... das erklärt alles. :)

Mal im ernst... für diese 19 zum großteil technischen "gammelgames", z.B. Jurassic World Evolution?

Kann mir nur vorstellen, dass das die 19 am schlechtesten programmierten Games waren wo nichts anderes mehr geholfen hatte. Rainbow Six würd da gut dazu passen.
Einzig bei Factorio im Lategame kann ich mir vorstellen, dass es eine art Benchmark für die CPU ist.
 
  • Gefällt mir
Reaktionen: Thorque, Onkel Föhn, Termy und 2 andere
Naja, wenn es sich um die Behebung von CPU-Stabilitätsproblemen handelt, können sie diese Fixes ja schlecht im Grafiktreiber unterbringen, weil eine AMD-CPU keine AMD-GPU voraussetzt und im Bios könnte man das nur machen, wenn das immer regelmäßig upgedated werden würde, was einmal die Hersteller schon selten machen und die Anwender fast garnicht.

Da bleibt eigentlich nur noch der PCI-Treiber...der vermutlich per System immer installiert wird - was dann eigentlch sogar eine kluge Lösung wäre...
 
  • Gefällt mir
Reaktionen: Tanzmusikus, fullnewb, AssembIer und 2 andere
Klassischer Fall von "Chef ich fix das. Ist nicht schön aber funktional." . 🙃

Nix Bildzeitungs Niveau macht weiter so.
 
  • Gefällt mir
Reaktionen: Tanzmusikus, ohman, Buggi85 und 6 andere
Jan schrieb:
Umsetzung und Versteckspiel lassen dennoch aufhören.
Ist eventuell "aufhorchen" gemeint?
Ergänzung ()

onkas schrieb:
Was heutzutage eine News wert ist. Sensationell. Alleine der Titel, zur Manipulation von CPU Funktionen. Wahnsinn. Bild Zeitung Niveau
Schlecht geschlafen?
Ich finde die news durchaus interessant, wie anscheinend viele andere auch, wenn man sich den thread hier anschaut.
 
  • Gefällt mir
Reaktionen: The_Lutzifer, ohman, FlasherXXL und 8 andere
NJay schrieb:
"sudo rm -rf /* --no-preserve-root"
den unterschied habe ich mal hervorgehoben. den bsod kann man nämlich auch unprivilegiert auslösen.
 
  • Gefällt mir
Reaktionen: KingZero, fullnewb, Rage und 6 andere
Gnah schrieb:
Die Sache mit Crashen des Systems sehe ich hingegen nicht so kritisch. Wenn mir irgendwas Befehle in die Powershell schieben kann hab ich ganz andere Probleme als nen Systemabsturz.
Naja, kann man so sehen, gerade als Privatanwender... kann man aber auch anders sehen.
Für Meltdown und Spectre musste man auf dem anzugreifenden System auch erstmal Code ausführen können. Ob ich die Fehler selbst, aber auch insbesondere die Auswirkungen, die sie hatten bzw. teilweise immer noch haben, als "nicht so kritisch" einstufen würde, wär ich mir nicht so sicher.

Natürlich hast du schon ein Problem, wenn der Schädling erstmal im System sitzt. Aber ob der dir dann auf triviale Weise das System wegknipst oder nicht, ist sicher in einigen Fällen schon ein großer Unterschied.
Ich meine, für Meltdown und Spectre braucht man schon ziemlich ausgefeilte Schädlinge, um damit irgendwas verwertbares anzustellen. Da ist das hier vergleichsweise echt trollhaft einfach.
 
onkas schrieb:
Was heutzutage eine News wert ist. Sensationell. Alleine der Titel, zur Manipulation von CPU Funktionen. Wahnsinn. Bild Zeitung Niveau

Wenn es doch nicht soo sensationell ist, wieso werden entsprechende "hacks" nicht offen kommuniziert geschweige denn mal ordentlich dokumentiert?
 
Jan schrieb:
Genau. Daher haben wir auch erst einmal gewartet und können jetzt sogar direkt die korrekte Version und nicht die mit "AMD macht Ryzen in 19 Spielen über den PCI-Treiber schneller!" online bringen.

Oder: "Wenn Intel diesen AMD Trick wüsste ..." Oder wie die scheiß Headlines immer heißen.

Zum Topic: Im System passiert sehr viel über Treibermanipulationen und abfragen. Ich sehe das relativ unkritisch. Was aber gut ist, dass solche Sachen gefunden werden und so auch eine Dokumentation erzwungen werden kann - das sollte so nämlich schon sein.
 
  • Gefällt mir
Reaktionen: ohman
Das ein Großteil der Funktionen bei proprietärer Hardware und Treiber undokumentiert ist ist doch nichts neues?
Weiss nicht was der Aufschrei soll, wo hätte AMD das denn sonst unterbringen sollen um auch alle Systeme zu erreichen?
Ergänzung ()

flappes schrieb:
Wenn es doch nicht soo sensationell ist, wieso werden entsprechende "hacks" nicht offen kommuniziert geschweige denn mal ordentlich dokumentiert?
Wenn du saubere Dokumentation willst musst du aus der Windows/proprietäre Treiber-Ecke raus...
Und selbst dann hast du z.b. unter Linux immernoch den Blob-Microcode und die ganze undokumentierte Geschichte, was die CPU noch so intern alles macht...
Ergänzung ()

Hitman145 schrieb:
Bei den Hashes handelt es sich anscheinend um die Executables von folgenden Spielen (2 fehlen noch):

[...]

Die Liste sieht für mich aber auch nach top Kandidaten für ein "Programme, die sich nicht an Standards (Win-APIs etc) halten, evtl nur auf Intel getestet wurden und dann auf AMD für Probleme sorgen" aus.
Damit sind ja auch die Wine-Entwickler ständig am Kämpfen, wenn Spiele an der offiziellen Windows-API vorbei ihr eigenes "Voodoo" treiben...
 
  • Gefällt mir
Reaktionen: Tanzmusikus, fullnewb, Kalsarikännit und eine weitere Person
NJay schrieb:
Fuer unter linux mal folgenden befehl aus:

"sudo rm -rf /* --no-preserve-root"
Nun ja, es klingt so als ob das hier vorgestellte Problem keine erhöhten Rechte benötigt...
NJay schrieb:
Das ist aber keine Sicherheitsluecke oder "billig", sondern normal,
Als root darf man unter Unix/Linux mehr oder weniger alles, als normaler User sollte man jedoch keinesfalls direkt in ein CPU-Register schreiben dürfen...
 
Ich vermute mal das es hier um diverse probleme gegangen ist z.b. rdrand im zen 2 wo destiny 2 abgestürzt ist bzw. nicht gestartet ist.

https://www.techquila.co.in/destiny-2-amd-ryzen-3000-fix/

Diese Lösung wäre dann schlicht einfacher realisierbar als regelmäßig neue Microcodes rauszuhauen ^^ und wo die Leute dann auf Ihren Mobo Hersteller x Wochen od. Monate warten müssen bis Sie dann per neuen BIOS diesen Microcode bekommen.
 
  • Gefällt mir
Reaktionen: Tanzmusikus, Celinna und Puscha
https://gpuopen.com/ryzen-performance/
hier werden suboptimale Umsetzungen in Programmen betont die zu schlechter Leistung mit SMT oder den Prefetchern führen können.
Es könnte also in den gefundenen Games, Instruktionen abschalten, SMT abschalten oder Prefetching abschalten, NUMA-binding machen oder sonstiges.

z.B. ständig wechselnde Patterns oder Offsets, die die Prefetcher immerweider dazu verleiten falsche Daten zu prefetchen weil es in Wirklichkeit kein brauchbares Pattern im Programm gibt. Dort sollte man den/die Prefetcher dann abschalten.
Diese Zeilen die in Richtung SMT zeigen:
Use Software Prefetch instructions for linked data structures experiencing cache misses
  • While in dual-thread mode, beware that too many software prefetches from one thread may evict the working set of the other thread from their shared caches.
  • However, games often suffer from SMT contention on the main or render threads during gameplay.
  • Game initialization – including decompressing assets and compiling/warming shaders – may benefit from logical processors using SMT dual-thread mode.
  • Game play may prefer physical core count using SMT single-thread mode.
 
  • Gefällt mir
Reaktionen: Tanzmusikus, Termy und [wege]mini
Manche Probleme, die von Seiten der Softwarehersteller die Hardwarehersteller ins Schwitzen bringen, kann man halt mit einem "work around" fixen.

Manche Probleme existieren, da manche Softwarehersteller gerne ihre Software auf Produkte anderer Hardwarehersteller "optimieren".

Guter Pfusch ist keine schlechte Arbeit, hat schon der Opa gesagt :evillol:

Gerade bei den genannten Titeln und den Herstellern dieser Software (EA z.B.) würde ich auch lieber einen undokumentierten Pfusch machen als den Hersteller zu bitten, sich an generelle Standards zu halten. :heilig:

Ein gewisses "Geschmäckle" bleibt natürlich erhalten und den schwarzen Peter darf jetzt jeder, jedem nach belieben zuschieben.

Wer irgend ein Problem mit "schwarzer" Peter hat, bitte PN an mich, das gehört nicht in ein Technikforum.

mfg
 
  • Gefällt mir
Reaktionen: Tanzmusikus, AssembIer, Brati23 und eine weitere Person
Zurück
Oben