A BPF Microconference will be featured at this year's Linux Plumbers Conference (LPC) in Lisbon, Portugal.
The goal of the BPF Microconference is to bring BPF developers together to discuss and hash out unresolved issues and to move new ideas forward. The focus of this year's event is on the core BPF infrastructure as well as its many subsystems and related user space tooling.
The BPF Microconference will be open to all LPC attendees. There is no additional registration required. This is also a great occasion for BPF users and developers to meet face to face and to exchange and discuss developments.
Similar to last year's BPF Microconference the main focus will be on discussion rather than pure presentation style.
Therefore, each accepted topic will provide introductory slides with subsequent discussion as the main part for the rest of the allocated time slot. The expected time for one discussion slot is approximately 20 min.
MC is lead by both BPF kernel maintainers:
The way BPF application developers build applications is constantly improving. There are still rough corners, as well as (as of yet) fundamentally inconvenient developer workflows involved (e.g., on-the-fly compilation). The ultimate goal of BPF application development is to provide experience as straightforward and simple as a typical user-land application.
We'll discuss major pain points...
Debugging BPF program logic is hard these days.
Developers typically write their programs and
then checking map values or perf_event outputs
make sense or not. For tricky issues, temporary
maps or bpf_trace_printk are used so developer
can get more insight about what happens. But
this requires possibly multiple rounds of
modifying sources, recompilation and redeployment, etc.
At the LSF/MM eBPF track, we discussed the necessity of a common Go
library to interact with BPF. Since then, Cilium and Cloudflare have
worked out a proposal to upstream parts of github.com/newtools/ebpf
and github.com/cilium/cilium/pkg/bpf into a new common library.
Our goal is to create a native Go library instead of a CGO wrapper
of C libbpf. This provides superior performance,...
Currently, most BPF functionality requires CAP_SYS_ADMIN or CAP_NET_ADMIN. However, in many cases, CAP_SYS_ADMIN/CAP_NET_ADMIN gives the user more than enough permissions. For example, tracing users need to load BPF programs and access BPF maps, so they need CAP_SYS_ADMIN. However, they don't need to modify the system, so CAP_SYS_ADMIN adds significant risk.
To better control BPF...
eBPF offload is a powerful feature on modern SmartNICs used to accelerate
XDP or TC based BPF. The current kernel eBPF offload infrastructure was
introduced for the Netronome NFP based SmartNICs, these were based around a
proprietary ISA and had some specific verifier requirements.
In the near future this may be joined by SmartNICs using public ISA's such
as RISC-V and Arm which also happen...
Currently, the BPF verifier has to "execute" code at least once and then it can prune branches when it detects the state is the same. In this session we would like to cover a technique called Scalar Evolution (SCEV) which is used by LLVM and GCC to perform optimization passes such as identifying and promoting induction variables and do worst case trip analysis over loops. At its most basic...
The Restartable Sequences system call [1,2,3,4] introduced in Linux 4.18 has limitations which can be solved by introducing a bytecode interpreter running in inter-processor interrupt context which accesses user-space data.
This discussion is about the subset of the eBPF bytecode and context needed by this interpreter, and extensions of that bytecode to cover load-acquire and...
Existing Linux Security Modules can only be extended by modifying and rebuilding the kernel, making it difficult to react to new threats. The Kernel Runtime Security Instrumentation project (KRSI) ([prototype code]) aims to help this by providing an LSM that allows eBPF programs to be added to security hooks.
The talk discusses the need for such an LSM (with representative use cases) and...
bcc community has long discussed that batch
dump, lookup and delete will help its typical
use case, periodically retrieving and deleting
all samples in the kernel. Without batch APIs,
bcc typically does
iterate through all keys (get_next_key API)
get (key, value) pairs
iterate through all keys to delete them
Also, Brian Vazquez
has proposed BPF_MAP_DUMP command to dump
more than one...