Mit den Launchreviews von Ryzen 3 3100/3100X hat AMD auch aktualisierte Informationen zum Prozessoren-Support auf AMDs Mainboard-Chipsätzen für zukünftige Ryzen-Generationen verlauten lassen. Ursprünglich ging man basierend auf einer 2017er AMD-Aussage davon aus, das alle Prozessoren des Sockels AM4 auch auf allen Mainboards dieses Sockels funktionieren würden – obwohl AMD dies im Original eigentlich nicht versprochen hatte (da geht es nur um die Benutzung des Sockels AM4 bis zum Jahr 2020 im generellen). Aber natürlich konnte man exakt dieses Verhalten zumindest erhoffen – was AMD nun aber bei den kommenden Ryzen 4000 Prozessoren auf Basis von Zen 3 jedoch nicht mehr einhalten wird. Jene bedingen ein neues Mainboard auf mindestens Niveau X570 & B550 – trotz weiterhin der Verwendung des Sockels AM4 bei Ryzen 4000 (womit natürlich nicht die Renoir-basierten Ryzen 4000 U/H/G Prozessoren gemeint sind). Angeblich liegt dabei das Problem allein in der Größe der BIOS-Bausteine bzw. das jene nicht die Daten für alle Prozessoren über mehrere Ryzen-Serien speichern können.

AMD Ryzen 1000/2000/3000/4000 Mainboard-Kompatibilität

Selbiges klang als Problem in der Vergangenheit bei älteren Mainboards schon an, es verwundert allerdings etwas, das dies für die schließlich neu aus der Taufe gehobenen B550-Mainboards noch ein wirkliches Problem sein soll – man könnte schließlich einfach größere BIOS-Bausteine verwenden, es geht hierbei um einen Bereich von wenigen Megabyte. Möglicherweise ist aber natürlich AMDs Stellung bei den Mainboard-Herstellern bei weitem nicht so gefestigt wie diejenige von Intel, welche solcherart Dinge dann einfach über Design-Richtlinien erzwingen. In der Summe wird damit zwar kein Versprechen AMDs gebrochen, aber dennoch wird AMD somit den Prozessoren-Support bisheriger Ryzen-Platinen früher beenden, als dies von den Nutzern angenommen werden durfte. Nutzer von Ryzen-Platinen mit Chipsätzen von 300er und 400er Chipsätzen werden ergo maximal auf Zen-2-basierte Prozessoren aufrüsten können, dies ergibt (von Ryzen 1000 an gerechnet) eine Mainboard-Kompatibilität über maximal drei CPU-Generationen. Dies ist leicht besser als das, was Intel üblicherweise anbietet (maximal zwei CPU-Generationen) – aber es wäre sicherlich eindrucksvoller gewesen, wenn AMD die ursprünglichen Pläne verwirklicht und eine Mainboard-Kompatibiliät über die komplette Laufzeit des Sockels AM4 und damit über vier CPU-Generationen geboten hätte.

Bei Igor's Lab hat man sich mit der technischen Seite von RTX Voice beschäftigt – und ist insbesondere der Frage nachgegangen, auf welchen Hardware-Einheiten nVidias "Nebengeräuschoptimierung" nunmehr wirklich läuft. Die letzten Benchmarks deuteten eher auf die normalen Shader-Einheiten anstatt der Tensor-Cores hin, doch Igor's Lab erbringen gemäß der eigenen, sehr ausgefeilten Benchmarks den Gegenbeweis: Unter Wolfenstein: Youngblood bricht mit einer GeForce RTX 2060 unter DLSS die Framerate mit RTX Voice sehr massiv um 30-70% (je nach Nutzungsgrad von RTX Voice) ein, ohne DLSS bewegt sich der Performanceeffekt von RTX Voice dagegen nur im Rahmen von von 1-4%. Da DLSS selber die Tensor-Kerne nutzt, behindern sich in diesem Fall DLSS und RTX Voice augenscheinlich gegenseitig – womit klar wird, das (zumindest auf RTX-Grafikkarten) RTX Voice einwandfrei auf den Tensor-Kernen läuft. Auf GTX-Karten werden dann logischerweise die normalen Shader-Einheiten in einem Fallback-Modus verwendet – dass dies vergleichsweise schnell läuft, erklären Igor's Lab mit dem alles limitierenden Power-Limit: Eine RTX-Karte mag ihre extra Tensor-Kerne haben und für RTX Voice nutzen, aber auch dafür wird elektrische Energie unter dem Power-Limit benötigt – welches nachfolgend den Shader-Einheiten fehlt. Allenfalls kann man also sagen, das die Fallback-Lösung nicht wirklich gravierend langsamer ist, die Beschränkung von RTX Voice auf RTX-Karten ergo tatsächlich reine Produktpolitik darstellt.

Golem beschäftigen sich mit der Problematik von BadUSB-Sticks, den damit möglichen Angriffen und vorhandenen Schutzmaßnahmen dagegen. Als BadUSB-Gerät bezeichnet man USB-Gerätschaften, welche mehr Funktionalität enthalten als eigentlich vorgegeben wird – wie einen USB-Stick, welcher ausführbaren Code (zur Übernahme des Systems) mit bringt oder auch zusätzliche Geräte ins System einbindet, welche ein Hacker für sich nutzt. Die meisten hierzu erhältlichen Geräte bringen eine zusätzliche Tastatur ins System, auf welcher dann automatisiert (aber scheinbar durch den Nutzer selber) irgendwelche Schad-Scripts abgetippt und damit aktiviert werden. Die Einfallslücke ist die grundsätzliche Systematik heutiger Betriebssysteme, neue USB-Geräte gleich vollumfänglich mit allen Treibern zu installieren – weil das Betriebssystem nun einmal nicht erkennen kann, ob der USB-Stick mit integrierter Tastatur ohne Wissen des Nutzers über diese spezielle Zusatz-Funktionalität angesteckt wurde. Die Gegenmaßnahmen beschäftigen sich primär damit, neue USB-Gerätschaften und insbesondere Tastaturen nur noch nach Nutzer-Bestätigung zuzulassen – was jedoch mit dem Risiko verbunden ist, die default-Tastatur ausversehen zu blockieren. Erstaunlicherweise gibt es derzeit fast nur Zusatz-Programme als Schutz vor BadUSB-Sticks, weder Schutzmaßnahmen seitens Windows oder von Antiviren-Lösungen – dabei ist jener Angriffsweg wegen der geringen Kosten der BadUSB-Sticks durchaus ernst zu nehmen.