Login
Newsletter
Werbung

Thema: Mageia 7.1 patcht Boot-Problem bei AMD Ryzen 3000 CPUs

13 Kommentar(e) || Alle anzeigen ||  RSS || Kommentieren
Kommentare von Lesern spiegeln nicht unbedingt die Meinung der Redaktion wider.
1
Von kamome umidori am Mi, 17. Juli 2019 um 13:36 #

> Ryzen-Generation einer weiteren Regression unterlag und AMD es versäumte, die neuen CPUs auf aktuellen Distributionen aus diesem Jahr zu testen.

Kann ja mal passieren? … Nein!
Wer hätte auch gedacht, dass manche Leute auf einer aktuellen CPU ein aktuelles BS installieren?!

1
Von Josef Hahn am Mi, 17. Juli 2019 um 16:39 #

Man muss eine CPU nicht explizit gegen irgendwelche Betriebssysteme testen. Man muss auch eine Webseite nicht gegen konkrete Browserimplementierungen testen. Zumindest nicht, wenn der Quatsch halbwegs schlüssig aufgesetzt ist.

Warum kann es nicht eine Spezifikation geben, an die sich beide Seite so gut halten (Ja, die Spec muss dafür auch halbwegs tauglich sein), dass die Interaktion automatisch funktioniert? Das klingt doch technisch erstmal deutlich geschickter, oder findet ihr nicht?

Natürlich gibt es in der Technik immer mal wieder die Situationen, an denen man tricksen muss. Ich kenne das als Softwareentwickler auch ein wenig aus der Praxis. Aber man bekommt den Eindruck, dass ihr (auch auf diesem Gebiet) überhaupt garnicht mehr _versucht_, es richtig zu machen... Kann das? Oder sehe ich das wieder zu schwarz?

  • 1
    Von klopskind am Mi, 17. Juli 2019 um 18:06 #

    Warum kann es nicht eine Spezifikation geben, an die sich beide Seite so gut halten (Ja, die Spec muss dafür auch halbwegs tauglich sein), dass die Interaktion automatisch funktioniert? Das klingt doch technisch erstmal deutlich geschickter, oder findet ihr nicht?
    Ja, wird doch angeblich bereits getan, jedenfalls größtenteils, oder nicht? Problem ist nur, dass entweder die Spezifikation so vage/kompliziert ist, dass eine korrekte Implementierung jener in Hardware/Microcode zur Sisyphusaufgabe wird, oder die betreffenden Hersteller Fehler machen. Da die Haupthersteller (Intel und AMD) für die Ausarbeitung der Spezifikation verantwortlich sind, fällt es in jedem Fall in deren Verantwortungsbereich, wenn am Ende Bugs auftreten.

    Vermutlich ist genau das passiert: AMD hat bei RDRAND/RDSEED geschlampt und diesen Bug produziert. Die QA hat's durchgewunken. Und nun reift das Produkt beim Kunden. Da ist es nicht verwunderlich, wenn der Bug quasi durch Zufall in der Softwareentwicklung entdeckt wird.

    Aber man bekommt den Eindruck, dass ihr (auch auf diesem Gebiet) überhaupt garnicht mehr _versucht_, es richtig zu machen... Kann das? Oder sehe ich das wieder zu schwarz?
    Im Fall von RDRAND/RDSEED seitens AMD wirkt definitiv wie Schlamperei und mangelhafter QA.

    Besonders transparent lief der Fix auch nicht ab. Warum gibt es eigentlich keine CVE dafür?

    Unabhängig davon kann ich die Implementierung der Zufallzahlengenerierung unter Verwendung von RDRAND in systemd nicht gänzlich nachvollziehen; bin aber auch Laie.

    p.s.: beste Informationsquellen, die ich auftreiben konnte... heise: AMD beseitigt Fehler des Ryzen 3000 über BIOS-Updates, systemd issue.

    • 1
      Von Josef Hahn am Mi, 17. Juli 2019 um 18:27 #

      > Ja, wird doch angeblich bereits getan, jedenfalls größtenteils, oder nicht?

      Man könnte den Eindruck bekommen, dass das nicht wirklich passiert. Natürlich gibt es eine Spezifikation irgendwo. Aber scheinbar ist sie nicht belastbar. Ansonsten müsste man nicht testen, ob bestimmte Betriebssysteme mit bestimmten OSes kompatibel sind. Nenne mich Traumtänzer. Baumkuschler. Naiver Trottel. Aber für mich erfüllt ein Standard dann ideal sein Ziel, wenn verschiedene Teilnehmer, die ihn implementieren, _automatisch_ kompatibel zueinander sind.

      > Da die Haupthersteller (Intel und AMD) für die Ausarbeitung der Spezifikation verantwortlich sind, fällt es in jedem Fall in deren Verantwortungsbereich, wenn am Ende Bugs auftreten.

      Das ist mir zu einfach. Sieht nicht die Marktwirtschaft (die ist ja immerhin hier mit verantwortlich, dass billig gepfuscht wird) auch einen Hebel für den Konsumenten vor, so etwas zu steuern? Warum versagt dieser Hebel hier?

      Wie man's auch wendet und dreht: Der Artikel schreibt "[...] und AMD es versäumte, die neuen CPUs auf aktuellen Distributionen aus diesem Jahr zu testen [...]". Und da rollen sich mir die Fußnägel hoch; aus genannten Gründen. Die Industrie soll gefälligst gescheite Standards festlegen, und die dann einfach implementieren. Und die Gegenseite implementiert auch einfach diesen Standard. Und fertig ist die Laube!

      Ich weiß, dass es im Detail Fallstricke geben kann... Aber man kann ja beim Design wenigstens ein kleines bisschen so tun, als ob man es im Hinterkopf hätte, oder? Bei solchen Formulierungen hat man den Eindruck, dass das Konzept der Standardisierung grundsätzlich unbekannt ist.

      • 1
        Von klopskind am Mi, 17. Juli 2019 um 19:51 #

        Nenne mich Traumtänzer. Baumkuschler. Naiver Trottel.
        Dazu sehe ich keinen Anlass.

        Aber für mich erfüllt ein Standard dann ideal sein Ziel, wenn verschiedene Teilnehmer, die ihn implementieren, _automatisch_ kompatibel zueinander sind.
        Welcher Standard schwebt Ihnen vor, der dieses Kriterium strikt erfüllt? Was soll "automatisch" in diesem Zusammenhang bedeuten?

        In jeder Umsetzung einer hinreichend komplizierten Spezifikation gibt es einen Fehler, würde ich behaupten.

        Sieht nicht die Marktwirtschaft (die ist ja immerhin hier mit verantwortlich, dass billig gepfuscht wird) auch einen Hebel für den Konsumenten vor, so etwas zu steuern? Warum versagt dieser Hebel hier?
        Meinen Sie bspw. Gewährleistung oder Garantie? Ich vermute, dass die Hersteller sich diesbezüglich juristisch abgesichert haben (z.B. Produktbeschreibungen vage und mit Vorbehalten formulieren). Intel hat aber spätestens nach dem Debakel um den FDIV-Bug juristische Konsequenzen gezogen, sodass heute keine Umtausche oder Entschädigungen mehr stattfinden - soweit mir bekannt. Auch ggü. AMD konnten keine Ansprüche wegen des TLB-Erratum des K10 geltend gemacht werden.

        Ich vermute, dass die Hersteller für Großabnehmer auch spezielle Verträge mit stärkeren Zusagen anbieten. Für alle anderen bleibt eben nur der Endkundenmarkt, der sehr viel sensibler auf den Preis reagiert, sodass

        Für den Endkunden ist das natürlich nicht so optimal. Eventuell müsste man tiefer in den Klingelbeutel greifen, schließlich würden die Hersteller dabei auch ein zusätzliches Risiko tragen. Das gilt aber für viele Produktkategorien und in diversen Branchen, oder?

        Die Industrie soll gefälligst gescheite Standards festlegen, und die dann einfach implementieren. Und die Gegenseite implementiert auch einfach diesen Standard. Und fertig ist die Laube!
        Ganz so einfach ist es leider nicht. Das funktioniert nur, wenn die Standards sich nicht ändern. Aber viele Standards müssen sich weiterentwickeln, um nicht an Relevanz zu verlieren. So auch hier: RDRAND/RDSEED existieren nicht erst seit dem i368. Und das betrifft eine ganze Reihe an Befehlen.

        Es gibt ja auch teils unterschiedliche/herstellerspezifische Erweiterungen. So können sich die Hersteller voneinander abheben. Ansonsten gäbe es kaum Gründe, überhaupt verschiedene Hersteller zu haben, bzw. würde es auf ein Monopol hinauslaufen, da der Größte alle Konkurrenten schlucken würde (von Kartellauflagen abgesehen). Der x86-Duopol ist schlimm genug.

        Aber man kann ja beim Design wenigstens ein kleines bisschen so tun, als ob man es im Hinterkopf hätte, oder?
        Ich glaube, das tun die Hersteller. Jedenfalls ist für mich nicht erkennbar, dass das unternehmenspolitische oder fahrlässige Entscheidungen gewesen wären, die ursächlich zu diesem Bug geführt hätten. Es ist auch praktisch nicht verifizierbar.
        Aber bei den Herstellern sitzen auch nur (Hinter)Köpfe, die sich irren. Irren ist menschlich.

        Haben Sie durch diesen Bug etwas von Wert verloren - außer eventuell Zeit, die Sie mit dem Lesen der Meldungen/Kommentare dazu verbracht haben?

mehr ...
1
Von Sudo am Mi, 17. Juli 2019 um 17:46 #

Interessant, ein Intel Zufallszahlengenerator in einer Ryzen CPU, welcher nicht richtig funktioniert.

Kann man ja testen ob es wieder läuft: rdrand-test
Link aus Golem News

Pro-Linux
Traut euch!
Neue Nachrichten
Werbung