Most of the latest operating system functionality occurs in and around the kernel. Hooking to kernel functions is complex, which can be a problem if you are implementing monitoring and observability tools, or if you are adding low-level security tools. Even Linux is difficult because it has an easily accessible kernel module loaded at run time and an editable source code system.
As soon as you start to deploy your own tools at the kernel level, you have a stack of almost impossible to maintain modules and a kernel that only works for your application. Then there is the matter of upgrading. Do the changes work with the new kernel version, or do I have to rebuild everything from scratch, or worse, prevent updates altogether?
Entering the Berkeley Extended Packet Filter
Until the development of eBPF, it was clearly in an unbearable position. Berkeley Extended Packet Filter.. Placing a sandbox inside the kernel allows you to add code that hooks up to kernel functions without making changes to the kernel itself. Similar to traditional Berkeley packet filters, eBPF provides an interface to kernel-level events, which launch eBPF programs that run in secure virtual machines in the Linux kernel.
This is fine if you are using a pure Linux environment, but most organizations now use 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 focused on scalable distributed systems, traditional monitoring technologies are difficult to justify and eBPF-based observability tools are becoming increasingly important.
If you want to use the eBPF API to examine 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 really makes sense. This allows the Windows and Linux kernel development teams to be in the same group and share ideas and tools. One of the first major collaborations between the teams Windows port for eBPF announced in May..
Run eBPF on Windows
Under development on GitHub EBPF on Windows It provides many of the same functionality as Linux. However, the architectural differences between Windows and Linux mean that they have to be implemented in completely different ways. Microsoft has implemented eBPF in a way that safely crosses the boundaries between Windows user mode and the kernel. The eBPF code in the standard eBPF toolchain is compiled into bytecode and ready for use in security and monitoring tools. You can validate and test your eBPF code and call it from the familiar netsh.exe Windows command to embed it in PowerShell scripted actions.
EBPF code works with user mode libraries to provide bytecode to protected services running in user space. The code is checked before execution using the standard eBPF checker PREVAIL.. This is a static code analyzer that checks your code to make sure that it is complete, that it is type and memory safe, and that it is not accessing structures. kernel data. PREVAIL is a second generation auditorCan handle complex eBPF code, such as loop support.
Windows Protected Services are signed with a key that allows the kernel to trust code running in the protected space. It is a way of allowing malicious code to enter the kernel while still allowing the use of trusted eBPF extensions. Keeping code outside of the kernel is an important part of 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.
Once validated, the code is passed to the JIT compiler or the Windows kernel-mode interpreter. The compiled and interpreted code runs in the ebpfcore.sys Windows driver, which acts as a sink for Windows Network Driver subsystem events and another eBPF driver which acts as a wedge for TCP / stack hooks. IP. Will be done. Second, it allows complex verification functions to be performed in a secure environment where compute-intensive operations do not affect other applications or services.
Building eBPF with Windows Tools
Most Windows eBPF stacks are built on existing open source tools, making it easy to port code already running on your Linux system to Windows. Using familiar environments and contexts, Windows becomes part of the existing eBPF-based monitoring environment, testing code running on Windows desktop development systems, or on-premises production or 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. Both operating systems have very specific behaviors and many Linux eBPF hooks do not translate directly to the Windows equivalent. If you are using eBPF to monitor some internal structures, this code may not work on Windows, which handles kernel memory differently. Instead, it’s best to think of the Windows version of eBPF as a place to use common hooks, focusing 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 has been around from the start and the driver that runs on Windows can be used as is. Internally, the tool uses Windows syntax and calls and exposes them as generic hooks to the eBPF client. Therefore, Microsoft does not have to sign all code at the kernel level. After being validated in a secure environment, the eBPF component that executes the code is already signed. This saves a lot of time and flexibility.
Initially, Microsoft supported network stack access, but in reality anything that uses drivers is supported, so eBPF is a file system behavior monitoring tool 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 shutting down operations as soon as malicious activity is detected.
Provide a user programmable kernel for Windows
These are the first steps for eBPF on Windows. Which ships is more than a proof of concept, but less than possible. There is a lot of demand for the interest and functionality of the community. Projects are open like Linux eBPF, so it’s up to the wider community to make them available, and Windows can be user-programmed like never before without opening the kernel for security vulnerabilities. The kernel is provided.
Keeping Windows eBPF in user space seems inconsistent, but the combination of kernel drivers and a secure sandbox gives you the security and flexibility you need. Microsoft is also demonstrating eBPF running on HVCI, a code integrity tool enforced by Windows hypervisors. Here, kernel-mode processes are virtualized and executed, with improved isolation and protection from the rest of the kernel against untrusted code. Compiled eBPF code cannot be run on HVCI, but it is suitable for interpreter use and adds a layer of protection against third-party applications.
It makes perfect sense to add support for eBPF on Windows. When scaling heterogeneous systems, you need cross-platform monitoring and security tools. It is convenient to use a common framework and API for Windows and Linux. Even though the same code does not run on both platforms, the shared way of developing components simplifies operation and development.
Copyright Â© 2021 IDG Communications, Inc.