Many of the latest operating system features are found in and around the kernel. It is complex to incorporate into kernel functionality, which can be a problem when you implement auditing and observability tools, or when you add low-level security tools. Even Linux is difficult because it has an easily accessible kernel module that loads at runtime and a system of changeable source code.
Once you start marketing your own kernel-level tools, you have a stack of modules that are almost unserviceable and a kernel that only works for your application. Next up is the upgrade issue. Will the changes work with the new kernel release, or do I have to build everything from scratch or, worse, prevent updates altogether?
Enter the Berkeley Advanced Packet Filter
Until the development of eBPF, it was clearly in an unsustainable position. Berkeley Advanced Packet Filter.. By sandboxing the kernel, you can add code that hooks into kernel functionality without making changes to the kernel itself. Similar to traditional Berkeley packet filters, eBPF provides an interface to kernel-level events that start eBPF programs that run in secure virtual machines in the Linux kernel.
This is fine if you’re running a pure Linux environment, but most organizations are now using heterogeneous systems with a mix of Windows and Linux. This also applies to the cloud. In the cloud, APIs are more important than the underlying operating system. In cloud-native development that focuses on scalable distributed systems, traditional surveillance technologies are difficult to justify and eBPF-based observability tools are becoming increasingly important.
If you want to use the eBPF-backed API to examine the low-level operating system performance of a distributed system, it is important to run it on a Windows system. This is where the recent reorganization of Microsoft’s operating system groups makes more sense. This allows both Windows and Linux kernel development teams to be in the same group, sharing ideas and tools. One of the first major collaborations between teams first Windows porting for eBPF announced in May..
Running eBPF on Windows
Currently being developed on GitHub EBPF on Windows It offers many of the same features as Linux. However, the architectural differences between Windows and Linux require an entirely different implementation. Microsoft has implemented eBPF in such a way that the boundaries between Windows user mode and kernel are safely exceeded. The eBPF code in the standard eBPF toolchain is compiled in bytecode and can be used in security and monitoring tools. You can validate and test your eBPF code and invoke it using the familiar Windows command netsh.exe to integrate it into scripted PowerShell actions.
eBPF code works with user mode libraries to deliver bytecode to protected services running in user space. Here The code is checked with the standard eBPF verifier PREVAIL. checked.. This is a static code analyzer that will check your code to make sure it is ready, type and memory safe, and not accessing kernel data structures. PREVAIL is a second generation verifierCan handle complex eBPF code, e.g.
Windows protected services are signed with a key that allows the kernel to trust the code running in the protected area. In this way, malicious code can penetrate the kernel and at the same time the use of trustworthy eBPF extensions is permitted. Keeping code out of the kernel is an important part of the Windows design philosophy. By hosting the eBPF-JIT with a driver, Windows can continue to run and automatically reload the driver in the event of a crash.
After validation, the code is passed to the JIT compiler or the Windows kernel mode interpreter. Both compiled and interpreted code run in the Windows driver ebpfcore.sys, which acts as a sink for events from the Windows network driver subsystem, and another eBPF driver, which acts as a shim for hooks from the TCP / IP stack. Be done. Second, it enables complex verifier functions to be performed in a secure environment where computationally intensive operations do not interfere with other applications or services.
Build eBPF with Windows tools
Many of the Windows eBPF stacks are based on existing open source tools, which makes it easy to port code that is already running on your Linux system to Windows. By using familiar environments and contexts, Windows becomes part of the existing eBPF-based monitoring environment, testing code that runs on Windows desktop development systems, or productively on-site or on Windows servers in Azure. You can run it in your environment.
This does not mean that eBPF for Windows is directly compatible with Linux eBPF systems. The two operating systems have very specific behavior, and many Linux eBPF hooks are not translated directly into the Windows equivalent. If you use eBPF to monitor certain internal structures, this code may not work on Windows, which handles kernel memory differently. Instead, it is best to think of the Windows version of eBPF as a place where common hooks are used, with an emphasis on the network stack rather than kernel operations.
Microsoft Simplify eBPF ports by providing the libbpf API As part of its implementation. The public API is available from the start and the driver running under Windows can be used unchanged. Internally, the tool uses Windows syntax and calls and provides them as generic hooks for the eBPF client. Therefore, Microsoft does not have to sign all code at the kernel level. After validation in a secure environment, the eBPF component that executes the code is already signed. That saves a lot of time and flexibility.
Initially, Microsoft supported access to the network stack, but in reality it supports anything that uses drivers, making eBPF a tool for monitoring file system behavior with file system filters. Can be integrated. You can imagine these tools running on every PC in your organization, monitoring ransomware behavior at the file system level, and quickly stopping operations as soon as malware activity is detected.
Provision of a user-programmable kernel for Windows
These are the early stages of eBPF on Windows. What is shipped is more than a proof of concept, but less than possible. There is a great demand for community interest and functionality. Projects are open like Linux eBPF, so it is up to the broader community to make them available, and Windows can be programmed by the user like never before without opening the kernel to security holes. Kernel is provided.
It seems inconsistent to leave Windows eBPF in userland, but the combination of kernel drivers and a secure sandbox gives you the security you need and the flexibility you need. Microsoft also demonstrates that eBPF is running on HVCI, a code integrity tool used by Windows hypervisors. This is where kernel mode processes are virtualized and executed, with improved isolation and protection of the rest of the kernel from untrustworthy code. Compiled eBPF code cannot be executed on HVCI, but is suitable for the use of an interpreter and provides an additional layer of protection against third-party applications.
It makes a lot of sense to add support for eBPF on Windows. When you scale heterogeneous systems, you need cross-platform monitoring and security tools. It’s convenient to have a common framework and API for Windows and Linux. Even if the same code does not run on both platforms, the joint development of components simplifies operation and development.
Copyright © 2021 IDG Communications, Inc.