开发动机

目前主流的调试工具依赖于ptrace接口，需要2个进程通过信号来互相唤醒处理调试事件。简单考察一次单点命中，目标tracee+trace线程至少需要 3次 用户/内核上下文切换：

{tracee执行直到命中hwbp_trap}
-[上下文切换，同步处理]->
（储存信号，唤醒tracer睡眠）
-[上下文切换+异步进程调度]->
{tracer被唤醒处理，重新执行tracee程序}
-[上下文切换+异步进程调度]->
{tracee重新开始运行}

符号标志意义为：[上下文开销] {用户态执行内容} (内核态执行内容)

可以看到上下文开销中直接由硬件异常导致的上下文切换是同步的，耗时较少，但是睡眠和唤醒tracer、tracee是一个不小的开销，并且tracer的处理函数需要反复使用ptrace调用陷入内核态以获取tracee的内存+寄存器信息,实际的运行开销比这里只考虑做ptrace_cont的场景更大。但是呢，为了能够在tracer线程里灵活执行可修改的调试操作，好像又是只能依赖这一套反复唤醒和切换的流程。对...对吗？

也并不一定，如果内核硬件调试异常的handler中直接把这个异常给处理完了，然后直接返回用户态，

{tracee执行直到命中hwbp_trap}
-[上下文切换，同步处理]->
（丢弃信号，内核内处理异常，硬件断点更新，直接返回用户态）
-[上下文切换，同步处理]->
{tracee重新开始运行}

这样的切换开销最多只是2次同步上下文切换，相比之下就是飞速。那么怎么实现可修改的异常处理功能呢？不妨把lua脚本植入进内核。查了下git，果然在内核层跑解释器语言这种烂点子已经有人想过。

技术要求

• 有可完整编译的kernel源码
• 编写内核模块的makefile与kconfig选项
• 植入内核lua运行环境lunatik
• 写好常用于在lua中调用的c接口:
  • hwbp_trap_handler（long current_pc，lua_runtime）处理硬件暂停，转发lua脚本接口
  • mem_accessor_b64(addr,base64str,write)包装调用函数 access_process_vm，以base64格式输入读出，访问用户态内存
  • regs_accessor（type，index，write） 获取/修改用户态各种类型的寄存器信息
  • install_hwbp_at(addr,pid,enabled) 执行断点安装/卸载
  • install_hwwp_at(addr,pid,enabled) 内存读写访问断点
• 改写特定的系统调用，用于向内核传入lua脚本字符串，以配置对应的hwbp_trap_handler中实现的功能
• 将硬件调试中断的处理导入通用lua处理函数，然后立即清除线程异常状态返回用户态

实践用例

未完待续...后续可以给大家演示一下常见的几个骚操作,包括

• JumpKing.lua，命中断点后跳转进入任意位置代码继续执行
• hookEnter.lua 函数入口hook
• hookRet.lua 函数返回hook
• DepthTracer.lua 有限制调用栈的函数trace
• v_vdso.lua 仿vdso用户空间映射动态可执行库
  ...