AArch32用户态寄存器影响性及Linux实现相关技术问询

核心疑问解答 #

1. AArch32用户态代码能否读取/修改/影响x15-x30的值及x0-x14的高32位？ #

• x16-x30：AArch32指令集没有操作这些寄存器的编码，用户态程序无法直接读取或修改它们，这些寄存器在AArch32模式下完全对用户态隐藏。x15对应AArch32的PC（程序计数器），用户态只能通过指令流或跳转修改其低32位，高32位无法访问。
• x0-x14的高32位：AArch32下通用寄存器都是32位宽度，所有针对r0-r14的指令仅会操作低32位，高32位对用户态完全不可见，也无法通过AArch32指令直接修改或读取。

2. AArch32用户态代码的执行是否会受x15-x30的值及x0-x14的高32位影响？ #

• x16-x30：AArch32模式下，CPU仅使用寄存器的32位视图（r0-r15），x16-x30的内容不会参与任何AArch32指令的执行流程，因此完全不影响用户态代码的运行。
• x0-x14的高32位：AArch32指令在执行计算、参数传递等操作时，只会读取寄存器的低32位，高32位的内容不会被作为操作数或状态依据，因此也不会影响用户态代码的执行。

未考虑到的关键要点 #

• 跨模式进程切换的一致性：内核需要支持AArch32和AArch64用户态进程的切换，此时x16-x30及x0-x14的高32位是AArch64进程的可见寄存器，必须完整保存和恢复。Linux保存所有x0-x30寄存器，就是为了保证跨模式进程切换时的状态一致性，避免数据错乱。
• 系统调用的规范防御：Linux清除x0高32位是为了严格遵守AArch32系统调用的32位参数规范——即使AArch32用户态无法设置高32位，内核仍需主动清除，防止内核逻辑中误将高32位当作参数的一部分。重复清除属于防御性编程，避免代码路径遗漏导致的异常。
• 硬件实现的兼容性：QEMU和树莓派3B在AArch32到AArch64切换时的寄存器行为差异，说明不同硬件/模拟器的处理逻辑可能不一致。内核不能依赖硬件自动处理高32位，必须主动统一处理，保证跨平台兼容性。
• 异常/中断的嵌套处理：除系统调用外，AArch32用户态的中断、异常进入内核时，寄存器的完整状态（包括高32位）需要被正确保存，否则嵌套异常场景下可能出现寄存器数据污染，影响内核稳定性。

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