ebpf

质检员与超能引擎的碰撞：KASAN 护航 eBPF JIT 的技术演进与安全抉择在 Linux 内核开发与现代云原生技术交织的演进中，内核地址消毒剂（KASAN）与扩展版伯克利包过滤器（eBPF）分别扮演着“质检员”与“超能引擎”的角色。

走向长时运行：引入协程（Coroutines），打破 BPF 程序的“一堂到底”限制在 Linux 内核生态中，BPF（Berkeley Packet Filter）程序因其高性能与安全性，已被广泛用于扩展网络、安全追踪及可观测性等多个内核子系统。然而，长久以来 BPF 留有一个底层硬性限制：BPF 程序必须在启动时的同一个上下文中“一鼓作气”地运行至结束。

BPF 的进化史：从网络过滤器到 AI 时代的 Linux 核心引擎eBPF（Extended Berkeley Packet Filter）是现代 Linux 内核中一项革命性的技术。它允许开发者在不修改内核源代码、也不加载内核模块的情况下，安全、动态地在内核空间运行沙盒程序。

面朝大海，春不暖，花不开

BPF与eBPF简介：核心概念与观测工具概览BPF（Berkeley Packet Filter）最初于1992年由Steven McCanne和Van Jacobson提出，旨在提升网络包捕获工具的性能。它通过在内核中运行精简的指令集，只复制用户感兴趣的数据包，显著降低了数据拷贝的开销。经过二十多年的发展，2013年Alexei Starovoitov提出对BPF进行重大重写，随后与Daniel Borkmann共同完善，于2014年合入Linux内核主线。这一新版本被称为eBPF（Extended BPF），但官方缩写仍统一为BPF。如今的BP

Sched_ext 回调深度解析（八）：running —— 任务开始执行（6.18.26）基于 Linux 6.18.26，结合内核源码逐行分析系列文章：框架背景与回调总览见前言，本文聚焦 running 回调。

Sched_ext框架总览基于 Linux 6.18.26，结合内核源码逐行分析系列文章：sched_ext（简称 scx）是 Linux 内核的 eBPF 调度器框架，自 6.12 起合入主线。它允许开发者用 eBPF 程序在用户态编写自定义 CPU 调度策略，而无需修改内核代码或重启系统。

破局与守正：eBPF 在 Linux 内存管理中的应用、演进与重构构想作为 Linux 内核中一项革命性的技术，eBPF（Extended Berkeley Packet Filter，扩展版伯克利包过滤器）正在以前所未有的速度改变着操作系统的底层生态。它允许开发者在不修改内核源码、不需要重启内核的前提下，安全地在内核中运行自定义程序。这种“即插即用”、兼顾极致性能与绝对安全的特性，已经让 eBPF 在网络（如 Cilium）、可观测性（如 BCC、Pixie）以及安全审计（如 Falco）三大领域大放异彩。

linux开发之路

C++项目推荐：eBPF+调度器性能分析框架来源：程序员老廖的个人空间想象一个场景：你写了一个程序，运行起来很慢，但你不知道慢在哪里。是 CPU 算得慢？还是等磁盘 IO？还是被锁卡住了？

Linux 跨设备内存共享核心：dma-buf 全景演进与技术前沿dma-buf（DMA Buffer）是 Linux 内核中用于跨设备/跨驱动内存共享的核心子系统。近年来，随着 AI 训练、大模型推理以及超高性能网络（如 400G/800G 网络）的爆发，数据在 GPU、网卡（NIC）、存储设备（NVMe）之间的零拷贝（Zero-copy）传输成为了刚需。dma-buf 已经从最初一个简单的“媒体设备间共享内存”的小工具，演变成了如今支撑现代 AI 数据中心、GPU 服务器超高性能通信的底层基石。

Sched_ext 回调深度解析（二）：enable —— 任务被调度器接管的关键时刻（6.18.26）基于 Linux 6.18.26 内核源码（kernel/sched/ext.c）分析。系列文章：struct sched_ext_ops 代表一个 BPF 调度器，其中定义了多个回调函数（hook）。当一个 task 被 sched_ext 调度器正式接管时触发 enable 回调。

Sched_ext 回调深度解析（一）：init_task —— 每个任务走进调度器的第一道门（6.18.26）基于 Linux 6.18.26，结合内核源码逐行分析sched_ext（简称 scx）是 Linux 内核的 eBPF 调度器框架。你可以把它理解为一个"调度器插件系统"——内核提供了标准的钩子（hook），你用 eBPF 程序实现这些钩子，就能写出一个完整的调度器。

比 veth 更强、为 eBPF 而生：深度解析 Linux netkit 虚拟网卡驱动在云原生网络（如 Cilium、Calico）的演进过程中，veth-pair 一直是连接容器与宿主机的功臣。然而，随着对高性能、低延迟的极致追求，传统 veth 的协议栈开销逐渐成为瓶颈。

[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）与物理硬件的“天然隔阂”，让这项黑科技长期难以进入容器。