Can you run eBPF on Windows? Of course, if you are using the Windows Subsystem for Linux 2.0. Of course you are running it on Linux kernel under Windows 10. But running eBPF under Windows natively? No. That will change soon, however. Microsoft started an open-source project to make eBPF work on Windows 10 and Windows Server 2016 and later.
It’s the ebpf-for-windows project. With it, Windows developers can use eBPF toolchains and application programming interfaces (APIs) in addition to existing versions of Windows. It won’t be easy. Yet, relying on the work of others, it should be possible. This project takes several existing eBPF open-source projects and adds the “glue” to make them work on Windows.
Why would you want to do this? Linux developers already know the answer to this, but Windows programmers probably don’t.
Here is the story.
First of all, it all started with a firewall program: the Berkeley Packet Filter (BPF). This was designed to capture and filter network packets on a registry-based virtual machine (VM). It was useful. But, over the years, Alexei Starovoitov, Linux kernel developer and Facebook software engineer, found that updating BPF to work with modern processors, Extended BPF (eBPF), running user-supplied programs inside the kernel would make it much more powerful. It was introduced in the Linux 3.15 kernel, and programmers quickly began to use it for all kinds of programs.
Today, eBPF is still very useful for filtering, analysis and network management, but it has many more jobs. EBPF is also used for filtering system calls and tracking process context. In short, it has become a Swiss Army Knife for programming tracing, system profiling, and low-level custom metrics collection and aggregation. At a higher level, this means that the eBPF has become the foundation for safety programs, such as Cilium, Falco, and Trace; Kubernetes observation programs like Hubble and Pixie, and, of course, toolchains such as Noise.
In Windows, this is how it will work: Existing eBPF toolchains will generate eBPF bytecode from source code in different languages. This bytecode can then be used by any application or manually through the Windows netsh command line tool. This will be done using a shared library which exposes Libbpf API. This is still a work in progress.
The library will then send the eBPF bytecode to the PREVAIL static checker. This, in turn, is hosted in user mode protected process, which is a Windows security environment that allows a kernel component to trust a user-mode daemon signed by a trusted key. If the bytecode passes all the security checks of the verifier, the bytecode can be loaded either into the uBPF interpreter running in an execution context in Windows kernel mode or compiled by the uBPF just in time (JIT) and have the native code loaded into the kernel mode execution context. the UBPF step is based on an Apache licensed library for running eBPF programs.
Then eBPF programs running in the kernel mode execution context will be attached to hooks that handle events and call helper APIs. These are exposed via the eBPF wedge. This shim encapsulates the public APIs of the Windows kernel. This allows eBPF to be used on Windows. So far, two hooks (XDP and socket bind) have been added. Other hooks, not just network hooks, will be added.
It is by no means an eBPF fork. It’s just a matter of adding a Windows-specific hosting environment for eBPF.
The name of the game is to allow Windows developers to use eBPF programs, which will be compatible with source code on Windows and Linux. Part of this will be done using the Libbpf API
Of course, some eBPF codes are very Linux specific – for example, if they use Linux internal data structures. But there are plenty of other APIs and hooks that will work on all platforms. EBPF, as advanced Linux programmers know, gives Linux developers great power. Now this take on eBPF will share the wealth with Windows developers.