谢欢，大家可以叫我Jeff, 我目前就职于某国际知名linux发行版开源公司， 热衷于linux内核。我平时把linux内核源码当小说一样阅读学习，也一直把能给linux社区贡献更多有质量的代码而努力。
问题场景： 云计算IaaS平台上，经常使用libvirt+qemu-kvm做基础平台。libvirt会在/etc/libvirt/qemu/目录下，保存很多份qemu的配置文件，如ubuntu.xml。 作者发现其中的配置文件会在特定的场景下被修改，却不知道哪个进程是凶手。为了找到凶手，作者写下了这个debug工具。 代码分析： 代码路径：https://github.com/pacepi/whotouchmyfile #include <linux/kernel.h> #include <linux/mo
Linux 内核在 2022 年主要发布了 5.16-5.19 以及 6.0 和 6.1 这几个版本，每个版本都为 eBPF 引入了大量的新特性。本文将对这些新特性进行一点简要的介绍，更详细的资料请参考对应的链接信息。总体而言，eBPF 在内核中依然是最活跃的模块之一，它的功能特性也还在高速发展中。某种意义上说，eBPF 正朝着一个完备的内核态可编程接口快速进化。
kprobe 是一种动态调试机制，用于debugging，动态跟踪，性能分析，动态修改内核行为等，2004年由IBM发布，是名为Dprobes工具集的底层实现机制[1][2]，2005年合入Linux kernel。probe的含义是像一个探针，可以不修改分析对象源码的情况下，获取Kernel的运行时信息。
Linux 存在众多 tracing tools，比如 ftrace、perf，他们可用于内核的调试、提高内核的可观测性。众多的工具也意味着繁杂的概念，诸如 tracepoint、trace events、kprobe、eBPF 等，甚至让人搞不清楚他们到底是干什么的。本文尝试理清这些概念。
Linux内核调试技术——kprobe使用与实现（五）-触发kprobe探测和回调
某机器上网络出现时断时续的问题，网络的同事发现ovs进程的CPU消耗很高，硬件offload的规则下发卡住的问题。即通过netlink向内核发送消息卡住。
Linux内核调试技术——kprobe使用与实现（四）--kprobe内核注册过程
kprobe机制用于在内核中动态添加一些探测点，可以满足一些调试需求。本文主要探寻kprobe的执行路径，也就是说如何trap到kprobe，以及如何回到原路径继续执行。
对于kprobe功能的实现主要利用了内核中的两个功能特性：异常（尤其是int 3），单步执行（EFLAGS中的TF标志）。
前言：之前的文章介绍了基于 tracepoint 静态追踪技术的实现，本文再介绍基于 kprobe 的动态追踪即使的实现。同样，动态追踪也是排查问题的利器。
开发人员在内核或者模块的调试过程中，往往会需要要知道其中的一些函数有无被调用、何时被调用、执行是否正确以及函数的入参和返回值是什么等等。
利用linux kernel 动态追踪技术，排查问题本身就可能会变成一个非常有趣的过程，让我们遇到线上的诡异问题就感到兴奋，就仿佛好不容易又逮着机会，可以去解一道迷人的谜题。
在《Linux 内核调试利器 | kprobe 的使用》一文中，我们介绍过怎么使用 kprobe 来追踪内核函数，而本文将会介绍 kprobe 的原理和实现。
忽然想起的回忆，那是2007上周五在冬季，我看我的老湿调试Linux堆IP层，只看到他改变路由查找的逻辑，然后直接make install上的立竿见影的效果有点，我只知道，，这种逻辑必须再次更改编译内核。再一次，他没有编译，就像刚才编译的文件…时又无聊的工作阻碍了我对Linux内核的探索进度，直到今天，我依旧对编译内核有相当的恐惧，不怕出错，而是怕磁盘空间不够，initrd的组装拆解之类，太繁琐了。我之所以知道2007年的那天是周五，是由于第二天我要加班。没有谁逼我。我自愿的，由于我想知道师父是怎么做到不又一次编译内核就能改变非模块的内核代码处理逻辑的。第二天的收获非常多，不但知道了他使用了“镜像协议栈”。还额外赚了一天的加班费。我还记得周六加完班我和老婆去吃了一家叫做石工坊的羊排火锅。人家赠送了一仅仅绿色的兔子玩偶。
在上一篇文章中介绍了内核加载的方式使用kprobe的方法，现在介绍一下使用debugfs接口使用kprobe的方法。
我们可以使用BPF对Linux内核进行跟踪，收集我们想要的内核数据，从而对Linux中的程序进行分析和调试。与其它的跟踪技术相比，使用BPF的主要优点是几乎可以访问Linux内核和应用程序的任何信息，同时，BPF对系统性能影响很小，执行效率很高，而且开发人员不需要因为收集数据而修改程序。
前言：ebpf 是现代 Linux 内核提供的非常复杂和强大的技术，它使得 Linux 内核变得可编程，不再是完全的黑盒子。随着 ebpf 的发展和成熟，其应用也越来越广泛，本文介绍如何使用 ebpf 来追踪 Node.js 底层的代码。
这周帮朋友用 eBPF/SystemTap 这样的动态 tracing 工具做了一些很有趣的功能。这篇文章算是一个总结
eBPF (Extended Berkeley Packet Filter) 是 Linux 内核上的一个强大的网络和性能分析工具。它允许开发者在内核运行时动态加载、更新和运行用户定义的代码。
在日常分析外部软件时，遇到的反调试/反注入防护已经越来越多，之前使用的基于 frida 的轻量级沙盒已经无法满足这类攻防水位的需要，因此需要有一种更加深入且通用的方式来对 APP 进行全面的监测和绕过。本文即为对这类方案的一些探索和实践。
网络攻击者通常会利用被攻击网站中存在的漏洞，通过在网页中植入非法暗链对网页内容进行篡改等方式，进行非法牟利或者恶意商业攻击等活动。网页被恶意篡改会影响用户正常访问网页内容，还可能会导致严重的经济损失、品牌损失甚至是政治风险。
Linux kprobes调试技术是内核开发者们专门为了便于跟踪内核函数执行状态所设计的一种轻量级内核调试技术。利用kprobes技术，内核开发人员可以在内核的绝大多数指定函数中动态的插入探测点来收集所需的调试状态信息而基本不影响内核原有的执行流程。kprobes技术目前提供了3种探测手段：kprobe、jprobe和kretprobe，其中jprobe和kretprobe是基于kprobe实现的，他们分别应用于不同的探测场景中。本文首先简单描述这3种探测技术的原理与区别，然后主要围绕其中的kprobe技术进行分析并给出一个简单的实例介绍如何利用kprobe进行内核函数探测，最后分析kprobe的实现过程（jprobe和kretprobe会在后续的博文中进行分析）。
Linux kernel 的 kretprobe 机制和 kprobe 完全不同，本质原因在于，函数的入口地址是固定的，但函数的返回地址不固定，由于返回位置不固定，无法固定函数大小，无法事先插桩。一图以示之:
BPF (Berkeley Packet Filter) 最早是用在 tcpdump 里面的，比如 tcpdump tcp and dst port 80 这样的过滤规则会单独复制 tcp 协议并且目的端口是 80 的包到用户态。整个实现是基于内核中的一个虚拟机来实现的，通过翻译 BPF 规则到字节码运行到内核中的虚拟机当中。最早的论文是这篇，这篇论文我大概翻了一下，主要讲的是原本的基于栈的过滤太重了，而 BPF 是一套能充分利用 CPU 寄存器，动态注册 filter 的虚拟机实现，相对于基于内存的实现更高效，不过那个时候的内存比较小才几十兆。bpf 会从链路层复制 pakcet 并根据 filter 的规则选择抛弃或者复制，字节码是这样的，具体语法就不介绍了，一般也不会去直接写这些字节码，然后通过内核中实现的一个虚拟机翻译这些字节码，注册过滤规则，这样不修改内核的虚拟机也能实现很多功能。
weavescope是一款Docker 和 Kubernetes 的可视化和监控工具，WeaveScope 监控展示了主机、容器、进程的众多常用数据和状态，并提供 WebUI 帮助我们进行基本的管理操作，并且在整个过程中不需要进行额外的配置，易于上手使用。同时，WeaveScope 提供插件和插件机制方便我们进行扩展，可以说，WeaveScope 是我们初期搭建容器监控管理系统的极佳选择。
Linux阅码场内核月报栏目，是汇总当月Linux内核社区最重要的一线开发动态，方便读者们更容易跟踪Linux内核的最前沿发展动向。
当今，可观测性领域正在经历一场颠覆性的转变，其中核心驱动力便是 “eBPF”（扩展伯克利数据包过滤器）技术。作为下一代改革先锋，eBPF 技术正在彻底改变我们对系统观测和监控的认知。在之前的文章中，我们已经详细介绍了 eBPF 技术及其对可观测性的影响。
bpftrace提供了一种快速利用eBPF实现动态追踪的方法，可以作为简单的命令行工具或者入门级编程工具来使用。本文以bpftrace为例，介绍如何利用eBPF实现内核的动态追踪。
在本系列的前一篇文章中，我讨论了如何使用eBPF安全地运行内核内用户空间提供的代码。然而，对于新手来说，eBPF最大的挑战之一是编写程序需要编译并从内核源代码链接到eBPF库。内核开发人员可能总是可以获得内核源代码的副本，但是对于在生产环境机器或客户机器上工作的工程师来说，情况就不一样了。解决这个限制是创建BPF编译器集合的原因之一。该项目包括用于编写、编译和加载eBPF程序的工具链，以及用于调试和诊断性能问题的示例程序和久经考验的工具。
Linux kprobes调试技术是内核开发者们专门为了便于跟踪内核函数执行状态所设计的一种轻量级内核调试技术。利用kprobes技术，内核开发人员可以在内核的绝大多数指定函数中动态的插入探测点来收集所需的调试状态信息而基本不影响内核原有的执行流程。kprobes技术目前提供了3种探测手段：kprobe、jprobe和kretprobe，其中jprobe和kretprobe是基于kprobe实现的，他们分别应用于不同的探测场景中。
在介绍eBPF (Extended Berkeley Packet Filter)之前，我们先来了解一下它的前身－BPF (Berkeley Packet Filter)伯克利数据包过滤器。
BCC是一个用于跟踪内核和操作程序的工具集，其软件包中包含了一些有用的工具和例子，它扩展了BPF(Berkeley Packet Filters)，通常被称为eBPF , 在Linux3.15中首次引入，但大多数BCC的功能需要Libux4.1及以上版本。
在云函数的日常运营中，经常有用户提出要求协助排查网络问题。一般的手段就是使用 tcpdump 抓包，但是部署抓包往往是在问题发生之后，而且抓包后复现的时机也不确定，往往费时费力。本文讲述使用 BPF 记录 TCP 的重传和丢包记录，作为定位网络问题的一种辅助手段。
Linux内核如何替换内核函数并调用原始函数 ：https://blog.csdn.net/dog250/article/details/84201114
不需要写main函数，目前知道可以写两种函数，以“kprobe__”开头的函数和自定义函数。bpf函数至少要包含一个参数“ctx”，即使不使用也应该存在，可以声明为“void *ctx”。
前言： 互联网后台的服务器上，通常需要运行多达数百个进程，甚至更多。 有一天，运维兄弟突然找上门，说：xx服务器上为什么要访问yy服务（例如yy服务使用UDP的12345端口）？ 开发一脸懵逼：没有呀！并不是我部署的服务访问的。。。 运维兄弟：我不管，这台机器分配给你了，你要负责，要不你抓包看看？ 开发兄弟娴熟的一手tcpdump -iany -Xnnls0 udp port 12345：哎呦我去，还真有进程在访问，but，是哪个进程呢？UDP无连接，netstat是没有办法了，tcpdump只能证明有包发
几乎所有编程接口都可见于：内核源代码的include/uapi/linux/bpf.h文件中
本文主要用于演示基于 ebpf 技术来实现对于系统调用跟踪和特定条件过滤，实现基于 BCC[1] 的 Python 前端绑定，过程中对于代码的实现进行了详细的解释，可以作为学习 ebpf 技术解决实际问题的参考样例。
eBPF (Extended Berkeley Packet Filter) 是一项强大的网络和性能分析工具，被应用在 Linux 内核上。eBPF 允许开发者动态加载、更新和运行用户定义的代码，而无需重启内核或更改内核源代码。
本文不会介绍eBPF和bcc的由来和历史，而是会基于bcc文档中的例子来介绍与学习ebpf和bcc。
Systemtap 使用了类似于 awk 和 C 语言的脚本语言（类似于 Dtrace 的 D 语言）。
作者 | 许庆伟 策划 | 凌敏 随着 eBPF 技术在各种行业领域上的使用和普及，人们在享受着技术变革红利的同时，也遭受着无孔不入的恶意攻击。就像任何事物都有两面性一样，没有任何一项技术只有高高在上的优势，而没有弊端。只有更加清晰地剖析清楚 eBPF 的内核，才能推动它不断地进步，趋利避害，尽可能发挥正向的作用。 1 eBPF 的安全能力是检验其可持续发展的重要指标 日益严峻的 Linux 安全形势 根据安全分析机构 ESG 云原生安全研究，88% 的网络安全专业人士表示，在过去 12 个
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
实时音视频
即时通信 IM
对象存储
