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

Grundlagen der sicheren Programmierung ignoriert oder vergessen?

  1. Thema
  1. 1
  2. 2

Neues Thema Ansicht wechseln


  1. Grundlagen der sicheren Programmierung ignoriert oder vergessen?

    Autor: Akusai 09.07.19 - 16:41

    Wenn ich mir das Snippet des verlinkten Codes ansehe - dann sehe ich irgendwie keine Fehlerbearbeitung.
    Und AMD selbst hat dazu in ihrem "AMD64 Architecture Programmer's Manual" ( https://www.amd.com/system/files/TechDocs/24594.pdf ) auf Seite 287 (bzw. 323 im Firefox PDF viewer) folgendes geschrieben:
    Software must test the state of the CFflag prior to using the value returned in the destination register to determine if the value is valid. If the returned value is invalid, software must execute the instruction again. Software should implement a retry limit to ensure forward progress of code.
    Das heißt, die AMD Ingenieure waren so genial und wussten, dass sie nicht jederzeit und sofort genügend Entropie haben, um eine wahrlich zufällige Zahl zu erzeugen. Und jeder der sich mit Zufallszahlen und Computern bisschen tiefer auseinandergesetzt hat sollte auch wissen, dass kurz nach dem Neustart eines Rechners dieser noch nicht genügend Entropie hat um wahre Zufallszahlen zu erzeugen.
    Daher muss ich sagen: für mich hat AMD alles richtig gemacht - und es braucht kein Update des Microcodes.

  2. Re: Grundlagen der sicheren Programmierung ignoriert oder vergessen?

    Autor: MarcusK 09.07.19 - 16:44

    Akusai schrieb:
    --------------------------------------------------------------------------------
    > Wenn ich mir das Snippet des verlinkten Codes ansehe - dann sehe ich
    > irgendwie keine Fehlerbearbeitung.

    was ist das?

    if (!success)
    return -EAGAIN;

    sie machen doch genau das, was in der Doku steht, die CFlags auswerten.

  3. Re: Grundlagen der sicheren Programmierung ignoriert oder vergessen?

    Autor: nille02 09.07.19 - 16:49

    Wie Markus schon sagte, laut Dokumentation haben sie alles richtig gemacht. Man kann ihnen höchstens vorwerfen der CPU vertraut zu haben.

  4. Re: Grundlagen der sicheren Programmierung ignoriert oder vergessen?

    Autor: L3G0 09.07.19 - 16:55

    Dieser Part "Software should implement a retry limit to ensure forward progress of code." fehlt beim
    if (!success)
    return -EAGAIN;

  5. Re: Grundlagen der sicheren Programmierung ignoriert oder vergessen?

    Autor: nille02 09.07.19 - 17:04

    L3G0 schrieb:
    --------------------------------------------------------------------------------
    > Dieser Part "Software should implement a retry limit to ensure forward
    > progress of code." fehlt beim
    > if (!success)
    > return -EAGAIN;

    Das Problem ist, die CPU sagt dir, dass es ein Erfolg war und gibt dir dennoch stets die -1.

  6. Re: Grundlagen der sicheren Programmierung ignoriert oder vergessen?

    Autor: L3G0 09.07.19 - 17:08

    nille02 schrieb:
    --------------------------------------------------------------------------------
    > Das Problem ist, die CPU sagt dir, dass es ein Erfolg war und gibt dir
    > dennoch stets die -1.

    In der tat, dass ist das Hauptproblem mit dem Ryzen 3000, aber nicht die Ursache für die SystemD Probleme. Sie Verwenden Zufallszahlen als Quelle um nicht wiederholende Zahlen zu erhalten, eine Anforderung die sie nicht erfüllen können. (Quelle: https://github.com/systemd/systemd/issues/11810#issuecomment-509554660) Aus diesem Grund ist es ein Problem wenn mehrmals die "Zufallszahl" -1 kommt.

    Das Ändert nichts daran, das AMD hier einen Bug mit dem Status hat.



    1 mal bearbeitet, zuletzt am 09.07.19 17:09 durch L3G0.

  7. Re: Grundlagen der sicheren Programmierung ignoriert oder vergessen?

    Autor: Hotohori 09.07.19 - 19:08

    Wenn ich das korrekt verstehe ist das Problem doch, dass endlos immer wieder die Zahl -1 zurück gegeben wird. Endlos weil deswegen eben immer wieder eine neue Zahl abgefragt wird, welche eben immer -1 ist. Also eine Endlos Schleife, weil eine Funktion nicht so arbeitet wie man es erwartet.

    Ich kenne es aber so, dass man sich als Programmierer darauf verlassen können muss, dass Funktionen richtig arbeiten und dazu gehört es eben, dass wenn es zu einem Fehler kommt mitzuteilen, dass ein Fehler vorliegt. Wenn mir die Funktion dann aber sagt "alles korrekt" obwohl ein Fehler auftrat, dann ist das so definitiv keine korrekte Funktionsweise und einem Software Entwickler kann man dafür absolut null die Schuld geben, er muss sich darauf verlassen können das eine Funktion richtig arbeitet.

    Ansonsten müsste ein Programmierer absolut jeder Funktion misstrauen und ein Workaround einbauen, das wäre purer Irrsinn.

  8. Re: Grundlagen der sicheren Programmierung ignoriert oder vergessen?

    Autor: brotiger 09.07.19 - 19:15

    nille02 schrieb:
    --------------------------------------------------------------------------------
    > Wie Markus schon sagte, laut Dokumentation haben sie alles richtig gemacht.

    Nein. RDRAND ist eine Zufallsfunktion und darf daher auch bei korrekter Funktion mehr als ein Mal hintereinander (!) den gleichen Wert zurückliefern.

    Ja, das ist nicht sehr wahrscheinlich, aber für den Fall hätten die systemd-Entwickler so oder so vorsorgen müssen. Sonst gäbe es auch bei vollkommen korrekt arbeitenden Systemen eine gewisse Wahrscheinlichkeit, dass das System plötzlich nicht bootet.

    Und hätten sie das getan, wäre die fehlerhafte RDRAND-Implementierung in den neuen Ryzen-CPUs halt gleich mit abgedeckt gewesen.

  9. Re: Grundlagen der sicheren Programmierung ignoriert oder vergessen?

    Autor: Gallantus 09.07.19 - 19:37

    brotiger schrieb:
    --------------------------------------------------------------------------------
    > nille02 schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > Wie Markus schon sagte, laut Dokumentation haben sie alles richtig
    > gemacht.
    >
    > Nein. RDRAND ist eine Zufallsfunktion und darf daher auch bei korrekter
    > Funktion mehr als ein Mal hintereinander (!) den gleichen Wert
    > zurückliefern.
    >
    > Ja, das ist nicht sehr wahrscheinlich, aber für den Fall hätten die
    > systemd-Entwickler so oder so vorsorgen müssen. Sonst gäbe es auch bei
    > vollkommen korrekt arbeitenden Systemen eine gewisse Wahrscheinlichkeit,
    > dass das System plötzlich nicht bootet.
    >
    > Und hätten sie das getan, wäre die fehlerhafte RDRAND-Implementierung in
    > den neuen Ryzen-CPUs halt gleich mit abgedeckt gewesen.


    Das die selbe Zahl zweimal hintereinander ausgewählt wird liegt bei 2^64. Es wäre wahrscheinlicher 1 Jahr lang jede Woche 6 richtige im Lotto zu haben. Auch bin ich mir nicht sicher, ob es schon reichen würde, dass die selbe Zahl zweimal hintereinander ausgewählt wird oder sie sogar für einen Absturz 10 mal hintereinander ausgewählt werden müsste, was zu einer Wahrscheinlichkeit von (2^64)^9 führen würde, was absolut lächerlich hoch wäre. Theoretisch möglich, aber doch sehr sehr sehr sehr unwahrscheinlich. Solche Wahrscheinlichkeiten sind wirklich vernachlässigbar, da nicht einmal wirklich ein Schaden entsteht, wenn der Computer/Server einmal nicht beim ersten Versuch startet und nochmal neu gestartet werden muss.

  10. Re: Grundlagen der sicheren Programmierung ignoriert oder vergessen?

    Autor: nille02 09.07.19 - 19:40

    brotiger schrieb:
    --------------------------------------------------------------------------------
    > nille02 schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > Wie Markus schon sagte, laut Dokumentation haben sie alles richtig
    > gemacht.
    >
    > Nein. RDRAND ist eine Zufallsfunktion und darf daher auch bei korrekter
    > Funktion mehr als ein Mal hintereinander (!) den gleichen Wert
    > zurückliefern.

    Richtig, aber das alleine wäre ja nicht AMDs Problem. Laut Dokumentation bekommst du über das Carry flag mitgeteilt ob eine gültige Zufallszahl generiert wurde oder nicht. Sie Meldet den Erfolg und gibt dennoch jedes mal nur -1 zurück.

    > Ja, das ist nicht sehr wahrscheinlich, aber für den Fall hätten die
    > systemd-Entwickler so oder so vorsorgen müssen. Sonst gäbe es auch bei
    > vollkommen korrekt arbeitenden Systemen eine gewisse Wahrscheinlichkeit,
    > dass das System plötzlich nicht bootet.
    >
    > Und hätten sie das getan, wäre die fehlerhafte RDRAND-Implementierung in
    > den neuen Ryzen-CPUs halt gleich mit abgedeckt gewesen.

    Was sie mit dem Ergebnis machen, ist ja erst mal unabhängig von der rdrand Funktion an sich. Ich weiß nicht wie sie ihre UUIDs dann letztlich generieren, ob sie dafür mehrere Zufallszahlen nutzen oder nur eine.
    Zum Beispiel wie hoch sind die Chancen das 10 mal die selbe Zufallszahl zurück gegeben wird? Wenn sie z.B. 10 Zahlen für eine UUID nutzen, könnte auch das noch keine Auswirkungen haben, wenn denn dann bald mal andere Zahlen kommen für die weiteren UUIDs.

    Ich bin übrigens auch der Meinung das systemd hier Mist gebaut hat, aber AMD ist alles andere als Unschuldig und sie müssen den Fehler beheben.

  11. Re: Grundlagen der sicheren Programmierung ignoriert oder vergessen?

    Autor: MarcusK 09.07.19 - 19:58

    Gallantus schrieb:
    > Solche Wahrscheinlichkeiten sind wirklich vernachlässigbar, da nicht einmal
    > wirklich ein Schaden entsteht, wenn der Computer/Server einmal nicht beim
    > ersten Versuch startet und nochmal neu gestartet werden muss.

    sie wird auch im normen Betrieb gebraucht, es kann also durchaus passieren das das System einfach abstützt.

    Ich hätte vermutlich einfach einmalig eine Zufallszahl genommen (oder die Systemzeit) und bei jedem Aufruf + 1 gerechnet. Dann hätte man aufsteigende UUID die eindeutig sind. Das sie immer und global eindeutig sein müssen, war denke ich nicht gefordert. Sie müssen nur zwischen Boot und Shutdown eindeutig sein.

  12. Re: Grundlagen der sicheren Programmierung ignoriert oder vergessen?

    Autor: brotiger 09.07.19 - 20:36

    Gallantus schrieb:
    --------------------------------------------------------------------------------

    > Solche Wahrscheinlichkeiten sind wirklich vernachlässigbar, da nicht einmal
    > wirklich ein Schaden entsteht, wenn der Computer/Server einmal nicht beim
    > ersten Versuch startet und nochmal neu gestartet werden muss.

    ...man kann sich aber auch einfach wie ein Profi benehmen und es gleich richtig machen. systemd ist ein kritisches Stück Infrastruktur und läuft nicht nur auf Desktops.

  13. Re: Grundlagen der sicheren Programmierung ignoriert oder vergessen?

    Autor: brotiger 09.07.19 - 20:38

    nille02 schrieb:
    --------------------------------------------------------------------------------

    > Ich weiß nicht wie sie ihre UUIDs dann letztlich
    > generieren, ob sie dafür mehrere Zufallszahlen nutzen oder nur eine.

    Wenn sie mehrere nutzen würden, würden nicht 100% der Bootversuche schiefgehen.

  14. Re: Grundlagen der sicheren Programmierung ignoriert oder vergessen?

    Autor: Der braune Lurch 09.07.19 - 20:40

    > Software must test the state of the CFflag prior to using the value returned in the destination register to determine if the value is valid. If the returned value is invalid, software must execute the instruction again. Software should implement a retry limit to ensure forward progress of code.

    Diese Diskussion habe ich auch schon bei Heise gelesen.

    Aus meiner Sicht macht systemd hier nichts falsch, es handelt sich um technisches bzw. Vertragsenglisch. Was systemd machen MUSS:

    - CFflag prüfen (tut es)
    - falls geliefertes Zufallsergebnis invalid ist (hier auch zu beachten, dass die Doku eben nicht explizit sagt, dass die Prüfung des Flags ausreicht), erneut abfragen, auch das tut systemd

    > Software should implement a retry limit to ensure forward progress of code

    Kann gemacht werden, sonst stünde dort shall oder must.

    ------------------------------
    Der Molch macht's.
    ------------------------------

  15. Re: Grundlagen der sicheren Programmierung ignoriert oder vergessen?

    Autor: nille02 09.07.19 - 20:49

    brotiger schrieb:
    --------------------------------------------------------------------------------
    > Wenn sie mehrere nutzen würden, würden nicht 100% der Bootversuche
    > schiefgehen.

    Da 100% der Zufallszahlen, durch den Bug hier, -1 (‭ 0xFFFFFFFFFFFFFFFF‬ ) ist, schon. Anscheint wird ja nichts anderes benutzt. Keinen Timestamp oder einfachen hochzählen.

  16. Re: Grundlagen der sicheren Programmierung ignoriert oder vergessen?

    Autor: Quantium40 09.07.19 - 21:55

    nille02 schrieb:
    > Das Problem ist, die CPU sagt dir, dass es ein Erfolg war und gibt dir
    > dennoch stets die -1.

    Das ist doch kein Problem. Auch ein Würfel kann zufälligerweise immer die 6 als Zufallszahl erwürfeln. Wenn man stets unterschiedliche Zufallszahlen braucht, muss man das ggf. durch eine nachgeordnete Funktion sicherstellen, die die vorher bereits generierten Werte mit einbezieht oder aber bei n aufeinanderfolgenden gleichen Werten zu einem Abbruch führt oder eine andere Entropiequelle nutzt.

  17. Re: Grundlagen der sicheren Programmierung ignoriert oder vergessen?

    Autor: Quantium40 09.07.19 - 22:09

    Gallantus schrieb:
    > Das die selbe Zahl zweimal hintereinander ausgewählt wird liegt bei 2^64.

    Und doch kann es vorkommen und offensichtlich fatale Auswirkungen haben.

  18. Re: Grundlagen der sicheren Programmierung ignoriert oder vergessen?

    Autor: mambokurt 10.07.19 - 01:01

    brotiger schrieb:
    --------------------------------------------------------------------------------
    > nille02 schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > Wie Markus schon sagte, laut Dokumentation haben sie alles richtig
    > gemacht.
    >
    > Nein. RDRAND ist eine Zufallsfunktion und darf daher auch bei korrekter
    > Funktion mehr als ein Mal hintereinander (!) den gleichen Wert
    > zurückliefern.

    Und? Lass sie doch. Das wird schon abgefangen sein bei systemd. Hilft aber einen Dreck wenn die den Loop 'Zufallszahl holen (immer -1)- flag prüfen - flag in Ordnung - uuid generieren und checken - gibts schon - von vorn' fahren und irgendwann nach 10000 Durchläufen abbrechen wenns nicht geklappt hat.

    > Ja, das ist nicht sehr wahrscheinlich, aber für den Fall hätten die
    > systemd-Entwickler so oder so vorsorgen müssen. Sonst gäbe es auch bei
    > vollkommen korrekt arbeitenden Systemen eine gewisse Wahrscheinlichkeit,
    > dass das System plötzlich nicht bootet.

    Können sie ja gemacht haben, siehe Loop oben. Weiter hätte ich auch nicht vorgesorgt wenn der besch*eidene* CFlag mir sagt dass alles bestens ist.

    > Und hätten sie das getan, wäre die fehlerhafte RDRAND-Implementierung in
    > den neuen Ryzen-CPUs halt gleich mit abgedeckt gewesen.

    Nö, siehe meinen Loop. Klar kann man dann wenn die 10000 Kollisionen durch sind einfach einen Fallback machen, aber das sind völlig akademische Diskussionen im Nachhinein. Ich betrachte mich als relativ vorsichtigen Programmierer aber damit dass mir die Cpu -1 als Zufallswert zurückwirft und mich frech angrinst dabei, ob ich das abfangen würde wüsste ich echt nicht...

  19. Re: Grundlagen der sicheren Programmierung ignoriert oder vergessen?

    Autor: blubberer 10.07.19 - 07:31

    Als vorsichtiger Coder wirst Du Dich aber nicht nur auf einen Entropiepool verlassen. Normalerweise. Gerade Entropie sollte immer mind. 1-2 Fallbacks haben, da es eben kritisch ist bzw sein kann.

  20. Re: Grundlagen der sicheren Programmierung ignoriert oder vergessen?

    Autor: Anonymer Nutzer 10.07.19 - 07:37

    Quantium40 schrieb:
    --------------------------------------------------------------------------------
    > Das ist doch kein Problem. Auch ein Würfel kann zufälligerweise immer die 6
    > als Zufallszahl erwürfeln. Wenn man stets unterschiedliche Zufallszahlen
    > braucht, muss man das ggf. durch eine nachgeordnete Funktion sicherstellen,
    > die die vorher bereits generierten Werte mit einbezieht oder aber bei n
    > aufeinanderfolgenden gleichen Werten zu einem Abbruch führt oder eine
    > andere Entropiequelle nutzt.
    Immer bei unendlichen Versuchen? Eher nicht. Wenn man sich auf Basics nicht verlassen kann, dann ist es eben schlecht. Wie soll den der Entwickler alle potentiellen Hardwarefehler abfangen? Wie komplex soll denn bitte Software werden?

    AMD hat es verkackt, in diesem Fall kann man immerhin die Software ggf. anpassen um den Fehler auszugleichen.

  1. Thema
  1. 1
  2. 2

Neues Thema Ansicht wechseln


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

Stellenmarkt
  1. Bayerische Versorgungskammer, München
  2. Infokom GmbH, Karlsruhe
  3. Taunus Sparkasse, Bad Homburg vor der Höhe
  4. AWO Kreisverband Mittelfranken-Süd e.V., Schwabach

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Hardware-Angebote
  1. mit Gutschein: NBBGRATISH10


Haben wir etwas übersehen?

E-Mail an news@golem.de


Whatsapp: Krankschreibung auf Knopfdruck
Whatsapp
Krankschreibung auf Knopfdruck

Ein Hamburger Gründer verkauft Arbeitsunfähigkeitsbescheinigungen per Whatsapp. Ist das rechtens? Ärztevertreter warnen vor den Folgen.
Von Miriam Apke

  1. Medizin Schadsoftware legt Krankenhäuser lahm
  2. Medizin Sicherheitslücken in Beatmungsgeräten
  3. Gesundheitsdaten Gesundheitsapps werden beliebter, trotz Datenschutzbedenken

IT-Arbeitsmarkt: Jobgarantie gibt es nie
IT-Arbeitsmarkt
Jobgarantie gibt es nie

Deutsche Unternehmen stellen weniger ein und entlassen mehr. Es ist zwar Jammern auf hohem Niveau, aber Fakt ist: Die Konjunktur lässt nach, was Arbeitsplätze gefährdet. Auch die von IT-Experten, die überall gesucht werden?
Ein Bericht von Peter Ilg

  1. IT-Standorte Wie kann Leipzig Hypezig bleiben?
  2. IT-Fachkräftemangel Arbeit ohne Ende
  3. IT-Forensikerin Beweise sichern im Faradayschen Käfig

Galaxy Note 10 im Hands on: Samsungs Stift-Smartphone kommt in zwei Größen
Galaxy Note 10 im Hands on
Samsungs Stift-Smartphone kommt in zwei Größen

Samsung hat sein neues Android-Smartphone Galaxy Note 10 präsentiert - erstmals in zwei Versionen: Die Plus-Variante hat ein größeres Display und einen größeren Akku sowie eine zusätzliche ToF-Kamera. Günstig sind sie nicht.
Ein Hands on von Tobias Költzsch

  1. Werbung Samsung bewirbt Galaxy Note 10 auf seinen Smartphones
  2. Smartphone Samsung präsentiert Kamerasensor mit 108 Megapixeln
  3. Galaxy Note 10 Samsung korrigiert Falschinformation zum Edelstahlgehäuse

  1. 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.

  2. Verfassungsschutz: Einbruch für den Staatstrojaner
    Verfassungsschutz
    Einbruch für den Staatstrojaner

    Der Verfassungsschutz soll künftig auch Computer und Smartphones von Verdächtigen durchsuchen dürfen. Um Staatstrojaner zu installieren, sollen Wohnungseinbrüche erlaubt sein.

  3. Be emobil: Berliner Ladesäulen auf Verbrauchsabrechnung umgestellt
    Be emobil
    Berliner Ladesäulen auf Verbrauchsabrechnung umgestellt

    Der Ladenetzbetreiber Allego hat die Abrechnung der öffentlichen Ladestationen in Berlin umgestellt. Statt eines Pauschalpreises für den Ladevorgang zahlen Elektroautomobilisten in Zukunft nach geladener Strommenge.


  1. 09:01

  2. 14:28

  3. 13:20

  4. 12:29

  5. 11:36

  6. 09:15

  7. 17:43

  8. 16:16