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: nixidee 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. Melitta Professional Coffee Solutions GmbH & Co. KG, Minden
  2. Landesbetrieb Bau und Immobilien Hessen (LBIH), Wiesbaden
  3. Camelot Management Consultants AG, Mannheim, Köln, München, Basel (Schweiz)
  4. BWI GmbH, Bonn

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Hardware-Angebote
  1. 349,00€


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

Transport Fever 2 angespielt: Wachstum ist doch nicht alles
Transport Fever 2 angespielt
Wachstum ist doch nicht alles

Wesentlich mehr Umfang, bessere Übersicht dank neuer Benutzerführung und eine Kampagne mit 18 Missionen: Das Schweizer Entwicklerstudio Urban Games hat Golem.de das Aufbauspiel Transport Fever 2 vorgestellt - bei einer Bahnfahrt.
Von Achim Fehrenbach

  1. Mordhau angespielt Die mit dem Schwertknauf zuschlagen
  2. Bus Simulator angespielt Zwischen Bodenschwelle und Haltestelle
  3. Bright Memory angespielt Brachialer PC-Shooter aus China

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