Leserreporter: Wer schöne Verschwörungslinks für mich hat: ab an felix-bloginput (at) fefe.de!
[zurück][ältere Posting][neuere Posting] Freitag, 21 April 2017 | Blog: 4 | No: 38323
Benutzt hier jemand Cap'n Proto?
Der Fix ist hier.
Und DAS erwischt mich ja jetzt schon hart, denn das ist seit 2006 bekannt. Ich hielt es damals für einen Compiler-Bug, aber es stellte sich dann als pure, bösartige Absicht heraus. gcc fand damals, dass wenn der Standard sagt, dass es bei Pointer-Arithmetik in wohlgeformtem Code keinen Überlauf geben darf, dass man dann auch Code, der gucken will, ob ein Überlauf stattgefunden hat — um das Programm wohlgeformt zu halten! —, wegoptimiert werden kann. Weil nicht sein kann, was nicht sein darf. Wissenschon.
Das hat ihnen damals eine Tonne Probleme beschafft und inzwischen hat gcc diese Optimierung zumindest für Zeiger zurückgenommen. Unter anderem hatten sich auch Teile von gcc selbst darauf verlassen, dass das nicht wegoptimiert wird. Das war echt ein Brüller.
Aber leider ist es formaljuristisch korrekt, was gcc macht, daher darf man diese Art von Check nicht mehr machen, sondern muss die Pointer vorher zu uintptr_t casten. Vorsicht: nicht intptr_t! Integer mit Vorzeichen haben das selbe Problem.
Was mich jetzt irritiert, ist dass diese Art von Fehler in einer Library wie Cap'n Proto passieren kann. Das ist immerhin das Nachfolgeprojekt (von dem selben Typen) von Protocol Buffers, das Google und die halbe Welt benutzt. Der Typ macht das seit vielen Jahren. Ich hätte getippt, dass der das weiß.
Aber da seht ihr mal: Der Teufel liegt im Detail. Nicht auf Libraries von irgendwelchen Quellen vertrauen, alles nochmal selber auditieren.
Oh und: Mir fiel dieser Fehler damals auf, weil ich eine Testsuite hatte, die auch Fehlerfälle geprüft hat, ob die korrekt abgefangen wurden. Wer das für Code mit Sicherheits-Implikationen (wie Parser, Bounds-Checking-Code) nicht tut, handelt fahrlässig.
[zurück]
[ältere Posting][neuere Posting]
[zurück][ältere Posting][neuere Posting] Freitag, 21 April 2017 | Blog: 4 | No: 38323
n Proto?
Benutzt hier jemand Cap'n Proto?
Der Fix ist hier.
Und DAS erwischt mich ja jetzt schon hart, denn das ist seit 2006 bekannt. Ich hielt es damals für einen Compiler-Bug, aber es stellte sich dann als pure, bösartige Absicht heraus. gcc fand damals, dass wenn der Standard sagt, dass es bei Pointer-Arithmetik in wohlgeformtem Code keinen Überlauf geben darf, dass man dann auch Code, der gucken will, ob ein Überlauf stattgefunden hat — um das Programm wohlgeformt zu halten! —, wegoptimiert werden kann. Weil nicht sein kann, was nicht sein darf. Wissenschon.
Das hat ihnen damals eine Tonne Probleme beschafft und inzwischen hat gcc diese Optimierung zumindest für Zeiger zurückgenommen. Unter anderem hatten sich auch Teile von gcc selbst darauf verlassen, dass das nicht wegoptimiert wird. Das war echt ein Brüller.
Aber leider ist es formaljuristisch korrekt, was gcc macht, daher darf man diese Art von Check nicht mehr machen, sondern muss die Pointer vorher zu uintptr_t casten. Vorsicht: nicht intptr_t! Integer mit Vorzeichen haben das selbe Problem.
Was mich jetzt irritiert, ist dass diese Art von Fehler in einer Library wie Cap'n Proto passieren kann. Das ist immerhin das Nachfolgeprojekt (von dem selben Typen) von Protocol Buffers, das Google und die halbe Welt benutzt. Der Typ macht das seit vielen Jahren. Ich hätte getippt, dass der das weiß.
Aber da seht ihr mal: Der Teufel liegt im Detail. Nicht auf Libraries von irgendwelchen Quellen vertrauen, alles nochmal selber auditieren.
Oh und: Mir fiel dieser Fehler damals auf, weil ich eine Testsuite hatte, die auch Fehlerfälle geprüft hat, ob die korrekt abgefangen wurden. Wer das für Code mit Sicherheits-Implikationen (wie Parser, Bounds-Checking-Code) nicht tut, handelt fahrlässig.
Twiter-Ticker
Fefes Latest Youtube Video Links
Der Betrieb der KraftZeitung kostet Geld. Da wir auch weiterhin unabhängig, überparteilich und ohne kommerzieller Werbung für Sie da sein wollen, sind wir auf Ihre Spende angewiesen. Vielen Dank.
