Abo
  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. Zum Login

Stellenmarkt
  1. Flughafen München GmbH, München
  2. Kommunale Datenverarbeitung Oldenburg (KDO), Oldenburg
  3. Bundesnachrichtendienst, Pullach
  4. Rational AG, Landsberg am Lech

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Spiele-Angebote
  1. (u. a. Wolfenstein: Youngblood, Days Gone, Metro Exodus, World War Z)
  2. (u. a. FIFA 19, Battlefield V, Space Huilk Tactics, Rainbow Six Siege)
  3. 2,99€
  4. (-91%) 1,10€


Haben wir etwas übersehen?

E-Mail an news@golem.de


Elektromobilität: Die Rohstoffe reichen, aber ...
Elektromobilität
Die Rohstoffe reichen, aber ...

Brennstoffzellenautos und Elektroautos sollen künftig die Autos mit Verbrennungsantrieb ersetzen und so den Straßenverkehr umweltfreundlicher machen. Dafür sind andere Rohstoffe nötig. Kritiker mahnen, dass es nicht genug davon gebe. Die Verfügbarkeit ist aber nur ein Aspekt.
Eine Analyse von Werner Pluta

  1. Himo C16 Xiaomi bringt E-Mofa mit zwei Sitzplätzen für rund 330 Euro
  2. ADAC-Test Hohe Zusatzkosten bei teuren Wallboxen möglich
  3. Elektroroller E-Scooter sollen in Berlin nicht mehr auf Gehwegen parken

OKR statt Mitarbeitergespräch: Wir müssen reden
OKR statt Mitarbeitergespräch
Wir müssen reden

Das jährliche Mitarbeitergespräch ist eines der wichtigsten Instrumente für Führungskräfte, doch es ist gerade in der IT-Branche nicht mehr unbedingt zeitgemäß. Aus dem Silicon Valley kommt eine andere Methode: OKR. Sie erfüllt die veränderten Anforderungen an Agilität und Veränderungsbereitschaft.
Von Markus Kammermeier

  1. IT-Arbeitsmarkt Jobgarantie gibt es nie
  2. IT-Fachkräftemangel Freie sind gefragt
  3. Sysadmin "Man kommt erst ins Spiel, wenn es brennt"

IT-Arbeit: Was fürs Auge
IT-Arbeit
Was fürs Auge

Notebook, Display und Smartphone sind für alle, die in der IT arbeiten, wichtige Werkzeuge. Damit man etwas mit ihnen anfangen kann, ist ein anderes Werkzeug mindestens genauso wichtig: die Augen. Wir geben Tipps, wie man auch als Freiberufler augenschonend arbeiten kann.
Von Björn König

  1. Verdeckte Leiharbeit Wenn die Firma IT-Spezialisten als Fremdpersonal einsetzt
  2. IT-Standorte Wie kann Leipzig Hypezig bleiben?
  3. IT-Fachkräftemangel Arbeit ohne Ende

  1. Nasa/DLR Design Challenge: Die Zubringerflugzeuge der Zukunft sind flexibel und öko
    Nasa/DLR Design Challenge
    Die Zubringerflugzeuge der Zukunft sind flexibel und öko

    Kaum Spielraum für Verbesserungen, aber viele Herausforderungen: Beim Bau von Flugzeugen machen Elektrifizierung und Automatisierung das Design noch wichtiger.

  2. Noch vor Cortana: Menschen werten Sprachaufnahmen seit sechs Jahren aus
    Noch vor Cortana
    Menschen werten Sprachaufnahmen seit sechs Jahren aus

    Nicht erst mit der Einführung von Cortana hat Microsoft damit begonnen, Mitschnitte des eigenen Sprachassistenten durch Mitarbeiter anzuhören. Diese Praxis gibt es bereits seit sechs Jahren, angefangen hat es mit der Sprachsteuerung Kinect in der Spielekonsole Xbox One.

  3. Starship Technologies: Roboterflotte soll Snacks auf Campussen ausliefern
    Starship Technologies
    Roboterflotte soll Snacks auf Campussen ausliefern

    Die fahrenden Lieferroboter von Starship Technologies sollen künftig in US-Universitäten Lebensmittel verteilen. Die Roboter fahren auf Bürgersteigen und haben sechs Räder.


  1. 09:02

  2. 08:32

  3. 07:57

  4. 07:21

  5. 19:42

  6. 18:31

  7. 17:49

  8. 16:42