sys: add windows support #1685

lmb · 2025-02-14T10:37:39Z

More Windows pieces. Note that package ebpf, btf, link need follow up work.

efw: add wrappers for eBPF for Windows runtime

Add basic infrastructure to call into the eBPF for Windows runtime. This
uses runtime dynamic linking to call into ebpfapi.dll instead of relying on
CGo. Ultimately this boils down to using syscall.SyscallN to call into
specific functions in the DLL and looks very similar to what we do on Linux.

The most important function is a wrapper for the bpf() function in 
ebpfapi.dll. This is an ABI compatible re-implementation of the Linux bpf()
syscall. Of course, not all of the syscall is implemented yet.

In addition to that there are a variety of helper functions that do not have
a bpf() equivalent and therefore need to be called directly.

Signed-off-by: Lorenz Bauer <lmb@isovalent.com>

sys: add windows support

The sys package is at the core of the library, so make it work on Windows to
minimise changes to the rest of the code base.

The first important piece is a custom FD abstraction. On Windows, operating
system resources are identified by handles. The differences are large enough
that the efW runtime decided to wrap them in a file descriptor abstraction,
most of which is provided by the Universal C Runtime on Windows. Change our
FD type to call into the efW runtime.

Second, Windows does not have the equivalent of bpffs. Instead objects are
stored in a global table, keyed by a string. This means that we can't use
file system APIs to manipulate pinning.

Third, the bpf() syscall is emulated by calling into ebpfapi.dll. This is
the key piece which allows most code to work unchanged.

Signed-off-by: Lorenz Bauer <lmb@isovalent.com>

internal/sys/fd.go

internal/sys/fd_windows.go

internal/sys/pinning_windows.go

internal/sys/syscall_ext_test.go

internal/efw/result.go

internal/efw/module.go

ti-mo

Thanks! Left a few nits.

internal/sys/fd_linux_test.go

internal/sys/ptr.go

Add basic infrastructure to call into the eBPF for Windows runtime. This uses runtime dynamic linking to call into ebpfapi.dll instead of relying on CGo. Ultimately this boils down to using syscall.SyscallN to call into specific functions in the DLL and looks very similar to what we do on Linux. The most important function is a wrapper for the bpf() function in ebpfapi.dll. This is an ABI compatible re-implementation of the Linux bpf() syscall. Of course, not all of the syscall is implemented yet. In addition to that there are a variety of helper functions that do not have a bpf() equivalent and therefore need to be called directly. Signed-off-by: Lorenz Bauer <lmb@isovalent.com>

The sys package is at the core of the library, so make it work on Windows to minimise changes to the rest of the code base. The first important piece is a custom FD abstraction. On Windows, operating system resources are identified by handles. The differences are large enough that the efW runtime decided to wrap them in a file descriptor abstraction, most of which is provided by the Universal C Runtime on Windows. Change our FD type to call into the efW runtime. Second, Windows does not have the equivalent of bpffs. Instead objects are stored in a global table, keyed by a string. This means that we can't use file system APIs to manipulate pinning. Third, the bpf() syscall is emulated by calling into ebpfapi.dll. This is the key piece which allows most code to work unchanged. Signed-off-by: Lorenz Bauer <lmb@isovalent.com>

lmb force-pushed the windows-sys branch 6 times, most recently from 35ae4b8 to a50a821 Compare February 14, 2025 11:49