Debugging eines ekligen SIGILL Crash: Text Segment Korruption

Question

Unseres ist ein PowerPC-basiertes Embedded-System mit Linux. Wir treffen auf einen zufälligen SIGILL-Absturz, der für eine Vielzahl von Anwendungen gilt. Die Ursache für den Absturz ist die Nullstellung des auszuführenden Befehls. Dies weist auf eine Beschädigung des Textsegments im Speicher hin. Da das Textsegment schreibgeschützt geladen wird, kann die Anwendung es nicht beschädigen. Ich vermute also, dass ein gemeinsames Subsystem (DMA?) Diese Korruption verursacht. Da das Problem Tage dauert, um sich zu reproduzieren (Absturz aufgrund von SIGILL), wird es schwierig zu untersuchen. Ich möchte also wissen, ob und wann das Textsegment einer Anwendung beschädigt wurde. Ich habe auf die Stack-Trace geschaut und alle Zeiger, Register sind richtig.
Habt ihr irgendwelche Vorschläge, wie ich das machen kann?

Einige Info:
Linux 3.12.19-RT30 # 1 SMP Fr 11. März 01.31.24 IST 2016 ppc64 GNU/Linux

(GDB) bt
0 0x10457dc0 in xxx

Ausbau Ausgang:
=> 0x10457dc0 < +80>: mr r1, r11
0x10457dc4 < +84>: blr

Anweisung an Adresse 0x10457dc0 erwartet: 0x7d615b78
Anweisung gefunden nach dem Fang SIGILL 0x10457dc0: 0x00000000

(GDB) Wartung Info Abschnitte
0x10006c60-> 0x106cecac bei 0x00006c60: .text ALLOC LOAD NURLESE- CODE HAS_CONTENTS

Erwartet (aus der Anwendung binär):
(gDB) x/32 0x10457da0
x10457da: 0x913e0000 0x4bff4f5d 0x397f0020 0x800B0004
0x10457db0: 0x83abfff4 0x83cbfff8 0x7c0803a6 0x83ebfffc
0x10457dc0: 0x7d615b78 0x4e800020 0x7c7d1b78 0x7fc3f378
0x10457dd0: 0x4bcd8be5 0x7fa3eb78 0x4857e109 0x9421fff0

Actual (nach SIGILL und Dumping in der Nähe Speicherplätze Handling):
Fehlgeschlagene Befehlsadresse: 0x10457dc0
0x10457da0: 0x913E0000
0x10457db0: 0x83ABFFF4
=> 0x10457dc0: 0x00000000
0x10457dd0: 0x4BCD8BE5
0x10457de0: 0x93E1000C

Edit:
Eine Leitung, die wir haben, ist, dass die Korruption immer bei einem Offset auftritt, die mit 0xdc0 endet.
Für z.B.
Fehlgeschlagene Befehlsadresse: 0x10653dc0 < < durch unsere Anwendung gedruckt SIGILL nach dem Fang
Faulting-Adresse-Anweisung: 0x1000ddc0 < < durch unsere Anwendung gedruckt nach SIGILL Fang
flash_erase [8557]: Unbehandelte Signal 4 bei 0fed6dc0 nip 0fed6dc0 lr 0fed6dac Code 30001
nandwrite [8561]: Unbehandelte Signal 4 bei 0fed6dc0 nip 0fed6dc0 lr 0fed6dac Code 30001
a wk [4448]: Unbehandelte Signal 4 bei 0fe09dc0 nip 0fe09dc0 lr 0fe09dbc Code 30001
awk [16002]: Unbehandelte Signal 4 bei 0fe09dc0 nip 0fe09dc0 lr 0fe09dbc Code 30001
getStats [20670]: Unbehandelte Signal 4 bei 0fecfdc0 nip 0fecfdc0 lr 0fecfdbc Code 30001
expr [27923]: Unbehandelte Signal 4 bei 0fe74dc0 nip 0fe74dc0 lr 0fe74dc0 Code 30001

Edit 2: Eine weitere Leitung ist, daß die Korruption auftritt immer an physikalischer Rahmennummer 0x00a4d. Ich nehme an mit PAGE_SIZE von 4096 bedeutet dies die physikalische Adresse von 0x00A4DDC0. Wir vermuten einige unserer Kernel-Treiber und untersuchen weiter. Gibt es eine bessere Idee (wie Hardware Watchpoint), die effizienter sein könnte? Wie wäre es mit KASAN wie unten vorgeschlagen?

Jede Hilfe wird geschätzt. Vielen Dank.

Answer 1

1.) Textsegment ist RO, aber die Berechtigungen von mprotect geändert werden konnte, können Sie das, wenn Sie denken, dass es möglich ist,

2.) Wenn es Kernel-Problem ist:

• Run Kernel mit KASAN und KUBSAN (undefiniert Verhalten) Sanitizer
• Konzentrieren Sie sich auf Treiber-Code nicht in Mainline enthalten
• Der Hinweis hier ist ein Byte Korruption. Vielleicht liege ich falsch, aber das bedeutet, dass DMA nicht schuld ist. Es sieht wie eine Art ungültiger Speicher aus.

3.) Hardware. Ich denke, dein Problem sieht wie ein Hardwareproblem aus (RAM-Problem).

• Sie können versuchen, im Bootloader-RAM Systemfrequenz zu verringern
• Überprüfen Sie, ob dieses Problem auf stabile Software Fernwiedergibt, das ist, wie Sie nachweisen können, dass sie es ist