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

Bug bei AMD, Teilschuld bei systemd

  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. Hays AG, Ansbach
  2. CHECK24 Versicherungsservice GmbH, München
  3. Advantest Europe GmbH, Böblingen
  4. Haufe Group, Freiburg im Breisgau

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Top-Angebote
  1. 199,97€ inkl. Direktabzug (Vergleichspreis 249€)
  2. 119,90€ + 6,99€ Versand (Vergleichspreis 148,98€ inkl. Versand)
  3. 64,90€ inkl. Direktabzug (Vergleichspreis 81,90€)
  4. 59,99€ (Vergleichspreis 97,83€)


Haben wir etwas übersehen?

E-Mail an news@golem.de


Star Wars und Star Trek: Was The Mandalorian besser macht als Discovery
Star Wars und Star Trek
Was The Mandalorian besser macht als Discovery

Unabhängig von der Story und davon, ob man Star Trek oder Star Wars lieber mag - nach den jüngsten Staffeln wird deutlich: Discovery kann handwerklich nicht mit The Mandalorian mithalten. Achtung, Spoiler!
Ein IMHO von Tobias Költzsch

  1. Lucasfilm Games Ubisoft entwickelt Open World mit Star Wars
  2. Krieg der Sterne Star Wars spielt unter dem Logo von Lucasfilm Games
  3. Star Wars chronologisch Über 150 Stunden Krieg der Sterne

Boeing 737 Max: Neustart mit Hindernissen
Boeing 737 Max
Neustart mit Hindernissen

Die Boeing 737 ist nach dem Flugzeugabsturz in Indonesien wieder in den Schlagzeilen. Die Version Max darf seit Dezember wieder fliegen - doch Kritiker halten die Verbesserungen für unzureichend.
Ein Bericht von Friedrich List

  1. Flugzeug Boeing erhält den letzten Auftrag für den Bau der 747
  2. Boeing 737 Max Boeing-Strafverfahren gegen hohe Geldstrafe eingestellt
  3. Zunum Luftfahrt-Startup verklagt Boeing

Westküste 100: Wie die Energiewende an der Küste aussehen soll
Westküste 100
Wie die Energiewende an der Küste aussehen soll

An der Nordseeküste stehen die Windräder auch bei einer frischen Brise oft still. Besser ist, mit dem Strom Wasserstoff zu erzeugen. Das Reallabor Westküste 100 testet das.
Ein Bericht von Werner Pluta

  1. 450 MHz Energiewirtschaft gewinnt Streit um Funkfrequenzen
  2. Energiewende Statkraft baut Schwungradspeicher in Schottland