Illegal instruction 问题处理

Illegal (iLLegal) instruction 直观解释----非法指令。表面看是CPU在执行指令过程中,发现指令非法,也就是不认识的指令或者无权限的指令。如果只是沿着这个思路,很容易陷入对编译器的信任上。其实,这个问题,也很可能是程序自己造成的。比如使用了嵌入汇编,那么编写者要对使用的指令负责。还比如堆栈、内存出错,此时,访问的指令可能是内存随机的数据或者非指令数据,这同样会导致CPU无法识别。网上看到一篇比较全的分析文章,放在这里供参考:

非法指令(Illegal Instruction)问题定位 - ArnoldLu - 博客园

关于这个问题需要再补充一下:

之前没有经过认真思考,就做出了上述论断,后来仔细想了想,感觉没有那么简单。对于第一种情况,使用嵌入汇编,实际测试,发现如果使用了错误的汇编指令,编译器是不认的。想想也是,嵌入汇编也是一种格式,也有很多种扩展写法,编译器并不是按照类似宏定义的方式,直接信任和使用的,而是需要进行二次处理,保留基本处理流程,重新生成不影响上下文的汇编指令(寄存器使用通盘考虑)。这样一来,想通过嵌入汇编轻松欺骗机器是行不通的。关于嵌入汇编,简单的例子可参考下面的链接:

内联汇编很可怕吗?看完这篇文章,终结它!

继续,对于第二种情况,修改代码指令,也不是简单轻松的事情。现代操作系统都是用了虚拟内存机制,进一步的,大部分都采用了分页机制。那么,对于程序的代码段,操作系统在映射内存页面的时候,会标记这类页面为只读,所以,尝试对代码直接修改,也是行不通的。

对于这一点,也不是绝对的。可以通过mprotect调用,修改页面的读写属性,参考文章:

内核热补丁,真的安全么?

综合上述两点,人为产生非法指令,还需要再思考思考。

第三次补充:在X86下尝试多次均失败后,终于在arm下人为成功产生了上述错误指令提示。具体过程如下:

首先,对程序做了简单处理,增加了如下的异常信号捕获

void signal_handler(int signum) {
   printf("Signal %d (number) captured \n", signum);
}

signal(SIGILL , signal_handler);


上述代码期望在非法指令产生时,由应用捕获,并进一步处理。

然后对于x86,因为简单的错误指令会被编译器识别,所以主要尝试了call和jmp指令。在这两个指令后都附带一个随机地址,可以编译通过。但是,实际运行,都是类似段错误,也就是主要是内存错误。
call因为是类似函数调用,有入栈出栈等操作,段错误还是可以理解的,但是jmp指令是无条件跳转,跳转到的地址包含的内容可能不是有效的代码,比如无法译码。但是,多次尝试,仍然也是报段错误。x86下放弃。

尝试ARM平台。找到了一个跟CPU版本相关的指令,swpb,这是一个存在于早期ARM CPU上的指令,感兴趣的读者可以搜索了解一下。
使用如下嵌入汇编代码

asm volatile("swpb %0,%2,[%3]"
             : "=&r"(ret), "=m" (*ptr)
             : "r"(newval), "r"(ptr)
             : "cc", "memory");    //memory == no cache  |  cc == status register update

编译通过。执行程序,报非法指令。
gdb跟踪调试,发现报非法指令时,的确在swpb指令处。如下图:

Illegal instruction 问题处理_第1张图片

Program received signal SIGILL, Illegal instruction.    成功产生非法指令。
这说明,在嵌入式平台上,可能会因为嵌入汇编、编译器版本、连接库等导致出现运行时非法指令。

你可能感兴趣的:(Linux系统开发,c++,python,c语言)