如何通过编译指令针对性插桩特定Linux内核函数？

首先直接给结论：你完全可以通过GCC的函数属性实现仅对特定内核函数的插桩，无需启用全局的-finstrument-functions标志，同时针对KProbe黑名单的限制，也有替代或补充方案。

一、使用GCC函数属性实现精准插桩 #

GCC提供了__attribute__((instrument_function))这个函数属性，专门用于给单个函数开启插桩，完全替代全局的-finstrument-functions编译选项。

具体操作方式 #

你只需要把这个属性添加到目标内核函数的声明或定义上即可：

1. 在函数定义中添加：
   比如修改内核中sys_open函数的定义：

   asmlinkage long __attribute__((instrument_function)) sys_open(const char __user *filename, int flags, umode_t mode)
   {
       // 原函数的实现代码
       return do_sys_open(AT_FDCWD, filename, flags, mode);
   }
   

2. 在头文件声明中添加：
   如果函数声明在头文件里，也可以直接给声明加属性：

   asmlinkage long sys_open(const char __user *filename, int flags, umode_t mode) __attribute__((instrument_function));
   

注意事项 #

• 这种方式只会对添加了该属性的函数插桩，不会影响其他内核函数，完美解决全局插桩带来的性能开销和冗余问题。
• 确保你的内核编译使用的GCC版本支持该属性（主流GCC 4.4及以上版本都支持），同时避免使用会破坏插桩的优化选项（比如-fomit-frame-pointer可能影响插桩函数的调用栈获取）。
• 插桩后的函数会自动调用你定义的__cyg_profile_func_enter和__cyg_profile_func_exit函数（和-finstrument-functions的行为一致），你需要在内核中实现这两个函数来处理插桩逻辑（比如记录函数调用、统计耗时等）。

二、针对KProbe黑名单的替代方案 #

KProbe的黑名单是为了保护内核中最核心、最敏感的函数（比如调度器核心函数、自旋锁相关函数），强行插桩这些函数可能导致系统死锁或崩溃。如果你的需求必须覆盖这些函数，除了上面的编译时插桩方案，还可以考虑：

• 使用ftrace：ftrace是内核自带的追踪框架，支持对几乎所有内核函数进行追踪，包括KProbe黑名单中的函数。它通过静态插桩（编译时在函数入口添加NOP指令）实现，性能开销极低，适合生产环境使用。
• 手动修改KProbe黑名单：不推荐，但如果你是在测试环境中，可以临时修改内核源码中的KProbe黑名单列表（比如kprobe_blacklist数组），移除你需要监控的函数。但务必注意，这种操作可能带来严重的稳定性风险，只适合实验场景。

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