如何安全判断ARM64机器是否支持挂载BPF Uprobe与断点功能

编辑说明：截至2023年7月21日，该Bug在Microsoft Azure上已修复。

问题背景 #

Microsoft Azure上的ARM64 Linux机器曾存在一处Bug：在多数（非全部）二进制文件上挂载Uprobe或设置GDB断点后，继续执行时会触发SIGILL或SIGSEGV信号。示例复现步骤及报错如下：

$ gdb /bin/bash
(gdb) break readline
(gdb) run
Breakpoint 1, 0x0000aaaaaab522fc in readline ()
(gdb) continue
Program received signal SIGSEGV, Segmentation fault.
0x0000fffff7d91350 in strlen () from /lib64/libc.so.6

该测试基于Ubuntu-22.04系统（内核版本5.15.0-1040-azure），且当时Azure上所有发行版及内核版本均受此影响，而VMWare ARM环境则无此问题。

1. 应用程序能否在启动阶段提前判断断点与单步调试功能是否正常？ #

可以实现预检测逻辑，核心思路是在启动时创建小型测试进程，模拟断点/Uprobe挂载操作，验证后续执行状态：

• GDB断点检测：编写极简测试程序（如仅调用strlen等基础函数），通过子进程调用GDB设置断点并继续执行，检查是否触发异常信号。若测试进程崩溃，则判定当前环境调试功能异常。
• Uprobe挂载检测：使用bpf系统调用挂载针对测试函数的Uprobe，触发函数执行后，检查是否出现崩溃或异常信号。若出现异常，直接禁用相关Uprobe逻辑。

这类检测需注意：

• 保持轻量化，避免占用过多系统资源；
• 测试进程需隔离，不影响主应用运行；
• 检测到异常时，提供降级方案（如禁用调试/探针功能、输出告警），防止陷入崩溃循环导致机器不可达。

2. 这是否为部分ARM主机/虚拟机的已知虚拟化限制？ #

该问题并非ARM架构的通用虚拟化限制，而是当时Azure ARM64虚拟化层的特定Bug。VMWare ARM等其他虚拟化环境未受影响，说明ARM本身的调试机制（断点、Uprobe）可正常工作。这类问题通常与虚拟化平台对ARM调试寄存器、指令断点的模拟实现缺陷有关，属于特定厂商的实现问题，而非架构层面的限制。

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