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

nokia schrieb:

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

Zum Vergrößern anklicken....

kriegaex schrieb:

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:

Code:

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

Zum Vergrößern anklicken....

frank_m24 schrieb:

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.

Zum Vergrößern anklicken....

RalfFriedl schrieb:

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.

Code:

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

Zum Vergrößern anklicken....

kriegaex schrieb:

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?

Zum Vergrößern anklicken....

nokia schrieb:

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:

Code:

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.

Code:

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.

Zum Vergrößern anklicken....

RalfFriedl schrieb:

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:

Code:

$ 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?

Zum Vergrößern anklicken....