F40 Change proposal: Bpfman as default eBPF manager (Self-Contained)

Fedora 40: Bpfman as default eBPF manager (Self-Contained Change proposal)

This is a proposed Change for Fedora Linux.
This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee.


:link: Summary

bpfman: An eBPF Manager bpfman operates as an eBPF manager, focusing on simplifying the deployment and administration of eBPF programs. Its notable features encompass:

  • System Overview: Provides insights into how eBPF is utilized in your system.
  • eBPF Program Loader: Includes a built-in program loader that supports program cooperation for XDP and TC programs, as well as deployment of eBPF programs from OCI images.
  • eBPF Filesystem Management: Manages the eBPF filesystem, facilitating the deployment of eBPF applications without requiring additional privileges.

We do aim to have this included in Fedora so it becomes the de-facto and easy way to load eBPF programs.

:link: Owner

:link: Detailed Description

bpfman operates as an eBPF manager, focusing on simplifying the deployment and administration of eBPF programs. bpfman is a software stack that aims to make it easy to load, unload, modify and monitor eBPF programs whether on a single host, or in a Kubernetes cluster. bpfman includes the following core components:

  • bpfman: A system daemon that supports loading, unloading, modifying and monitoring of eBPF programs exposed over a gRPC API.
  • eBPF CRDS: bpfman provides a set of CRDs (XdpProgram, TcProgram, etc.) that provide a way to express intent to load eBPF programs as well as a bpfman generated CRD (BpfProgram) used to represent the runtime state of loaded programs.
  • bpfman-agent: The agent runs in a container in the bpfman daemonset and ensures that the requested eBPF programs for a given node are in the desired state.
  • bpfman-operator: An operator, built using Operator SDK, that manages the installation and lifecycle of bpfman-agent and the CRDs in a Kubernetes cluster.

bpfman is developed in Rust and built on top of Aya, a Rust eBPF library.

:link: Feedback


:link: Benefit to Fedora

bpfman is a software stack simplifying the management of eBPF programs in Kubernetes clusters or on individual hosts. It comprises a system daemon (bpfman), eBPF Custom Resource Definitions (CRDs), an agent (bpfman-agent), and an operator (bpfman-operator). Developed in Rust on the Aya library, bpfman offers improved security, visibility, multi-program support, and enhanced productivity for developers.

For Fedora, integrating bpfman would streamline eBPF program loading. It enhances security by restricting privileges to the controlled bpfman daemon, simplifies deployment in Kubernetes clusters, and offers improved visibility into running eBPF programs. This integration aligns with Fedora’s commitment to providing efficient and secure solutions, making it easier for users to leverage the benefits of eBPF in their systems.

:link: Scope

  • Proposal owners:Submit / review pull-requests and packages to Fedora
  • Other developers: @ebpf-sig/bpfman-next Copr migrate these packages from copr to Fedora alongside proposal owners
  • Release engineering: #Releng issue number
  • Policies and guidelines: N/A (not needed for this Change)
  • Trademark approval: N/A (not needed for this Change)
  • Alignment with Community Initiatives: N/A

:link: Upgrade/compatibility impact


:link: How To Test


:link: User Experience

Users would be able to easily load eBPF programs within Fedora in a way more simpler way than currently using bpfman.

:link: Dependencies

:link: Contingency Plan

  • Contingency mechanism: (What to do? Who will do it?) N/A (not a System Wide Change)
  • Contingency deadline: N/A (not a System Wide Change)
  • Blocks release? N/A (not a System Wide Change), No

:link: Documentation

:link: Release Notes

1 Like

What is the current way for comparison?
Why is it easier to use bpfman?

Let’s assume an easy xdp application. Usually you’d need to do something along the lines of:

$ clang -O2 -g -Wall -target bpf -c xdp_drop.c -o xdp_drop.o

Then create your veth interface for it

$ip link set veth1 xdpgeneric obj xdp_drop.o sec xdp_drop

Load the program itself

$xdp-loader load -m skb -s xdp_drop veth1 xdp_drop.o

And check the output

Using bfman you can directly fetch the program from a container image (althought it'd also work locally) and you'd get a similar result in just one command-

sudo ./target/debug/bpfman load image --image-url quay.io/bpfman-bytecode/xdp_pass:latest xdp --iface vethff657c7 --priority 100
 Bpfman State
 Name:          pass
 Image URL:     quay.io/bpfman-bytecode/xdp_pass:latest
 Pull Policy:   IfNotPresent
 Global:        None
 Metadata:      None
 Map Pin Path:  /run/bpfman/fs/maps/6213
 Map Owner ID:  None
 Map Used By:   6213
 Priority:      100
 Iface:         vethff657c7
 Position:      0
 Proceed On:    pass, dispatcher_return

 Kernel State
 ID:                               6213
 Name:                             pass
 Type:                             xdp
 Loaded At:                        2023-07-17T17:48:10-0400
 Tag:                              4b9d1b2c140e87ce
 GPL Compatible:                   true
 Map IDs:                          [2724]
 BTF ID:                           2834
 Size Translated (bytes):          96
 JITed:                            true
 Size JITed (bytes):               67
 Kernel Allocated Memory (bytes):  4096
 Verified Instruction Count:       9

It would also allow you to have more then one bpf program based on priority, and you’d be able to list them as in

sudo ./target/debug/bpfman list
Program ID Name Type Load Time
6213 pass xdp 2023-07-17T17:48:10-0400
6215 pass xdp 2023-07-17T17:52:46-0400
6217 pass xdp 2023-07-17T17:53:57-0400
6219 pass xdp 2023-07-17T17:59:41-0400

while xfp-loader wouldn't allow you to do this.

Furthermore, it can be run as a systemd service and also can use a kubernetes controller if there's a cluster available. For more details feel free to check the ilnks there or go to the examples provided in https://bpfman.io/main/getting-started/building-bpfman/ directly. Thanks!

Is this about providing a package that can be installed, or about including it by default in some or all Editions and Spins? For example, I have never loaded an eBPF program, hence I suppose would not want this installed by default.

Also, it is unclear if something is replaced, removed or changed, or if this just adds a new tool.

Hi Otto, thanks for your question! This is about a package that can be installed (bpfman), it doesn’t have to be included by default on Editions/spins. As you comment, I also assume not every user would ever like to install an eBPF program.

We have a COPR repo [1] for buils and have opened a Bugzilla for a spec in Fedora, just in case you’d be so kind of reviewing it [2]

[1] Project List
[2] 2257948 – Review Request: bpfman - EBPF Program Manager

Why is a change proposal needed?
Just package bpfman and do not install it by default.

Hi Barry, thanks for your question too! We’re proposing this change from the ebpf-sig-group [1] and we wanted to have awareness of the community for it.

For now we’ll just go ahead, package bpfman as you suggest and not install it as default. That said, we may have follow up packages later on and of course this is an effort within the Special Interest Group (SIG) which has limited impact outside.

We wanted to have this publicly announced and proposed to have a wider scope even if it wouldn’t have many (or any) impact outside the SIG’s functional area (just somehow quoting this from Fedora docs at [2])

We’re also happy to get feedback about the change as we already did (thanks all) and will be totally open to collaborate with anyone interested, this being also partially the motivation for announcing this new tool/package as a Self Contained Change from the SIG.


[1] Fedora ebpf-sig-group SIGs/eBPF - Fedora Project Wiki
[2] Changes policy :: Fedora Docs

This change proposal has now been submitted to FESCo with ticket #3153 for voting.

To find out more, please visit our Changes Policy documentation.