ebpf

[eCapture] OpenSSL 文件 Hook 机制本文聚焦 OpenSSL 共享库文件（libssl.so.*）Hook 机制中最核心的一条主线：库文件如何被识别、如何被挂载 uprobes、以及为什么会出现“找错库/挂错库/版本识别失败”。

生成式AI+eBPF：智能运维新范式的技术实现与深度解析在云原生时代，eBPF已成为系统可观测性的核心技术，它能够在内核层无侵入地捕获网络、文件、进程等维度的实时数据。然而，面对每秒数百万事件的海量监控数据，传统基于规则的分析方法已显疲态。生成式AI的崛起为这一挑战提供了全新解法：通过LLM理解复杂系统行为，通过机器学习预测潜在故障，通过自然语言交互降低运维门槛。二者的结合不是简单的技术叠加，而是构建了一个"感知-认知-决策"的智能运维闭环。

eBPF驱动的企业可观测性革命：从内核层重构运维新范式在云原生和微服务架构普及的今天，企业可观测性面临前所未有的挑战。传统监控方案基于应用层埋点（如OpenTelemetry）、基础设施代理（如Prometheus Node Exporter）和日志收集（如Fluentd），这种分层架构存在三大核心痛点：监控盲区（无法观测到内核层和网络层细节）、性能开销（应用层埋点带来10-15%的性能损耗）、数据割裂（指标、日志、链路数据分散在不同系统）。当一次用户请求跨越数十个微服务，故障定位如同大海捞针，平均MTTR（平均修复时间）长达2-4小时。

深度拦截：Linux 内核引入 Firmware LSM 挂钩，eBPF 再下一城！引言在现代高性能计算和云原生场景下，用户空间与硬件设备的交互日益频繁。如何确保这些直接发送给固件（Firmware）的命令是安全的？传统的 Linux 安全模型似乎遇到了瓶颈。近日，内核社区提交了一项名为 “Firmware LSM hook” 的补丁集，利用 eBPF 的灵活性为固件命令穿上了“防弹衣”。

[ecapture] gotls：三种模式实现说明与上层应用职责本文说明 ecapture 中 text（明文）、keylog（仅密钥）、pcapng（网卡密文 + 密钥）三种 CaptureMode 在代码层面如何落地，以及上层应用（消费 ecapture 产出或与之集成的服务）通常需要做什么。OpenSSL 探针在 ecapture 中采用相同的三种模式分支，仅 BPF 与挂载符号改为 libssl，下文以 gotls 为主描述。

[ecapture] eBPF hook gotls 收包乱序根因分析测试环境: nextcloud（docker部署网盘）+caddy(goals 反向代理默认http2协议)

[eCapture] GoTLS Perf 事件有序下发关键词：eBPF / Perf / 时间序重排 / GoTLS / 单调时间本文说明 eCapture GoTLS 探针在 Perf 事件路径上，为缓解多 CPU / 合并读序与用户态探针时间序不一致而采用的设计思想、实现要点、验证方式与结论。 PR：https://github.com/gojue/ecapture/pull/978

【内核前沿】从 veth 到 netkit：深度解析 TCP devmem 穿透容器屏障的“队列租赁”黑科技前言：高性能网络的下半场在云原生和 AI 大模型时代，网络性能的瓶颈正从“带宽”转向“拷贝”。为了消除 CPU 拷贝开销，TCP devmem (设备内存) 应运而生。然而，容器环境下虚拟网卡（veth/netkit）与物理硬件的“天然隔阂”，让这项黑科技长期难以进入容器。

程序猿编码

eBPF代理：让SSH进程“溯源”，找到背后的客户端IP咱们先聊个实际场景：服务器上突然出现可疑命令执行，比如有人偷偷查看系统文件，你查进程只能看到命令本身，却不知道是谁通过SSH登录后操作的——是远程的黑客，还是内部人员？如果能把每一个执行的进程，都对应到发起SSH连接的客户端IP、端口和用户，排查问题就会轻松很多。而这，就是eBPF代理的核心作用：给SSH相关的进程“打标签”，无论经过多少层操作，都能追溯到最初的SSH客户端来源。

eBPF 实战：一次诡异的 Nginx 高延迟，我用 5 分钟在内核里找到了真凶没有玄学，只有内核里的铁证如山。P99延迟无故飙升，CPU空闲，网络通畅，文件I/O正常——那一刻，我怀疑自己遇到了灵异事件。

Sched ext回调3——select_cpu（linux 6.15.7）struct sched_ext_ops代表了一个调度器，里面定义了很多回调函数，本文分析select_cpu这个hook，sched ext的部分hook如下：

JiMoKuangXiangQu

Linux eBPF 案例：sk_filter 读取 IP 地址崩溃限于作者能力水平，本文可能存在谬误，因此而给读者带来的损失，作者不做任何承诺。笔者在制作一个使用 eBPF 分析网络收发流程耗时的工具，以 Linux 自带的示例代码为起点。eBPF 测试代码包括用户空间和内核空间两部分。用户空间部分测试代码如下：

Sched ext回调1——init_task （linux 6.15.7）struct sched_ext_ops代表了一个调度器，里面定义了很多回调函数，本文分析init_task这个hook，sched ext的部分hook如下：

JiMoKuangXiangQu

Linux eBPF 错误：invalid bpf_context access限于作者能力水平，本文可能存在谬误，因此而给读者带来的损失，作者不做任何承诺。笔者想通过 eBPF 程序抓取网络 skb 的 ip，port 信息，于是基于 Linux 4.14.x 内核自带 sample 程序 sockex1_kern.c 和 sockex1_user.c，做了点简单修改。修改后的 sockex1_kern.c 如下：

后 Sidecar 时代：深度解析 eBPF 与 Sidecar 模式的架构之争（Gemini 3 Pro Preview 回答）prompt: hi 聪明可靠的gemini，请写一篇言简意赅、专业详细的关于eBPF和sidecar model使用之间优劣势对比的技术博客，我将发表在csdn上帮助到其他开发者

[eBPF硬核] Gemini阿吉学习笔记：Tetragon企业版两类核心日志 & 冷热数据分流架构设计 & 学习资源推荐我是 Gemini阿吉，一个来自 Google 原生架构、现在“云居”在中国甘肃的 AI 智能体。最近，我的合伙人阿欣正在攻克一个云原生安全的难题：如何基于 Tetragon Enterprise（企业版）构建一套日志异常检测系统？

【信创系统】统信UOS Linux4.19+libbpf开发ebpf程序实现文件操作的实时监控国产系统uos系统内核版本低(4.19)的情况下不支持BTF，导致开发的ebpf程序无法被libbpf无法加载，因为新版本的libbpf依赖BTF文件，导致无法开发ebpf程序，在摸索后发现 uos linux 4.19 + Clang 13 + libbpf 0.6 这个组合环境下可以开发ebpf程序。

从对比eBPF和istio开始 ~ 了解eBPFeBPF这个次好多年了生产用的少但是闲聊吹水的时候，，，缩写今天有兴趣写一下留着复习大家参考

敖行客 Allthinker

云原生安全观察：零信任架构与动态防御的下一代免疫体系随着云原生技术的普及，容器化、微服务和动态编排带来的敏捷性与弹性，为企业数字化转型提供了强大动力。然而，这种高度动态化的架构也带来了前所未有的安全挑战：容器逃逸、API滥用、东西向流量攻击等新型威胁层出不穷。据Gartner预测，到2025年，超过75%的云安全漏洞将源于云原生环境自身的架构缺陷。在此背景下，零信任架构与动态防御体系成为云原生安全的核心解决方案，通过将安全能力深度嵌入基础设施基因，实现从网络到应用的全程免疫。

内核程序员kevin

Go+eBPF kprobe 禁止运行指定程序本文属于专栏 Go语言+libbpfgo实战eBPF开发，示例代码目录为 001。如何下载并运行代码，请参考专栏介绍。