OpenSSL在Graviton/armv8平台上的寄存器破坏问题分析

问题背景

在OpenSSL 3.4.0版本中，用户在使用AWS Graviton服务器（基于armv8架构）时发现了一个严重的寄存器破坏问题。具体表现为，在执行随机数生成相关函数（如RAND_bytes()或RAND_get0_public()）后，浮点寄存器d15的值被意外修改为0，而原本该寄存器中存储的值为2。

问题表现

通过一个简单的测试程序可以重现该问题：

#include <openssl/rand.h>
#include <stdio.h>

int main(void)
{
    unsigned long tmp = 2;
    unsigned long tmp2 = 0;
    __asm__("ldr d15, %0" : : "m"(tmp));
    unsigned char buf[1024];
    RAND_bytes(buf, sizeof(buf));
    __asm__("str d15, %0" : "=m"(tmp2));
    printf("d15 is now %lu\n", tmp2);
}

在正常情况下，程序应该输出"d15 is now 2"，表明d15寄存器的值被正确保留。然而在实际运行中，程序却输出"d15 is now 0"，表明寄存器值被错误修改。

问题根源

经过深入分析，发现问题出在OpenSSL的AES加密实现中。具体来说，在函数aes_v8_ctr32_encrypt_blocks_unroll12_eor3的恢复寄存器阶段存在缺陷。

在arm64架构的ABI规范中，d8-d15寄存器是被调用者保存的（callee-saved），这意味着任何函数如果修改了这些寄存器，必须在返回前恢复它们的原始值。然而在OpenSSL的实现中，恢复寄存器的代码存在错误：

.Lctr32_done_unroll:
    ldp     d8,d9,[sp, #16]
    ldp     d10,d11,[sp, #32]
    ldp     d12,d13,[sp, #48]
    ldp     d15,d16,[sp, #64]

这段代码本应从栈中恢复之前保存的寄存器值，但实际上却错误地将0加载到了d15寄存器中，而不是恢复其原始值。

影响范围

该问题不仅影响OpenSSL的随机数生成功能，还会影响所有依赖这些功能的组件，如TLS连接建立过程（通过SSL_CTX_new()）。PostgreSQL等其他开源项目也报告了类似问题，表明这是一个具有广泛影响的缺陷。

解决方案

修复方案是确保在恢复寄存器时正确地从栈中加载原始值，而不是加载0。具体修复包括：

1. 检查所有寄存器保存/恢复代码路径
2. 确保栈偏移计算正确
3. 验证所有被调用者保存寄存器的处理逻辑

总结

这个案例展示了在低级加密实现中处理平台特定ABI细节的重要性。arm64架构对浮点寄存器的使用有严格规定，任何违反这些规定的行为都可能导致难以调试的问题。对于密码学库来说，保证在所有平台上正确遵循ABI规范尤为重要，因为这类问题可能导致安全关键功能出现不可预测的行为。