Can you run eBPF on Windows? Sure, if you’re using Windows Subsystem for Linux 2.0. Of course, there you’re running it on the Linux kernel on Windows 10. But running eBPF on Windows natively? Nah. That will change soon, however. Microsoft has started an open-source project to make eBPF work on Windows 10 and Windows Server 2016 and later.
This is the ebpf-for-windows project. With it, Windows developers can use eBPF toolchains and application programming interfaces (APIs) on top of existing versions of Windows. This won’t be easy. Still, by building 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 run on Windows.
Why would you want to do this? Linux developers already know the answer to that, but Windows programmers probably don’t.
Here’s the story.
First, it all started with a firewall program: The decades-old Berkeley Packet Filter (BPF). This was designed for capturing and filtering network packets on a register-based virtual machine (VM). That was useful. But, as the years went by, Alexei Starovoitov, Linux kernel developer and Facebook software engineer, realized that updating BPF to work with modern processors, extended BPF (eBPF), to run user-supplied programs inside of the kernel would make it far more powerful. It was introduced in the 3.15 Linux kernel and programmers quickly started using it for all kinds of programs.
Today, eBPF remains very useful for network filtering, analysis, and management, but it has far more jobs. EBPF is also used for system call filtering and process context tracing. In short, it’s become a Swiss-army knife for programming tracing, system profiling, and collecting and aggregating low-level custom metrics. At a higher level, this means eBPF has become the foundation of security programs, such as Cilium, Falco, and Tracee; Kubernetes observation programs like Hubble and Pixie, and, of course, toolchains such as Clang.
In Windows, here’s how it’s going to work: Existing eBPF toolchains will generate eBPF bytecode from source code in various 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 that exposes Libbpf APIs. This is still a work in progress.
The library will then send the eBPF bytecode to the PREVAIL static verifier. This, in turn, is hosted in a 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 verifier’s safety checks, the bytecode can be loaded either into the uBPF interpreter running in a Windows kernel-mode execution context or compiled by the uBPF just-in-time (JIT) compiler and have native code loaded into the kernel-mode execution context. The uBPF step is based on an Apache-licensed library for executing eBPF programs.
Then, the 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 shim. This shim wraps public Windows kernel APIs. This enables eBPF to be used on Windows. So far, two hooks (XDP and socket bind) have been added. Other hooks, and not just network ones, will be added.
This is in no way an eBPF fork. It’s just adding a Windows-specific hosting environment for eBPF.
The name of the game is to enable Windows developers to use eBPF programs, which will be source code compatible across Windows and Linux. Some of this will be done by using the Libbpf APIs
Of course, some eBPF code is very specific to Linux — for example, if it uses Linux internal data structures. But many other APIs and hooks will work across platforms. EBPF, as advanced Linux programmers know, gives Linux developers a great deal of power. Now, this take on eBPF will share the wealth with Windows developers.
Related Stories:
