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

Zufallszahlen aus einer Quelle sind

  1. Thema

Neues Thema Ansicht wechseln


  1. Zufallszahlen aus einer Quelle sind

    Autor: m4mpf 09.07.19 - 16:03

    ... immer eine blöde Idee, denn sie könnten immer korrumpiert sein.

    Und sowas wie systemd sollte IMHO etwas 'robuster' implementiert sein. Immerhin ist auch -1 und 0 eine Zufallszahl, oder nicht? Auch zehnmal hintereinander, wenn's sein muss.

    Ergo: systemd ist schuld an seinen eigenen "Abstürzen".

  2. Re: Zufallszahlen aus einer Quelle sind

    Autor: Top-OR 09.07.19 - 16:10

    Ich stimme.

    Ich denke zwar, dass CPU Features auch funktionieren müssen und würde erwarten, dass eine solche Funktion auch eine statistisch etwas überzeugendere Zufallszahl liefert, aber an mehreren Stellen muss sich gerade systemd fragen, ob es alles richtig macht:

    1) stabile Software sollte so gebaut sein, dass auch mit "komischem Umgebungsverhalten" nicht immer sofort der Weltuntergang (Absturz) eintritt. Wenn Java-Programmierer das machen, wunderts mich ja nicht ...

    2) Eine Zufallszahl nur von der CPU zu holen und dann zu hoffen, dass es eine "statistisch saubere Zufallszahl" (möchte es mal so nennen) ist, ist irgendwie dümmlich. Nicht umsonst sammeln manche Security-Tools ihre Entropie aus ganz anderen Quellen ein ...

    3) Ja, auch -1 ist 100 hintereinander eine Zufallszahl ... wenn auch ne ziemlich "seltsame". Das das gleich zu nem Absturz führt, ist irgendwie nur halb gedacht von systemd ...

    Daher: Ja, ich denke auch - selbst Schuld!

    -----
    Verallgemeinerungen sind IMMER falsch.



    1 mal bearbeitet, zuletzt am 09.07.19 16:11 durch Top-OR.

  3. Re: Zufallszahlen aus einer Quelle sind

    Autor: nille02 09.07.19 - 16:13

    m4mpf schrieb:
    --------------------------------------------------------------------------------
    > Ergo: systemd ist schuld an seinen eigenen "Abstürzen".

    AMDs CPU verhält sich nicht so wie Dokumentiert. Aber ich bin auch der Meinung, dass der Absturz auf das systemd Konto geht. Wenn man Wiederholt die selbe Zahl bekommt, kann etwas nicht stimmen.

    Es wirft die Frage auf warum solch eine Grundlegende Funktion nicht getestet wurde. Besonders für Kryptografie ist das wichtig.



    1 mal bearbeitet, zuletzt am 09.07.19 16:15 durch nille02.

  4. Re: Zufallszahlen aus einer Quelle sind

    Autor: L3G0 09.07.19 - 16:18

    Es ist schlecht das AMD hier scheinbar unter manchen Umständen die Flags falsch setzt und behauptet die Befehl wurde korrekt ausgeführt, wenn dem nicht so ist.

    Ein weiteres Kernproblem ist hier gut Erklärt:
    https://github.com/systemd/systemd/issues/11810#issuecomment-509589902

    SystemD verwendet Zufallszahlen als Quelle für sich nicht wiederholende Zahlen. Das ist eine Anforderung die Zufallszahlen nicht erfüllen können (und sollen). Aufgrund dieser Annahme ist es für SystemD überhaupt erst ein Problem, wenn 100mal hintereinander die "Zufallszahl" -1 kommt.

  5. Re: Zufallszahlen aus einer Quelle sind

    Autor: Hugo1of2 09.07.19 - 16:25

    Dokumentiert ist, wenn die CPU behauptet der Befehl war erfolgreich:
    > Non-zero random value available at time of execution.

    Über die -1 kann man ja streiten...aber ein positives Ergebnis und dann 0 im Register ablegen ist definitiv fehlerhaftes verhalten.
    Meiner meinung nach sollte Software darauf vertrauen dürfen, dass sich Hardware (vor allem die CPU) entsprechend der Dokumentation verhält. Alles andere endet ja in völlig paranoiden Algorithmen.

  6. Re: Zufallszahlen aus einer Quelle sind

    Autor: MarcusK 09.07.19 - 16:28

    nille02 schrieb:
    --------------------------------------------------------------------------------
    > m4mpf schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > Ergo: systemd ist schuld an seinen eigenen "Abstürzen".
    >
    > AMDs CPU verhält sich nicht so wie Dokumentiert. Aber ich bin auch der
    > Meinung, dass der Absturz auf das systemd Konto geht. Wenn man Wiederholt
    > die selbe Zahl bekommt, kann etwas nicht stimmen.

    oder es ist ein wirklicher Zufall? Wie soll die Software das Unterscheiden?

    Es gibt auch genug Software die sie darauf verlässt, das 1+2 = 3 ist oder soll man das auch noch mal gegenrechnen?

  7. Re: Zufallszahlen aus einer Quelle sind

    Autor: nille02 09.07.19 - 16:44

    MarcusK schrieb:
    --------------------------------------------------------------------------------
    > nille02 schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > m4mpf schrieb:
    > >
    > ---------------------------------------------------------------------------
    >
    > > -----
    > > > Ergo: systemd ist schuld an seinen eigenen "Abstürzen".
    > >
    > > AMDs CPU verhält sich nicht so wie Dokumentiert. Aber ich bin auch der
    > > Meinung, dass der Absturz auf das systemd Konto geht. Wenn man
    > Wiederholt
    > > die selbe Zahl bekommt, kann etwas nicht stimmen.
    >
    > oder es ist ein wirklicher Zufall? Wie soll die Software das
    > Unterscheiden?

    Ich hole mir mehr als eine Nummer. Wenn gleich sind, kann ich davon ausgehen das der Zahlengenerator kaputt ist.


    > Es gibt auch genug Software die sie darauf verlässt, das 1+2 = 3 ist oder
    > soll man das auch noch mal gegenrechnen?

    Wenn grundlegende Arithmetik nicht mehr läuft ist wirklich alles schon vorbei und man wäre wohl auch nicht soweit beim Boot gekommen. rdrand ist aber eine Zusatzfunktion und systemd hat ja sogar einen Fallback falls es nicht vorhanden ist.

    Stell dir vor das passiert in einer größeren Umgebung. Ein Firmwareupdate macht rdrand kaputt und plötzlich booten alle Maschinen nicht mehr. Im Kernel sind solche Probleme ja nicht neu, und ein Grund warum man rdrand nicht mehr als alleinigen Generator benutzt.

  8. Re: Zufallszahlen aus einer Quelle sind

    Autor: Top-OR 09.07.19 - 16:48

    Hugo1of2 schrieb:
    --------------------------------------------------------------------------------
    > Meiner meinung nach sollte Software darauf vertrauen dürfen, dass sich
    > Hardware (vor allem die CPU) entsprechend der Dokumentation verhält. Alles
    > andere endet ja in völlig paranoiden Algorithmen.

    Ja, da stimme ich auch zu. Das ist wohl grundsätzlich richtig.

    Praktisch gesehen, hält sich der Schaden m.M.n. jedoch in Grenzen und es gibt in maschinennahem Code eh oft schon einen Sack voller Pfade/Impls für die verschiedenen Typen von Hardware.

    Gutes Softwaredesign kann das halbwegs passabel wegkapseln, ohne dass die Algorithmen als solches unlesbar werden.

    Ich würde mir wünschen, dass Grafiktreiber/-karten mal über die Hersteller hinweg ein halbwegs einheitliches Ergebnis bei "gleichem Featureset" liefern würden, so wie CPUs.

    -----
    Verallgemeinerungen sind IMMER falsch.

  9. Re: Zufallszahlen aus einer Quelle sind

    Autor: MarcusK 09.07.19 - 16:55

    nille02 schrieb:
    --------------------------------------------------------------------------------
    > MarcusK schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > nille02 schrieb:
    > >
    > ---------------------------------------------------------------------------
    >
    > > -----
    > > > m4mpf schrieb:
    > > >
    > >
    > ---------------------------------------------------------------------------
    >
    > >
    > > > -----
    > > > > Ergo: systemd ist schuld an seinen eigenen "Abstürzen".
    > > >
    > > > AMDs CPU verhält sich nicht so wie Dokumentiert. Aber ich bin auch der
    > > > Meinung, dass der Absturz auf das systemd Konto geht. Wenn man
    > > Wiederholt
    > > > die selbe Zahl bekommt, kann etwas nicht stimmen.
    > >
    > > oder es ist ein wirklicher Zufall? Wie soll die Software das
    > > Unterscheiden?
    >
    > Ich hole mir mehr als eine Nummer. Wenn gleich sind, kann ich davon
    > ausgehen das der Zahlengenerator kaputt ist.

    davon kann man nicht ausgehen, wenn es der Zufall so will kommt 2 mal die gleiche Zahl raus und dann muss der code auch arbeiten. Wenn man das umgeht, dann schwächte man damit schon die Zufallzahlen.
    > Wenn grundlegende Arithmetik nicht mehr läuft ist wirklich alles schon
    > vorbei und man wäre wohl auch nicht soweit beim Boot gekommen. rdrand ist
    > aber eine Zusatzfunktion und systemd hat ja sogar einen Fallback falls es
    > nicht vorhanden ist.
    es ist eine CPU Befehlt wie jeder andere auch. ist AVX schon Zusatz oder normal? Wer legt fest was Zusatz ist und was normal ist?

    > Stell dir vor das passiert in einer größeren Umgebung. Ein Firmwareupdate
    > macht rdrand kaputt und plötzlich booten alle Maschinen nicht mehr.
    bei jedem Software update hat man das Risiko das etwas nicht mehr geht, aus dem Grund haben größere Umgebungen eine Testumgebung.

    > Kernel sind solche Probleme ja nicht neu, und ein Grund warum man rdrand
    > nicht mehr als alleinigen Generator benutzt.
    doch sind sie. Im Kernel wird es nur aus Sicherheitsgründen gemacht, wenn man aber nur einfache Zufallszahlen braucht man nicht verschienden Quellen.

    Ich frage mich mehr, wozu ein SystemD überhaupt Zufallszahlen braucht.

  10. Re: Zufallszahlen aus einer Quelle sind

    Autor: L3G0 09.07.19 - 16:58

    MarcusK schrieb:
    --------------------------------------------------------------------------------
    > Ich frage mich mehr, wozu ein SystemD überhaupt Zufallszahlen braucht.

    Die Antwort (bzw warum die Idee hinter den Zufallszahlen schlecht ist) habe ich oben verlinkt.

    Hier der genaue Link zur Antwort:
    https://github.com/systemd/systemd/issues/11810#issuecomment-509554660

    Edit: TLDR: Sie verwenden Zufallszahlen um UUIDs zu erzeugen, die nicht wiederholend sein sollen. Da Zufallszahlen die Anforderung "nicht wiederholend" aber nicht erfüllen, ist dies bereits eine Fehlerhafte Anforderung.



    1 mal bearbeitet, zuletzt am 09.07.19 16:59 durch L3G0.

  11. Re: Zufallszahlen aus einer Quelle // kt

    Autor: Top-OR 09.07.19 - 17:01

    // ach, was solls ...

    -----
    Verallgemeinerungen sind IMMER falsch.



    1 mal bearbeitet, zuletzt am 09.07.19 17:02 durch Top-OR.

  12. Re: Zufallszahlen aus einer Quelle sind

    Autor: Top-OR 09.07.19 - 17:03

    Ich stimmt Dir zu!

    -----
    Verallgemeinerungen sind IMMER falsch.

  13. Re: Zufallszahlen aus einer Quelle sind

    Autor: Balion 09.07.19 - 17:08

    nille02 schrieb:
    --------------------------------------------------------------------------------
    > Wenn grundlegende Arithmetik nicht mehr läuft ist wirklich alles schon
    > vorbei und man wäre wohl auch nicht soweit beim Boot gekommen. rdrand ist
    > aber eine Zusatzfunktion und systemd hat ja sogar einen Fallback falls es
    > nicht vorhanden ist.
    >
    > Stell dir vor das passiert in einer größeren Umgebung. Ein Firmwareupdate
    > macht rdrand kaputt und plötzlich booten alle Maschinen nicht mehr. Im
    > Kernel sind solche Probleme ja nicht neu, und ein Grund warum man rdrand
    > nicht mehr als alleinigen Generator benutzt.

    Amüsant, dass der Softwarehersteller dafür verteufelt wird, dass der Hardwarehersteller nicht liefert. xD

  14. Re: Zufallszahlen aus einer Quelle sind

    Autor: Ford Prefect 09.07.19 - 17:14

    Die Antwort auf deine Frage steht im Patch. https://github.com/systemd/systemd/commit/97fa202a61c040215b0f9460059d8d5621a5980a

    Wieso aufwendig kryptographisch sichere Zufallszahlen berechnen, wenn die CPU sie deutlich billiger liefert?

    Man kann den Systemd-Autoren maximal overengineering vorwerfen, aber es gibt anscheinend gute Gründe, nicht auf /dev/urandom zu setzen, was Poettering in einem Kommentar auf Github schreibt.



    1 mal bearbeitet, zuletzt am 09.07.19 17:20 durch Ford Prefect.

  15. Re: Zufallszahlen aus einer Quelle sind

    Autor: zilti 09.07.19 - 18:09

    L3G0 schrieb:
    --------------------------------------------------------------------------------
    > SystemD verwendet Zufallszahlen als Quelle für sich nicht wiederholende
    > Zahlen. Das ist eine Anforderung die Zufallszahlen nicht erfüllen können
    > (und sollen). Aufgrund dieser Annahme ist es für SystemD überhaupt erst ein
    > Problem, wenn 100mal hintereinander die "Zufallszahl" -1 kommt.

    Ich kann dir garantieren, dass Poettering das ganz anders sieht, sein Genie liegt niiiie falsch.

  16. Re: Zufallszahlen aus einer Quelle sind

    Autor: blubberer 10.07.19 - 07:41

    Genau das war ebenfalls. ein erster Gedanke. Sein Ego ist größer als das bekannte Universum.

    Ja, AMD baut hier Mist. Viele sagen, wenn zweimal die selbe Zahl kommt, kann es Zufall sein. Theoretisch auch bei 2^64. Aber deshalb würde ich mir immer einen Pool an Zahlen generieren, wenn ich eindeutige UUIDs will. Also zu mind. bei so etwas wichtigem wie systemd. Sind alle Zahlen gleich, stimmt was nicht, und Ersatz Entropie muss her. Notfalls teuer selber errechnet. Dann dauert der Boot halt 100.000 Ticks länger.

    Aber wie schon erwähnt, der Meister macht niemals Fehler.

  17. Re: Zufallszahlen aus einer Quelle sind

    Autor: a user 10.07.19 - 09:28

    Zu dem Zeitpunkt steht nur eine Quelle zur Verfügung.

  18. Re: Zufallszahlen aus einer Quelle sind

    Autor: gorsch 10.07.19 - 10:38

    > Und sowas wie systemd sollte IMHO etwas 'robuster' implementiert sein.

    Moderne CPUs haben unzählige Fehler die unter sehr seltenen Umständen auftreten. Da kann man nicht im vornherein "robuster" implementieren, man muss warten bis Probleme tatsächlich auftreten und dann Workarounds bauen. Und genau das passiert jetzt.

    > Immerhin ist auch -1 und 0 eine Zufallszahl, oder nicht? Auch zehnmal hintereinander, wenn's sein muss.

    Die Wahrscheinlichkeit, dass du von RDRAND eine -1 oder eine 0 bekommst ist 1 zu 2^256.

  19. Re: Zufallszahlen aus einer Quelle sind

    Autor: freebyte 11.07.19 - 00:16

    L3G0 schrieb:
    --------------------------------------------------------------------------------
    > Hier der genaue Link zur Antwort:
    > github.com#issuecomment-509554660

    Wenn ich das lese, möchte ich Lennart Poettering sofort den Computer wegnehmen:

    "We assign UUIDs for all service invocations, to make them recognizable in logs and stuff so that we can associate logs with their invocations properly. For UUIDs using rand() is not good enough, since the results are likely not going to be unique"

    Idiot.

    UUIDs erzeugt man zentral zb. via UTC-Datum/Zeit/Zähler - für einen erfahrenen Entwickler kaum Aufwand für sorgenfreies Arbeiten.

    fb

  1. Thema

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Zum Login

Stellenmarkt
  1. Wirecard Technologies GmbH, Aschheim bei München
  2. spectrumK GmbH, Berlin
  3. Baettr Stade GmbH über Jauss HR-Consulting GmbH & Co.KG, Stade
  4. Adecco Personaldienstleistungen GmbH, Erfurt

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Hardware-Angebote
  1. ab 369€ + Versand
  2. 349,00€
  3. 529,00€
  4. täglich neue Deals bei Alternate.de


Haben wir etwas übersehen?

E-Mail an news@golem.de


In eigener Sache: Neue Workshops zu agilem Arbeiten und Selbstmanagement
In eigener Sache
Neue Workshops zu agilem Arbeiten und Selbstmanagement

Wir haben in unserer Leserumfrage nach Wünschen für Weiterbildungsangebote gefragt. Hier ist das Ergebnis: Zwei neue Workshops widmen sich der Selbstorganisation und gängigen Fehlern beim agilen Arbeiten - natürlich extra für IT-Profis.

  1. In eigener Sache ITler und Board kommen zusammen
  2. In eigener Sache Herbsttermin für den Kubernetes-Workshop steht
  3. Golem Akademie Golem.de startet Angebote zur beruflichen Weiterbildung

In eigener Sache: Golem.de bietet Seminar zu TLS an
In eigener Sache
Golem.de bietet Seminar zu TLS an

Der Verschlüsselungsexperte und Golem.de-Redakteur Hanno Böck gibt einen Workshop zum wichtigsten Verschlüsselungsprotokoll im Netz. Am 24. und 25. September klärt er Admins, Pentester und IT-Sicherheitsexperten in Berlin über Funktionsweisen und Gefahren von TLS auf.

  1. In eigener Sache Zweiter Termin für Kubernetes-Seminar
  2. Leserumfrage Wie können wir dich unterstützen?
  3. In eigener Sache Was du schon immer über Kubernetes wissen wolltest

Mobilfunktarife fürs IoT: Die Dinge ins Internet bringen
Mobilfunktarife fürs IoT
Die Dinge ins Internet bringen

Kabellos per Mobilfunk bringt man smarte Geräte am leichtesten ins Internet der Dinge. Dafür haben deutsche Netzanbieter Angebote für Unternehmen wie auch für Privatkunden.
Von Jan Raehm

  1. Smart Lock Forscher hacken Türschlösser mit einfachen Mitteln
  2. Brickerbot 2.0 Neue Schadsoftware möchte IoT-Geräte zerstören
  3. Abus-Alarmanlage RFID-Schlüssel lassen sich klonen

  1. TLS-Zertifikat: Gesamter Internetverkehr in Kasachstan kann überwacht werden
    TLS-Zertifikat
    Gesamter Internetverkehr in Kasachstan kann überwacht werden

    In Kasachstan müssen Internetnutzer ab sofort ein spezielles TLS-Zertifikat installieren, um verschlüsselte Webseiten aufrufen zu können. Das Zertifikat ermöglicht eine staatliche Überwachung des gesamten Internetverkehrs in dem Land.

  2. Ari 458: Elektro-Lieferwagen aus Leipzig kostet knapp 14.000 Euro
    Ari 458
    Elektro-Lieferwagen aus Leipzig kostet knapp 14.000 Euro

    Ari 458 ist ein kleiner Lieferwagen mit Elektroantrieb, den der Hersteller mit Aufbauten für verschiedene Einsatzzwecke anbietet. Die Ausstattung ist einfach, dafür ist das Auto günstig.

  3. Quake: Tim Willits verlässt id Software
    Quake
    Tim Willits verlässt id Software

    Seit 24 Jahren ist Tim Willits einer der entscheidenden Macher bei id Software, nun kündigt er seinen Rückzug an. Was er künftig vorhat, will der ehemalige Leveldesigner und studierte Computerwissenschaftler erst nach der Quakecon verraten.


  1. 17:52

  2. 15:50

  3. 15:24

  4. 15:01

  5. 14:19

  6. 13:05

  7. 12:01

  8. 11:33