热补丁激活流程优化(WO_FTRACE实现)

【特性描述】
## 功能
本特性是基于CONFIG_LIVEPATCH_WO_FTRACE实现下的热补丁激活流程优化，对基于CONFIG_LIVEPATCH_FRACE的实现不影响。特性通过在被打补丁函数入口插入断点异常，引流对旧函数的调用，提升栈检查通过概率，进而提升热补丁激活成功率。

## 方案
下面描述基于CONFIG_LIVEPATCH_WO_FTRACE实现。

内核热补丁提供了force选项，以调整激活（enable）热补丁时栈检查的宽松程度，当前支持如下设置：
- force = 0: 保证旧函数（需要被打补丁的函数）不在所有任务的栈上，会严格检查旧函数的每一条指令，有最强的一致性保证，对比较热点的函数，打补丁成功率低
- force = 1：不进行栈检查，强制激活补丁，此时旧函数指令替换区（插入跳转指令时原函数会被覆盖的指令）的某个pc在栈上，强制指令替换可能会造成系统crash，并且没有一致性保证
- force = 2：只检查旧函数指令替换区的指令是否在栈上，只要指令替换区不在栈上就进行指令替换。因为指令替换区通常在函数的prologue中，而prologue中一般不会生成函数调用，所以指令替换区不会处于调用栈的中间，优化后激活成功率会有提升，并且能避免上面描述的force=1时造成系统crash的情况。但这样会允许系统中同时存在旧函数与新函数调用，即便是同一任务的调用栈，也可能出现新旧两个版本的函数，安全性有所降低。

force=2时热补丁激活流程:
![force=2时热补丁激活流程](https://images.gitee.com/uploads/images/2022/0616/101524_50632953_8933178.png "屏幕截图.png")

基于force=2的实现，可以进一步进行激活流程优化。在某些架构下指令替换区会有几条指令，比如ppc64有8条指令、arm开启module_plt支持时有4条指令等。如果热点函数被反复调用，stop machine时任务可能反复在指令替换区被抢占，热补丁就会反复激活失败。针对这个问题，可先在旧函数入口插一条breakpoing指令，此后内核再调用到旧函数时就会触发breakpoint，breakpoint的handler中拦截执行流，避免反复进入旧函数。此时整体流程大致如下：
![插入breakpoint引流旧函数时热补丁激活流程](https://images.gitee.com/uploads/images/2022/0616/101650_cc05c9a9_8933178.png "屏幕截图.png")

同时，要求对需要打补丁的函数全部设置force=2才启用特性优化。

【硬件架构】
x86、arm64、arm32、ppc64、ppc32

GVP openEuler/kernel

内容风险标识

评论 (2)

GVPopenEuler/kernel

内容风险标识