Experimental eBPF Backend
Relevant source files
The following files were used as context for generating this wiki page:
The Experimental eBPF Backend is a specialized compilation target for Pop Lang designed to emit extended Berkeley Packet Filter (eBPF) bytecode. This backend allows Pop Lang code to be executed within restricted environments such as the Linux kernel or high-performance networking data planes. It leverages the LLVM backend architecture to lower backend-neutral Intermediate Representations (IR) into BPF-compatible machine code.
As an experimental feature, this backend focuses on providing a secure, verifiable path for Pop programs into the kernel while adhering to the project's strong static typing and no-dynamic-fallback invariants. It is implemented within the Rust-based compiler toolchain, specifically utilizing the pop-backends-llvm crate to interface with LLVM's BPF target.
Sources: architecture/decisions/0071-experimental-ebpf-backend.md, crates/compiler/backends/llvm/src/bpf.rs, architecture/README.md:27-31
Architecture and Pipeline
The eBPF backend integrates into the standard Pop Lang semantic pipeline. It consumes verified, backend-neutral Canonical MIR (Mid-level Intermediate Representation) and lowers it into LLVM IR configured for the BPF target.
Compilation Flow
The diagram above illustrates the transformation from Pop source code to eBPF bytecode, highlighting the transition from backend-neutral MIR to target-specific LLVM BPF lowering.
Sources: architecture/03-compiler-pipeline.md, architecture/README.md:144-149, architecture/decisions/0071-experimental-ebpf-backend.md
Implementation Details
The implementation is housed within the LLVM backend crate and uses Inkwell (a safe LLVM wrapper) to configure the BPF target.
Target Configuration
The backend explicitly enables the BPF target within LLVM. This configuration is restricted to reviewed native and BPF targets to prevent dependency bloat and maintain security boundaries.
| Component | Responsibility |
|---|---|
BpfBackend | Orchestrates the lowering of MIR to BPF-specific LLVM IR. |
Inkwell | Provides the interface to LLVM for target machine creation and code generation. |
BPF Target | LLVM-internal target responsible for generating BPF instructions. |
Sources: crates/compiler/backends/llvm/src/bpf.rs:1-15, architecture/decisions/0018-rust-workspace-and-crate-boundaries.md:30-36
Lowering Logic
The BPF backend must handle specific eBPF constraints, such as restricted stack size (512 bytes) and the absence of arbitrary loops. The Pop Lang compiler ensures these invariants are respected during the MIR-to-LLVM transition.
// Example of BPF target initialization in crates/compiler/backends/llvm/src/bpf.rs
pub fn initialize_bpf_target() {
Target::initialize_bpf(&InitializationConfig::default());
}
Sources: crates/compiler/backends/llvm/src/bpf.rs:5-10, architecture/decisions/0071-experimental-ebpf-backend.md
Design Invariants and Constraints
The eBPF backend is subject to strict architecture conformance policies to ensure backend equivalence and security.
Conformance Policies
- Backend Neutrality: The HIR and MIR must remain backend-neutral and cannot contain BPF-specific opcodes or layouts.
- No Dynamic Escape Hatches: The backend cannot introduce
anyor dynamic lookup, as these are incompatible with the kernel's eBPF verifier. - Safety: The backend preserves Pop Lang's checked arithmetic and control-flow semantics, ensuring that generated BPF bytecode does not trigger kernel verifier failures for undefined behavior.
Sources: architecture/19-architecture-conformance-and-regression-policy.md:28-35, architecture/README.md:144-149, architecture/decisions/0071-experimental-ebpf-backend.md
Capabilities and Limitations
As an experimental backend, it focuses on a subset of the language suitable for kernel execution:
| Feature | Support Level | Notes |
|---|---|---|
| Fixed-width Integers | Full | Map directly to BPF registers. |
| Scalar Operations | Full | Arithmetic and logic operations are verified for safety. |
| Function Calls | Restricted | Limited to eBPF helper functions or BPF-to-BPF calls. |
| Managed Memory | None | BPF does not support the standard Pop GC; requires stack or maps. |
| Closures | None | Escaping closures are currently unauthorized in BPF MIR. |
Sources: architecture/decisions/0071-experimental-ebpf-backend.md, architecture/19-architecture-conformance-and-regression-policy.md:120-135
Security and Verification
A critical phase of the eBPF backend is ensuring bytecode passes the kernel verifier. The Pop Lang compiler uses its typed semantic model to prevent common BPF hazards.
The sequence diagram shows the verification chain from MIR lowering to the final kernel acceptance check.
Sources: architecture/decisions/0071-experimental-ebpf-backend.md, architecture/19-architecture-conformance-and-regression-policy.md:150-160
Summary
The Experimental eBPF Backend provides a high-performance, secure bridge for Pop Lang into the Linux kernel environment. By leveraging the project's backend-neutral MIR and the robust LLVM BPF target, it enables the development of kernel-level logic using a strongly typed, Luau-inspired language. While currently limited in its support for managed runtime features, it establishes the foundation for future data plane and systems programming capabilities within the Pop ecosystem.
Sources: architecture/decisions/0071-experimental-ebpf-backend.md, architecture/README.md:180-185