调试令人讨厌的SIGILL崩溃:文本段损坏

Question

Ours是一个运行Linux的基于PowerPC的嵌入式系统.我们遇到了一个随机的SIGILL崩溃,可以看到各种各样的应用程序.崩溃的根本原因是将要执行的指令归零.这表示驻留在内存中的文本段损坏.由于文本段以只读方式加载,因此应用程序无法破坏它.所以我怀疑一些常见的子系统(DMA？)导致这种腐败.由于问题需要数天才能重现(由于SIGILL而崩溃),因此很难进行调查.首先,我希望能够知道任何应用程序的文本段是否以及何时被破坏.我查看了堆栈跟踪和所有指针,寄存器是正确的.
你们有什么建议我怎么办？

一些信息:
Linux 3.12.19-rt30#1 SMP Fri Mar 11 01:31:24 IST 2016 ppc64 GNU/Linux

(gdb)bt
0 xxx中的0x10457dc0

反汇编输出:
=> 0x10457dc0 <+80>:mr r1,r11
0x10457dc4 <+84>:blr

地址为0x10457dc0的
指令:0x7d615b78捕获SIGILL 0x10457dc0后的指令:0x00000000

(gdb)维护信息部分
0x10006c60-> 0x106cecac在0x00006c60:.text ALLOC LOAD READONLY CODE HAS_CONTENTS

预期(从应用程序二进制):
(GDB)的x/32 0x10457da0
0x10457da0:0x913e0000 0x4bff4f5d 0x397f0020 0x800b0004
0x10457db0:0x83abfff4 0x83cbfff8 0x7c0803a6 0x83ebfffc
0x10457dc0: 0x7d615b78 0x4e800020 0x7c7d1b78 0x7fc3f378
0x10457dd0:0x4bcd8be5 0x7fa3eb78 0x4857e109 0x9421fff0

实际(处理SIGILL并转储附近的内存位置后):
错误指令地址:0x10457dc0
0x10457da0:0x913E0000
0x10457db0:0x83ABFFF4
=> 0x10457dc0:0x00000000
0x10457dd0:0x4BCD8BE5
0x10457de0:0x93E1000C

编辑:
我们的一个主要原因是损坏始终发生在以0xdc0结尾的偏移处.
例如Faulting
指令地址:0x10653dc0 <<我们的应用程序在捕获SIGILL Faulting
指令地址后打印:0x1000ddc0 <<我们的应用程序在捕获SIGILL flash_erase后打印
[8557]:未处理的信号4在0fed6dc0 nip 0fed6dc0 lr 0fed6dac code 30001
nandwrite [8561] :未处理信号4在0fed6dc0 nip 0fed6dc0 lr 0fed6dac代码30001
awk [4448]:未处理信号4在0fe09dc0 nip 0fe09dc0 lr 0fe09dbc代码30001
awk [16002]:未处理信号4在0fe09dc0 nip 0fe09dc0 lr 0fe09dbc代码30001
getStats [ 20670 ]:未处理信号4在0fecfdc0 nip 0fecfdc0 lr 0fecfdbc代码30001
expr [27923]:未处理信号4在0fe74dc0 nip 0fe74dc0 lr 0fe74dc0代码30001

编辑2:另一个领导是腐败总是发生在物理帧号0x00a4d.我想,如果PAGE_SIZE为4096,则会转换为0x00A4DDC0的物理地址.我们怀疑我们的几个内核驱动程序并进一步调查.是否有更好的想法(比如放置硬件观察点)哪个更有效？如下所示,KASAN怎么样？

任何帮助表示赞赏.谢谢.

Answer 1

1.）文本段是RO，但是可以通过mprotect更改权限，您可以检查一下是否可以

2.) 如果是内核问题：

• 使用KASAN和 KUBSAN（未定义行为）清理程序运行内核
• 重点关注未包含在主线中的驱动程序代码
• 这里的提示是一字节损坏。也许我错了，但这意味着 DMA 不应该受到指责。它看起来像是某种无效的商店。

3.) 硬件。我认为，您的问题看起来像是硬件问题（RAM 问题）。

• 您可以尝试在引导加载程序中降低 RAM 系统频率
• 检查此问题是否在稳定的主线软件上重现，这就是您可以证明问题所在的方法