TI-Checksum (tichksum) auf 64-Bit-Systemen

[kriegaex]

Vorwort

Wieder mal zeigt sich, wie unvorteilhaft eine Diskussion über PN (private Nachrichten) doch ist. Angefangen hat alles mit einer PN von Benutzer nokia an mich, und ich machte den Fehler, danach weiter mit mehreren Benutzern über PN zu diskutieren. Das möchte ich jetzt korrigieren, damit jeder alles mitbekommt und das Thema öffentlich diskutiert werden kann.

Was bisher geschah

TI-chksum benutzt unsigned long, um eine CRC32 zu berechnen. Da die Größe von unsigned long abhängig vom verwendeten Prozessor ist, sollte stattdessen unsigned int verwendet werden, das überall 32 Bit groß ist. Derzeit wird in cs_calc_sum() "zufälliger" Speicher außerhalb von crctab gelesen.

Außerdem wurden in cs_calc_buf_sum() verschiedene Datentypen für length und size verwendet.

Aufgefallen ist es mir in ds26-15.2, aber möglicherweise sind auch die
anderen Varianten betroffen.

Den Patch findest Du hier: http://www.saftware.de/patches/TI-chksum-0.1.diff

Daraufhin bat ich um Feedback im Release-Thread. Ich zitiere nochmals:

Anfrage an alle, die ein 64-Bit-Linux zum Bauen von ds26 verwenden oder dort etwas für mich testen können und wissen, wie man einen einfachen Patch einspielt: Ich bekam einen Patch zugesandt, der tichksum für 64-Bit-Systeme fixen soll. Mangels Testsystem bitte ich um Mithilfe. Bitte alle per PN (nicht hier im Thread!) melden, bei denen folgende Sequenz eine andere Checksumme ergibt als hier angegeben und die den Fix testen wollen:

[B]$ echo "test" > xxx
$ tools/tichksum xxx[/B]
File doesn't contain the checksum, adding
Calculated checksum is [B][COLOR="Blue"]37BF48AF[/COLOR][/B]
Added successfully

Anmerkung: Bei Benutzern mit abweichender Prüfsumme sollte auch das Firmware-Flashen schief gehen, wie ich annehme.

Zwei Benutzer, RalfFriedl und frank_m24, antworteten bisher auf die Anfrage und bereichteten übereinstimmend, daß sie schon lange mit 64 bit bauen und noch nie Probleme mit der Prüfsumme hatten:

Das mit dem tichksum 64bit Problem scheint nicht generell aufzutreten. Auf meinem Gentoo Linux 64bit System (Intel Core2 Duo T7200 @ 2 GHz) stimmt die Checksum jedenfalls. (...) Ich hab auf dem System auch schon eine 14.04.33ds26-15.2 Firmware erfolgreich gebaut.

Hier wie gewünscht der Bericht zu tichksum. Ich habe den ds-mod von Anfang an auf einem 64-Bit System erstellt. (...) Bei genauerer Betrachtung ist mir aufgefallen, daß das Problem nicht die Erstellung einer Prüfsumme ist, sondern der Test der Prüfsumme.

$ echo "test" > xxx
$ tools/tichksum xxx
File doesn't contain the checksum, adding
Calculated checksum is [B]37BF48AF[/B]
Added successfully
$ tools/tichksum xxx
File doesn't contain the checksum, adding
Calculated checksum is [B]60B135B9[/B]
Added successfully
$ tools/tichksum xxx
File doesn't contain the checksum, adding
Calculated checksum is [B]9C61AE8F[/B]
Added successfully

Wenn Du einen 32-Bit Prozessor hast, sieht das bei Dir vermutlich anders aus.

Dazu ist zu sagen, daß bei mir die Prüfsumme auf 32 bit nicht mehrfach angehängt, sondern, wie erwartet, erfolgreich überprüft wird, und zwar sowohl mit als auch ohne Patch von Benutzer nokia. Daraufhin bat ich nokia nochmals um Feedback, das ich auch erhielt:

Zwei Benutzer mit 64-Bit-Systemen haben sich inzwischen bei mir gemeldet. Ihr tichksum rechnet richtig. Kann man den Fehler irgendwie provozieren, so daß er reproduzierbar wird?

Ich sehe gerade, dass nicht alle meine Annahmen korrekt waren. Ich hatte nämlich das "& 0xFF" übersehen. Demzufolge wird auch kein "zufälliger" Speicher gelesen.

Dennoch bleiben zwei Probleme:

int cs_is_tagged(FILE *fp)
{
  char buf[8];

  fseek(fp, -8, SEEK_END);
  fread(buf, 8, 1, fp);
  if(*(unsigned long*)buf == MAGIC_NUMBER)
    return 1;
  return 0;
}

*(unsigned long*)buf kann auf einem 64-Bit-System niemals MAGIC_NUMBER sein, wenn die CRC32 nach der MAGIC_NUMBER ungleich 0 ist.

unsigned long cs_read_sum(FILE *fp)
{ 
  char buf[8];
  
  fseek(fp, -8, SEEK_END);
  fread(buf, 8, 1, fp);
  return *((unsigned long*)&buf[4]);
}

Hier werden buf[4] bis buf[11] zu einem unsigned long konvertiert und daher irgendwelche Werte vom Stack verwendet, die nicht voraussehbar sind. Das kann je nach Compiler verschiedene Resultate geben. Bei manchen Compilern steht da möglicherweise immer 0, so dass der Fehler nicht überall aufteten muss.

Ob noch weitere Fehler enthalten sind, kann ich jetzt nicht sehen. Vorher hatte mir jedenfalls der AVM-Server beim Flashen gesagt, dass die Prüfsumme des Kernels nicht stimmen würde. Nach meinen Änderungen war das Problem behoben.

Es kam auch von RalfFriedl nochmals eine Antwort:

Hat sich der Einsender des Patches auch geäußert, welches Problem bei ihm aufgetaucht ist?
Daß in cs_calc_sum() "zufälliger" Speicher außerhalb von crctab gelesen würde, kann ich nicht nachvollziehen.
Dafür spricht auch, daß bei der Berechnung der Prüfsumme auf einem 64-Bit System das gleiche Ergebnis kommt. Wenn zufälliger Speicher gelesen würde, käme mit hoher Wahrscheinlichkeit ein Speicherzugriffsfehler oder zumindest ein falsches Ergebnis.

Wie ich Dir schon geschrieben hat, funktioniert die Prüfung einer vorhandenen Summe auf einem 64-Bit System nicht. Der Fehler liegt in cs_is_tagged(), wo MAGIC_NUMBER überprüft wird. Eine weitere Unschönheit ist in cs_get_sum(), das würde aber funktionieren, da die Variable vorher initialisiert wird. Außerdem kommt es gar nicht soweit, wegen dem Fehler in cs_is_tagged().
cs_read_sum() ist auch fehlerhaft, wird aber nirgends verwendet.
Die unterschiedlichen Typen in cs_calc_buf_sum() sind ohne Bedeutung, solange die Datei kleiner als 2GB ist, außerdem wird auch diese Funktion nirgends verwendet.

Bei der Prüfung gibt es noch einen anderen Fehler. Mach mal folgendes:

$ dd if=/dev/zero of=xxx bs=65532 count=1
$ tichksum xxx
File doesn't contain the checksum, adding
Calculated checksum is 725CC451
Added successfully
$ tichksum xxx
File already contains the checksum, verifying
Speicherzugriffsfehler

Das passiert auch auf einem 32-Bit System.

Das Programm hat noch ein weiteres Problem, wenn in der Datei zufällig schon an der richtigen Stelle die MAGIC_NUMBER steht, wird keine Prüfsumme angehängt, sondern eine Überprüfung vorgenommen. Die Wahrscheinlichkeit dafür, daß das passiert, ist aber gering.

Außerdem ist der Exit-Status immer 0, unabhängig davon, ob es funktioniert hat oder nicht.

Ich gehe nicht davon aus, daß durch den Patch Probleme verursacht werden. Allerdings, mit oder ohne Patch, daß Programm läuft nicht auf Big-Endian Systemen und hat den Fehler, den ich gerade beschrieben habe.

Hast Du Interesse daran, daß das mal in Ordnung gebracht wird, oder soll es so bleiben, wie es ist?

Wie geht's jetzt weiter?

Ab diesem Zeitpunkt übergebe ich die Diskussion wieder an die interessierte Allgemeinheit, die gern etwas dazu beitragen möchte, den Sachverhalt zu klären. Ich möchte mich dort nicht hinein vertiefen, aber RalfFriedl und nokia könnten ja kooperieren und gemeinsam weiter basteln. Alle bisher vorliegenden Infos sind jetzt hier zu finden.

 

[RalfFriedl]

Gibt es bisher einen Fall, wo auf einem 64-Bit System eine Eingabedatei ohne Prüfsumme eine falsche Prüfsumme erhält? Nach Durchsicht des Programms und einigen Versuchen kommt bei mir immer die richtige Prüfsumme heraus.

Das Programm hat etliche andere Fehler, die sich aber nur auf die Prüfung einer vorhandenen Prüfsumme berechnen lassen.

Wenn man das Programm schon überarbeitet, dann vorzugsweise auch gleich richtig. Allerdings hatte ich bisher keine Probleme damit.

 

[kriegaex]

Ich persönlich würde mich freuen, wenn jemand sich die Zeit nehmen könnte, auch die Fehler bei der Prüfung der Summen zu beheben, da Du sie schon erkannt hast. Momentaner Stand im Repository ist der Patch von nokia, so würde es irgendwann in 15.3 ausgeliefert werden. Aber wenn schon, denn schon. Ich freue mich auf weitere bereinigte Versionen.

 

[RalfFriedl]

Ok, ich kümmere mich darum.

Trotzdem oder gerade deswegen hätte ich aber gern den Fall bzw. die Testdaten, wo beim Erstellen der Prüfsumme ein falsches Ergebnis kommt.

 

[kriegaex]

Ist mir nie passiert, aber ich nutze auch noch ein 32-Bit-Linux (in einer VM auf auf einem 64-Bit-Host)... Die Prüfsummenverifikation klappt hier astrein.

 

[RalfFriedl]

Das ist mir klar. Ich vermute, daß nokia einen derartigen Fall hat, sonst hätte er ja wohl nicht den Patch erstellt.

Da mir nach Durchsicht des Programms nicht klar ist, wo es einen Fehler bei der Erstellung der Prüfsumme gibt, wäre es gut, wenn ich die Daten hätte, um das zu überprüfen, schon um sicherzustellen, daß das geänderte Programm mit diesem Fall auch zurechtkommt.

 

[RalfFriedl]

Geändertes Programm TI-chksum

Ich habe mal eine geänderte Version des Programms angehängt.

• Läuft auf 32-Bit oder 64-Bit Rechnern.
• Läuft auf Big-Endian oder Little-Endian Rechnern.
• Gibt im Fehlerfall einen Exit-Status ungleich 0 zurück.
• Optionen zum Erstellen, Prüfen und Entfernen einer Prüfsumme.
• Wenn keine Option angegeben wird, ist das Verhalten kompatibel zum alten Programm: Prüfen, wenn vorhanden, sonst anhängen.

 

[RalfFriedl]

Daß die kernel.image Dateien keine Prüfsumme enthalten, hat sich inzwischen als Irrtum herausgestellt. Nur die urlader.image dateien enthalten keine Prüfsumme.

Ursprünglicher Text:

Ich habe gerade anläßlich dieses Beitrags festgestellt, daß keine der AVM kernel.image Dateien, die ich habe, eine Prüfsumme enthält, auch kein urlader.image.
Auch ältere filesystem.image und kernel.image aus Firmwares der 2.4 Kernels haben keine Prüfsumme.

Was auch immer auf der Box passiert, es gibt keine Prüfsumme, also kann sie auch nicht überprüft werden.

Ich habe gerade ein kernel.image auf die Box kopiert und das dazugehörige chksum aufgerufen:

$ ./chksum kernel.image
File doesn't contain the checksum, adding
Calculated checksum is C06D0E66
Adding failed
$ echo $?
0

Die Meldung "Adding failed" kommt, ohne daß das Programm überhaupt versucht hätte, etwas an der Datei zu ändern.

Da der Exit-Status aber immer 0 ist, stört das nicht weiter.

 

[olistudent]

Immerhin haben unsere dsmod-Images eine Prüfsumme.

MfG Oliver

 

[RalfFriedl]

Und alle Probleme, die auftauchen, liegen nur daran, daß das install-Skript manchmal nicht richtig funktioniert, wenn entgegen allen Erwartungen doch eine Prüfsumme an der Datei ist.

 

[kriegaex]

Ralf, hast Du Deine letzte Behauptung geprüft, oder handelt es sich um eine Vermutung? Es ist ja kein Problem, die CRC-Prüfsumme wegzulassen. Seltsam nur, daß sie überprüft wird und extra ein Werkzeug dafür im Image vorhanden ist.

Außerdem stimmt es nicht, daß kernel.image keine Prüfsumme enthielte. Es enthält sehr wohl eine in den von mir überprüften Fällen (7170-FWs). Weglassen wäre also der falsche Weg, denn wenn AVM irgendwann mal den Fehler bereinigt, daß immer 0 zurück gegeben wird, stehen wir dumm da.

Kann es sein, daß Du nicht direkt in den FW-Images nach kernel.image geschaut hast, sondern unter build/original/firmware? Dort wurde sie beim Entpacken bereits entfernt. Achte mal auf den Dateigrößenunterschied von 8 Bytes. ;-)

 

[RalfFriedl]

Das mit den Problemen war nur als Scherz gemeint.

Außerdem hast Du recht, ich habe mir die Image-Dateien angeschaut, nachdem die Prüfsumme bereits entfernt wurde. Beim Überprüfen der Summe wird auch nicht nur eine Meldung ausgegeben,sondern auch ein Fehler-Status zurückgegeben, so daß das Skript dann tatsächlich abbricht.

Das Urlader-Image hat allerdings auch frisch aus der tar-Datei keine Prüfsumme. Da eine Datei ohne Prüfsumme aber nie einen Fehler-Status zurückgibt, ist das vermutlich auch kein Problem.