Skip to content

Remove XDP_TEST hook and program type in ebpf-for-windows #4662

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 11 commits into from
Oct 3, 2025
Merged

Remove XDP_TEST hook and program type in ebpf-for-windows #4662

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
11 commits
Select commit Hold shift + click to select a range
8d61a00
Removed the XDP Test Extension
kumarvin123 Sep 25, 2025
5fbb498
Fixed Failing Tests and scripts
kumarvin123 Sep 27, 2025
aa61fed
Fixed the Fuzzer Build
kumarvin123 Sep 27, 2025
c112f7f
Fixed documentation
kumarvin123 Sep 27, 2025
744b8dd
Removed net_ebpf_ext_xdp_hooks.h and all XDP Unit tests
kumarvin123 Sep 30, 2025
9e012a9
Fixed the Lib Fuzzer Harness
kumarvin123 Sep 30, 2025
0804fc2
Fixed the Cilium Tests
kumarvin123 Oct 1, 2025
99ee14d
ebpfVerifier Sync
kumarvin123 Oct 1, 2025
9e2dbd1
Reverted files with only white space changes
kumarvin123 Oct 2, 2025
529d968
CR feedback from Anurag
kumarvin123 Oct 3, 2025
3ca5dfb
CR feedback
kumarvin123 Oct 3, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
1 change: 0 additions & 1 deletion docs/AutomatedTests.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -33,7 +33,6 @@ Tests in this category currently include:
* connect_redirect_tests.exe: This tests connection redirection functionality.
* sample_ext_app.exe: This tests the sample extension driver.
* socket_tests.exe: This tests eBPF programs that attach to socket events.
* xdp_tests.exe: This tests eBPF programs that attach to XDP_TEST.
* ebpf_stress_tests_km.exe: This tests the in-kernel eBPF sub-system's resilience in multi-threaded stress scenarios.

## Fuzz tests
Expand Down
1 change: 0 additions & 1 deletion docs/Diagnostics.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -18,7 +18,6 @@ netebpfext.sys uses the Windows Filtering Platform (WFP) to implement certain eB
program and attach type, different WFP objects are expected to be created.

The following program types rely on WFP:
- BPF_PROG_TYPE_XDP_TEST
- BPF_PROG_TYPE_BIND
- BPF_PROG_TYPE_CGROUP_SOCK_ADDR
- BPF_PROG_TYPE_SOCK_OPS
Expand Down
86 changes: 0 additions & 86 deletions docs/GettingStarted.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -144,8 +144,6 @@ This will build the following binaries:
and EbpfCore and NetEbpfExt drivers to be loaded.
- `sample_ebpf_ext.sys`: A sample eBPF extension driver that implements a test hook (for a test program type) and test helper functions.
- `sample_ext_app.exe`: A sample application for testing the sample extension driver.
- `xdp_tests.exe`: Application for testing various XDP_TEST functionalities. This requires the EbpfSvc service to be running,
and the EbpfCore and NetEbpfExt drivers to be loaded on a remote system to test.
- `socket_tests.exe`: Application for testing the eBPF extension that implements the BPF_CGROUP_SOCK_ADDR program type and related attach types.

and a few binaries just used for demo'ing eBPF functionality, as in the demo walkthrough discussed below:
Expand Down Expand Up @@ -332,90 +330,6 @@ Other useful options include:
1. `-l` to list test cases
1. `Test_name` to run a single test

### xdp_tests.exe

This application tests various XDP_TEST functionalities. These tests require two hosts to run. There are three variations of the XDP_TEST tests.

#### Reflection Test

This tests the XDP_TX functionality.

1. On the first host:
1. [Install eBPF for Windows](https://github.com/microsoft/ebpf-for-windows/blob/main/docs/InstallEbpf.md).
1. Load the test eBPF program by running the following command, and note the ID (see **Note 3** below):

```cmd
netsh ebpf add program reflect_packet.o xdp_test
```

1. On the second host:
1. Allow inbound traffic for `xdp_tests.exe` through Windows Defender Firewall. See **Note 1** below.
1. Run (see **Note 2** below):

```cmd
xdp_tests.exe xdp_reflect_test --remote-ip <IP on the first host>
```

#### Encapsulation Test

This uses `bpf_xdp_adjust_head` helper function to encapsulate an outer IP header to a packet.

1. On the first host:
1. [Install eBPF for Windows](https://github.com/microsoft/ebpf-for-windows/blob/main/docs/InstallEbpf.md).
1. Load the test eBPF program by running the following command, and note the ID (see **Note 3** below):

```cmd
netsh ebpf add program encap_reflect_packet.o xdp_test
```

1. On the second host:
1. Allow inbound traffic for `xdp_tests.exe` through Windows Defender Firewall. See **Note 1** below.
1. Run (see **Note 3** below):

```cmd
xdp_tests.exe xdp_encap_reflect_test --remote-ip <IP on the first host>
```

#### Decapsulation Test

This uses `bpf_xdp_adjust_head` helper function to decapsulate an outer IP header from a packet.

1. On *both* the hosts, [install eBPF for Windows](https://github.com/microsoft/ebpf-for-windows/blob/main/docs/InstallEbpf.md).
1. On the first host load the first test eBPF program by running the following command. and note the ID (see **Note 3** below):

```cmd
netsh ebpf add program encap_reflect_packet.o xdp_test
```

1. On the second host:
1. Load the second test eBPF program by running the following command, and note the ID (see **Note 3** below):

```cmd
netsh ebpf add program decap_permit_packet.o xdp_test
```

2. Allow inbound traffic for `xdp_tests.exe` through Windows Defender Firewall. See **Note 1** below.
3. Run the following command (see **Note 3** below):

```cmd
xdp_tests.exe xdp_reflect_test --remote-ip <IP on the first host>
```

**Note 1:** To allow inbound traffic to `xdp_tests.exe`, in a Windows Powershell with administrative privilege, run:

```cmd
New-NetFirewallRule -DisplayName "XDP_Test" -Program "<Full path to xdp_tests.exe>" -Direction Inbound -Action Allow
```

**Note 2:** For the `--remote-ip` parameter to `xdp_tests.exe` program that is run on the second host,
pass an IPv4 or IPv6 address of an Ethernet-like interface on the first host in string format.

**Note 3:** After completion of each test variation, unload the eBPF programs from both host machines by running
`delete program <id>` on the netsh prompt, where `<id>` is the ID noted when the eBPF programs were loaded.

***Advanced:*** The eBPF program can be attached to a specific interface by passing `interface=<IfIndex>`
parameter either to the netsh `add program` or `set program` commands.

### socket_tests.exe

This application loads the `cgroup_sock_addr.o` eBPF program and attaches to hooks to handle various socket operations.
Expand Down
36 changes: 19 additions & 17 deletions docs/eBpfExtensions.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -125,6 +125,8 @@ typedef struct _sample_program_context
uint8_t* data_end;
uint32_t uint32_data;
uint16_t uint16_data;
uint32_t helper_data_1;
uint32_t helper_data_2;
} sample_program_context_t;

// Program context including the context header.
Expand Down Expand Up @@ -240,25 +242,25 @@ invoking an eBPF program. The various fields of this struct are as follows.
* `end`: Offset (in bytes) to the field in the context structure that is pointing to the end of context data.
* `meta`: Offset (in bytes) to the field in the context structure that is pointing to the beginning of context metadata.

For example, for the XDP_TEST program types, the context data structure is as follows:
For example, for the BPF_PROG_TYPE_SAMPLE program types, the context data structure is as follows:
```c
// XDP_TEST hook. We use "struct xdp_md" for cross-platform compatibility.
typedef struct xdp_md
// Sample extension program context.
typedef struct _sample_program_context
{
void* data; ///< Pointer to start of packet data.
void* data_end; ///< Pointer to end of packet data.
uint64_t data_meta; ///< Packet metadata.

/* size: 12, cachelines: 1, members: 3 */
/* last cacheline: 12 bytes */
} xdp_md_t;
uint8_t* data_start;
uint8_t* data_end;
uint32_t uint32_data;
uint16_t uint16_data;
uint32_t helper_data_1;
uint32_t helper_data_2;
} sample_program_context_t;
```
The corresponding context descriptor looks like:
```c
const ebpf_context_descriptor_t g_xdp_context_descriptor = {sizeof(xdp_md_t),
EBPF_OFFSET_OF(xdp_md_t, data),
EBPF_OFFSET_OF(xdp_md_t, data_end),
EBPF_OFFSET_OF(xdp_md_t, data_meta)};
const ebpf_context_descriptor_t g_sample_program_context_descriptor = {sizeof(sample_program_context_t),
EBPF_OFFSET_OF(sample_program_context_t, data_start),
EBPF_OFFSET_OF(sample_program_context_t, data_end),
-1};
```
If any of the data or metadata pointer fields are not present on the context structure, the offset value is set to -1
in the context descriptor.
Expand Down Expand Up @@ -467,7 +469,7 @@ structure from the passed in parameters:
* `ClientDispatch`: Client dispatch table (see section 2.5 below).
* `NpiSpecificCharacteristics`: Obtained from `ClientRegistrationInstance` parameter. This contains attach-type
specific data that may be used by an extension for attaching an eBPF program. For example, when an eBPF program is
being attached to an XDP_TEST hook, the network interface index can be passed via this parameter. This tells the extension
being attached to an BPF_XDP hook, the network interface index can be passed via this parameter. This tells the extension
to invoke the eBPF program whenever there are any inbound packets on that network interface. The attach parameter can
be obtained as follows:
```c
Expand Down Expand Up @@ -597,8 +599,8 @@ The parameter and return types for these helper functions must adhere to the `eb

### 2.8 Registering Program Types and Attach Types - eBPF Store
The eBPF execution context loads an eBPF program from an ELF file that has program section(s) with section names. The
prefix to these names determines the program type. For example, the section name `"xdp_test"` implies that the corresponding
program type is `EBPF_PROGRAM_TYPE_XDP_TEST`.
prefix to these names determines the program type. For example, the section name `"xdp"` implies that the corresponding
program type is `BPF_PROG_TYPE_XDP`.

The *execution context* discovers the program type associated with a section prefix by reading the data from the ***"eBPF store"***, which is currently kept in the Windows registry. An extension developer must author a user mode application which will use eBPF store APIs to update the program types it implements along with the associated section prefixes. eBPF store APIs are exported from ebpfapi.dll.

Expand Down
20 changes: 10 additions & 10 deletions docs/tutorial.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -476,8 +476,8 @@ Hook points are callouts exposed by the system to which eBPF programs can
attach. By convention, the section name of the eBPF program in an ELF file
is commonly used to designate which hook point the eBPF program is designed
for. Specifically, a set of prefix strings are typically used to match against the
section name. For example, any section name starting with "xdp_test" is meant
as an XDP_TEST layer program. This is a convenient default, but can be
section name. For example, any section name starting with "xdp" is meant
as an XDP layer program. This is a convenient default, but can be
overridden by an app asking to load an eBPF program, such as when the eBPF program is simply in the
".text" section.

Expand All @@ -492,7 +492,7 @@ structure which contains an arbitrary amount of data. (Tail calls to
programs can have more than one argument, but hooks put all the info in a
hook-specific context structure passed as one argument.)

The "xdp_test" hook point has the following prototype in `net_ebpf_ext_xdp_hooks.h`:
The BPF_XDP hook point has the following prototype in `net_ebpf_ext_xdp_hooks.h`:

```c
typedef struct xdp_md
Expand Down Expand Up @@ -520,10 +520,10 @@ A sample eBPF program might look like this:
#include "ebpf_nethooks.h"
#include "net_ebpf_ext_xdp_hooks.h"

// Put "xdp_test" in the section name to specify XDP_TEST as the hook.
// Put "xdp" in the section name to specify XDP as the hook.
// The SEC macro below has the same effect as the
// clang pragma used in section 2 of this tutorial.
SEC("xdp_test")
SEC("xdp")
int my_xdp_parser(xdp_md_t* ctx)
{
int length = (char *)ctx->data_end - (char *)ctx->data;
Expand Down Expand Up @@ -577,10 +577,10 @@ sockops ProgramType : {77, 34, 251, 67...}
AttachType : {205, 2, 125, 131...}
BpfProgType : 4
BpfAttachType : 7
xdp_test ProgramType : {248, 206, 140, 206...}
AttachType : {93, 193, 204, 13...}
BpfProgType : 5
BpfAttachType : 9
xdp ProgramType : {133, 42, 131, 241...}
AttachType : {239, 216, 224, 133...}
BpfProgType : 1
BpfAttachType : 1
```

With the above, our sample program will pass verification:
Expand All @@ -595,7 +595,7 @@ Program terminates within 30 instructions
```

What would have happened had the prototype not matched? Let's say the
verifier is the same as above but XDP_TEST instead had a different struct
verifier is the same as above but XDP instead had a different struct
definition:

```c
Expand Down
51 changes: 2 additions & 49 deletions ebpf-for-windows.sln
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,4 +1,4 @@


Microsoft Visual Studio Solution File, Format Version 12.00
# Visual Studio Version 17
VisualStudioVersion = 17.4.33205.214
Expand Down Expand Up @@ -169,11 +169,6 @@ Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "performance", "tests\perfor
{245F0EC7-1EBC-4D68-8B1F-F758EA9196AE} = {245F0EC7-1EBC-4D68-8B1F-F758EA9196AE}
EndProjectSection
EndProject
Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "xdp_tests", "tests\xdp\xdp_tests.vcxproj", "{07DC6181-84A2-4A14-A806-5E9AF6C929C2}"
ProjectSection(ProjectDependencies) = postProject
{231EE32B-EBA4-4FE5-A55B-DB18F539D403} = {231EE32B-EBA4-4FE5-A55B-DB18F539D403}
EndProjectSection
EndProject
Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "bpftool", "tools\bpftool\bpftool.vcxproj", "{CA179B38-EBF5-4371-B830-73486E35250B}"
ProjectSection(ProjectDependencies) = postProject
{231EE32B-EBA4-4FE5-A55B-DB18F539D403} = {231EE32B-EBA4-4FE5-A55B-DB18F539D403}
Expand Down Expand Up @@ -386,7 +381,6 @@ Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "onebranch", "tools\onebranc
ProjectSection(ProjectDependencies) = postProject
{02A1913F-7FF5-4C20-B230-2240B4EDEC10} = {02A1913F-7FF5-4C20-B230-2240B4EDEC10}
{030A7AC6-14DC-45CF-AF34-891057AB1402} = {030A7AC6-14DC-45CF-AF34-891057AB1402}
{07DC6181-84A2-4A14-A806-5E9AF6C929C2} = {07DC6181-84A2-4A14-A806-5E9AF6C929C2}
{12161211-5463-4AA9-9B6E-552552B475DC} = {12161211-5463-4AA9-9B6E-552552B475DC}
{21C137EC-9AE3-4C8C-8E74-8BFCC999D856} = {21C137EC-9AE3-4C8C-8E74-8BFCC999D856}
{231EE32B-EBA4-4FE5-A55B-DB18F539D403} = {231EE32B-EBA4-4FE5-A55B-DB18F539D403}
Expand Down Expand Up @@ -1645,46 +1639,6 @@ Global
{724EB55A-CCFC-4662-92E3-B664CDA365E7}.RelWithDebInfo|x64.Build.0 = Release|x64
{724EB55A-CCFC-4662-92E3-B664CDA365E7}.RelWithDebInfo|x86.ActiveCfg = Release|x64
{724EB55A-CCFC-4662-92E3-B664CDA365E7}.RelWithDebInfo|x86.Build.0 = Release|x64
{07DC6181-84A2-4A14-A806-5E9AF6C929C2}.Debug|ARM64.ActiveCfg = Debug|ARM64
{07DC6181-84A2-4A14-A806-5E9AF6C929C2}.Debug|ARM64.Build.0 = Debug|ARM64
{07DC6181-84A2-4A14-A806-5E9AF6C929C2}.Debug|x64.ActiveCfg = Debug|x64
{07DC6181-84A2-4A14-A806-5E9AF6C929C2}.Debug|x64.Build.0 = Debug|x64
{07DC6181-84A2-4A14-A806-5E9AF6C929C2}.Debug|x86.ActiveCfg = Debug|x64
{07DC6181-84A2-4A14-A806-5E9AF6C929C2}.Debug|x86.Build.0 = Debug|x64
{07DC6181-84A2-4A14-A806-5E9AF6C929C2}.FuzzerDebug|ARM64.ActiveCfg = FuzzerDebug|ARM64
{07DC6181-84A2-4A14-A806-5E9AF6C929C2}.FuzzerDebug|x64.ActiveCfg = FuzzerDebug|x64
{07DC6181-84A2-4A14-A806-5E9AF6C929C2}.FuzzerDebug|x86.ActiveCfg = FuzzerDebug|x64
{07DC6181-84A2-4A14-A806-5E9AF6C929C2}.FuzzerDebug|x86.Build.0 = FuzzerDebug|x64
{07DC6181-84A2-4A14-A806-5E9AF6C929C2}.MinSizeRel|ARM64.ActiveCfg = Debug|ARM64
{07DC6181-84A2-4A14-A806-5E9AF6C929C2}.MinSizeRel|ARM64.Build.0 = Debug|ARM64
{07DC6181-84A2-4A14-A806-5E9AF6C929C2}.MinSizeRel|x64.ActiveCfg = Debug|x64
{07DC6181-84A2-4A14-A806-5E9AF6C929C2}.MinSizeRel|x64.Build.0 = Debug|x64
{07DC6181-84A2-4A14-A806-5E9AF6C929C2}.MinSizeRel|x86.ActiveCfg = Release|x64
{07DC6181-84A2-4A14-A806-5E9AF6C929C2}.MinSizeRel|x86.Build.0 = Release|x64
{07DC6181-84A2-4A14-A806-5E9AF6C929C2}.NativeOnlyDebug|ARM64.ActiveCfg = NativeOnlyDebug|ARM64
{07DC6181-84A2-4A14-A806-5E9AF6C929C2}.NativeOnlyDebug|ARM64.Build.0 = NativeOnlyDebug|ARM64
{07DC6181-84A2-4A14-A806-5E9AF6C929C2}.NativeOnlyDebug|x64.ActiveCfg = NativeOnlyDebug|x64
{07DC6181-84A2-4A14-A806-5E9AF6C929C2}.NativeOnlyDebug|x64.Build.0 = NativeOnlyDebug|x64
{07DC6181-84A2-4A14-A806-5E9AF6C929C2}.NativeOnlyDebug|x86.ActiveCfg = NativeOnlyDebug|x64
{07DC6181-84A2-4A14-A806-5E9AF6C929C2}.NativeOnlyDebug|x86.Build.0 = NativeOnlyDebug|x64
{07DC6181-84A2-4A14-A806-5E9AF6C929C2}.NativeOnlyRelease|ARM64.ActiveCfg = NativeOnlyRelease|ARM64
{07DC6181-84A2-4A14-A806-5E9AF6C929C2}.NativeOnlyRelease|ARM64.Build.0 = NativeOnlyRelease|ARM64
{07DC6181-84A2-4A14-A806-5E9AF6C929C2}.NativeOnlyRelease|x64.ActiveCfg = NativeOnlyRelease|x64
{07DC6181-84A2-4A14-A806-5E9AF6C929C2}.NativeOnlyRelease|x64.Build.0 = NativeOnlyRelease|x64
{07DC6181-84A2-4A14-A806-5E9AF6C929C2}.NativeOnlyRelease|x86.ActiveCfg = NativeOnlyRelease|x64
{07DC6181-84A2-4A14-A806-5E9AF6C929C2}.NativeOnlyRelease|x86.Build.0 = NativeOnlyRelease|x64
{07DC6181-84A2-4A14-A806-5E9AF6C929C2}.Release|ARM64.ActiveCfg = Release|ARM64
{07DC6181-84A2-4A14-A806-5E9AF6C929C2}.Release|ARM64.Build.0 = Release|ARM64
{07DC6181-84A2-4A14-A806-5E9AF6C929C2}.Release|x64.ActiveCfg = Release|x64
{07DC6181-84A2-4A14-A806-5E9AF6C929C2}.Release|x64.Build.0 = Release|x64
{07DC6181-84A2-4A14-A806-5E9AF6C929C2}.Release|x86.ActiveCfg = Release|x64
{07DC6181-84A2-4A14-A806-5E9AF6C929C2}.Release|x86.Build.0 = Release|x64
{07DC6181-84A2-4A14-A806-5E9AF6C929C2}.RelWithDebInfo|ARM64.ActiveCfg = Release|ARM64
{07DC6181-84A2-4A14-A806-5E9AF6C929C2}.RelWithDebInfo|ARM64.Build.0 = Release|ARM64
{07DC6181-84A2-4A14-A806-5E9AF6C929C2}.RelWithDebInfo|x64.ActiveCfg = Release|x64
{07DC6181-84A2-4A14-A806-5E9AF6C929C2}.RelWithDebInfo|x64.Build.0 = Release|x64
{07DC6181-84A2-4A14-A806-5E9AF6C929C2}.RelWithDebInfo|x86.ActiveCfg = Release|x64
{07DC6181-84A2-4A14-A806-5E9AF6C929C2}.RelWithDebInfo|x86.Build.0 = Release|x64
{CA179B38-EBF5-4371-B830-73486E35250B}.Debug|ARM64.ActiveCfg = Debug|ARM64
{CA179B38-EBF5-4371-B830-73486E35250B}.Debug|ARM64.Build.0 = Debug|ARM64
{CA179B38-EBF5-4371-B830-73486E35250B}.Debug|x64.ActiveCfg = Debug|x64
Expand Down Expand Up @@ -3498,7 +3452,6 @@ Global
{A4037E5D-B00C-4AF1-9398-76B3ECE95F62} = {492C9B22-9237-4996-9E33-CA14D3533616}
{370E7D53-C97F-4077-A3D5-620C4FD87EED} = {69CDB6A1-434D-4BC9-9BFF-D12DF7EDBB6B}
{724EB55A-CCFC-4662-92E3-B664CDA365E7} = {492C9B22-9237-4996-9E33-CA14D3533616}
{07DC6181-84A2-4A14-A806-5E9AF6C929C2} = {492C9B22-9237-4996-9E33-CA14D3533616}
{CA179B38-EBF5-4371-B830-73486E35250B} = {B09749EC-3D14-414B-BA9B-CD20E218DC84}
{69B97E52-18DC-434E-A6E4-4C0F3E88C44A} = {B09749EC-3D14-414B-BA9B-CD20E218DC84}
{61DF9973-81B9-4006-9148-52F58259BBCF} = {492C9B22-9237-4996-9E33-CA14D3533616}
Expand Down Expand Up @@ -3550,4 +3503,4 @@ Global
GlobalSection(ExtensibilityGlobals) = postSolution
SolutionGuid = {3D5F862D-74C6-4357-9F95-0B152E33B7B8}
EndGlobalSection
EndGlobal
EndGlobal
Loading
Loading