8adab0de10
* Add stress test for tail calls * Added the code generated bindmonitor_mt_tailcall files * Added the test case description to readme.md * Update tests/stress/km/stress_tests_km.cpp Co-authored-by: Dave Thaler <dthaler@microsoft.com> * Update tests/stress/km/stress_tests_km.cpp Co-authored-by: Dave Thaler <dthaler@microsoft.com> * Addressed PR comments and Fixed merge conflicts with latest * Fixed function name * Regenerated the expected files, after the macro MAX TAIL CNT change done yesterday * Update tests/stress/readme.md Co-authored-by: Dave Thaler <dthaler@microsoft.com> * Removed clean_up tail call * Add bind in loop * updated the readme * Addressed PR comments * Changed LOG_VERBOSE to LOG_ERROR * Updated readme and addressed PR comment --------- Co-authored-by: Dave Thaler <dthaler@microsoft.com> |
||
|---|---|---|
| .github | ||
| cmake | ||
| docs | ||
| ebpfapi | ||
| ebpfcore | ||
| ebpfsvc | ||
| external | ||
| images | ||
| include | ||
| installer | ||
| libs | ||
| manifests/Kubernetes | ||
| netebpfext | ||
| resource | ||
| rpc_interface | ||
| scripts | ||
| tests | ||
| tools | ||
| .clang-format | ||
| .gitattributes | ||
| .gitignore | ||
| .gitmodules | ||
| Analyze.default.ruleset | ||
| CMakeLists.txt | ||
| CONTRIBUTING.md | ||
| Directory.Build.props | ||
| Doxyfile | ||
| LICENSE.rtf | ||
| LICENSE.txt | ||
| README.md | ||
| ebpf-for-windows.sln | ||
| mainpage.dox | ||
README.md
eBPF for Windows
eBPF is a well-known technology for providing programmability and agility, especially for extending an OS kernel, for use cases such as DoS protection and observability. This project is a work-in-progress that allows existing eBPF toolchains and APIs familiar in the Linux ecosystem to be used on top of Windows. That is, this project takes existing eBPF projects as submodules and adds the layer in between to make them run on top of Windows.
New to eBPF?
See our basic eBPF tutorial and our tutorial on debugging eBPF verification failures.
Architectural Overview
The following diagram shows the basic architecture of this project and related components:
As shown in the diagram, existing eBPF toolchains (clang, etc.) can be used to generate eBPF bytecode from source code in various languages. Bytecode can be consumed by any application, or via bpftool or the Netsh command line tool, which use a shared library that exposes Libbpf APIs, though this is still in progress.
The eBPF bytecode is sent to a static verifier (the PREVAIL verifier) that is hosted in a secure user-mode environment such as a system service (which is the case at present), enclave, or trusted VM. If the eBPF program passes all the verifier checks, it can be loaded into the kernel-mode execution context. Typically this is done by being JIT compiled (via the uBPF JIT compiler) into native code that is passed to the execution context. In a debug build, the byte code can instead be directly loaded into an interpreter (from uBPF in the kernel-mode execution context) though the interpreter is not present in a release build as it is considered less secure. See also the HVCI FAQ answer below.
eBPF programs installed into the kernel-mode execution context can attach to various hooks and call various helper APIs exposed by the eBPF shim, which internally wraps public Windows kernel APIs, allowing the use of eBPF on existing versions of Windows. Many helpers already exist, and more hooks and helpers will be added over time.
Getting Started
This project supports eBPF on Windows 10 or later, and on Windows Server 2019 or later. To try out this project, see our Getting Started Guide.
Want to help? We welcome contributions! See our Contributing guidelines. Feel free to take a look at our Good First Issues list if you're looking for somewhere to start.
Want to chat with us? We have a:
- Slack channel (If you are new, sign up at http://slack.cilium.io/)
- Zoom meeting for github issue triage: see meeting info
For tracking Q&A and general discussion, we use Discussions in github. This can also function similar to a mailing list if you subscribe to discussion notifications by clicking "Watch" (or "Unwatch") and selecting "Custom" -> "Discussions" (or by selecting "All Activity" if you want to receive notifications about everything else too).
Frequently Asked Questions
1. Is this a fork of eBPF?
No.
The eBPF for Windows project leverages existing projects, including the IOVisor uBPF project and the PREVAIL verifier, running them on top of Windows by adding the Windows-specific hosting environment for that code.
2. Does this provide app compatibility with eBPF programs written for Linux?
The intent is to provide source code compatibility for code that uses common hooks and helpers that apply across OS ecosystems.
Linux provides many hooks and helpers, some of which are very Linux specific (e.g., using Linux internal data structs) that would not be applicable to other platforms. Other hooks and helpers are generically applicable and the intent is to support them for eBPF programs.
Similarly, the eBPF for Windows project exposes Libbpf APIs to provide source code compatibility for applications that interact with eBPF programs.
3. Will eBPF work with HyperVisor-enforced Code Integrity (HVCI)?
Yes. With HVCI enabled, eBPF programs cannot be JIT compiled, but can be run either natively or in interpreted mode (but the interpreter is disabled in release builds and is only supported in debug builds). To understand why JIT compiled mode does not work, we must first understand what HVCI does.
HyperVisor-enforced Code Integrity (HVCI) is a mechanism whereby a hypervisor, such as Hyper-V, uses hardware virtualization to protect kernel-mode processes against the injection and execution of malicious or unverified code. Code integrity validation is performed in a secure environment that is resistant to attack from malicious software, and page permissions for kernel mode are set and maintained by the hypervisor.
Since a hypervisor doing such code integrity checks will refuse to accept code pages that aren't signed by a key that the hypervisor trusts, this does impact eBPF programs running natively. As such, when HVCI is enabled, eBPF programs work fine in interpreted mode, but not when using JIT compilation because the JIT compiler does not have a key that the hypervisor trusts. And since interpreted mode is absent in release builds, neither mode will work on an HVCI-enabled production system.
Instead, a third mode is also supported by eBPF for Windows, in addition to JIT compiled and interpreted modes. This third mode entails compiling eBPF programs into regular Windows drivers that can be accepted by HVCI. For more discussion, see the Native Code Generation documentation.