Skip to content

Possible ideas for the future

This is some possible ideas for open source events, like GSOC(Google Summer of Code) or OSPP(Open Source Promotion Plan) and others. Our projects are designed to suit contributors with varying levels of expertise, from students to more advanced developers.

It's also part of our project roadmap, if you don't participate in these events, you can also help or colaborate with these ideas! Need help? Please contact in the email list or in the Discord channel.

Persistent eBPF Maps with Crash‑Consistent Semantics

Project Overview

Kernel eBPF maps are frequently treated as small in‑kernel KV stores, but today they provide no persistence or crash‑consistency semantics. Pinned maps survive loader exit but not reboots; updates have no durability guarantees; and applications build fragile ad‑hoc recovery logic. This project aims to design and prototype persistent eBPF maps with explicit, documented semantics for durability, crash recovery, and versioning—suitable for production observability, policy modules, and long‑running agents.

Objectives

  • Define a persistence model for kernel maps, including durability levels, epoch barriers, permitted partial states after crashes, and expected reconstruction rules.
  • Build a persistence backend (privileged user‑space daemon + kernel API usage) that mirrors map mutations into an append‑only log and periodic snapshots, with recovery logic that reconstructs kernel maps on reboot.
  • Integrate persistence without modifying verifier or map types initially; persistence is additive through metadata and a daemon, with an optional future “persistent map” flag.
  • Implement automatic recovery at boot: detect persistent maps, rebuild state, repopulate kernel maps before programs attach, and require no application‑specific handlers.

Expected Outcomes

  • A documented durability and crash‑consistency model for eBPF maps.
  • A daemon and on‑disk format for logging and snapshotting kernel map state.
  • A crash‑injection test suite validating correctness of recovery.
  • Example cases such as persistent counters, node‑local policies, and replicated state.

May have a chance to publish papers on top conference.

Useful References

sched_ext‑Based Coz‑Style Causal Profiler (“SchedCoz”)

Project Overview

Coz (paper) introduced causal profiling via virtual speedups: when a target line executes, other threads are artificially slowed to approximate the effect of optimizing that line. Coz implements this in user space with LD_PRELOAD and injected sleeps. This project re‑implements causal profiling inside the kernel scheduler using sched_ext, producing a cleaner, zero‑injection mechanism suitable for real multi‑process services and container environments.

Objectives

  • Use eBPF perf‑event sampling and uprobes/USDT to collect user stacks and progress points; a user‑space controller selects regions and coordinates experiments.
  • Implement a sched_ext scheduler that maintains a global “debt” incremented when the target region executes, and reduces CPU service to tasks with unpaid debt, reproducing Coz’s virtual‑speedup semantics.
  • Establish correctness by mapping Coz’s delay‑insertion model to scheduler‑level service‑reduction, handling multi‑core behavior, preemption boundaries, and wakeup dependencies.
  • Provide scoped deployment by confining experiments to specific cgroups and ensuring clean fallback to CFS.

Expected Outcomes

  • A functioning SchedCoz profiler that integrates eBPF sampling and sched_ext scheduling to perform causal experiments.
  • Experimental fidelity comparable to Coz, with potentially lower variance and no user‑space sleeps or preload libraries.
  • Demonstrations on multi‑process workloads (Memcached, Redis, SQLite, NGINX) and containerized environments.
  • Documentation and runnable examples for building sched_ext‑based profilers.

May have a chance to publish papers on top conference.

Useful References

Porting bpftime to macOS and Windows, FreeBSD, or other platforms

Since bpftime can run in userspace and does not require kernel eBPF, why not enable eBPF on MacOS/FreeBSD/Other Platforms?

The goal of this project is to port bpftime to macOS and other platforms, expanding its cross-platform capabilities and enabling macOS users to leverage the powerful features of eBPF in their development and production environments. With bpftime, now you may be able to run bcc and bpftrace tools on macOS and other OSs!

Objectives for enable eBPF on macOS and Windows, FreeBSD

  1. Compatibility and Integration: Achieve compatibility of bpftime with macOS and/or other OSs, ensuring that core features and capabilities are functional on this platform.
  2. Performance Optimization: Fine-tune the performance of bpftime on macOS and/or other OSs, focusing on optimizing the LLVM JIT and the lightweight JIT for x86 specifically for macOS architecture.
  3. Seamless Integration with macOS Ecosystem: Ensure that bpftime integrates smoothly with macOS and/or other OSs environments, providing a native and efficient development experience for eBPF users.
  4. Documentation and Tutorials: Develop documentation and tutorials tailored to macOS users, facilitating easy adoption and use of bpftime on this platform.

Expected Outcomes

  • A functional port of bpftime for macOS and Windows, FreeBSD, with core features operational.
  • You should be able to run bpftrace and bcc tools on them, and get expected output.
  • documentation and guides for using bpftime on macOS and/or other OSs.

Prerequisites and Skills

  • Proficiency in C/C++ and system programming.
  • Familiarity with macOS development environment and tools.
  • Understanding of eBPF and its applications.

Reference and issue

User-Space eBPF Security Modules for Comprehensive Security Policies

Project Overview

bpftime is a user-space eBPF runtime that allows existing eBPF applications to run directly in unprivileged user space, using the same libraries and toolchains, and to obtain trace analysis results. It provides tracing points such as Uprobe and Syscall tracepoint for eBPF, reducing the overhead by about 10 times compared to kernel uprobe, without the need for manual code instrumentation or process restarts. It enables non-intrusive analysis of source code and compilation processes. It can also be combined with DPDK to implement XDP functionality in user-space networking, compatible with kernel XDP. The runtime supports inter-process eBPF maps in user-space shared memory, as well as kernel eBPF maps, allowing seamless operation with the kernel's eBPF infrastructure. It also includes high-performance eBPF LLVM JIT/AOT compilers for multiple architectures.

Linux Security Modules (LSM) is a security framework implemented in the Linux kernel, providing a mechanism for various security policy modules to be inserted into the kernel, enhancing the system's security. LSM is designed to offer an abstraction layer for the Linux operating system to support multiple security policies without changing the core code of the kernel. This design allows system administrators or distributions to choose a security model that fits their security needs, such as SELinux, AppArmor, Smack, etc.

What can LSM be used for?

  • Access Control: LSM is most commonly used to implement Mandatory Access Control (MAC) policies, different from the traditional owner-based Access Control (DAC). MAC can control access to resources like files, network ports, and inter-process communication in a fine-grained manner.
  • Logging and Auditing: LSM can be used to log and audit sensitive operations on the system, providing detailed log information to help detect and prevent potential security threats.
  • Sandboxing and Isolation: By limiting the behavior of programs and the resources they can access, LSM can sandbox applications, reducing the risk of malware or vulnerability exploitation.
  • Enhancing Kernel and User-Space Security: LSM allows for additional security checks and restrictions to enhance the security of both the kernel itself and applications running in user-space.
  • Limiting Privileged Operations: LSM can limit the operations that even processes with root privileges can perform, reducing the potential harm from misconfigurations by system administrators or malicious software with root access.

With bpftime, we can run eBPF programs in user space, compatible with the kernel, and collaborate with the kernel's eBPF to implement defense. Is it possible to further extend eBPF's security mechanisms and features to user space, allowing user-space eBPF and kernel-space eBPF to work together to implement more powerful and flexible security policies and defense capabilities? Let's call this mechanism USM (Userspace Security Modules or Union Security Modules).

You can explore more possibilities with us:

Objectives

  1. USM Framework Design and Implementation: Architect and implement the USM framework within bpftime, enabling user-space eBPF programs to work alongside kernel-space eBPF LSM programs.
  2. Security Scenario Exploration: Investigate potential security scenarios where USM can effectively intercept and defend against security threats, using both kernel and user-space eBPF mechanisms.
  3. Continuous Integration and Testing: Integrate USM testing into the bpftime CI pipeline, conducting regular checks to ensure compatibility and effectiveness of security policies.
  4. Documentation and Community Feedback: Generate comprehensive documentation on USM's architecture, API, and implementation. Engage with the bpftime community to gather feedback and refine USM.
  5. Security Policy Development and Validation: Develop and validate security policies that leverage USM, demonstrating its potential in enhancing system security.

Expected Outcomes

  • A fully implemented USM framework within the bpftime environment, allowing for seamless operation with kernel-space eBPF LSM programs and compatible with kernel eBPF toolchains and libraries.
  • Integration of USM testing into the bpftime CI pipeline to ensure ongoing compatibility and security efficacy.
  • A set of validated security policies showcasing USM's capability to enhance both kernel and user-space security.
  • Comprehensive documentation and a feedback loop with the community for continuous improvement of USM.

Prerequisites and Skills

  • Proficiency in C/C++ and system programming.
  • Understanding of security mechanisms and policies, especially related to Linux Security Modules (LSM) and eBPF.
  • Familiarity with user-space and kernel-space programming paradigms.
  • Experience with developing and testing eBPF programs is highly advantageous.

Reference and Issue

BPFTime Profiling and Machine Learning Prediction for far memory or distributed shared memory management

The upcoming world for CXL.mem provides a new way of memory fabric, it can seemingly share the memory between different nodes adding another layer between NUMA Remote, and SSDs. It can either be far memory node for disaggregation or distributed shared memory shared or pooled across nodes. However, issuing load and store to the CXL pool is easily throttle the performance. BPFTime can provide an extra layer of metrics collection and prediction for profiling guided memory management. BPFTime provides a cross kernel space and userspace boundary observability online. We think the offline access to the far memory is not deterministic across different workloads, and the same workloads with different runs, and the machine learning model can provide a better prediction for the memory access pattern.

Project Overview

Objectives

  • Implement application specific metrics collection and profiling in BPFTime.
  • Write eBPF for the far memory or distributed shared memory management.

Expected Outcomes

  • A set of metrics that can provide the right information for the memory scheduling and the memory access pattern.
  • A set of eBPF programs that can provide the right metrics for the large language model Training or Inference.

Prerequisites and Skills

  • Proficiency in C/C++ and system programming.
  • Understanding of kernel memory subsystem and memory management.
  • Familiarity with user-space and kernel-space programming paradigms.
  • Experience with developing and testing eBPF programs is highly advantageous.

Reference and Issue

Large Language Model specific metrics observability in BPFTime

BPFTime is able to provide multiple source of metrics in the userspace from the classical uprobe with maps. We can also provide metrics from gathering from the GPU, memory watch point, and other hardware. To support gdb rwatch BPFTime, we need to set a segfault to the certain memory accessed. For the GPU uprobe, we need static compilation and runtime API hooks to hook the certain GPU function calls. The uprobe attatched to the certain function calls provides the right online spot for annotate and make adjustment to the kernel's memory scheduling. The memory watch points can provide the memory access pattern and the memory access frequency. The GPU metrics can provide the GPU utilization and the memory access pattern. The combination of these metrics can provide the right information for the memory scheduling and the memory access pattern.

Project Overview

Objectives

  • Provide the right metrics for the large language model Training or Inference.
  • Programme the eBPF program to collect the right metrics and do the right scheduling.

Expected Outcomes

  • Implement the gdb rwatch and GPU metrics in BPFTime.
  • A set of metrics that can provide the right information for the memory scheduling and the memory access pattern.
  • A set of eBPF programs that can provide the right metrics for the large language model Training or Inference.

Prerequisites and Skills

  • Proficiency in C/C++ and system programming.
  • Understanding the architecture of the large language model, and the metrics that are important for the performance.
  • Has strong knowledge of GPU metrics collection, and gdb, perf, and other tools for metrics collection.
  • Experience with developing and testing eBPF programs is highly advantageous.

Reference and Issue

Share on Share on