You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hello everyone, I am excited to propose the addition of a set of eBPF/BPF-related APIs to the WASI (WebAssembly
System Interface) ecosystem.
What is eBPF?
eBPF is a revolutionary technology with origins in the Linux kernel that can run sandboxed programs in a privileged context such as the operating system kernel. It is used to safely and efficiently extend the capabilities of the kernel without requiring to change kernel source code or load kernel modules.
By allowing to run sandboxed programs within the operating system, application developers can run eBPF programs to add additional capabilities to the operating system at runtime. The operating system then guarantees safety and execution efficiency as if natively compiled with the aid of a Just-In-Time (JIT) compiler and verification engine.
Now eBPF can run on both Linux and Windows, across many kernel versions. A portable BPF applications can run on multiple kernel versions and configurations without modifications and runtime source code compilation on the target machine, using BPF CO-RE (Compile Once – Run Everywhere)approach.
Bring eBPF ability to Wasm can allow Wasm programs and modules to have more use cases:
Today, eBPF is used extensively to drive a wide variety of use cases: Providing high-performance networking and load-balancing in modern data centers and cloud native environments, extracting fine-grained security observability data at low overhead, helping application developers trace applications, providing insights for performance troubleshooting, preventive application and container runtime security enforcement, and much more. The possibilities are endless, and the innovation that eBPF is unlocked has only just begun.
There are some discussions in #218, but I don't think we shall need to embed WASI runtime in the kernel: we just need to have some API to dynamically load, control and communicate with eBPF programs from user space. This is the typical use cases for eBPF applications.
Wasm sandbox would run the userspace part of an eBPF-based application, while eBPF sandbox run the kernel part.
WASI may be able to provide API include:
Load eBPF programs from Wasm modules into the kernel;
Attach the eBPF program to a specify hook, since eBPF programs are event-driven and are run when the kernel or an application passes a certain hook point;
Read and Write from bpf maps, since the eBPF programs are using maps for communications between kernel and userspace;
A vital aspect of eBPF programs is the ability to share collected information and to store state. For this purpose, eBPF programs can leverage the concept of eBPF maps to store and retrieve data in a wide set of data structures. eBPF maps can be accessed from eBPF programs as well as from applications in user space via a system call.
Unload and detach eBPF programs from kernel
The text was updated successfully, but these errors were encountered:
This is a minimal working runtime and toolchain example based on libbpf and WAMR, with only 300+ lines in runtime host implementation: https://github.com/eunomia-bpf/wasm-bpf
It provides most abilities from eBPF to Wasm, polling from the ring buffer or perf buffer, bidirectional communications between kernel eBPF and userspace Wasm using bpf maps, dynamically loading, attaching or detaching, etc.
Hello everyone, I am excited to propose the addition of a set of eBPF/BPF-related APIs to the WASI (WebAssembly
System Interface) ecosystem.
What is eBPF?
For more details and use cases, maybe you can refer to https://ebpf.io/what-is-ebpf/
Now eBPF can run on both Linux and Windows, across many kernel versions. A portable BPF applications can run on multiple kernel versions and configurations without modifications and runtime source code compilation on the target machine, using BPF CO-RE (Compile Once – Run Everywhere)approach.
Bring eBPF ability to Wasm can allow Wasm programs and modules to have more use cases:
There are some discussions in #218, but I don't think we shall need to embed WASI runtime in the kernel: we just need to have some API to dynamically load, control and communicate with eBPF programs from user space. This is the typical use cases for eBPF applications.
We have provided a prove-of-concept runtime and toolchain in the eunomia-bpf project: https://github.com/eunomia-bpf/eunomia-bpf
The API description
See the figure below:
Wasm sandbox would run the userspace part of an eBPF-based application, while eBPF sandbox run the kernel part.
WASI may be able to provide API include:
The text was updated successfully, but these errors were encountered: