1. Foren
  2. Kommentare
  3. OpenSource
  4. Alle Kommentare zum Artikel
  5. › Linux-Abstürze: Fehlerhafter…

Bug bei AMD, Teilschuld bei systemd

Noch zwei unbeantwortete Fragen im Forum Hilfeschrei - Wer kann helfen?
AMD Ryzen 5 5600X USB freezes/stuttering - Noch jemand betroffen?
Mailserver bei kleinen Firmen
  1. Thema

Neues Thema Ansicht wechseln


  1. Bug bei AMD, Teilschuld bei systemd

    Autor: chithanh 09.07.19 - 21:59

    Die rdrand-Instruktion von AMD ist verbuggt, keine Frage. Und das nicht erst seit gestern, aber seit gestern in derartigem Ausmaß.

    Die systemd-Entwickler hingegen müssen sich aber den Vorwurf gefallen lassen, nicht best practices zu befolgen, und damit die nun auftretenden Probleme zumindest fahrlässig herbeigeführt zu haben, indem sie:

    1. sich auf eine einzige Quelle von Zufall verlassen haben, und dazu auf eine bekannt nicht vertrauenswürdige Instruktion,
    2. nicht die Kernel-Funktionen wie /dev/urandom verwendet haben,
    3. Kollisionen in der rdrand-Ausgabe nicht erkannt und vermieden haben (dies kann bei Zufall nicht völlig ausgeschlossen werden, siehe Geburtstagsparadoxon).

  2. Re: Bug bei AMD, Teilschuld bei systemd

    Autor: lear 09.07.19 - 23:04

    1 & 2 fallen flach, weil es nicht um Zufall geht und 3 ist die Ursache des Problems.
    systemd benutzt das hier um UUIDs zu generieren - und die Kollision hört leider nie auf.

    Natürlich sollte sowas nicht zu deadlocks oder Abstürzen führen - wenn Du zweimal hintereinander die selbe Zahl kriegst (bzw. auch für ein paar hundert Versuche ist die W'keit für eine Kollision verschwindend klein), ist der Generator scheiße - Zeit fürs failsafe.
    Solange lennart nicht anfägt zu erklären, warum das (mangelnde Robustheit) notabug ist, kriegt er von mir in diesem Fall einen pass - darauf, daß die CPU dermaßen buggy ist, muß man im Vorfeld nicht kommen - zumal es hier nicht um Systemsicherheit sondern "wir brauchen mal 'ne Zahl" geht.

  3. Re: Bug bei AMD, Teilschuld bei systemd

    Autor: mambokurt 10.07.19 - 01:08

    chithanh schrieb:
    --------------------------------------------------------------------------------
    > Die rdrand-Instruktion von AMD ist verbuggt, keine Frage. Und das nicht
    > erst seit gestern, aber seit gestern in derartigem Ausmaß.
    >
    > Die systemd-Entwickler hingegen müssen sich aber den Vorwurf gefallen
    > lassen, nicht best practices zu befolgen, und damit die nun auftretenden
    > Probleme zumindest fahrlässig herbeigeführt zu haben, indem sie:
    >
    > 1. sich auf eine einzige Quelle von Zufall verlassen haben, und dazu auf

    Die gewöhnlich genügen würde, da gehts nicht um Crypto sondern um schwer zu ratende Dateinamen.

    > eine bekannt nicht vertrauenswürdige Instruktion,

    Beziehst du dich darauf dass das Blackbox ist oder dass das im Bezug auf Suspend schon mal auftrat?

    > 2. nicht die Kernel-Funktionen wie /dev/urandom verwendet haben,

    Die sind an der Stelle noch nicht einsatzfähig.

    > 3. Kollisionen in der rdrand-Ausgabe nicht erkannt und vermieden haben
    > (dies kann bei Zufall nicht völlig ausgeschlossen werden, siehe
    > Geburtstagsparadoxon).

    Jo, da bauste nen Loop drum der das 10.000 mal macht bis nix mehr kollidiert. Hab ich selber schon so gemacht. Hilft dir halt nicht wenn dein Salt immer der selbe ist ;)

    Geburtstagsparadoxon gut und schön, aber in dem Fall hat das Jahr halt auch ein paar mehr Tage (wenn die Diskussionen so weiter gehen guck ich mir ernsthaft noch den systemd Quellcode an -.-)

  4. Re: Bug bei AMD, Teilschuld bei systemd

    Autor: brotiger 10.07.19 - 08:52

    mambokurt schrieb:
    >> 2. nicht die Kernel-Funktionen wie /dev/urandom verwendet haben,
    > Die sind an der Stelle noch nicht einsatzfähig.

    Das ist übrigens falsch. Es ist tatsächlich so, dass /dev/urandom neuerdings unter Linux blockiert, wenn noch nicht genug Entropie im Pool ist. Aber "genug" bedeutet in diesem Fall 256 Bit. Entgegen der Aussagen der systemd-Entwickler sind diese 256 Bit auch auf Embedded-Geräten und in virtuellen Maschinen schnell zusammengekommen.

    Man erkennt die Lüge an folgendem Punkt:

    Wenn systemd der Ansicht ist, dass dem Kernel die Entropie ausgegangen ist, weicht er auf RDRAND aus. Allerdings ist RDRAND nur auf x86-Systemen verfügbar, und selbst dort üblicherweise nicht in für den Embedded-Einsatz vorgesehenen CPUs. Viele Virtualisierungslösungen, auch solche mit Hardware-Virtualisierung, unterstützen RDRAND nicht. Wenn RDRAND nicht verfügbar ist, geht systemd zurück zu /dev/urandom und wartet bis es nicht mehr blockiert. Wenn das also ein echtes Problem wäre, müssten Embedded-Geräte und virtuelle Maschinen mit systemd also schon seit Jahren ständig beim Booten hängen.

    Wie häufig hört man davon? Nie.


    > Jo, da bauste nen Loop drum der das 10.000 mal macht bis nix mehr
    > kollidiert.

    Das löst das Problem ja nicht. Auch ein korrekt funktionierender Zufallszahlengenerator dürfte 10.000 Mal in Folge die gleiche Zahl liefern. Man kann z.B. auch nach dem dritten Mal einfach aufgeben und so lange die letzte Zahl um Konstante X inkrementieren bis nichts mehr kollidiert.

    Ja, ist natürlich unwahrscheinlich, aber es gibt absolut keinen Grund es nicht so zu machen. Es kostet nichts..

  5. Re: Bug bei AMD, Teilschuld bei systemd

    Autor: a user 10.07.19 - 09:20

    Mensch, informier dich doch erst einm al bevor du solche unwahrheiten schreibst.... oder frag wenigstens.

  6. Re: Bug bei AMD, Teilschuld bei systemd

    Autor: mambokurt 12.07.19 - 15:32

    brotiger schrieb:
    --------------------------------------------------------------------------------
    > mambokurt schrieb:
    > >> 2. nicht die Kernel-Funktionen wie /dev/urandom verwendet haben,
    > > Die sind an der Stelle noch nicht einsatzfähig.
    >
    > Das ist übrigens falsch. Es ist tatsächlich so, dass /dev/urandom
    > neuerdings unter Linux blockiert, wenn noch nicht genug Entropie im Pool
    > ist. Aber "genug" bedeutet in diesem Fall 256 Bit. Entgegen der Aussagen
    > der systemd-Entwickler sind diese 256 Bit auch auf Embedded-Geräten und in
    > virtuellen Maschinen schnell zusammengekommen.

    Faktisch ist das richtig, die sind an der Stelle noch nicht einsatzfähig. Wenn du wartest sind sie es. Wie lange das dauert kann ich nicht sagen, aber ich geh mal davon aus dass das schon etwas Zeit frisst, sonst würde kein Mensch da eine Weiche einbauen und rand nutzen, oder?

    > Man erkennt die Lüge an folgendem Punkt:
    >
    > Wenn systemd der Ansicht ist, dass dem Kernel die Entropie ausgegangen ist,
    > weicht er auf RDRAND aus. Allerdings ist RDRAND nur auf x86-Systemen
    > verfügbar, und selbst dort üblicherweise nicht in für den Embedded-Einsatz
    > vorgesehenen CPUs. Viele Virtualisierungslösungen, auch solche mit
    > Hardware-Virtualisierung, unterstützen RDRAND nicht. Wenn RDRAND nicht
    > verfügbar ist, geht systemd zurück zu /dev/urandom und wartet bis es nicht
    > mehr blockiert. Wenn das also ein echtes Problem wäre, müssten
    > Embedded-Geräte und virtuelle Maschinen mit systemd also schon seit Jahren
    > ständig beim Booten hängen.
    >
    > Wie häufig hört man davon? Nie.

    Ne die würden nicht hängen, die bräuchten nur länger...

    >
    > > Jo, da bauste nen Loop drum der das 10.000 mal macht bis nix mehr
    > > kollidiert.
    >
    > Das löst das Problem ja nicht. Auch ein korrekt funktionierender
    > Zufallszahlengenerator dürfte 10.000 Mal in Folge die gleiche Zahl liefern.

    Das ist möglich aber unwahrscheinlich. Kollisionen _können_ passieren und sollten abgefangen werden, aber wenn du 10.000 Kollisionen hattest bei den paar UUIDs die Linux beim Boot generiert darf es gerne sterben, dann kannst du davon ausgehen dass es die nächsten 100.000 Versuche nicht besser wird ;)

    > Man kann z.B. auch nach dem dritten Mal einfach aufgeben und so lange die
    > letzte Zahl um Konstante X inkrementieren bis nichts mehr kollidiert.

    Hätte man machen können.

    > Ja, ist natürlich unwahrscheinlich, aber es gibt absolut keinen Grund es
    > nicht so zu machen. Es kostet nichts..

    Im NACHHINEIN ist man immer schlauer. Ich persönlich hätte die Möglichkeit gar nicht in Betracht gezogen, dass rand immer wieder die selbe Zahl ausspuckt. Dass mal eine UUID kollidiert - geschenkt, kann passieren je nach Hashalgorithmus. Aber dass die CPU da so einen Bullsh zurückgibt, sorry ne, damit würde ich im Albtraum nicht rechnen.

  1. Thema

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Sie müssen ausserdem in Ihrem Account-Profil unter Forum einen Nutzernamen vergeben haben. Zum Login

Stellenmarkt
  1. Computacenter AG & Co. oHG, Erfurt
  2. Computacenter AG & Co. oHG, Kerpen, Erfurt
  3. Landeshauptstadt Stuttgart, Stuttgart
  4. Technische Universität Darmstadt, Darmstadt

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Spiele-Angebote
  1. 9,99€
  2. 28,99€


Haben wir etwas übersehen?

E-Mail an news@golem.de


The Legend of Zelda: Das Vorbild für alle Action-Adventures
The Legend of Zelda
Das Vorbild für alle Action-Adventures

The Legend of Zelda von 1986 hat das Genre geprägt. Wir haben den 8-Bit-Klassiker erneut gespielt - und waren hin- und hergerissen.
Von Benedikt Plass-Fleßenkämper


    Star-Trek-Experte: Star Trek zeigt uns eine Zukunft, die erstrebenswert ist
    Star-Trek-Experte
    "Star Trek zeigt uns eine Zukunft, die erstrebenswert ist"

    Hubert Zitt gilt als einer der größten Star-Trek-Experten Deutschlands. Er schätzt Discovery und Picard ebenso wie die alten Serien - und hat eine Sternwarte als R2-D2 bemalt.
    Ein Interview von Tobias Költzsch

    1. Star Trek Kobayashi-Maru-Test als Browserspiel verfügbar
    2. Star Trek: Lower Decks Für Trekkies die beste aktuelle Star-Trek-Serie
    3. Star Trek: Discovery 3. Staffel Zwischendurch schwer zu ertragen

    Bundestagswahl 2021: Die Rache der Uploadfilter
    Bundestagswahl 2021
    Die Rache der Uploadfilter

    Die Bundestagswahl im September scheint immer noch weit weg zu sein. Doch gerade das Thema Corona könnte die Digitalisierung in den Mittelpunkt des Wahlkampfs rücken.
    Eine Analyse von Friedhelm Greis