一、引子

一个月前写过一篇总结，主要是对自己在前段时间遇到的一些问题的分析以及对破局之法的思考，其中解决措施这块的主要思想为“确立目标和航线”，目标是指自己人生道路上的终极目标，且必须为整体的、抽象的、本质的，“航线”为目标的拆分，是达到指定目标的方式，为局部的、具体的、可落地的；总结中回忆起了自己从小到大的经历，通过对过去每一件记忆中的小事进行分析，定位自己的初心，思考自我在人生层面上应当去确立和实现的目标，并在最终定下了专属于自我的独特人生意义，以及给出了一些具体可落地的未来规划；也希望在未来能将这些规划坚持执行下去，真正贯彻和落实自己人生总目标。半个月前，非常偶然读到了伟人青年时代写给友人的一封信，发现其部分所述和自己所想相合，读到精彩处更是非常惊讶，感叹历史上竟有人和自己思考过同一样事物，并产生了相似的看法；读完全文在感慨伟人之豪迈、眼光之长远、气量之大的同时也对伟人的生平产生了浓厚的兴趣，遂读<<毛泽东传>>，颇有感悟，目前已读到第一卷21章（国共建立统一战线联合抗日那个时期），后面难再读下去了，相比中年时代的伟人，青年时期的伟人经历和思想显然更吸引自己。扯远了，这边记录下伟人写给友人的信原文，并记录下感悟。

一、前言

之前记录了sysdig驱动部分的源码理解，还缺少用户态的捕获解析过程的分析，这边补上。因为真实的项目中没有用到sysdig的CLI解析引擎，而是自研的，所以关于libsinsp部分针对具体事件的解析过滤逻辑相关的源码分析将不会去进行（或者是等后续需要的时候）。

一、前言

前段时间老大说想对驱动做下benchmark，主要有如下几个原因：

1、在（灰度）推广前对驱动在跟踪特定syscall event下的overhead（开销）有大致的了解，从而对某些造成tracepoint handler较高overhead的syscall tracepoint采取默认关闭策略，避免对业务产生影响

2、字节之前开源的Elkeid（前Agent-smith）中有输出driver的性能测试报告，可以与其做下对比，也好有个底（字节的驱动部署量级很高）

目标确定后开始测试流程，一开始是参照Elkeid使用trace-cmd（ftrace） + LTP测TP90/95/99（Top Percentile），结果发现Elkeid的测试方式这边并不适用（主要是因为elkeid采用了kprobe选型，针对每一个syscall都有特定的kprobe handler，这些注册的hook函数可以被ftrace跟踪到；但是这边的驱动走的是tracepoint，而且是在sys_enter/sys_exit的系统调用总出入口处做的hook，所以在ftrace的观测视野中，只能看到对sys_enter/sys_exit对应tracepoint handler的执行耗时，但却没有办法将其对应到指定系统调用事件），中途踩了许多坑（主要是验证测试方式及数据可靠性上的，甚至一度放弃ftrace使用perf与systemtap，但是最终对比之下还是回到了ftrace上），甚至在测试过程中发现Elkeid自身的测试方式可能存在问题，过程还挺曲折//捂脸，最终将测试过程自动化，输出了一份性能测试报告；当然这些扯远了。之所以想记录这篇文章，主要是在测试过程中感受到了ftrace能力的强大，不仅可用于性能分析，还可以在日常研究学习中用于内核函数/代码执行流程观测，来代替动态调试的繁琐（当然主要还是得看场景，动调也有其自己的优势，但是如果只是想看控制流的话ftrace还是非常方便的），甚至ftrace从功能上来说本身都可直接用于IDS上（kprobe on ftrace的一些高级用法）；此篇主要记录ftrace观测kprobe和tracepoint函数的过程，目的主要是1、记录ftrace的使用方式 方便后面回忆 2、以可视化的方式（graph）展示kprobe与tracepoint的执行流程，加深对这两种机制的记忆与理解。

一、前言

公司hids平台目前的事件监控维度相对较少，于是老大借鉴sysdig手撸了一个内核模块从kernel解析syscall事件，以此增加监控的事件类型，也为后续的产品检测能力增强提供了数据基础。但是dalao手撸的内核模块存在一些bug，在帮dalao找bug、保证内核模块稳定性的过程中深入了解了sysdig这个项目本身的一些代码层面的东西，同时也解开了之前看falco时候的许多代码执行流程上的困惑，非常愉悦，这边做下记录和总结。

一、前言

前言

当agent涉及内核模块捕获事件时，具体事件如何吐给工作在用户态的agent事件捕获引擎并由其进行后续的事件处理？这个问题涉及到linux内核中一个非常经典的部分，即进程间通信；linux进程间通信的方式非常多，在入侵检测领域下这种内核态-用户态的通信需求场景中最常用到的通信手段包括但不限于如下三种：1、netlink 2、共享内存 3、ioctl；使用netlink最典型的例子是yulong，这块在之前的博客中有记录，yulong在driver层会将事件放到skb中通过netlink发送到用户态监听指定端口的进程，是目前效率最高且优雅的一种内核-用户通信方式；其次是mmap共享内存，常见的如agent-smith、sysdig等都是使用这种通信模式将内核事件类消息发送出去，是效率高，但缺少消息同步机制；最后是ioctl，这种通信方式比较老，文档齐全、编码简单，但是存在拷贝动作，不适合大批量数据的传输，且必须用户态程序先发出ioctl信号，常用于用户态对驱动模块的控制等；这篇文章记录下共享内存这块的学习过程和相关资料。

kprobes简介

1
2
3

KProbes is a debugging mechanism for the Linux kernel which can also be used for monitoring events inside a production system. You can use it to weed out performance bottlenecks, log specific events, trace problems etc. KProbes was developed by IBM as an underlying mechanism for another higher level tracing tool called DProbes. DProbes adds a number of features, including its own scripting language for the writing of probe handlers. However, only KProbes has been merged into the standard kernel.
...
The figure to the right describes the architecture of KProbes. On the x86, KProbes makes use of the exception handling mechanisms and modifies the standard breakpoint, debug and a few other exception handlers for its own purpose. Most of the handling of the probes is done in the context of the breakpoint and the debug exception handlers which make up the KProbes architecture dependent layer. The KProbes architecture independent layer is the KProbes manager which is used to register and unregister probes. Users provide probe handlers in kernel modules which register probes through the KProbes manager.

Kprobes是Linux内核的一种调试机制，可以用来在生产环境中监控内核事件，其允许使用者在内核指定位置注册自定义的回调函数，捕捉内核事件、对内核信息进行过滤、分析，达到内核观测的效果。kprobes这种内核追踪机制常用于性能、安全监控领域，最常见的，比如用于hids/cwpp/edr的agent；本质上，他和替换系统调用表这种比较暴力的开膛破腹式的监控手段不同（典型的如yulong），内核机制的支持使其相对比较稳定和优雅（虽然不如ebpf），如果probe点合适（字段不经常变更），且兼容性足够好，那么将kprobes用在agent模块上则会使agent获得性能、安全（绕过相对用户态较难）的双重优势，典型如开源项目agent-smith，目前agent已在字节大量部署，据说部署规模有10w+；不再赘述，记录下核心知识点的学习过程。