News Radeon Adrenalin: Grafiktreiber übertaktet AMD Ryzen ungefragt über das BIOS

sikarr schrieb:
In der Form schon.
auch mit uefi-systemen konnte man sein system schon bricken -> https://www.heise.de/ct/artikel/UEFI-Linux-kann-aktuelle-Thinkpads-beschaedigen-2105920.html

generell ist es mit uefi vorgesehen, dass programme und das os mit dem uefi interagieren können. die liste der variablen kann man sich ansehen, darunter befinden sich neben sachen wie für die bootreihenfolge eben auch die für die cpu-einstellungen:

Code:
$ efivar --list | grep -i amd
79941ecd-ed36-49d0-8124-e4c31ac75cd4-AmdAcpiVar
3a997502-647a-4c82-998e-52ef9486a247-AmdSetup
a339d746-f678-49b3-9fc7-54ce0f9df226-AMD_PBS_SETUP
fe26a894-d199-47d4-8afa-070e3d54ba86-AMD_RAID

nicht nur ryzen-master oder das sdk aus dem adrenalin-package könnten da änderungen vornehmen, sondern im grunde jedes programm, dass da rankommt.
 
  • Gefällt mir
Reaktionen: sikarr
IBISXI schrieb:
Das geht ja mal überhaupt nicht.

Ein dauerhaft instabiles System durch ein Treiberupdate braucht niemand.
Ein Update passiert immer auf eigene Gefahr.
Sollte man wissen.
Zudem wartet man für gewöhnlich immer ab, bis genug Deppen, die nicht abwarten konnten, die Sicherheits und Stabilitätstest für einen abgeschlossen haben.
Es ist grundlegend ausgeschlossen, dass alle Probleme erkannt und behoben werden können.
Dazu müsste jeder Anwender mit seinem Computer an den Tests teilnehmen und dann aufwendig alles ausgewertet, geprüft und ggf. versucht werden zu beheben.
Im Prinzip passiert das ja auch so nach der Freigabe der Releaseversion.
Ich bin selbst Testperson für eine Profisoftware und habe Kontakt mit deren Support- und Entwicklerteam, auch per monatlichen Teams-Videositzungen.
Da gibt es alles, von offensichtlichen Fehlern, die andere aber einfach nicht bemerkt haben, bis hin zu sehr verzwickt und ungewöhnlich auftretenden Problemfällen, die man manchmal gar nicht oder nur sehr schwer nachvollziehen und reproduzieren kann, weil die z.B. auch nur mit bestimmten Software- und sonstigen Konfigurationen auftreten.
Ich kann euch versichern, dass die richtigen Buglisten um ein vielfaches länger sind als das, was hier bei Computerbase etc. veröffentlicht wird.
Das dient nämlich nur zur allgemeinen Information, worauf man vielleicht aufpassen sollte, wenn man sich das installieren möchte.
Ich habe wirklich respekt davor, wenn man etwas veröffentlich wird und das anscheinend wirklich rund läuft.
Wenn man wissen möchte, wie man es besser nicht macht, dann schaut mal Igors Test zur DG1 von Intel an. (kleiner Seitenhieb zum Schluss^^) ;-P
 
Dass Software auf das UEFI zugreifen (und sogar schreiben) darf, ist für mich Fortschritt und keine schlimme Sache, die es unbedingt zu unterbinden gilt.

Eine sehr gute Absicherung vorausgesetzt(!!!), kann das sehr viele Vorteile mit sich bringen. Warum sollte ich jedes mal meine Einstellungen in der UEFI UI machen, wenn ich die Einstellungen bequem von Windows aus machen kann (bessere Auflösung, weniger Probleme mit manchen Eingabegeräten, Zugriff aufs Dateisystem für Sicherungen, ...).

Ich erinnere mich noch gut daran, wie groß der Aufschrei war, als ABS für PKWs eingeführt wurde. Was? Ein "Computer" kann mein Auto abbremsen, das ist doch Wahnsinn! Heute macht "der Computer" im Auto fast alles. Sogar Flugzeuge werden von Computern geflogen.

Wie oben aber bereits gesagt, muss eine funktionierende Absicherung vorhanden sein (was ja aktuell nicht der Fall ist). Für mich heißt das, dass zumindest eine Funktion wie UAC (bei Windows) vorgeschaltet sein muss. Optimal sogar mit einer Auflistung was geändert wird (so wie es bei den meisten UEFIs ja auch der Fall ist, wenn man auf "save changes" klickt).
 
  • Gefällt mir
Reaktionen: lord_mogul
0x8100 schrieb:
generell ist es mit uefi vorgesehen, dass programme und das os mit dem uefi interagieren können.
Das wäre grundsätzlich ja auch kein Problem. Jedoch sollte es wenigstens eine Absicherung geben, die der User erst bestätigen muss. Ich finde jetzt so ein bisschen "Bla bla... könnten Schäden auftreten" in irgendeiner Treibersoftware zu wenig. Gefühlt haut einem das jedes zweite Programm um die Ohren. Bislang war es für mich immer so.. "im Bios wird es ernst". Wenn man jetzt wegen der Umstellung auf Uefi diese Sicherheit nicht mehr hat im Zweifel einfach das System platt zu machen ist das einfach nur fahrlässig. Ich denke ich werde die Tage mal ein Uefi-Passwort setzen, in der Hoffnung dass das so etwas unterbindet (wenn es das denn tut).
 
Das Thema wird viel zu sehr aufgebauscht und mehr daraus gemacht als es eigentlich ist.
Der Prozentsatz an Nutzer den das überhaupt betrifft ist verschwindend gering.
 
Creeping.Death schrieb:
Warum sollte ich jedes mal meine Einstellungen in der UEFI UI machen, wenn ich die Einstellungen bequem von Windows aus machen kann
Die Frage ist doch eher wie oft muss ich den UEFI Einstellungen machen? Bei Firmen die Flotten an PCs einrichten und verwalten müssen ist sowas ja noch in Ordnung ansonsten ist es aber nur eine weitere potenzielle Sicherheitslücke die ausgenutzt werden wird.
Creeping.Death schrieb:
Zugriff aufs Dateisystem für Sicherungen
Und genau da gehen die Probleme los, wie gesagt, wenn Bequemlichkeit über Vernunft siegt.
 
sikarr schrieb:
Die Frage ist doch eher wie oft muss ich den UEFI Einstellungen machen?
Manche sehr oft, manche gelegentlich, manche nie (Komplett-PC gekauft und nie erweitert).
sikarr schrieb:
Und genau da gehen die Probleme los, wie gesagt, wenn Bequemlichkeit über Vernunft siegt.
Ich kann ein Profil auf meinem NAS sichern und dieses auch wieder einspielen. Direkt im UEFI kann ich es auch heute schon von einem USB-Stick einspielen. Das hat nichts mit (Un-)Vernunft zu tun. Das kann dir Unmengen an Zeit sparen, wenn du an deinen RAM-Settings gearbeitet hast.

Ich finde es besser, an der Sicherheit des Prozesses zu arbeiten, als zu sagen "alles zu gefährlich - lassen wir es lieber".
 
  • Gefällt mir
Reaktionen: Spacebone
BxBender schrieb:
Zudem wartet man für gewöhnlich immer ab, bis genug Deppen, die nicht abwarten konnten, die Sicherheits und Stabilitätstest für einen abgeschlossen haben.
Und wenn alle vernünftig sind und deinen geistreichen Vorschlag befolgen, installiert niemand mehr Updates, weil jeder auf den ersten Deppen wartet.

Es werden keine Updates mehr eingespielt, riesige Sicherheitslücken überall, das Finanz-und Gesundheitswesen brechen zusammen und die Zivilisation versinkt im Chaos, nur weil sich alle an deinen komplett zu Ende gedachten Ratschlag orientiert haben.
 
Creeping.Death schrieb:
Direkt im UEFI kann ich es auch heute schon von einem USB-Stick einspielen. Das hat nichts mit (Un-)Vernunft zu tun.
Darum geht es auch nicht, aber das ist ein Prozess aus dem UEFI heraus, damit kann man leben da es eine bewusste, manuelle Handlung erfordert. Aber aus dem OS heraus über eine API bringt mehr Probleme mit sich als es löst.
Creeping.Death schrieb:
Ich finde es besser, an der Sicherheit des Prozesses zu arbeiten, als zu sagen "alles zu gefährlich - lassen wir es lieber".
Das ist ein rühmlicher Ansatz, das Problem ist aber das die Systeme immer komplexer werden und die Hersteller über all kosten optimiert arbeiten wollen/müssen. Von daher wird eben weniger Fokus auf Sicherheit gelegt und auch weniger getestet entweder aus Zeit- oder Kostengründen.
 
@sikarr
Das sind aber alles Probleme, die man lösen kann. APIs mit einer (wie auch immer gearteten) Authentifizierung zu versehen ist machbar. Vielleicht könnte man auch als Kompromiss eine Option ins UEFI einbauen "API enabled/disabled" und alle sind happy.

Ich sehe halt auch die Vorteile, die sich dadurch ergeben. Simples Beispiel: User kauft sich eine neue GPU, findet aber die Option zum Einschalten von SAM/Resizable BAR nicht (bzw. hat gar keine Ahnung was das sein soll). Der Treiber sieht, dass es im UEFI disabled ist und frägt "soll SAM/RBAR aktiviert werden?".
Manche Software verlangt, dass Virtualisierung aktiviert wird. Also warum nicht direkt über die Software aktivierbar machen?
Windows 11 hätte gerne diverse Einstellungen im UEFI um alle Voraussetzungen erfüllt zu haben (ob das jetzt sinnvoll ist oder nicht, wird an anderer Stelle diskutiert). Warum also nicht über Software genau die richtigen Einstellungen anpassen lassen?

AMD bewegt sich - zumindest mit ihren eigenen Treibern - wohl in diese Richtung. Jetzt sieht man auch, dass dies problematisch sein kann und hat die Möglichkeit es in Zukunft besser zu machen.
Dass dies Gefahren birgt ist nicht abzustreiten. Ich sehe das Glas aber lieber halb voll.
 
  • Gefällt mir
Reaktionen: Rezzer
Und dann finde den Fehler. "Nein, ich habe meine CPU nicht übertaktet" :D

sikarr schrieb:
Da sieht man mal was für ein Schwachsinn das ist wenn eine Anwendung Werte im UEFI setzten darf, das hätte es beim alten BIOS nicht gegeben.

Das UEFI sollte aus dem OS heraus nicht veränderbar sein, war schon beim Erscheinen von EFI ein heiß diskutiertes Thema. Wenn Bequemlichkeit über Vernunft siegt.
Ich halte da auch nichts von. Kann man das denn überhaupt nicht verhindern? UEFI-PW? Nichtinstallieren von SM-Bus etc?
Auch dass Grafikkarte etliches in Windows cachen, halte ich für fragwürdig, aber das ist ein anders Thema...
Und dann finde den Fehler. "Nein, ich habe meine CPU nicht übertaktet"
 
Creeping.Death schrieb:
Vielleicht könnte man auch als Kompromiss eine Option ins UEFI einbauen "API enabled/disabled" und alle sind happy.
z.B. oder einen Jumper/Dip Schalter auf dem Board, als Schreibschutz, oder man legt dem Board einen Dongle bei der als Zugriffsschlüssel dient

Creeping.Death schrieb:
Ich sehe halt auch die Vorteile, die sich dadurch ergeben.
Sehe ich auch so, doch aktuelle Umsetzungen zeigen warum nicht.
Creeping.Death schrieb:
Also warum nicht direkt über die Software aktivierbar machen?
Weil es anscheinend keinen entsprechenden Kontrollmechanismus gibt der wildes Einstellen verhindert. Entweder dürfen alle oder gar keiner, dazwischen gibts nichts.
 
  • Gefällt mir
Reaktionen: lord_mogul
zeedy schrieb:
Seltsam ich habe sowohl die Ryzen Master Software als auch den besagten Treiber aber habe keine Auffälligkeiten festgestellt. Die CPU boostet nach wie vor auf 4.65 GHz.
Hast du denn auch manuelle Einstellungen bei Treiber der Grafikkarte vorgenommen? Das reine Installiert-Sein führt ja nicht zu dem Bug, sondern erst, wenn man an den Parametern der Grafikkarte manuell etwas ändert.
Ergänzung ()

sikarr schrieb:
z.B. oder einen Jumper/Dip Schalter auf dem Board, als Schreibschutz, oder man legt dem Board einen Dongle bei der als Zugriffsschlüssel dient
Oder man macht es so, wie es bei manchem Boards schon mit dem CMOS-Reset (Button hinten bei den Anschlüssen) gemacht wird. Gibt's dann halt einen Button, den man drücken muss, damit die Änderungen durch die Software übernommen werden.
 
@mibbio Ja, sowohl undervolting als auch starke Übertaktung gehabt.
 
Eine AMD/RTG dGPU kaeme bei mir prinzipiell noch in Frage, nur gut, dass das System dadurch nicht komplett "rot" wuerde und man dann im Nachhinein davon erfaehrt und sich keine Sorgen ueber moeglicherweise problematischen Zugriff von aussen machen muss.

Eigentlich denkt man i.d.R. es sei besser alles aus einer Quellen/von einem Entwickler zu kaufen, da es i.d.R. besser abgestimmt sein koennte, aber das ist hier wohl ein gegenteiliges Beispiel (wenn es auch mehr um den nicht vom Nutzer abgesegneten oder ersichtlichen Zugriff bzgl. der Kontrolle des Rechners geht).

Ergo, ist es wohl doch ganz gut Entwickler/Hersteller zu mischen, zumal ich bspw. mit ASUS dGPU und Board vor langer Zeit schon einmal ein grosses Problem hatte und nachdem die ASUS dGPU gegen eine damalige von ELSA getauscht wurde, lief es lange Zeit gut (bis sich dann das ASUS Board irgendwann kurz nach Garantieablauf verabschiedet hat und das nachfolgende Abit Board dann einen besseren Dienst geleistet hat).
 
Zuletzt bearbeitet:
Chismon schrieb:
Eigentlich denkt man i.d.R. es sei besser alles aus einer Quellen/von einem Entwickler zu kaufen, da es i.d.R. besser abgestimmt sein koennte,
Ja das hört bzw. denkt man oft, meistens stimmt das ja auch, der Hersteller hat sich sein Ökosystem geschaffen in dem meist alles Reibungslosklappt, siehe Apple. Manchmal führt aber auch genau das zu Problemen weil hersteller evtl. Wechselwirkungen nicht absehen konnten oder wollten.
Chismon schrieb:
Ergo, ist es wohl doch ganz gut Entwickler/Hersteller zu mischen,
Hat auch vor und Nachteile, Einige NAS Hersteller mischen mit absicht die verbauten Festplatten und sonstige module um mögliche Chargenfehler zu vermeiden. Auch bei Firewalls werden oft 2 Hersteller verbaut damit sich Schadsoftware nicht einfach bei einem Bug durch beide frist.
Das alles hat natürlich auch seinen Preis z.B. bei der Anschaffung, Unterhaltung und Zeit.

Ich glaube ein allgemein gültiges Rezpt gibt es nicht, es kann heute so und morgen schon wieder anders sein. Kauf was gefällt :)
 
  • Gefällt mir
Reaktionen: Chismon
Mangels passender CPU/GPU bin ich offenbar nicht betroffen. Kann keinen Unterschied zwischen
den einzelnen Versionen feststellen. Ab und an schmiert alles mal ab, das kommt jedoch relativ selten vor.
Zieht sich aber schon ne Weile bei AMD durch, da könnten die mal rangehen.
Ansonsten soweit zufrieden.
Vom geplanten Kauf einer besseren AMD-Karte zum Jahresende hin wird mich das -Stand jetzt- nicht abhalten
 
Hi,

bei8 mir war es nach der Treiberinstallation automatisch so eingestellt wie auf dem Bild.
Bedeutet dies ich bin auch von der Übertaktung meiner Ryzen 5 CPU betroffen?
 

Anhänge

  • Unbenannt.PNG
    Unbenannt.PNG
    32,4 KB · Aufrufe: 207
tsw2 schrieb:
Hi,

bei8 mir war es nach der Treiberinstallation automatisch so eingestellt wie auf dem Bild.
Bedeutet dies ich bin auch von der Übertaktung meiner Ryzen 5 CPU betroffen?
Ich sage mal nein, deine CPU muss auf OC stehen (so zumindest bei mir)
Am besten schaust du im Bios nach.
 
Zurück
Oben