Skip to content

Latest commit

 

History

History
32 lines (20 loc) · 5.82 KB

File metadata and controls

32 lines (20 loc) · 5.82 KB

遇到的困难

在项目开发中我们遇到了以下困难:

  • 技术选型:在项目初期,我们构思了数种项目架构,有全部在内核态中通过kfence实现,也有全部在内核态中使用eBPF实现。在选择使用用户态之后,也尝试过开发基于源代码/AST分析的静态开发器,抑或是参考valgrind方式的动态分析,但是很多思路和想法都被证实了实现难度过大。但是经过不断阅读代码与调研,我们最终选择了基于IR的符号执行静态分析器,基于asan的动态检测器以及基于eBPF的内核采样器的三层思路架构。
  • 团队协作:在项目初期,团队成员之间的协作不够紧密,同时由于技术选型还没有确立,基础代码框架还没有写好等等问题,项目前期进展缓慢。但是经过了数月的磨合以及项目体系不断完善,团队协作逐渐变得紧密,大家的分工也越来越明确。
  • 代码问题:在项目开发过程中,曾经数次因为静态检测器的方向或性能问题停滞,前后经过了多次大幅度的重构代码,最终实现了现在颇有成效的静态分析器。动态分析器则因为asan代码复杂冗长难以阅读,llvm-project过于庞大难以调试等问题开发进度缓慢,经过了多次尝试最终实现了现在的动态分析器。
  • 时间问题:由于项目周期长,以及课内学业压力,我们在项目开发过程中多次因为时间问题而停滞,甚至有一段时间因为期末考试的压力而暂停了项目开发。

静态检测器

  • 性能问题: 在静态检测器的开发过程中,我们曾经尝试过多种路径选择算法,例如DFS、BFS、随机选择等,但是由于这些算法均无法有效地避免路径爆炸问题,导致程序在中等规模以上的测试集上均无法在合理时间内完成符号执行。经过调研,我们最终选择了MPC算法,并通过对程序进行预处理(例如循环展开、函数内联等)来进一步提升符号执行效率,最终实现了在大部分测试集上均能在合理时间内完成符号执行。

  • 测试困难:在编译各种测试集与开源项目时,由于需要编译到LLVM IR以及其他系统适配问题,导致我们在测试过程中遇到了诸多困难,例如编译错误、链接错误等问题。经过不断调试与查阅资料,我们最终解决了这些问题,并成功地在多个测试集与开源项目上进行了测试。

  • 代码复杂度问题:在静态检测器的开发过程中,由于需要处理各种复杂的程序结构与语法,导致代码复杂度较高,难以维护与扩展。为了解决这个问题,我们通过模块化设计与代码重构来提升代码的可读性与可维护性,同时也编写了详细的文档来帮助团队成员理解代码逻辑。

动态检测器

  • asan源码复杂:在动态检测器的开发过程中,由于asan源码复杂冗长,导致我们在阅读与理解代码时遇到了诸多困难。为了解决这个问题,我们通过查阅相关文档与资料,逐步理解了asan的工作原理与实现细节,最终成功地实现了动态检测器。

  • llvm-project庞大:在动态检测器的开发过程中,由于llvm-project过于庞大,编译时间长,代码理解复杂,各个模块间可能存在影响,学习成本高等问题,导致我们在调试与测试过程中遇到了诸多困难。为了解决这个问题,我们通过查阅相关文档与资料,逐步理解了llvm-project的结构与模块划分,最终成功地实现了动态检测器。

  • 性能问题:在动态检测器的开发过程中,由于asan本身的性能开销较大,导致我们在测试过程中遇到了性能瓶颈。为了解决这个问题,我们通过优化代码逻辑与数据结构,尽可能地减少asan的性能开销,同时也通过选择合适的测试集来提升测试效率。

系统采样器

  • 测试集选取: 在采样器部分开发初期,采用了juliet-test-suite-c作为测试集,但是由于该测试集程序大多规模极小,不符合采样器监控长期运行泄漏的场景要求,经过筛选,我们最后使用了具备一定程序规模和多种应用场景的SPEC CPU2006作为测试集。
  • 目标与采样器交互的设计: 我们尝试过多种交互设计方案,例如通过管道在多目标程序与采样器之间传递数据,但存在严重的数据损失,并且交互逻辑极其混乱。多番尝试以后,我们最后采用共享内存的方式(Pinned BPF Map)进行通信,高效且可靠地传递数据。
  • 特征工程设计:在采样器部分开发初期,我们对于特征工程提取的设计并没有清晰且足够可靠的思路,曾尝试过直接利用原始分配事件作为数据集进行训练,经过了对时序分析法和相关论文的学习,我们最终设计了将特征分类为即时特征和窗口特征进行提取、采用按Epoch存储数据的数据压缩逻辑、用滑动窗口的方式进行时间序列数据的处理的方案。
  • 机器学习模型选取:在采样器我们使用了随机森林等模型进行回归预测,但由于回归模型标签与程序规模高度相关,同时随机森林并不适合滑动窗口提取的时序特征分析,导致模型训练效果极差。经过调研,我们最终选择了LightGBM分类模型,并通过编写脚本调参批量训练模型和特征工程的改进,极大的提升了预测精度。
  • 开发周期问题: 采样器部分在决赛阶段启动编写,开发周期短,同时开发期间model.py, dataproc.py等核心模块还经历了大幅度重构,导致了部分功能未能及时实现,尤其是预测泄漏后目标程序如何处理泄漏,截至决赛交稿仍未设计出可行有效的方案。