核心现象拆解 #

• 已启用ECC的裸机环境下，执行修改ECC数据的STRH故障注入指令时触发双重中断/故障
• 运行后关键数据：
  • debuglist[13-15]：[0x10101010, 0xbadcafe9, 0]
  • victim值：0xdeafbeef（未被错误注入影响，说明ECC纠错或故障触发逻辑提前拦截）
  • scratch值：0xdedebeef
  • GENERAL_FAULT从0变为2（对应ARM架构中不可纠正数据错误的故障类型）
• 初始ACTLR配置：0x8a3fc1c4（FSBL配置，ECC预开启）

双重中断的可能原因 #

1. 故障注入指令本身触发同步异常，后续ECC错误又触发异步异常

   • STRH修改ECC数据时，若操作地址未正确配置为允许ECC故障注入的区域（如未开启ACTLR中的故障注入允许位），会先触发指令访问异常；随后ECC校验错误触发数据访问异常，形成双重中断。
   • 核对ACTLR的FIEN（Fault Injection Enable）位：0x8a3fc1c4二进制中对应位是否置1，若未开启，故障注入指令本身会被拦截。

2. ECC错误响应优先级与中断处理逻辑冲突

   • 当注入单比特错误时，处理器本应自动纠错并触发SError中断（可纠正错误通知），但如果GENERAL_FAULT变为2（不可纠正错误），说明注入的错误超出单比特范围，或者ECC配置被意外修改。
   • 检查故障注入的STRH指令是否错误修改了多比特ECC数据：若写入的ECC值导致数据+ECC的错误比特数超过纠错能力，会直接触发不可纠正错误，同时指令执行本身可能因ECC异常触发同步故障。

3. 内存区域的ECC属性配置错误

   • 确认victim变量所在内存区域是否被正确配置为ECC使能：若该区域实际未开启ECC，修改ECC数据的操作会触发非法内存访问异常，后续又因ECC校验逻辑混乱触发二次故障。

排查步骤 #

• 拆解ACTLR寄存器值0x8a3fc1c4，确认FIEN（bit[24]）、ECCEN（相关ECC使能位）是否正确置位，确保故障注入功能被允许。
• 调整故障注入指令：先尝试注入单比特ECC错误，比如通过STRH写入仅翻转1比特的ECC值，验证处理器的纠错能力；若注入多比特错误，应触发不可纠正错误中断，此时需确保中断处理程序能正确捕获，避免双重中断。
• 检查中断处理程序：确保SError和Data Abort中断的处理逻辑不会互相干扰，比如在处理一个中断时关闭另一个中断的触发，或者正确区分同步/异步异常的来源。
• 验证内存区域配置：通过MMU或内存控制器寄存器确认victim所在区域的ECC属性，确保读写操作会触发ECC校验。

关键验证点 #

• 若注入单比特错误后，victim值保持0xdeafbeef且GENERAL_FAULT未变为2，同时触发SError中断，说明ECC纠错功能正常。
• 若注入多比特错误后，GENERAL_FAULT变为2且触发不可纠正错误中断，说明不可纠正错误检测功能正常，此时需排查双重中断是否因中断处理程序未正确清除异常状态导致。

内容的提问来源于stack exchange，提问作者Seth Robertson