ebpf是linux内核的「万能插头」，它通过安全沙箱机制在不修改内核源码、不加载内核模块的前提下，实现高精度、低开销的内核可观测性与安全防护，已成为云原生时代基础设施的核心技术。
这个问题在大厂内核/安全方向三面中属于高阶考察点，但需先明确一个关键前提：现代主流操作系统（如Linux 5.10+、Windows 10/11）在生产环境下严格限制甚至禁止用户直接部署低级钩子（如IDT patch、syscall table hook、CR0.WP绕过）来拦截程序计数器（RIP/EIP）——这不是技术不可行，而是被内核保护机制（KPTI、SMAP、CET、Kernel Page Protection、Driver Signature Enforcement）系统性封堵。
为什么不能直接 Hook 程序计数器？
程序计数器（PC）本身不是可被“拦截”的资源，它是CPU执行流的自然指针。所谓“拦截PC”，实质是想在指令执行前/后插入观测逻辑，这必须落在以下任一可控时机：
- 系统调用入口（syscall entry）：通过
sys_call_table替换或ftrace注册handler（需root + CONFIG_FTRACE=y） - 中断/异常向量（如#BP、#DB）：利用硬件断点（DR0–DR3）或单步标志（TF bit），但仅对用户态有效，且内核态触发会引发oops
- kprobe/kretprobe：Linux内核提供的安全动态插桩机制，可无侵入地在任意内核符号（含函数入口/返回）处观测寄存器上下文，RIP自动包含在struct pt_regs中
- eBPF tracepoint/kprobe：用户态通过libbpf加载eBPF程序，在内核态安全沙箱中提取
regs->ip（即当前PC），无需修改内核代码或关闭WP位
面试官真正想考察什么？
不是让你手写汇编Patch IDT，而是判断你是否理解：
- 内核可观测性的演进路径：从危险的inline hook → kprobe → eBPF
- PC值的语义依赖执行上下文：用户态RIP指向vma中的虚拟地址；内核态RIP可能指向模块.ko、builtin函数或异常向量，需结合
symbol_lookup或/proc/kallsyms解析 - 权限与稳定性边界：比如用kprobe hook do_sys_open，可在回调中安全打印
regs->ip，但若hook到__do_softirq并做复杂操作，极易引发soft lockup
一个可现场演示的合法方案（Linux）
使用kprobe观测任意内核函数的调用时PC值（以sys_read为例）：
- 编写kprobe handler，访问
struct kprobe *p, struct pt_regs *regs参数 - 在handler中直接读取
instruction_pointer(regs)（已封装为跨架构宏） - 用
printk_ratelimited输出，避免日志风暴；配合current->mm == NULL判断是否内核线程 - 编译为ko模块，insmod后触发read()系统调用即可捕获PC —— 此PC是
sys_read函数入口地址，非调用点地址；如需调用点，改用kretprobe并在kp->symbol_name设为sys_read，在handler中取regs->ip即为返回地址（即调用者PC）
Windows平台注意事项
Win10 TH2之后，SSDT hook、IDT hook、Shadow SSDT patch全部被PatchGuard实时检测并蓝屏。合规做法只有：
- ETW（Event Tracing for Windows）订阅
Process/Thread/Module事件，从中推导执行流 - 使用
Kernel-Mode Callbacks（如PsSetCreateProcessNotifyRoutineEx）获取进程上下文，再结合KeStackAttachProcess读取用户态栈帧和RIP（需谨慎处理IRQL） - Windows 11+ 支持eBPF on Windows，可通过
bpf_trace_printk输出ctx->ip（x64）
真正能落地、可调试、不触发PG/KASLR/KPTI告警的方式，从来不是“低级钩子”，而是善用内核原生可观测接口。把精力放在理解pt_regs布局、instruction_pointer()实现差异、以及eBPF verifier的限制上，比纠结如何关CR0.WP更有价值。
