DynamoRIO项目中的AArch32信号处理问题分析与修复

问题背景

在DynamoRIO动态二进制插桩工具中，开发人员发现了一个与AArch32架构信号处理相关的严重问题。当在特定硬件平台（如基于Neoverse N1/V1的Graviton 2/3处理器）上运行32位ARM程序时，几乎所有与信号处理相关的测试用例都会失败，而这些测试在Cortex-A72等其他平台上却能正常运行。

现象分析

测试失败主要发生在信号处理相关的测试套件中，特别是code_api|linux.signalXXXX和code_api|linux.sigplainXXX等测试用例。问题在Debian 10/11/12等不同Linux发行版上均有出现，且与内核版本密切相关——在5.15.0内核上出现故障，而在5.4.47内核上则表现正常。

深入调查

通过编写简单的信号处理测试程序并使用GDB调试，开发人员发现问题的核心在于sigreturn系统调用后的异常行为。在故障系统中，程序会在sigreturn后意外收到SIGSEGV信号，导致崩溃。

进一步分析发现，问题源于信号帧(sigframe)中CPSR(当前程序状态寄存器)的bit 4设置不正确。根据ARM架构规范，CPSR的bit 4是RES1位，必须始终设置为1。然而在DynamoRIO处理过程中，该位被错误地清零。

内核行为差异

不同版本内核对此问题的处理方式不同：

• 较老内核(如5.4.47)会忽略CPSR的RES1位
• 较新内核(如5.15.0)会严格检查RES1位，发现非法值时会发送SIGSEGV信号

这种差异解释了为何问题只出现在特定内核版本上。

解决方案

修复方案相对简单直接——在构建信号帧时确保正确设置CPSR的RES1位。具体修改是在mcontext_to_sigcontext函数中添加对bit 4的强制设置：

sc->SC_FIELD(arm_cpsr) = mc->cpsr | 0x10;

这一修改确保了信号处理过程中传递给内核的CPSR值始终符合ARM架构规范，从而避免了新版本内核的严格检查导致的SIGSEGV信号。

技术启示

这个案例展示了几个重要的技术要点：

1. 架构规范中的RESERVED位必须正确处理，即使当前硬件可能不检查这些位
2. 内核版本升级可能引入更严格的规范检查，导致之前"能工作但不规范"的代码失效
3. 信号处理是操作系统和用户空间交互的复杂领域，需要特别注意架构规范的细节要求

该问题的修复不仅解决了DynamoRIO在特定平台上的兼容性问题，也为其信号处理机制的健壮性提供了保障。