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

APX-aware JIT backend for legacy x86 and bpftime

Modern Intel CPUs with APX (Advanced Performance Extensions) expose 32 general-purpose registers and richer 3-operand encodings, offering significant potential for reducing spills and memory traffic in hot code paths. Many existing binaries, JITs, and runtimes, however, still emit “legacy” x86-64 code that cannot automatically take advantage of APX. This project aims to build an APX-aware JIT / dynamic binary translation backend that can “rehydrate” legacy x86-64 code into an intermediate representation (IR) and re-emit it using APX features for maximum performance when running on APX-capable CPUs.

This JIT can be integrated with bpftime’s userspace runtime (e.g., for helpers, ufuncs, and host-side instrumentation code), or used as a standalone component for accelerating hot regions of existing x86-64 applications.

Project Overview

The goal of this project is to design and implement an APX-aware JIT backend that:

  • Detects APX support on the host CPU.
  • Lifts legacy x86-64 code (or bpftime-generated code) into an SSA-like IR.
  • Performs APX-specific optimizations (extra registers, 3-operand forms, flag suppression).
  • Emits APX machine code into a code cache and transparently routes hot paths through the APX-optimized version.

For bpftime, this enables a next-generation userspace runtime where both eBPF programs and their surrounding helper logic can benefit from APX when available, while still falling back to standard x86-64 on older hardware.

Objectives

  1. APX-capable CPU Detection and Dispatch
  2. Implement runtime feature detection for APX-capable processors.

  3. Provide a clean CPU dispatch layer that selects APX or legacy code paths at startup or JIT time.

  4. IR Lifting from Legacy x86-64

  5. Decode legacy x86-64 basic blocks or traces into an intermediate representation (SSA-like).
  6. Model registers, flags, and memory accesses so that APX-specific optimizations can be applied cleanly.

  7. Integrate this IR with bpftime’s existing VM / LLVM JIT infrastructure where appropriate.

  8. APX-specific Optimization Passes

  9. Use APX’s extra general-purpose registers (R16–R31) to eliminate spills and stack traffic in hot blocks.
  10. Convert classic 2-operand arithmetic into 3-operand APX forms to shorten dependency chains.
  11. Use flag-suppression forms (where available) when flags are not needed, reducing EFLAGS pressure.

  12. Explore small patterns where conditional loads/stores can replace short branches.

  13. Code Generation and Code Cache Management

  14. Implement an APX-aware register allocator that prefers EGPRs (R16–R31) for short-lived temporaries.
  15. Emit APX-encoded instructions into a code cache and manage patching/jump trampolines from original code.

  16. Provide safe fallbacks for unsupported or self-modifying code (e.g., interpretation or legacy re-emission).

  17. Integration with bpftime and Tooling

  18. Expose the APX JIT backend as an optional path for bpftime’s userspace runtime (e.g., for helpers, ufuncs, and hot loops in host code).
  19. Add configuration switches and environment variables to enable/disable APX optimizations.

  20. Provide benchmarks showing improvements for representative bpftime workloads (profiling, networking, file-system helpers, etc.).

  21. Documentation and Evaluation

  22. Document the design of the IR, the APX-specific passes, and integration points with bpftime.
  23. Provide microbenchmarks (e.g., arithmetic kernels, memcopy-like loops) and macrobenchmarks (bpftime-based tools) comparing:
    • Legacy x86-64 code,
    • APX-aware JIT code.
  24. Summarize trade-offs in code size, JIT overhead, and runtime performance.

Expected Outcomes

  • A working APX-aware JIT backend capable of:
  • Lifting legacy x86-64 code into an IR.
  • Re-emitting it using APX extensions on supported CPUs.
  • Integration hooks for bpftime so that bpftime’s userspace runtime can optionally use APX-optimized code for hot paths.
  • Benchmarks and evaluation showing tangible performance benefits (e.g., reduced spills, better throughput) on APX hardware.
  • Clear documentation and examples demonstrating how to enable APX JIT, how it behaves on non-APX CPUs, and how contributors can extend or customize the optimization passes.

Prerequisites and Skills

  • Strong C/C++ and systems programming skills.
  • Familiarity with x86-64 architecture, instruction encoding, and CPU microarchitecture concepts.
  • Experience with JIT compilation, dynamic binary translation, or compiler IR (e.g., LLVM IR, custom SSA).
  • Basic understanding of eBPF, bpftime’s goals, and userspace runtime design is highly desirable.
  • Experience with performance profiling and benchmarking on modern CPUs.

Reference and Issue

  • Intel APX and extended GPRs / instruction encodings (official whitepapers and manuals).
  • Existing JIT/DBT frameworks and code caches (e.g., LLVM ORC JIT, QEMU TCG, DynamoRIO, etc.).
  • bpftime runtime and VM code:
  • https://eunomia.dev/bpftime
  • https://github.com/eunomia-bpf/bpftime
  • A future GitHub issue in eunomia-bpf/bpftime can be created to track design, discussion, and implementation progress for the APX JIT backend.

Share on Share on