热补丁依赖识别及加载优化

作品完成和提交方式：选择本赛题的参赛队伍需要首先复刻（Fork）本项目，然后在复刻的项目中添加参赛队员、合作完成作品开发即可，无需提交PR到赛题项目。如果作品为文档形式，也请将作品文档提交到项目代码库中。在作品完成过程中，围绕作品的相关讨论等可以以疑修（Issue）形式发布和讨论，也可使用里程碑对整个任务进行规划管理。

1. 赛题说明

内核热补丁是系统运行时对内核进行修改的一种技术。与传统的内核冷补丁不同，内核热补丁不需要重新编译内核，也不需要重启系统，可以在不停机的情况下实现对内核的修改和更新。内核热补丁技术的实现原理是通过在内核中插入一段代码，这段代码可以在内核运行时被执行，从而实现对内核的修改。这种技术可以用于修复内核中的漏洞，增加新的功能或者改进内核性能等方面。 openEuler使用了kpatch内核热补丁技术，并在其上使用自研syscare技术进行封装，实现用户态、内核态热补丁的统一管理。然而，内核热补丁往往依赖了部分内核模块，导致加载时缺依赖报错。如何及早识别内核热补丁的依赖，并结合syscare实现依赖满足时的自动加载呢？ 在这个赛题中，参赛者需基于openEuler 22.03-LTS-SP3分支的kpatch和syscare代码进行设计开发，实现内核热补丁依赖识别与加载过程的优化。

2. 赛题要求

1)热补丁依赖元数据补充 参赛者需基于kpatch原有代码，在热补丁ko生成时将依赖信息注入其元数据中，使用户可以通过modinfo直接看到热补丁所需依赖，而非只能查看制作日志或激活后再通过livepatch -q进行查看。 2)热补丁缺失依赖识别 完成任务1后，参赛者需基于syscare原有代码进行优化，在热补丁加载前添加检查逻辑，通过热补丁ko的依赖信息提前判断当前依赖是否满足。若依赖不满足，则在终端界面提示缺失的所有依赖。 3)热补丁自加载 完成上两点后，参赛者需设计一套机制，监控热补丁依赖的内核模块的加载状态，当所有依赖满足时，自动加载满足条件的热补丁。这样既实现了热补丁的自动加载，又不会在加载时额外加载依赖，导致系统行为发生变化。 注意： a)参赛者无需修改现有热补丁状态机，依赖不满足的待加载热补丁可置为已激活。 b)不推荐使用额外进程或线程的形式轮询监测内核模块列表。 c)系统开销应尽可能低，在x86环境，22.03-LTS-SP3的openEuler操作系统上，cpu使用率小于1%

3. 赛题导师

zhuyuncheng@huawei.com; xiaobo.liu@huawei.com

4. 参考资料

1)kpatch制品仓及使用文档（https://gitee.com/src-openeuler/kpatch/tree/openEuler-22.03-LTS-SP3/） 2)syscare制品仓（https://gitee.com/src-openeuler/syscare/tree/openEuler-22.03-LTS-SP3/） 3)syscare使用文档 （https://gitee.com/openeuler/syscare）