Gast0ne schrieb:
Aufrufe über einen Retry-Counter:
Code:
if (ret == SECRNG_SUPPORTED)
{
ret = SECRNG_FAILURE;
unsigned long long *lrng_val = (unsigned long long *)rng_val;
//Invoke the rdrand intrinsic function
if (_rdrand64_step(lrng_val))
ret = SECRNG_SUCCESS;
else if (retry_count > 0)
{
//Check number of retries does not exceed the max limit
retry_count = (retry_count > MAX_RETRY_COUNT)? MAX_RETRY_COUNT : retry_count;
int i;
for (i = 0; i < retry_count; i++)
{
if (_rdrand64_step(lrng_val))
{
ret = SECRNG_SUCCESS;
break;
}
}
}
}
return ret;
Die Destiny-Macher hätten das nur so abschreiben brauchen und das Problem wäre keines geworden.
Könntest du bitte eine Quelle angeben? Denn was dieser Schnipsel genau macht kann kaum beantwortet werden ohne nicht mindestens die Funktion
_rdrand64_step(lrng_val) zu kennen.
Die RND Bibliothek von AMD hab ich mir gerade gezogen, da findet grep nur eben diese Funktion nicht -.-
https://developer.amd.com/amd-aocl/rng-library/#securerng
Wenn sich bei AMD an ihre eigene Empfehlungen gehalten wird, prüft die besagte Funktion auch nur das C-Flag und wäre vom Bug ebenso betroffen wie SystemD...
0xffffffff schrieb:
Ich schlichte das Streitgespräch mal mit einer simplen Feststellung:
[...]
Beide haben etwas verkackt, dass aber Linux nicht mehr ordentlich booten konnte kreide ich persönlich ausschließlich dem "Not Invented Here"-Syndrom bzw. einem Bug von Systemd an. Da können die so viel mit dem Finger auf andere zeigen wie sie wollen.
Die Designentscheidung bei SystemD ist vollkommen valide. Zum Zeitpunkt des Bedarfs liefert der Kernel noch keinen Zufall, also benutzt man andere, zulässige Quellen. Da es bei embedded Geräten und Servern recht lang dauern kann eh der Kernel Zufall liefert ist das sogar ein recht gute Idee.
nille02 schrieb:
Das haben sie nicht ignoriert. Sie kamen in eine Endlosschleife weil sie keine gültigen uuids erstellen konnten und nicht weil die Zufallszahl nicht "gut" war. Da das Starten des Systems von den Zufallszahlen abhängig gemacht wurde, hätte man die Zahlen aber auch betrachten sollen. Dabei hätte man schnell erkannt das der Generator nicht korrekt funktioniert und den langsameren Fallback nutzen können. Wobei ich es schon schlecht finde einfach nur Zufallszahlen für UUIDs zu nutzen, da gibt es andere Verfahren die zu erstellen die sinnvoller wären.
Welche anderen Verfahren schweben dir denn vor? SystemD arbeitet massiv nebenläufig. Alles andere als "Zufall" produziert tendenziell mehr Kollissionen bzw. benötigt einen viel höheren Aufwand bei der Synchronisation der Threads.
Alles was mir einfällt steigert die Komplexität und verringert die Performance deutlich schlimmer als die Kollisionsüberprüfung die mit ZufallsIDs notwendig ist. Vor allem da die Chance für eine Kollision im Normallfall weniger als 1.000.000 : 2^128 liegen sollte.
Man hätte einen Workaround einfach einbauen können und alles wäre gut gewesen. Aber nein, sie Meckern lieber, sie seien nicht zuständig und zeigen auf AMD. Wie gesagt, bei einer einfachen Anwendung könnte ich das verschmerzen, aber bei systemd booten die Systeme nicht mehr.
Stimmt doch aber, CPU Bug ist CPU Bug und benötigt einen fix der CPU und nicht der Software.
Eben solche Aussagen (Rants) hat auch ein gewisser Linus T. verfasst, als es darum ging die ganzen Meltdown / Spectre Fixes in den Kernel einzubinden.
Jesterfox schrieb:
Das Problem ist hier das systemd die Zufallszahlen für etwas benutzt das sie an sich nicht leisten können: zur Generierung von unique IDs. Deswegen müssen sie eine weitere Zufalszahl erzeugen wenn diese sich von der vorherigen nicht unterscheidet und bei einem Zufallsgenerator der immer nur -1 liefert wird das eben blöd ;-)
UUIDs über Zufall zu generieren und eine simplen test auf Kollision zu fahren ist "best practice". Kollisionen sind selten genug, dass sie nicht als Performanceproblem gelten, der Test ist äußerst simpel und die Generierung der UUIDs auch. Allemal besser als ein Codemonster welches bei nebenläufigen Threads die Vergabe von UUIDs synchronisiert (komplexer Code und langsamer ist es in der Regel auch).
nille02 schrieb:
Nur muss man sagen das systemd den Workaround nicht eingebaut hat und Lenard jede Schuld von sich gewiesen hat und gar verteidigte warum die User nun mal ein funktionsunfähiges System haben. Debian und noch eine Distribution dessen Name ich vergessen habe hatten den Fix selber eingepflegt. Fedora und
Lennart hat ja recht, an fehlerhaft agierenden CPUs hat er keine Schuld.
Und der "Fix" den du meinst ist derart Krude, dass es beim anschauen weh tut. Sowas will man in produktivem Code auf keinen Fall haben.
