Tilck项目在RISCV64架构下启用UBSAN时的NULL指针解引用问题分析

问题背景

在Tilck操作系统项目向RISCV64架构移植的过程中，开发团队发现了一个与用户空间内存操作相关的稳定性问题。当启用内核未定义行为检测工具（UBSAN）时，系统在执行getrusage系统调用测试时会触发内核崩溃，错误信息显示为NULL指针解引用。

问题现象

测试用例故意向getrusage系统调用传递NULL指针，目的是验证系统在遇到非法内存访问时的错误处理能力。在x86架构（i686）上，这一测试能够正常通过——系统会捕获内存访问异常并返回EFAULT错误码。然而在RISCV64架构上，系统却直接触发了UBSAN的NULL指针解引用警告，导致内核崩溃。

技术分析

内存访问机制差异

问题的核心在于不同架构下copy_to_user()函数的实现差异。该函数负责将数据从内核空间复制到用户空间，其内部通过fault_resumable_call()机制来安全地处理可能出现的用户空间内存访问错误。

在x86架构上，memcpy()函数是通过内联汇编实现的。汇编代码会直接尝试访问目标内存，触发硬件级的内存访问异常（page fault），然后由fault_resumable_call()机制捕获并处理这个异常。

而在RISCV64架构上，当前使用的是C语言实现的memcpy()。当UBSAN启用时，编译器会在生成代码中加入NULL指针检查，在解引用前就直接触发UBSAN警告，而不是产生硬件异常。

UBSAN的行为特点

UBSAN（Undefined Behavior Sanitizer）是一种在编译时插入的运行时检查工具，它会主动检测各种未定义行为，包括NULL指针解引用。与硬件异常不同，UBSAN检查发生在实际内存访问之前，因此会绕过操作系统设计的异常处理机制。

解决方案

经过深入分析，开发团队确定了以下解决方案：

1. 在copy_to_user()中添加显式NULL指针检查：在调用memcpy()之前，先检查用户空间指针是否为NULL。这种方法简单有效，能够避免UBSAN的干预。

2. 为RISCV64实现汇编优化的memcpy()：长期来看，为RISCV64编写内联汇编版本的memcpy()函数是更彻底的解决方案。这样不仅能解决UBSAN问题，还能提高内存复制操作的性能。

经验总结

这个案例揭示了几个重要的开发经验：

1. 架构差异带来的隐性问题：在不同硬件架构上，相同的代码可能表现出完全不同的行为，特别是在涉及底层内存操作时。

2. 安全工具与异常处理的交互：像UBSAN这样的安全工具会改变程序的正常执行流程，可能干扰系统设计的异常处理机制。

3. 防御性编程的重要性：即使在理论上可以通过异常处理机制捕获的错误，显式的条件检查仍然是更可靠的做法。

通过解决这个问题，Tilck项目在RISCV64架构上的稳定性和可靠性得到了进一步提升，为后续的多架构支持打下了坚实基础。