Menü
Avatar von Lokadamus
  • Lokadamus

mehr als 1000 Beiträge seit 21.01.2000

Re: War auch mein Gedanke

fr.osch schrieb am 08.07.2019 20:02:

Scheint eher ein Problem von Systemd zu sein, wenn doch ältere funktionieren, neuere aber nicht mehr, obwohl man das Problem offenbar längst kannte.

Falscher Umkehrschluss.

Der eigentlich Fehler steckt in der CPU die auf den Befehl RDAND wohl falsche Werte zurückgibt (0xFFFFFFFF). Die AMD-CPUs haben diesen Fehler wohl schon länger bekannterweise.

Das ist eine relevante Information: Der Fehler ist schon länger bekannt.

Alte systemd-Versionen holen sich ihre Zufallswerte aber ggf. nicht direkt von der CPU, sondern z.B. vom Kernel via /dev/random und der Kernel hat dort eben mehrere Zufallsquellen vermischt und/oder den Fehler der AMD-CPU grundsätzlich schon abgefangen, dann funktioniert das halt trotzdem
Wenn jetzt aber neuere systemd-Versionen den Kernel umgehen und direkt auf der CPU RDAND aufrufen (vielleicht um noch ein bisschen mehr Performance rauszukitzeln) aber den AMD-Fehler nicht explizit abfangen, dann gehts mit der neuen systemd-Version halt nicht mehr.

Richtig.

Der eigentliche Fehler liegt dann aber halt trotzdem noch bei der CPU. Ob jetzt hart verdrahtet in der CPU, oder evtl. per Microcodeupdate doch noch fixbar, steht wiederrum auf einem anderen Blatt.

Das ist zwar korrekt, aber CPU-Bugs sind Normalität, insofern ist das nicht außergewöhnlich. Es ist die Aufgabe des Kernels, die Hardware zu abstrahieren und dabei auch Bugs zu maskieren bzw. zu umgehen.

Wenn solche Fehler vorhanden sind, sollte der Hersteller die Fehler korrigieren und es sollte nicht im Kernel geschehen.
Das Problem ist der Verbreitungsgrad und dass einige Hersteller auch nach Jahren nicht reagieren.

Was der Befehl machen soll, ist klar definiert.
https://en.wikipedia.org/wiki/RdRand

Man kann sich die Bugs dann auch mal anschauen, der Kernel sagt an, was er alles gefunden hat: "Add bug flags to /proc/cpuinfo"

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/arch/x86/kernel/cpu/proc.c?id=80a208bd3948aceddf0429bd9f9b4cd858d526df

Der Kernel wird solche Bugs dann durch entsprechenden Code adressieren.

Das ist natürlich nicht optimal, denn in einer idealen Welt gäbe es keine Bugs in der Hardware, aber in einer idealen Welt gäbe es ja auch keine Bugs in Software, und wir alle wissen, dass eine ideale Welt nichts als langweilig wäre ;-)

Man sollte halt grundsätzlich nicht den eigentlichen Fehler mit einem Zwischenlayer verwechseln, der den bekannten Fehler ggf. korrigiert. Der Fehler ist dadurch nicht behoben.

Man sollte einfach gute Software schreiben. Software sollte nur dann direkt auf die Hardware zugreifen, wenn das unbedingt erforderlich ist - das sehe ich jetzt bei diesem Problem nicht.

Ansonsten ist der korrekte Weg über den Kernel, der entsprechende Funktionen bereitstellt, was auch in viele Betriebsmodi eine Rolle spielt, z. B. bei Virtualisierung. Das gilt natürlich besonders für Zufallszahlen, die wesentlich zufälliger werden, wenn nicht nur die CPU abgefragt wird, sondern weitere Hardware oder Herkunftsorte einbezogen werden.

Wenn Software dann aber doch direkt auf die Hardware zugreift, muss sie auch mit entsprechenden dabei entstehenden Problemen umgehen können. Das wird, wenn die möglichen Hardwareplattformen vielzählig sind, natürlich entsprechend komplex. Selbstverständlich sollten dann alle bekannten Bugs berücksichtigt werden.

fr.osch

Bewerten
- +
Anzeige