[
  {
    "Name": "libbpf",
    "License": "BSD-2-Clause",
    "License File": "LICENSE.BSD-2-Clause",
    "Version Number": "1.1",
    "Owner": "xiazhonglin@huawei.com",
    "Upstream URL": "https://github.com/libbpf/libbpf",
    "Description": "a third party library to use eBPF"
  }
]

<picture>
  <source media="(prefers-color-scheme: dark)" srcset="assets/libbpf-logo-sideways-darkbg.png" width="40%">
  <img src="assets/libbpf-logo-sideways.png" width="40%">
</picture>

libbpf
[![Github Actions Builds & Tests](https://github.com/libbpf/libbpf/actions/workflows/test.yml/badge.svg)](https://github.com/libbpf/libbpf/actions/workflows/test.yml)
[![Coverity](https://img.shields.io/coverity/scan/18195.svg)](https://scan.coverity.com/projects/libbpf)
[![CodeQL](https://github.com/libbpf/libbpf/workflows/CodeQL/badge.svg?branch=master)](https://github.com/libbpf/libbpf/actions?query=workflow%3ACodeQL+branch%3Amaster)
[![OSS-Fuzz Status](https://oss-fuzz-build-logs.storage.googleapis.com/badges/libbpf.svg)](https://oss-fuzz-build-logs.storage.googleapis.com/index.html#libbpf)
[![Read the Docs](https://readthedocs.org/projects/libbpf/badge/?version=latest)](https://libbpf.readthedocs.io/en/latest/)
======

**This is the official home of the libbpf library.**

*Please use this Github repository for building and packaging libbpf
and when using it in your projects through Git submodule.*

Libbpf *authoritative source code* is developed as part of [bpf-next Linux source
tree](https://kernel.googlesource.com/pub/scm/linux/kernel/git/bpf/bpf-next) under
`tools/lib/bpf` subdirectory and is periodically synced to Github. As such, all the
libbpf changes should be sent to [BPF mailing list](http://vger.kernel.org/vger-lists.html#bpf),
please don't open PRs here unless you are changing Github-specific parts of libbpf
(e.g., Github-specific Makefile).

Libbpf and general BPF usage questions
======================================

Libbpf documentation can be found [here](https://libbpf.readthedocs.io/en/latest/api.html).
It's an ongoing effort and has ways to go, but please take a look and consider contributing as well.

Please check out [libbpf-bootstrap](https://github.com/libbpf/libbpf-bootstrap)
and [the companion blog post](https://nakryiko.com/posts/libbpf-bootstrap/) for
the examples of building BPF applications with libbpf.
[libbpf-tools](https://github.com/iovisor/bcc/tree/master/libbpf-tools) are also
a good source of the real-world libbpf-based tracing tools.

See also ["BPF CO-RE reference guide"](https://nakryiko.com/posts/bpf-core-reference-guide/)
for the coverage of practical aspects of building BPF CO-RE applications and
["BPF CO-RE"](https://nakryiko.com/posts/bpf-portability-and-co-re/) for
general introduction into BPF portability issues and BPF CO-RE origins.

All general BPF questions, including kernel functionality, libbpf APIs and
their application, should be sent to bpf@vger.kernel.org mailing list. You can
subscribe to it [here](http://vger.kernel.org/vger-lists.html#bpf) and search
its archive [here](https://lore.kernel.org/bpf/). Please search the archive
before asking new questions. It very well might be that this was already
addressed or answered before.

bpf@vger.kernel.org is monitored by many more people and they will happily try
to help you with whatever issue you have. This repository's PRs and issues
should be opened only for dealing with issues pertaining to specific way this
libbpf mirror repo is set up and organized.

Building libbpf
===============
libelf is an internal dependency of libbpf and thus it is required to link
against and must be installed on the system for applications to work.
pkg-config is used by default to find libelf, and the program called can be
overridden with `PKG_CONFIG`.

If using `pkg-config` at build time is not desired, it can be disabled by
setting `NO_PKG_CONFIG=1` when calling make.

To build both static libbpf.a and shared libbpf.so:
```bash
$ cd src
$ make
```

To build only static libbpf.a library in directory
build/ and install them together with libbpf headers in a staging directory
root/:
```bash
$ cd src
$ mkdir build root
$ BUILD_STATIC_ONLY=y OBJDIR=build DESTDIR=root make install
```

To build both static libbpf.a and shared libbpf.so against a custom libelf
dependency installed in /build/root/ and install them together with libbpf
headers in a build directory /build/root/:
```bash
$ cd src
$ PKG_CONFIG_PATH=/build/root/lib64/pkgconfig DESTDIR=/build/root make install
```

BPF CO-RE (Compile Once – Run Everywhere)
=========================================

Libbpf supports building BPF CO-RE-enabled applications, which, in contrast to
[BCC](https://github.com/iovisor/bcc/), do not require Clang/LLVM runtime
being deployed to target servers and doesn't rely on kernel-devel headers
being available.

It does rely on kernel to be built with [BTF type
information](https://www.kernel.org/doc/html/latest/bpf/btf.html), though.
Some major Linux distributions come with kernel BTF already built in:
  - Fedora 31+
  - RHEL 8.2+
  - OpenSUSE Tumbleweed (in the next release, as of 2020-06-04)
  - Arch Linux (from kernel 5.7.1.arch1-1)
  - Manjaro (from kernel 5.4 if compiled after 2021-06-18)
  - Ubuntu 20.10
  - Debian 11 (amd64/arm64)

If your kernel doesn't come with BTF built-in, you'll need to build custom
kernel. You'll need:
  - `pahole` 1.16+ tool (part of `dwarves` package), which performs DWARF to
    BTF conversion;
  - kernel built with `CONFIG_DEBUG_INFO_BTF=y` option;
  - you can check if your kernel has BTF built-in by looking for
    `/sys/kernel/btf/vmlinux` file:

```shell
$ ls -la /sys/kernel/btf/vmlinux
-r--r--r--. 1 root root 3541561 Jun  2 18:16 /sys/kernel/btf/vmlinux
```

To develop and build BPF programs, you'll need Clang/LLVM 10+. The following
distributions have Clang/LLVM 10+ packaged by default:
  - Fedora 32+
  - Ubuntu 20.04+
  - Arch Linux
  - Ubuntu 20.10 (LLVM 11)
  - Debian 11 (LLVM 11)
  - Alpine 3.13+

Otherwise, please make sure to update it on your system.

The following resources are useful to understand what BPF CO-RE is and how to
use it:
- [BPF CO-RE reference guide](https://nakryiko.com/posts/bpf-core-reference-guide/)
- [BPF Portability and CO-RE](https://nakryiko.com/posts/bpf-portability-and-co-re/)
- [HOWTO: BCC to libbpf conversion](https://nakryiko.com/posts/bcc-to-libbpf-howto-guide/)
- [libbpf-tools in BCC repo](https://github.com/iovisor/bcc/tree/master/libbpf-tools)
  contain lots of real-world tools converted from BCC to BPF CO-RE. Consider
  converting some more to both contribute to the BPF community and gain some
  more experience with it.

Distributions
=============

Distributions packaging libbpf from this mirror:
  - [Fedora](https://src.fedoraproject.org/rpms/libbpf)
  - [Gentoo](https://packages.gentoo.org/packages/dev-libs/libbpf)
  - [Debian](https://packages.debian.org/source/sid/libbpf)
  - [Arch](https://archlinux.org/packages/core/x86_64/libbpf/)
  - [Ubuntu](https://packages.ubuntu.com/source/impish/libbpf)
  - [Alpine](https://pkgs.alpinelinux.org/packages?name=libbpf)

Benefits of packaging from the mirror over packaging from kernel sources:
  - Consistent versioning across distributions.
  - No ties to any specific kernel, transparent handling of older kernels.
    Libbpf is designed to be kernel-agnostic and work across multitude of
    kernel versions. It has built-in mechanisms to gracefully handle older
    kernels, that are missing some of the features, by working around or
    gracefully degrading functionality. Thus libbpf is not tied to a specific
    kernel version and can/should be packaged and versioned independently.
  - Continuous integration testing via
    [GitHub Actions](https://github.com/libbpf/libbpf/actions).
  - Static code analysis via [LGTM](https://lgtm.com/projects/g/libbpf/libbpf)
    and [Coverity](https://scan.coverity.com/projects/libbpf).

Package dependencies of libbpf, package names may vary across distros:
  - zlib
  - libelf

[![libbpf distro packaging status](https://repology.org/badge/vertical-allrepos/libbpf.svg)](https://repology.org/project/libbpf/versions)


bpf-next to Github sync
=======================

All the gory details of syncing can be found in `scripts/sync-kernel.sh`
script.

Some header files in this repo (`include/linux/*.h`) are reduced versions of
their counterpart files at
[bpf-next](https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git/)'s
`tools/include/linux/*.h` to make compilation successful.

License
=======

This work is dual-licensed under BSD 2-clause license and GNU LGPL v2.1 license.
You can choose between one of them if you use this work.

`SPDX-License-Identifier: BSD-2-Clause OR LGPL-2.1`

# libbpf

仓库包含第三方开源软件libbpf，libbpf是eBPF技术的一种实现，eBPF提供给开发者一种内核事件和用户进程事件发生时安全注入代码的机制，避免开发者直接进行内核编程时可能导致的系统锁定、内存损坏、进程崩溃和安全漏洞等问题。开发者基于libbpf第三方开源库高效便捷开发eBPF程序，应用于网络过滤、程序跟踪、性能分析以及调试等需求场景。

## 目录结构

```
docs/          文档
fuzz/          fuzz测试
include/       头文件
scripts/       脚本
src/           源文件
LICENSE        证书文件
README.md      英文说明
README_zh.md   中文说明
```

## OpenHarmony如何集成libbpf

### 1.头文件引入

```
#include "libbpf.h"
#include "bpf.h"
```

### 2.BUILD.gn添加引用

```
deps += ["//third_party/libbpf:libbpf"]
```
### 3.示例代码
```
# kprobe.bpf.c BPF程序
# 指定LICENSE
char LICENSE[] SEC("license") = "Dual BSD/GPL";
# 进入do_unlinkat函数时调用
SEC("kprobe/do_unlinkat")
int BPF_KPROBE(do_unlinkat, int dfd, struct filename *name)
{
	pid_t pid;
	const char *filename;

	pid = bpf_get_current_pid_tgid() >> 32;
	filename = BPF_CORE_READ(name, name);
	bpf_printk("KPROBE ENTRY pid = %d, filename = %s\n", pid, filename);
	return 0;
}
# 退出do_unlinkat函数时调用
SEC("kretprobe/do_unlinkat")
int BPF_KRETPROBE(do_unlinkat_exit, long ret)
{
	pid_t pid;

	pid = bpf_get_current_pid_tgid() >> 32;
	bpf_printk("KPROBE EXIT: pid = %d, ret = %ld\n", pid, ret);
	return 0;
}
```
```
# 用bpftool生成BPF skeleton脚手架文件
$ bpftool gen skeleton kprobe.bpf.o > kprobe.skel.h
```
```
# kprobe.c 将BPF程序加载进内核并附着到内核指定位置
#include kprobe.skel.h
struct kprobe_bpf *skel;
int err;
libbpf_set_strict_mode(LIBBPF_STRICT_ALL);
/* 加载并验证BPF程序 */
skel = kprobe_bpf__open_and_load();
if (!skel) {
	fprintf(stderr, "Failed to open BPF skeleton\n");
	return 1;
}
/* 将BPF程序附加到跟踪点 */
err = kprobe_bpf__attach(skel);
/* 销毁和回收资源 */
kprobe_bpf__destroy(skel);
```
## libbpf相关知识文档

[bpf参考指南](https://nakryiko.com/posts/bpf-core-reference-guide/)

[libbpf开发指导](https://nakryiko.com/posts/bcc-to-libbpf-howto-guide/)

[libbpf开发示例](https://github.com/libbpf/libbpf-bootstrap)
## License

`SPDX-License-Identifier: BSD-2-Clause OR LGPL-2.1`

‍

这是[Linux源码bpf](https://kernel.googlesource.com/pub/scm/linux/kernel/git/bpf/bpf-next)的`tools/lib/bpf`​目录及其支持的头文件的一个镜像。同步的所有细节都可以在`scripts/sync-kernel.sh`​脚本中找到。

此仓中的一些头文件（`include/linux/*.h`​）对应文件是[Linux源码bpf](https://kernel.googlesource.com/pub/scm/linux/kernel/git/bpf/bpf-next)的`tools/include/linux/*.h，使得libbpf能够编译成功。

# BPF/libbpf用法和问题

请查看[libbpf引导程序](https://github.com/libbpf/libbpf-bootstrap)和配套得[博客文章](https://nakryiko.com/posts/libbpf-bootstrap/)，使用libbpf构建BPF应用程序的示例。

[libbpf-tools](https://github.com/iovisor/bcc/tree/master/libbpf-tools)也是基于libbpf的跟踪工具的一个很好的实现。

另请参见[“BPF CO-RE参考指南”](https://nakryiko.com/posts/bpf-core-reference-guide/)，涵盖构建BPF CO-RE应用程序的实际方面，

以及[“BPF CO-RE”](https://nakryiko.com/posts/bpf-portability-and-co-re/)对于BPF可移植性问题和BPF CO-RE起源的一般介绍。

所有一般BPF问题，包括内核功能、libbpf API以及申请，应发送邮件至[bpf@vger.kernel.org](mailto:bpf@vger.kernel.org)。

你可以订阅[此处](http://vger.kernel.org/vger-lists.html#bpf)和搜索其档案[此处](https://lore.kernel.org/bpf/). 在提出新问题之前请搜索档案，很可能这已经是在之前被定位或回答。

[bpf@vger.kernel.org](mailto:bpf@vger.kernel.org)被很多人管理，他们会很乐意尝试帮助你解决任何问题。

# 构建指导

libelf是libbpf的内部依赖项，因此需要链接并且必须安装在系统上，应用程序才能工作。

pkg-config默认用于查找libelf，调用的程序可以是用“PKG_CONFIG”重写。

如果不希望在构建时使用“pkg config”，可以通过调用make时设置`NO_PKG_CONFIG=1`​。

构建静态库libbpf.a和动态库libbpf.so：

```
$cd src
$make
```

仅生成静态库libbpf.a

```
$cd src
$mkdir build root
$BUILD_STATIC_ONLY=y OBJDIR=build DESTDIR=root make install
```

构建静态库libbpf.a和动态库libbpf.so

```
$cd src
$PKG_CONFIG_PATH=/build/root/lib64/pkgconfig DESTDIR=/build/root make install
```

# 发行版

从此镜像打包libbpf的发行版：

-[Fedora](https://src.fedoraproject.org/rpms/libbpf)

-[Gentoo](https://packages.gentoo.org/packages/dev-libs/libbpf)

-[Debian](https://packages.debian.org/source/sid/libbpf)

-[Arch](https://www.archlinux.org/packages/extra/x86_64/libbpf/)

-[Ubuntu](https://packages.ubuntu.com/source/impish/libbpf)

-[Alpine](https://pkgs.alpinelinux.org/packages?name=libbpf)

从镜像打包优于从内核源打包的好处：

* 跨发行版的一致版本控制。

* 与任何特定内核无关，对旧内核的透明处理。

  Libbpf被设计为内核不可知的，可以跨多个内核版本。

  它有内置的机制，可以兼容老版本缺少某些功能的内核

  因此，libbpf没有绑定到特定的内核版本，并且可以/应该独立地打包和版本化。

* 通过以下方式进行持续集成测试

  [TravisCI](https://travis-ci.org/libbpf/libbpf).

* 通过[LGTM](https://lgtm.com/projects/g/libbpf/libbpf)和[Coverity](https://scan.coverity.com/projects/libbpf)进行静态代码分析

libbpf的包依赖性，包名称可能因发行版而异：

* zlib

* libelf

# BPF CO-RE（编译一次-到处运行）

libbpf支持构建支持BPF CO-RE的应用程序，这与[BCC](https://github.com/iovisor/bcc/)不同，不需要Clang/LLVM运行时部署到目标服务器并且不依赖于内核层的headers可用。
但是它依赖于使用[BTF](https://www.kernel.org/doc/html/latest/bpf/btf.html)构建的内核

尽管如此，一些主要的Linux发行版已经内置了内核BTF：

* Fedora31+
* RHEL 8.2+
* OpenSUSE Tumbleweed（下一个版本，截至2020-06-04）
* Arch Linux（来自内核5.7.1.arch1-1）
* Manjaro（如果在2021 06月18日之后编译，则来自内核5.4）
* Ubuntu 20.10
* Debian 11（amd64/arm64）

如果您的内核没有内置BTF，则需要构建自定义内核

您需要：

* pahole 1.16+工具（dwarves包的一部分），用于执行DWARF到BTF转换；

* 使用`CONFIG_DEBUG_INFO_BTF=y`​选项构建的内核；

* 您可以通过查找`/sys/kernel/btf/vmlinux`​文件来检查内核是否内置了BTF：

```
$ ls -la /sys/kernel/btf/vmlinux
-r--r--r--. 1 root root 3541561 Jun  2 18:16 /sys/kernel/btf/vmlinux
```

要开发和构建BPF程序，您需要Clang/LLVM 10+。以下发行版默认情况下具有Clang/LLVM 10+包：

* Fedora 32+

* Ubuntu 20.04+

* Arch Linux

* Ubuntu 20.10（LLVM 11）

* Debian 11（LLVM 11）

* Alpine 3.13+

否则，请确保在您的系统上更新它。

以下资源有助于理解什么是BPF CO-RE以及如何使用它：

* [BPF CO-RE参考指南](https://nakryiko.com/posts/bpf-core-reference-guide/)

* [BPF可移植性和CO-RE](https://nakryiko.com/posts/bpf-portability-and-co-re/)

* [HOWTO:BCC到libbpf的转换](https://nakryiko.com/posts/bcc-to-libbpf-howto-guide/)

* [BCC仓库中的libbpf工具](https://github.com/iovisor/bcc/tree/master/libbpf-tools)

# 许可证

本作品根据BSD 2条款许可证和GNU LGPL v2.1许可证双重许可。

如果您使用这项工作，您可以在其中一项中进行选择。

`SPDX-License-Identifier: BSD-2-Clause OR LGPL-2.1`