跳转至

Blog

Share on Share on

AgentCgroup: What Happens When AI Coding Agents Meet OS Resources?

AgentCgroup: What Happens When AI Coding Agents Meet OS Resources?

AI coding agents such as Claude Code, OpenHands, and SWE-agent are increasingly deployed in multi-tenant cloud environments, where they execute diverse tool calls inside sandboxed containers. Despite growing adoption, the OS-level resource dynamics of these workloads remain poorly understood. We present the first systematic characterization, analyzing 144 software engineering tasks from the SWE-rebench benchmark across two LLM backends. Our measurements reveal that OS-level overhead, including container initialization and tool execution, accounts for 56–74% of end-to-end latency, while LLM reasoning contributes only 26–44%. Memory exhibits a 15.4x peak-to-average ratio (compared to ~1.5x for serverless and 2–3x for microservices), with change rates reaching 3 GB/s in sub-second bursts. The same tool type (Bash) varies 13.7x in memory consumption depending on command semantics, and repeated runs of the same task produce 1.8x execution time variance with near-zero correlation (r = −0.14) between token output and peak memory.

These characteristics expose mismatches with existing resource management mechanisms, from kernel cgroup limits and systemd-oomd to Kubernetes VPA, where static allocation either wastes 93% of provisioned capacity or triggers OOM kills that destroy minutes of accumulated, non-reproducible agent state. In this post, we summarize the characterization findings from our AgentCgroup paper and describe how eBPF-based in-kernel enforcement can bridge the gap between agent workload dynamics and OS-level resource control.

Reverse Engineering Claude Code's SSL Traffic with eBPF

Reverse Engineering Claude Code's SSL Traffic with eBPF

Ever wondered what your AI coding agent is actually sending over the network? As part of our work on AgentSight — an eBPF-powered observability tool that monitors AI agents at system boundaries without modifying their code — we needed to intercept Claude Code's encrypted API traffic to understand its communication patterns. AgentSight can capture both what an AI agent intends to do (by intercepting LLM API traffic) and what it actually does (by monitoring kernel events), then correlate the two into a complete causal chain. To make this work, we first need to crack open the agent's encrypted network traffic. Sounds straightforward, right? Just hook into Node.js's OpenSSL with sslsniff, like we did with older versions of Claude Code. Back then, Claude Code ran on Node.js with dynamically linked libssl.so, and standard eBPF-based SSL hooking worked out of the box.

But everything changed. The new Claude Code is a 213 MB stripped Bun binary with BoringSSL statically linked and all symbols removed. No libssl.so, no SSL_write symbol to hook — standard tools are completely blind to it. So we did what any self-respecting systems researcher would do: we asked Claude Code to reverse engineer itself. Yes, the very AI agent we were trying to monitor became our reverse engineering assistant, analyzing its own binary, searching for byte patterns, and helping us locate the stripped SSL functions inside itself.

This post chronicles that complete journey: from discovering why standard tools fail, to matching byte patterns against Bun's open-source profile builds, to finally capturing every single API call — including the full /v1/messages conversation stream with prompts, responses, and SSE events. Along the way, we chased a fascinating red herring about Bun's "dual TLS paths" that turned out to be a simple timing issue. The techniques here apply to any stripped binary with statically-linked SSL, not just Claude Code.

AgentSight is open source at https://github.com/agent-sight/agentsight, and the arxiv paper describing the full system is available at https://arxiv.org/abs/2508.02736.

A Taxonomy of GPU Bugs: 19 Defect Classes for CUDA Verification

A Taxonomy of GPU Bugs: 19 Defect Classes for CUDA Verification

Introduction

GPU programming introduces a distinct class of correctness and performance challenges that differ fundamentally from traditional CPU-based systems. The SIMT (Single Instruction, Multiple Threads) execution model, hierarchical memory architecture, and massive parallelism create unique bug patterns that require specialized verification and detection techniques.

Just as eBPF enables safe, verified extension code to run inside the Linux kernel, bpftime gpu_ext (The arxiv, previous name eGPU) bring eBPF to GPUs, allowing user-defined policy code (for observability, scheduling, or resource control) to be injected into GPU drivers and kernels with static verification guarantees. Such a GPU extension framework must ensure that policy code cannot introduce crashes, hangs, data races, or unbounded overhead. A critical concern in modern GPU deployments is performance interference in multi-tenant environments: contention for shared resources makes execution time unpredictable. "Making Powerful Enemies on NVIDIA GPUs" studies how adversarial kernels can amplify slowdowns, arguing that performance interference is a system-level safety property when GPUs are shared. This motivates treating bounded overhead as a correctness property, not merely an optimization goal.

To build a sound GPU extension verifier, we must first understand what can go wrong. This taxonomy identifies the defect classes a verifier must address, drawing lessons from eBPF's success: restrict the programming model, enforce bounded execution, and verify memory safety before loading. We synthesize findings from static verifiers (GPUVerify, GKLEE, ESBMC-GPU), dynamic detectors (Compute Sanitizer, Simulee, CuSan), and empirical bug studies (Wu et al., ScoRD, iGUARD) into 19 defect classes organized along two dimensions: impact type (Safety, Correctness, Performance) and GPU specificity (GPU-specific, GPU-amplified, CPU-shared). Each entry provides concrete examples, documents detection tools, and offers actionable verification strategies.

智能体系统架构：隔离、集成与治理的综合调研

智能体系统架构：隔离、集成与治理的综合调研

基于大语言模型（LLM）的智能体系统，即能够利用LLM自主规划并借助外部工具执行多步任务的软件，正迅速从概念验证阶段迈向企业级规模化部署。这些智能体有望将编码、IT运维、数据分析等工作自动化，然而，将其部署于生产环境也带来了在安全性、可靠性及系统集成方面的一系列新挑战。过去半年，业界社区已在几项关键策略上形成共识：为执行不可信操作提供强有力的隔离保障，为工具集成建立标准化协议，并构建能确保智能体行为符合企业策略的治理框架。本调研旨在系统性地回顾近期（约2025年下半年）的相关进展，内容涵盖智能体沙箱架构、模型上下文协议（MCP）等新兴标准、重要的开源项目、行业倡议以及前沿研究成果。本文将聚焦于智能体系统在生产化落地过程中普遍存在的痛点，并探讨最新的解决方案如何应对（或在何种程度上尚未解决）这些核心需求。

GPU可观测性差距：为什么我们需要卸载到GPU设备上的eBPF

GPU可观测性差距：为什么我们需要卸载到GPU设备上的eBPF

Yusheng Zheng=, Tong Yu=, Yiwei Yang=

eBPF 作为一种在内核态提供可编程能力的革命性技术，已经在 CPU 的可观测性、网络和安全领域取得了巨大成功。然而，对于日益重要的 GPU 计算领域，我们同样需要一种灵活、高效的观测手段。目前，大多数 GPU 性能分析工具都局限于在 CPU 侧通过驱动/用户态 API 或厂商的性能分析接口（CUPTI）进行观测，难以深入了解 GPU 内部的执行细节。为了解决这一问题，bpftime 通过其 CUDA/SYCL 附加实现提供 GPU 支持，使 eBPF 程序能够在 NVIDIA 和 AMD GPU 上的 GPU 内核内部执行。这将 eBPF 的可编程性、可观测性和定制能力带到 GPU 计算工作负载中。通过这种方式，它实现了对 GPU 应用程序的实时性能分析、调试和运行时扩展，无需修改源代码，填补了当前可观测性领域的空白。

注意： GPU 支持仍处于实验阶段。如有问题或建议，提交问题或联系我们。

NVIDIA Open GPU Kernel Modules Comprehensive Source Code Analysis

NVIDIA Open GPU Kernel Modules Comprehensive Source Code Analysis

In May 2022, NVIDIA made a decision that would fundamentally alter the landscape of GPU computing on Linux: they open-sourced the kernel-mode components of their GPU driver. This wasn't a simple code dump. Instead, it was the release of over 935,000 lines of production-quality, battle-tested code that powers everything from consumer gaming rigs to the world's fastest supercomputers. For the first time, developers, researchers, and engineers could peer inside the machinery that manages some of the most complex hardware ever created.

This document represents a comprehensive deep-dive into that codebase, providing a technical autopsy of one of the most sophisticated device drivers in the Linux ecosystem. Over the course of this analysis, we've examined every major subsystem, traced data flows through multiple abstraction layers, and documented architectural decisions that span over a decade of GPU evolution. What emerges is not just a driver, but a masterclass in systems programming: how to manage heterogeneous computing resources, how to maintain binary compatibility across wildly different hardware generations, and how to balance the competing demands of performance, security, and maintainability.

Version: 580.95.05 Analysis Date: 2025-10-13 License: Dual MIT/GPL Repository: https://github.com/NVIDIA/open-gpu-kernel-modules

Understanding iaprof: A Deep Dive into AI/GPU Flame Graph Profiling

Understanding iaprof: A Deep Dive into AI/GPU Flame Graph Profiling

An exploration of Intel's innovative profiling tool that bridges the gap between CPU and GPU execution

Project Link: github.com/intel/iaprof - Intel's AI/GPU flame graph profiler

If you've ever tried to optimize a GPU-accelerated machine learning workload, you've likely encountered a frustrating problem: your code runs on the CPU, but the performance bottlenecks live on the GPU. Traditional profiling tools show you one world or the other, but never both together. This disconnect makes it nearly impossible to understand which lines of your Python or C++ code are responsible for expensive GPU operations.

Enter iaprof, Intel's solution to this observability challenge. At its core, iaprof is a profiling tool that generates what Intel calls "AI Flame Graphs" - interactive visualizations that seamlessly connect your application code to the GPU instructions it triggers, all while showing where performance is actually being lost. This blog post will take you on a deep dive into how iaprof works, the technologies it leverages, and the architecture that makes it possible.

AgentSight: 让 AI Agent 的一举一动都在掌控之中，基于 eBPF 的系统级可观测性方案

AgentSight: 让 AI Agent 的一举一动都在掌控之中，基于 eBPF 的系统级可观测性方案

想象一下，当你的 AI Agent 正在自主编写代码、执行命令时，你却不知道它究竟在做什么，或许有点令人不安？随着 Claude Code、Gemini-cli 等 LLM 智能体工具的普及，我们正在将越来越多的控制权交给 AI。但这里有个棘手的问题：这些 AI 智能体与传统软件截然不同，现有的监控工具要么只能看到它们的"想法"（LLM 提示词），要么只能看到它们的"行动"（系统调用），却无法将两者联系起来。就像你只能听到一个人在说什么，或者只能看到他在做什么，却不知道言行之间的联系。这个盲区让我们难以判断 AI 是在正常工作、遭受攻击还是陷入了昂贵的死循环。

这就是我们开发 AgentSight 的初衷，我们用 eBPF 在系统边界处巧妙地监控 AI Agent 的一举一动。AgentSight 能够拦截加密的 LLM 通信来理解 AI 的意图，同时监控内核事件来追踪它的实际行为，然后用智能引擎将这两条线索关联起来，形成完整的因果链。最棒的是，这一切都不需要修改你的代码，不依赖特定框架，性能开销还不到 3%！在实际测试中，AgentSight 成功检测出了提示注入攻击，及时发现了烧钱的推理死循环，还帮助我们找到了多智能体协作中的性能瓶颈。AgentSight 已经开源，欢迎来 https://github.com/agent-sight/agentsight 体验！论文的 arxiv 版本在 https://arxiv.org/abs/2508.02736 。

Profiling and Tracing Tools Across System Layers and Architectures

Profiling and Tracing Tools Across System Layers and Architectures

Profiling and tracing are complementary techniques for analyzing software performance and behavior. Profiling typically measures where a program spends its time or resources, aggregating data (e.g. CPU time per function, memory usage per module) to identify performance bottlenecks and hot spots. In contrast, tracing records a timeline of events or operations (e.g. function calls, kernel events, network requests) to reconstruct execution flows. Both are motivated by the need to understand and optimize complex systems: using these tools is “vital for understanding program behavior, performance bottlenecks and optimisation potentials”. Common use cases include finding CPU hotspots in code, diagnosing memory leaks or I/O delays, understanding concurrency issues (e.g. lock contention), and tracking requests across distributed services. By applying profiling or tracing, developers and researchers can observe the internal state and performance of software, leading to faster troubleshooting and more efficient, reliable systems.

In modern environments, profiling/tracing spans multiple layers – from low-level CPU and OS events up to application, runtime, and distributed system behaviors. The sections below present a comprehensive catalog of tools and frameworks at each level (covering both open-source and commercial solutions), organized by context. We compare their capabilities across major architectures (x86, ARM, RISC-V, GPUs, TPUs, DSPs, etc.), and discuss the design challenges (overhead, observability, correlation, etc.) that shape current research. Typical scenarios and use cases are highlighted to illustrate why these tools are indispensable – for example, improving end-user experience by optimizing slow code paths, catching sporadic memory leaks via continuous monitoring, or tracing microservice interactions to pinpoint latency in a complex transaction. The goal is to give both a broad overview and deep insights into the state of the art in profiling and tracing technology.

The Modern Memory Testing Arsenal -- A Complete Guide to Benchmarking Tools for Next-Gen Memory Systems

The Modern Memory Testing Arsenal -- A Complete Guide to Benchmarking Tools for Next-Gen Memory Systems

Introduction

Memory systems are evolving rapidly. From traditional DDR DRAM to high-bandwidth memory (HBM), persistent memory (PMEM), and the emerging Compute Express Link (CXL) technology, today's systems feature complex heterogeneous memory hierarchies that demand sophisticated evaluation approaches.

This comprehensive guide surveys the cutting-edge tools and methodologies available for testing, benchmarking, and profiling modern memory systems. Whether you're a hardware architect designing next-generation memory controllers, a software developer optimizing applications for heterogeneous memory, or a researcher exploring memory system co-design, this survey provides a roadmap to the essential tools shaping memory system evaluation from 2018 to 2025.

We cover everything from synthetic workload generators that can clone application memory behavior, to trace replay frameworks that enable reproducible testing, specialized benchmark suites for emerging technologies, and profiling tools that provide deep insights into memory performance bottlenecks. The landscape has evolved from simple bandwidth and latency measurements to sophisticated AI-driven workload synthesis and unified frameworks that span multiple memory technologies.

系统会议中的可观测性、性能分析和调试（2015–2025）

系统会议中的可观测性、性能分析和调试（2015–2025）

摘要：

本综述回顾了十多年来（2015–2025）计算机系统可观测性、性能分析和调试技术的研究，重点关注OSDI、SOSP和EuroSys的主会论文。我们涵盖了100多篇论文，涉及动态跟踪框架、日志记录和监控基础设施、性能异常检测、根因分析和系统可见性机制。我们识别了所解决的核心问题（从分布式请求跟踪到配置或并发错误检测）、采用的技术（动态插桩、静态分析、原位日志记录、分布式监控、ML辅助分析）、目标领域（操作系统内核、云和分布式系统、移动/物联网系统等），以及这些工作之间的关系和相互构建。我们讨论了随时间的趋势——例如，从单体系统中的临时跟踪演变为微服务中的持续低开销可观测性——以及机器学习在异常检测和根因分析中的新兴集成。我们总结了开放挑战，如将可观测性扩展到高度分解的系统、减少跟踪中的开销和噪声、自动化跨抽象层的诊断，以及改善生产环境中调试工具的可用性。

Checkpoint/Restore Systems: Evolution, Techniques, and Applications in AI Agents

Checkpoint/Restore Systems: Evolution, Techniques, and Applications in AI Agents

Checkpoint/restore (C/R) technology – the ability to save a running program’s state to persistent storage and later resume execution from that point – has long been a cornerstone of fault tolerance and process management in computing. By capturing a snapshot of a process or group of processes, C/R enables recovery from failures, migration of computations, load balancing, and the suspension/resumption of work. Traditionally, C/R has been critical in high-performance computing (HPC) environments to mitigate frequent failures in large clusters, in operating systems for process migration and preemption, and in virtualization platforms for live virtual machine (VM) migration with minimal downtime. As we usher in an era of AI-centric applications – from AI-assisted developer tools and autonomous agents to distributed machine learning pipelines – the scope of C/R is expanding. Modern AI systems often consist of long-running stateful agents, complex multi-process pipelines, and GPU-accelerated workloads, all of which introduce new requirements and challenges for checkpointing. For example, training massive deep learning models over weeks exposes a system to many failures; one 54-day run of a 405-billion parameter model across 16,000 GPUs experienced 419 interruptions (78% from hardware faults), potentially costing millions in lost work. Techniques like maintaining redundant in-memory states for fast recovery are used in such cases, underscoring the importance of robust checkpointing. This survey provides a comprehensive overview of C/R systems and their evolution, spanning traditional use cases (before the advent of AI agents) and emerging applications in AI. We cover checkpointing at all levels of the software stack (OS-level, container, VM, application, and library-level), discuss stateless vs. stateful restoration strategies for AI systems, compare prominent open-source and proprietary C/R solutions, delve into the technical mechanisms enabling C/R (memory snapshotting, I/O and descriptor handling, GPU state, etc.), and highlight research challenges in bringing reliable, efficient C/R to dynamic, interactive AI agent environments. We also include extensive references to both classic literature and recent works (with a focus on peer-reviewed research), and we provide comparative tables to summarize the landscape of C/R tools and their capabilities. By looking at past and present developments, we aim to outline the trajectory of checkpoint/restore technology and identify opportunities for new tooling tailored to the next generation of AI-driven applications.

ASPLOS 2025: Paper Summaries and Insights

ASPLOS 2025: Paper Summaries and Insights

The Association for Computing Machinery's Architectural Support for Programming Languages and Operating Systems (ASPLOS) conference is a premier venue where researchers present cutting-edge work spanning computer architecture, programming languages, operating systems, and their intersections. ASPLOS 2025 showcased significant advances across these domains, with particular emphasis on AI systems, heterogeneous computing, and novel memory architectures. This summary analyzes key papers and trends from the conference, highlighting their implications for both academia and industry.

EuroSys 2025 Paper Summaries and Analysis

EuroSys 2025 Paper Summaries and Analysis

This post offers a detailed examination of papers accepted at EuroSys 2025, one of the premier conferences in computer systems research. I've analyzed over 40 papers spanning AI systems, cloud computing, networking, storage, and security to identify emerging trends, technical breakthroughs, and industry implications. For researchers and practitioners alike, this analysis provides a roadmap of where systems research is heading—highlighting both solved problems and remaining challenges. Each paper is summarized with its key contributions and practical relevance, followed by a synthesis of overarching themes and future research directions.

深入GPU性能分析工具：现代加速器追踪工具的实现详解

深入GPU性能分析工具：现代加速器追踪工具的实现详解

对异构加速器（GPU、DPU和APU）进行性能分析和追踪对于优化现代系统的性能至关重要。本调研提供了一个深入的实现导向的综述，介绍了当前最先进的工具如何捕获低级执行细节。我们面向两类受众：(1) 工具开发者，他们希望了解现有性能分析工具的构建方式——包括它们钩住的接口以及如何追踪CPU和加速器；(2) 系统工程师，他们需要根据功能和开销决定集成哪些工具。我们探讨了关键性能分析工具的内部架构、它们拦截的运行时库和驱动API、它们是否追踪CPU、GPU或两者上的事件，以及它们如何处理跨设备关联。然后我们检查实现策略（插桩vs采样、性能计数器的使用、动态二进制插桩、内核钩子如eBPF）以及GPU特定技术（如warp级指令采样）。我们比较了数据处理和可视化方法，包括追踪数据格式、存储和导出方法，以及GUI/CLI/Web界面（与TensorBoard或Grafana等仪表板集成）。我们列出了这些工具收集的性能指标——从内核延迟和吞吐量到SM占用率、缓存未命中和互连利用率——解释了原始硬件计数器如何转换为派生指标以及涉及的粒度/精度权衡。接下来，我们讨论用户可以从可视化（时间线、火焰图、依赖图等）中获得的见解，例如检测流水线停顿、内存瓶颈或CPU-GPU不同步。我们回顾了工具的可扩展性（对插件或用户定义插桩的支持），以及不同测量技术的相对开销和侵入性。我们还讨论了安全和沙盒问题——例如，在容器化或多租户环境中的性能分析——并概述了已知限制和未来方向（包括对新兴DPU和集成CPU-GPU APU的支持）。本调研的目标是提供一个全面的系统级概述，超越功能列表，比较这些性能分析工具在底层的工作方式，包括开源工具使用的任何逆向工程或未记录的方法。

加速器工具箱：GPU和其他协处理器的性能分析和追踪详解

加速器工具箱：GPU和其他协处理器的性能分析和追踪详解

现代计算越来越依赖专用加速器——尤其是GPU、DPU和APU——来处理各种工作负载。图形处理单元(GPU)是一种大规模并行处理器，最初用于图形处理，现在在通用计算(HPC)和AI中必不可少。数据处理单元(DPU)是一种较新类型的可编程处理器，结合了CPU核心和高性能网络/存储引擎。DPU从CPU卸载网络、安全和存储任务，被认为是继CPU和GPU之后计算的"第三支柱"。同时，加速处理单元(APU)在一个芯片上集成了CPU和GPU组件——这一方法由AMD的Fusion架构首创——实现了统一内存和高吞吐量，适用于HPC和AI工作负载。这些加速器运行各种工作负载：GPU在并行数学（HPC模拟、深度学习训练/推理、数据分析）和图形渲染方面表现出色；DPU专注于数据中心任务（网络数据包处理、加密、存储卸载、虚拟化）；而APU针对需要紧密CPU-GPU耦合的异构工作负载（例如共享内存的AI或多媒体应用程序）。

性能分析和追踪工具对于优化这些加速器上的性能至关重要。这些工具收集低级硬件遥测数据（例如利用率、内存吞吐量、SM占用率、缓存未命中等计数器）并可以执行指令或事件级追踪（捕获内核执行、内存复制、网络数据包流等的时间线）。目标是识别通用代码和特定领域流水线（如ML模型训练、网络功能处理或图形渲染）中的瓶颈和低效率。然而，对高度并行、异构系统进行性能分析带来了开销、数据量和跨平台兼容性的挑战。本综述按硬件类型和领域对当前追踪/性能分析工具进行分类，比较开源和商业解决方案，并强调主要项目和最新研究。我们还讨论专门的工具集（包括类似于Linux BCC的基于eBPF的方法）如何适应GPU/DPU/APU，典型工作负载和匹配工具链，以及这一领域的局限和新兴方向。

OS-Level Challenges in LLM Inference and Optimizations

OS-Level Challenges in LLM Inference and Optimizations

Large Language Model (LLM) inference pushes computing systems to their limits, not only in raw compute but also in how the operating system (OS) manages resources. This report examines OS-level challenges for LLM inference and explores potential solutions. We focus first on key bottlenecks – memory management, CPU scheduling, I/O, and real-time constraints – then discuss how kernel-level techniques (like eBPF and custom scheduling) can address these issues. We also consider the impact of system calls and page faults on performance, security/isolation concerns in multi-tenant environments, best practices and emerging research in OS customization for AI, and practical considerations for implementing such optimizations in a research project. The goal is to guide a research initiative by outlining the challenges and then potential solutions and areas for further investigation.

WASI and the WebAssembly Component Model: Current Status

WASI and the WebAssembly Component Model: Current Status

WebAssembly (WASM) has evolved from a browser-based technology into a promising runtime for server and embedded applications. Key to this evolution are the WebAssembly System Interface (WASI) – a standardized set of syscalls for WASM outside the browser – and the emerging Component Model, which enables modular, language-agnostic composition of WebAssembly modules. This report analyzes the current status of WASI (including its major runtimes like Wasmtime and Wasmer) and the Component Model, focusing on the technical limitations that impede adoption. We draw from official proposals, runtime issue trackers, academic studies, and industry experiences to highlight critical gaps, unresolved bugs, and feature requests. Case studies illustrate how these challenges block real-world use cases, and we conclude with recommendations for improving WebAssembly’s performance, security, and integrability with host environments.

eBPF Ecosystem Progress in 2024–2025: A Technical Deep Dive

eBPF Ecosystem Progress in 2024–2025: A Technical Deep Dive

Introduction and Summary

Extended Berkeley Packet Filter (eBPF) continues to rapidly evolve, cementing its role as a cornerstone for operating system extensibility. In 2024 and into early 2025, the eBPF ecosystem saw significant advancements across the Linux kernel, tooling, security, networking, and observability domains. This report provides a comprehensive technical deep dive into these developments, with a high-level summary here and detailed sections below. Key highlights include:

This is a AI generated report from OpenAI Deep Reasearch. Let's see how it performs for eBPF.

Security Vulnerabilities Study in Software Extensions and Plugins

Security Vulnerabilities Study in Software Extensions and Plugins

Introduction

Software extensions and plugins allow customization and added features across many systems – from web servers and databases to browsers, IDEs, and CMS platforms. However, these extensibility mechanisms introduce security risks. Extensions often run with high privileges inside host applications, so a flaw in an extension can compromise the entire system ([PDF] Protecting Browsers from Extension Vulnerabilities - Google Research). Common vulnerability types include memory safety issues (buffer/stack overflows and heap corruptions), privilege escalations, sandbox escapes, infinite loops or livelocks causing Denial-of-Service, and arbitrary code execution (ACE). This report examines historical and recent vulnerabilities in extensions/plugins across various ecosystems, highlighting notable CVEs, trends, case studies of major incidents, and how improved security models like an Extension Interface Model (EIM) could mitigate such issues.

Can LLMs understand Linux kernel? A New AI-Powered Approach to Understanding Large Codebases

Can LLMs understand Linux kernel? A New AI-Powered Approach to Understanding Large Codebases

Ever tried diving into a massive codebase like the Linux kernel and felt like you were swimming in an ocean of code with no land in sight? Trust me, you're not alone. Understanding large, complex, and constantly evolving codebases is like trying to read a never-ending novel that's being written by thousands of authors simultaneously. It's overwhelming, to say the least.

See our arxiv and GitHub repository for more details!

构建高性能的用户态 eBPF 虚拟机：基于 LLVM 的 llvmbpf 项目

构建高性能的用户态 eBPF 虚拟机：基于 LLVM 的 llvmbpf 项目

我们很高兴向大家介绍 llvmbpf，这是一个全新的项目，旨在为开发者提供一个高性能、支持多架构的 eBPF 虚拟机（VM）。llvmbpf 利用 LLVM 框架实现了即时编译（JIT）和提前编译（AOT），让你能够在用户态中高效运行 eBPF 程序。

该项目是 bpftime 项目的一部分，但它专注于核心虚拟机功能。llvmbpf 可以作为独立的 eBPF VM 库或编译工具使用。它经过性能优化，具备极高的灵活性，并且依赖极少，能够轻松集成到各种环境中而不会带来额外负担。

eBPF的过去、现在与未来及其革新系统的道路

eBPF的过去、现在与未来及其革新系统的道路

这篇博客文章主要参考了 Alexei Starovoitov 在 BPFConf 2024 上的演讲“《为未来十年现代化BPF》”。

想象一下，你的电脑核心操作中有一把瑞士军刀——可以让你窥探数据流动的内部、实时调整进程，并且随时监控一切。这正是eBPF（扩展伯克利数据包过滤器）所提供的功能。在过去的十年里，eBPF已经从一个简单的数据包过滤工具转变为网络、可观测性和安全领域的强大利器。那么，eBPF的未来又会如何呢？让我们一起回顾它的历程，探讨未来十年的发展方向，并讨论前方的挑战与机遇。这将帮助我们理解eBPF如何塑造现代系统的未来。

简化内核编程：LLM驱动的eBPF工具

简化内核编程：LLM驱动的eBPF工具

内核编程通常需要深入了解操作系统内部结构和编程约束，因而令人生畏。我们的新工具Kgent旨在简化这一过程，使创建扩展的Berkeley Packet Filter（eBPF）程序变得更加容易。Kgent利用大语言模型（LLM）的强大功能，将自然语言提示转换为eBPF代码，从而降低内核编程的门槛。

我们的论文《Kgent：内核扩展的大语言模型代理》最近在eBPF '24：ACM SIGCOMM 2024 eBPF和内核扩展研讨会上发表。让我们深入了解Kgent为何能成为内核编程的变革者。

The eBPF Evolution and Future: From Linux Origins to Cross-Platform Dominance

The eBPF Evolution and Future: From Linux Origins to Cross-Platform Dominance

eBPF (Extended Berkeley Packet Filter) has become a revolutionary force in operating system kernel programming since its inception. Initially created for network packet filtering, eBPF has evolved into a versatile kernel extension tool, supporting system monitoring, performance analysis, security policy enforcement, and more. As the technology has advanced, eBPF has gained widespread adoption not only on Linux platforms but also on other operating systems like Windows and macOS, showing significant potential as a cross-platform infrastructure technology. In this context, eBPF is driving the evolution of modern operating system architectures, opening new possibilities for cloud-native infrastructure and platform engineering.

五分钟带你手搓一个简易的 inline hook 实现控制流劫持

五分钟带你手搓一个简易的 inline hook 实现控制流劫持

编程中令人着迷的一面在于我们尝试在程序运行时改变其行为。在本教程中，我们将揭示一种可以实现这一点的方法- inline hook 。只需要数十行代码，即可用 C 语言实现一个简单的 inline hook 示例，并将其应用于一个示例程序。

我们将探讨如何在 C 编程语言中操纵程序的执行流。通过实现 inline hook ，我们的目标是将程序的执行流分流到我们的函数中，然后再返回到正常流程。您可以在以下存储库中找到完整的开源代码示例： https://github.com/eunomia-bpf/inline-hook-demo

eBPF 的演进与影响：近年的关键研究论文一览

eBPF 的演进与影响：近年的关键研究论文一览

这是我近年来读过的与 eBPF 相关的论文列表，可能对于对 eBPF 相关研究感兴趣的人有所帮助。

eBPF（扩展的伯克利数据包过滤器）是一种新兴的技术，允许在 Linux 内核中安全地执行用户提供的程序。近年来，它因加速网络处理、增强可观察性和实现可编程数据包处理而得到了广泛的应用。此文档列出了过去几年关于 eBPF 的一些关键研究论文。这些论文涵盖了 eBPF 的几个方面，包括加速分布式系统、存储和网络，正式验证 eBPF 的 JIT 编译器和验证器，将 eBPF 用于入侵检测，以及从 eBPF 程序自动生成硬件设计。

eunomia-bpf v1.0：eBPF + Wasm 质的飞跃

eunomia-bpf v1.0：eBPF + Wasm 质的飞跃

随着技术的不断发展，eBPF已经成为了现代Linux内核中的一个核心组件，为开发者提供了强大的性能监控和网络跟踪功能。eunomia-bpf 作为一个新的 eBPF 开源开发框架，旨在简化 eBPF 程序的构建和分发，同时引入了 Wasm技术，为开发者提供了更多的可能性。在过去的半年中，从最初的PoC版本到如今的1.0版本，它已经经历了巨大的变革，成为了一个功能丰富的成熟产品。

eBPF 运行时安全性：面临的挑战与前沿创新

eBPF 运行时安全性：面临的挑战与前沿创新

郑昱笙

扩展伯克利数据包过滤器（eBPF）代表了我们与现代操作系统交互和扩展其能力方式的重大演变。作为一种强大的技术，它使得Linux内核能够响应事件运行沙盒程序，eBPF已成为系统可观察性、网络和安全特性的基石。

然而，像任何与内核紧密接口的系统一样，eBPF 运行时本身的安全性至关重要。在这篇博客中，我们将深入探讨常被忽视的 eBPF 安全性问题，探索旨在保护 eBPF 的机制本身如何被加固。我们将解析 eBPF 验证器的作用，审视当前的访问控制模型，并调查研究中的潜在改进机会。

用户空间 eBPF 运行时：深度解析与应用实践

用户空间 eBPF 运行时：深度解析与应用实践

郑昱笙

本文旨在对用户空间的 eBPF 运行时和对应的一些应用场景进行剖析和总结。尽管大多数人对基于内核的 eBPF 已有所了解，用户空间 eBPF 的进展和应用实践同样引人注目。本文还将探讨用户空间 eBPF 运行时与 Wasm 运行时的技术比较，后者在云原生和边缘计算领域已获得广泛的关注。我们也新开源了一个用户态 eBPF 运行时 bpftime。通过 LLVM JIT/AOT 后端支持，我们的基准测试表明 bpftime 是最快的用户空间 eBPF 运行时之一，同时还可以让内核中间的 eBPF Uprobe 无缝在用户空间运行，获得近十倍的性能提升。

bpftime: 让 eBPF 从内核扩展到用户空间

bpftime: 让 eBPF 从内核扩展到用户空间

郑昱笙，于桐

eBPF 是一项革命性的技术，起源于 Linux 内核，可以在操作系统的内核中运行沙盒程序。它被用来安全和有效地扩展内核的功能，而不需要改变内核的源代码或加载内核模块。

在这篇 Blog 中，我们希望向大家介绍一个全新的开源用户态 eBPF 运行时：https://github.com/eunomia-bpf/bpftime 。bpftime 进一步拓展了 eBPF 的能力，使现有的 eBPF 工具和应用，例如 BCC tools, bpftrace, Deepflow 等，能够不需要进行代码修改即可在非特权用户空间运行，同时使用和内核 eBPF 相同的库和工具链。

bpftime 不仅提供了 Uprobe 和系统调用追踪点等动态追踪或扩展机制，还相比内核 Uprobe 有一个数量级的性能提升，并且和内核 eBPF 一样，无需手动进行代码插桩或重启进程。bpftime 通过用户态共享内存支持进程间 eBPF maps，同时兼容内核 eBPF maps，能够实现与内核 eBPF 基础设施的无缝操作。此外，它包含了针对多种架构的高性能 LLVM JIT/AOT 编译器，以及针对 x86 的轻量级 JIT 和解释器。通过性能数据和实际案例，我们也将展示 bpftime 如何在现实世界中发挥作用，并对其未来发展进行展望，希望 bpftime 能为系统监控、分析和扩展带来前所未有的性能和灵活性。在 Linux plumbers 23 会议上，我们也介绍了 bpftime 的设计和实现[2]。

使用 ChatGPT ，通过自然语言编写 eBPF 程序和追踪 Linux 系统

使用 ChatGPT ，通过自然语言编写 eBPF 程序和追踪 Linux 系统

eBPF 是一项革命性的技术，起源于 Linux 内核，可以在操作系统的内核中运行沙盒程序。它被用来安全和有效地扩展内核的功能，而不需要改变内核的源代码或加载内核模块。今天，eBPF被广泛用于各类场景：在现代数据中心和云原生环境中，可以提供高性能的网络包处理和负载均衡；以非常低的资源开销，做到对多种细粒度指标的可观测性，帮助应用程序开发人员跟踪应用程序，为性能故障排除提供洞察力；保障应用程序和容器运行时的安全执行，等等。eBPF 已经成为了一个越来越受欢迎的技术，它可以帮助我们更加高效地对内核和用户态的几乎所有应用进行追踪和分析。

但是，eBPF 的开发，或者追踪内核产生的各类事件，需要一定的专业知识，对于一些不熟悉该技术的开发人员来说，可能会有一定的困难。这时，我们的 demo 工具 GPTtrace 所带来的一些新的思路，也许就可以帮助你解决这个问题。它使用 ChatGPT ，通过自然语言编写 eBPF 程序和追踪 Linux 内核：https://github.com/eunomia-bpf/GPTtrace

如果你是一名开发人员，想要更加高效地进行追踪和分析，那么类似的方案绝对值得尝试：这种 ChatGPT 和 eBPF 技术的结合将在未来的软件开发、调试、以及可观测性场景中发挥更加重要的作用，同时它可能也会带来一种全新的、交互式地学习范式。

快速构建 eBPF 项目和开发环境，一键在线编译运行 eBPF 程序

快速构建 eBPF 项目和开发环境，一键在线编译运行 eBPF 程序

如果您正在探索 eBPF 技术，并且对于如何开始搭建环境以及选择编程语言感到困惑，那么您来对地方了！本文将介绍一系列 GitHub 模板和 GitHub Codespaces，让您可以快速启动全新的 eBPF 项目，一键在线编译运行 eBPF 程序。现在就跟随我们的步骤，加速您的 eBPF 开发吧！

当 Wasm 遇见 eBPF ：使用 WebAssembly 编写、分发、加载运行 eBPF 程序

当 Wasm 遇见 eBPF ：使用 WebAssembly 编写、分发、加载运行 eBPF 程序

当今云原生世界中两个最热门的轻量级代码执行沙箱/虚拟机是 eBPF 和 WebAssembly。它们都运行从 C、C++ 和 Rust 等语言编译的高性能字节码程序，并且都是跨平台、可移植的。二者最大的区别在于： eBPF 在 Linux 内核中运行，而 WebAssembly 在用户空间中运行。我们希望能做一些将二者相互融合的尝试：使用 Wasm 来编写通用的 eBPF 程序，然后可以将其分发到任意不同版本、不同架构的 Linux 内核中，无需重新编译即可运行。

eBPF 进阶: 内核新特性进展一览

eBPF 进阶: 内核新特性进展一览

Linux 内核在 2022 年主要发布了 5.16-5.19 以及 6.0 和 6.1 这几个版本，每个版本都为 eBPF 引入了大量的新特性。本文将对这些新特性进行一点简要的介绍，更详细的资料请参考对应的链接信息。总体而言，eBPF 在内核中依然是最活跃的模块之一，它的功能特性也还在高速发展中。某种意义上说，eBPF 正朝着一个完备的内核态可编程接口快速进化。

eunomia-bpf 的 3 月进展

eunomia-bpf 的 3 月进展

eunomia-bpf 项目是一个开源项目，旨在提供一组工具，用于在 Linux 内核中更方便地编写和运行 eBPF 程序。在过去一个月中，该项目取得了一些新的进展，以下是这些进展的概述。

首先，eunomia-bpf 动态加载库进行了一些重要的更新。该库现在支持 btf hub，这使得在低内核版本上移植 eBPF 程序更加容易。ecli 程序也进行了完全的重写，现在是使用 Rust 编写的，已经取代了原本使用 C++ 编写的版本。此外，该库还修复了使用 JSON 动态加载 eBPF 程序的输出问题，并在 CI 中自动发布 Docker 镜像。

eunomia-bpf 0.3.0 发布：只需编写内核态代码，轻松构建、打包、发布完整的 eBPF 应用

eunomia-bpf 0.3.0 发布：只需编写内核态代码，轻松构建、打包、发布完整的 eBPF 应用

eunomia-bpf 简介

eBPF 源于 BPF，本质上是处于内核中的一个高效与灵活的虚拟机组件，以一种安全的方式在许多内核 hook 点执行字节码，开发者可基于 eBPF 开发性能分析工具、软件定义网络、安全等诸多场景。但是，目前对于开发和使用 eBPF 应用而言还可能存在一些不够方便的地方：

  • 搭建和开发 eBPF 程序是一个门槛比较高、比较复杂的工作，必须同时关注内核态和用户态两个方面的交互和信息处理，有时还要配置环境和编写对应的构建脚本；
  • 目前不同用户态语言如 C、Go、Rust 等编写的工具难以兼容、难以统一管理，多种开发生态难以整合：如何跨架构、跨语言和内核版本，使用标准化的方式方便又快捷的打包、分发、发布二进制 eBPF 程序，同时还需要能很方便地动态调整 eBPF 程序的挂载点、参数等等？
  • 如何更方便地使用 eBPF 的工具：有没有可能从云端一行命令拉下来就使用，类似 docker 那样？或者把 eBPF 程序作为服务运行，通过 HTTP 请求和 URL 即可热更新、动态插拔运行任意一个 eBPF 程序？

eunomia-bpf 是一个开源的 eBPF 动态加载运行时和开发工具链，是为了简化 eBPF 程序的开发、构建、分发、运行而设计的，基于 libbpf 的 CO-RE 轻量级开发框架。

Wasm-bpf: 架起 Webassembly 和 eBPF 内核可编程的桥梁

Wasm-bpf: 架起 Webassembly 和 eBPF 内核可编程的桥梁

作者：郑昱笙，陈茂林

Wasm 最初是以浏览器安全沙盒为目的开发的，发展到目前为止，WebAssembly 已经成为一个用于云原生软件组件的高性能、跨平台和多语言软件沙箱环境，Wasm 轻量级容器也非常适合作为下一代无服务器平台运行时。另一个令人兴奋的趋势是 eBPF 的兴起，它使云原生开发人员能够构建安全的网络、服务网格和多种可观测性组件，并且它也在逐步渗透和深入到内核的各个组件，提供更强大的内核态可编程交互能力。

Wasm-bpf 是一个全新的开源项目[1]，它定义了一套 eBPF 相关系统接口的抽象，并提供了一套对应的开发工具链、库以及通用的 Wasm + eBPF 运行时平台实例，让任意 Wasm 虚拟机或者 Wasm 轻量级容器中的应用，有能力将使用场景下沉和拓展到内核态，获取内核态和用户态的几乎所有数据，在网络、安全等多个方面实现对整个操作系统层面的可编程控制，从而极大的拓展 WebAssembly 生态在非浏览器端的应用场景。

Wasm-bpf: 为云原生 Webassembly 提供通用的 eBPF 内核可编程能力

Wasm-bpf: 为云原生 Webassembly 提供通用的 eBPF 内核可编程能力

作者：郑昱笙，陈茂林

Wasm 最初是以浏览器安全沙盒为目的开发的，发展到目前为止，WebAssembly 已经成为一个用于云原生软件组件的高性能、跨平台和多语言软件沙箱环境，Wasm 轻量级容器也非常适合作为下一代无服务器平台运行时。另一个令人兴奋的趋势是 eBPF 的兴起，它使云原生开发人员能够构建安全的网络、服务网格和多种可观测性组件，并且它也在逐步渗透和深入到内核的各个组件，提供更强大的内核态可编程交互能力。

Wasm-bpf 是一个全新的开源项目[1]，它定义了一套 eBPF 相关系统接口的抽象，并提供了一套对应的开发工具链、库以及通用的 Wasm + eBPF 运行时平台实例，让任意 Wasm 虚拟机或者 Wasm 轻量级容器中的应用，有能力将使用场景下沉和拓展到内核态，获取内核态和用户态的几乎所有数据，在网络、安全等多个方面实现对整个操作系统层面的可编程控制，从而极大的拓展 WebAssembly 生态在非浏览器端的应用场景。

eunomia-bpf：展望 2023，让 eBPF 插上 Wasm 的翅膀

eunomia-bpf：展望 2023，让 eBPF 插上 Wasm 的翅膀

回望过去的 2022 年，有两项技术备受瞩目：eBPF 和 WebAssembly。

eBPF: 全新的可能性

eBPF 是一项革命性的技术，起源于Linux内核，可以在操作系统的内核中运行沙盒程序。它被用来安全和有效地扩展内核的功能，而不需要改变内核的源代码或加载内核模块。

过去一年中，可观测技术得到了极大关注，也被 Gartner 列为 2023 年十大战略技术趋势之一。eBPF 本身是对传统观测能力一个非常好的补充，在对内核无侵入的前提下，它通过动态地向内核中插入一段自己的代码，实现定义监控及跟踪等多种多样的能力。同时， eBPF 也促进了网络，安全性，应用程序配置跟踪和性能故障排除等等领域的新一代工具的开发，这些工具不再依赖现有的内核功能，而是在不影响执行效率或安全性的情况下主动重新运行。

如今， eBPF 被广泛应用在云原生、可观测、性能调优、安全、硬件加速等领域，并且其应用场景还在快速扩展，各种场景基于 eBPF 技术的创新项目呈现井喷现象，对于操作系统社区而言，eBPF 技术带来了一个全新的可能性以及广阔的天地， eBPF 的时代已然来临。

过去的 eBPF summit 2022 中，《The future of eBPF in the Linux Kernel》展望了 eBPF 相关技术的发展方向，具体的演进方向可能包含几个方面：

  • 更完备的编程语义支持：当前 eBPF 的编程能力存在一些局限性（比如不支持变量边界的循环，指令数量受限等），未来希望能进一步提供图灵完备的编程能力，增强 eBPF 的循环、内存分配等多种语言特性。
  • 更强的安全性：支持类型安全，增强运行时 Verifier，希望 BPF 也能提供媲美 Rust 的安全编程能力，以及尝试有没有可能结合 Rust 和 BPF 的特性，提供更进一步的、同时保证可移植和安全性的内核功能。
  • 更广泛的移植能力：增强 CO-RE，加强 Helper 接口可移植能力，实现跨体系、平台的移植能力。
  • 更强的内核可编程能力：支持访问/修改内核任意参数、返回值，实现更强的内核编程能力，甚至使用 BPF 来帮助构建和增强内核本身的安全性。

Wasm: 引领下一代计算范式

相对于 eBPF 主要关注于内核态或者和内核相关的应用，用户态的 WebAssembly 也成为了 2022 年新的焦点。

WebAssembly（简称 Wasm）是一个自诞生之日起就充满潜力的技术，一开始为了一个可移植的目标而设计的一种类似汇编字节码的指令格式标准，可用于编译C/C+/RUST等高级语言，使客户端和服务器应用程序能够在浏览器上部署；时至今日，WebAssembly 正在沿着其名字中 Web 和 Assembly 两个领域之外的方向发展，使用与 Wasm 兼容的运行时，Wasm 文件可以在客户端和服务器端执行，从 "JavaScript 杀手" 到 "云计算的下一个前沿方向" 几乎覆盖了全部新兴领域，同时在从云计算、serverless 向边缘计算渗透，Wasm 已经远远超出了起作为第四种 Web 标准语言的角色。甚至重新定义了应用软件的开发模式，正逐渐接近其 “一次编写，随处运行” 的愿景。

Wasm 有几个关键的设计目标使其出生开始就自带令人亮眼的关注：

  • 可移植：Wasm 被设计为针对低级虚拟机架构，其指令由物理机单独翻译成机器代码。这意味着 Wasm 二进制文件最终可以在各种操作系统和芯片架构上运行 —— 无论是在运行 X86 笔记本电脑的浏览器中，还是在内部或云端的服务器上，在移动设备、物联网设备上等等。
  • 多语言：因为 Wasm 是一个编译目标，用于编程模块的具体语言并不重要，重要的是是否有支持将该语言编译到 Wasm。开发人员可以灵活地使用多种语言（如 C、C++、Rust、凹语言等）来构建二进制文件，并享受 Wasm 带来的红利。
  • 轻量和高效：作为一个低级别的二进制指令格式，只需要较少的操作来将 Wasm 翻译成优化的机器代码。
  • 安全：Wasm 目标之一是安全，它在一个沙盒环境中执行，对主机运行时没有初始可见性。这意味着对系统资源（如文件系统，硬件等）的访问是受限制的，除非明确导入了对应的函数以支持。因此 Wasm 极大限制了攻击面，实现了多租户环境中不受信任的代码安全受限地执行。

过去的 2022 年 Wasm 取得了不少激动人心的成就，许多新的 Wasm 初创公司涌现，老牌云服务商和公司宣布支持 Wasm，字节码联盟推出了许多新的 Wasm 标准，CNCF主办了两次 WasmDay 活动，而 Wasm 最大的用户之一 Figma 被 Adobe 以惊人的 200 亿美元收购。对于 WebAssembly 而言，2023 年很有可能也会是爆发的一年：

  • 组件模型描述了Wasm二进制文件相互交互的方式，正在迅速成熟，已经出现了参考实现。开发人员可以声明他们的应用程序需要哪些组件，或者更抽象地说，他们的应用需要哪些功能（而不是用他们首选的源语言查找库），然后Wasm运行时可以代表用户组装正确的组件集。2023 年将是组件模型开始重新定义我们如何编写软件的一年。
  • Wasm改变了无服务器环境的潜力。由于几乎即时的启动时间、较小的二进制文件大小以及平台和架构中立性，Wasm二进制文件可以用运行当今无服务器基础设施所需的一小部分资源来执行。
  • 2022年底，OCI Registry工作组宣布了一种存储容器镜像以外的其他内容的官方方式。这可能包括Helm图表、照片或Wasm应用程序。这个新功能被称为“工件存储”。
  • 所有大型编程语言都将得到Wasm支持：Wasm GC提案很可能在 2023 年初就能可用并得到支持，因此 Kotlin 和 Dart 将很快发布Wasm编译器，Java 也很可能将成为最流行的 Wasm 开发语言。

Coolbpf + eunomia-bpf = eunomia-lcc

在过去的一年中，阿里云龙蜥社区系统运维SIG（Special Interest Group） 正式开源了 Coolbpf 项目。Coolbpf 以 CO-RE（Compile Once-Run Everywhere）为基础实现，保留了资源占用低、可移植性强等优点，融合了BCC动态编译特性，通过远程服务能力，极大简化开发编译和运行效率，适合在生产环境批量部署应用。Coolbpf 还支持在没有 eBPF 特性的低内核版本上，通过提供的 eBPF 驱动，帮助它安全的在低版本上运行，从内核态和批量部署两个角度充分增强了 eBPF 程序"一次编译，到处运行” 的能力。

eunomia-bpf 也是一个结合 Wasm 的通用、轻量级、多语言的下一代 eBPF 开发框架/组件库，2022 年下半年在龙蜥社区 eBPF 技术探索 SIG [3] [5] 发起并孵化。eunomia-bpf 包含一个运行时和编译工具链，主要关注于改进 eBPF 程序用户态的开发和使用体验，主要有三个特性：

  1. 只需编写内核态代码即可运行 eBPF 程序，内核态前端完全兼容 bcc、原生 libbpf 等多种语法，可以降低 eBPF 开发的学习成本，提高开发效率；
  2. 编译工具链和运行时完全分离，保证不同版本编译工具链和运行时之间的兼容性，以 CO-RE（一次编译、到处运行）的方式加载，降低部署和使用的资源消耗；还可以让 BCC/bpftrace 类型的代码也支持 AOT 编译，在加载的的时候不依赖 llvm 等库，同时保留 bpftrace 类似脚本一样的简单使用方式；
  3. 用户态也支持多种语言，例如 C++/C/Rust 等，可以使用多种语言在 Wasm 中开发 eBPF 的用户态程序，并且以 Wasm 模块，或者 JSON/YAML 配置文件的方式分发和动态加载 eBPF 程序，同时以 Wasm OCI 镜像的形式存储和管理任意包含用户态和内核态的 eBPF 应用。

eunomia-bpf 希望成为一个以类库或者松散组合的框架的方式提供，在编译构建和分发运行 eBPF 程序方面做更多的探索工作，让其他公司和个人，想要基于自己的内核态 ebpf 基础设施，搭建一个类似的用户态开发运行环境，或者完整的开发平台、插件运行时，变得更容易很多。

在 2022 年底，我们尝试将 Coolbpf 和 eunomia-bpf 结合起来，借助 Coolbpf 提供的低内核版本支持的内核态基础设施，以及批量部署应用的能力，以及 eunomia-bpf 提供的结合 Wasm 的用户态开发、分发特性，在 Coolbpf 的大框架下创建了一个新的 eBPF 用户态开发库：eunomia-lcc，希望让 Coolbpf 也能：

  • 在编写 eBPF 程序或工具时只编写内核态代码，就能自动获取内核态导出信息，自动生成命令行参数、直方图输出等；
  • 使用 Wasm 进行用户态交互程序的开发，在 Wasm 虚拟机内部控制整个 eBPF 程序的加载和执行，以及处理 eBPF 上报的数据；
  • 可以将预编译的 eBPF 程序打包为通用的 JSON 或 Wasm 模块，跨架构和内核版本进行分发，无需重新编译即可动态加载运行。

同时还能保留 Coolbpf 的低版本兼容、BTF 自动获取、远程编译等特性，让 eBPF 程序的开发更加简便易行。

展望未来，eunomia-bpf 的团队在 2023 年也希望尝试探索、改进、完善 eBPF 程序开发、编译、打包、发布、安装、升级等的流程和工具、SDK，并积极向上游社区反馈，进一步增强 eBPF 的编程体验和语言能力；以及更进一步地和 WebAssembly 相结合，在可观测性、serverless、可编程内核等诸多方面做更多的探索和实践，朝着图灵完备和更完善的语言支持迈进。

参考资料

  1. Wasm 将引领下一代计算范式 [译]：https://www.oschina.net/news/214580
  2. WebAssembly：2023年的5个预测: https://www.sohu.com/a/626985661_121119003
  3. eBPF 技术探索 SIG 主页： https://openanolis.cn/sig/ebpfresearch
  4. Coolbpf 项目开源仓库: https://gitee.com/anolis/coolbpf
  5. eunomia-bpf 龙蜥社区镜像仓库：https://gitee.com/anolis/eunomia
  6. eunomia-bpf Github 仓库：https://github.com/eunomia-bpf/eunomia-bpf
  7. 当 Wasm 遇见 eBPF：使用 WebAssembly 编写、分发、加载运行 eBPF 程序 | 龙蜥技术: https://developer.aliyun.com/article/1050439
  8. 2023，可观测性需求将迎来“爆发之年”？https://36kr.com/p/dp2063589382737542

如何在 Linux 显微镜（LMP）项目中开启 eBPF 之旅？

如何在 Linux 显微镜（LMP）项目中开启 eBPF 之旅？

eBPF 为 Linux 内核提供了可扩展性，使开发人员能够对 Linux 内核进行编程，以便根据他们的业务需求快速构建智能的或丰富的功能。

我们的 LMP(Linux Microscope) 项目 是为了充分挖掘 ebpf 的可能性而建立的，项目以构建 eBPF 学习社区、成为 eBPF 工具集散地、孵化 eBPF 想法和项目为目标，正在大力建设中。之前我们在 LMP 其中的 eBPF Supermarket 中包含了大量由个人开发者编写的 eBPF 工具，覆盖了网络、性能分析、安全等多种功能，我们正在尝试把其中的一些程序迁移到 eBPF Hub，一些规范化的 eBPF 程序库，可以随时下载运行，或嵌入大型应用程序中作为插件使用。

我们尝试在 eBPF Hub 中，基于 eunomia-bpf 开发框架创建符合 OCI 标准的 Wasm 和 eBPF 程序，并利用 ORAS 简化扩展 LMP 的 eBPF 分发、加载、运行能力。

在 WebAssembly 中使用 C/C++ 和 libbpf 编写 eBPF 程序

在 WebAssembly 中使用 C/C++ 和 libbpf 编写 eBPF 程序

作者：于桐，郑昱笙

eBPF（extended Berkeley Packet Filter）是一种高性能的内核虚拟机，可以运行在内核空间中，用来收集系统和网络信息。随着计算机技术的不断发展，eBPF 的功能日益强大，进而被用来构建各种效率高效的在线诊断和跟踪系统，以及安全的网络和服务网格。

WebAssembly（Wasm）最初是以浏览器安全沙盒为目的开发的，发展到目前为止，WebAssembly 已经成为一个用于云原生软件组件的高性能、跨平台和多语言软件沙箱环境，Wasm 轻量级容器也非常适合作为下一代无服务器平台运行时，或在边缘计算等资源受限的场景高效执行。

现在，借助 Wasm-bpf 编译工具链和运行时，我们可以使用 Wasm 将 eBPF 程序编写为跨平台的模块，同时使用 C/C++ 或 Rust 来编写 Wasm 程序。通过在 WebAssembly 中使用 eBPF 程序，我们不仅能让 Wasm 应用享受到 eBPF 的高性能和对系统接口的访问能力，还可以让 eBPF 程序使用到 Wasm 的沙箱、灵活性、跨平台性、和动态加载，并且使用 Wasm 的 OCI 镜像来方便、快捷地分发和管理 eBPF 程序。结合这两种技术，我们将会给 eBPF 和 Wasm 生态来一个全新的开发体验！

在 WebAssembly 中使用 Rust 编写 eBPF 程序并发布 OCI 镜像

在 WebAssembly 中使用 Rust 编写 eBPF 程序并发布 OCI 镜像

作者：于桐，郑昱笙

eBPF（extended Berkeley Packet Filter）是一种高性能的内核虚拟机，可以运行在内核空间中，以收集系统和网络信息。随着计算机技术的不断发展，eBPF 的功能日益强大，并且已经成为各种效率高效的在线诊断和跟踪系统，以及构建安全的网络、服务网格的重要组成部分。

WebAssembly（Wasm）最初是以浏览器安全沙盒为目的开发的，发展到目前为止，WebAssembly 已经成为一个用于云原生软件组件的高性能、跨平台和多语言软件沙箱环境，Wasm 轻量级容器也非常适合作为下一代无服务器平台运行时，或在边缘计算等资源受限的场景高效执行。

现在，借助 Wasm-bpf 编译工具链和运行时，我们可以使用 Wasm 将 eBPF 程序编写为跨平台的模块，使用 C/C++ 和 Rust 编写程序。通过在 WebAssembly 中使用 eBPF 程序，我们不仅让 Wasm 应用获得 eBPF 的高性能、对系统接口的访问能力，还可以让 eBPF 程序享受到 Wasm 的沙箱、灵活性、跨平台性、和动态加载的能力，并且使用 Wasm 的 OCI 镜像来方便、快捷地分发和管理 eBPF 程序。例如，可以类似 docker 一样，从云端一行命令获取 Wasm 轻量级容器镜像，并运行任意 eBPF 程序。通过结合这两种技术，我们将会给 eBPF 和 Wasm 生态来一个全新的开发体验！