Remove XDP hook support from netebpfext.sys (#3040)

* replace XDP guids with XDP_TEST guids * updated missde instance * update bpf2c * leave xdp_hook as is * remove extra files * update with new XDP_TEST guid, update other tests to use sample_ext * update some tests, update test_helper * update fuzzer * temporarily remove bpftool tests * update execution context test * replace XDP guids with XDP_TEST guids * updated missde instance * update bpf2c * leave xdp_hook as is * remove extra files * update with new XDP_TEST guid, update other tests to use sample_ext * update some tests, update test_helper * update fuzzer * temporarily remove bpftool tests * update execution context test * build failures * update sample ext with context_allocate and destroy * update vm script to use xdp_test * switch api tests to use sample program * rename to xdp_Test * update sample ext * update incorrect SAL, update netsh tests * update sample, update tests to use sample where applicable * update tests * fix up tests * fix libbpf tets * revert unnecessary changes * remove extra prints * add back in bpftool tests * update to use xdp instead of xdp_test for bpftool test * update atomic_instructions_others.o * extra debug logs * updated expected, update bpftool tests * correct bpftool tests * more debug logs * add reg debug * clear program info * Attempt fix of buffer overrun * remove debug logs, minor cleanup, set XDP guids back to their original names * update docs with xdp_test * fix guid usage * CR: remove program, update comments, fix commented out tests, update bpf_program__attach_xdp * revert changes in libbpf, as they need to use the actual XDP guids * update comment * update some XDP tests to use sample ext, comment out some expected failing tests * update bpftool tests * fix up bpf prog test run expected output, move to #if instead of comments * fix up return code issue * fix bpftool testes * add some failed xdp tests, set some params to null for sample tests * update comment * tmp commit - move to xdp mock * update unit tests to use mock XDP where possible * made some samples back to XDP type * netebpfext unit tests should use xdp_test * CR
microsoft · Dec 6, 2023 · 2000daf · 2000daf
1 parent 99744a1
commit 2000daf
Show file tree

Hide file tree

Showing 129 changed files with 19,620 additions and 20,088 deletions.
diff --git a/docs/AutomatedTests.md b/docs/AutomatedTests.md
@@ -33,7 +33,7 @@ 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.
+* 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

diff --git a/docs/Diagnostics.md b/docs/Diagnostics.md
@@ -18,7 +18,7 @@ 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
+- BPF_PROG_TYPE_XDP_TEST
 - BPF_PROG_TYPE_BIND
 - BPF_PROG_TYPE_CGROUP_SOCK_ADDR
 - BPF_PROG_TYPE_SOCK_OPS

diff --git a/docs/GettingStarted.md b/docs/GettingStarted.md
@@ -163,7 +163,7 @@ 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 functionalities.  This requires the EbpfSvc service to be running,
+- `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.
 
@@ -255,17 +255,17 @@ On the attacker machine, do the following:
    ```
 1. Show eBPF byte code for `droppacket.o`:
    ```cmd
-   netsh ebpf show disassembly droppacket.o xdp
+   netsh ebpf show disassembly droppacket.o xdp_test
    ```
 1. Show that the verifier checks the code:
    ```cmd
-   netsh ebpf show verification droppacket.o xdp
+   netsh ebpf show verification droppacket.o xdp_test
    ```
 1. Launch netsh `netsh`
 1. Switch to ebpf context `ebpf`
 1. Load eBPF program, and note the ID:
    ```cmd
-   add program droppacket.o xdp
+   add program droppacket.o xdp_test
    ```
 1. Show UDP datagrams received drop to under 10 per second
 1. Unload program:
@@ -280,11 +280,11 @@ On the attacker machine, do the following:
    ```
 1. Show that the verifier rejects the code:
    ```cmd
-   netsh ebpf show verification droppacket.o xdp
+   netsh ebpf show verification droppacket.o xdp_test
    ```
 1. Show that loading the program fails:
    ```cmd
-   netsh ebpf add program droppacket.o xdp
+   netsh ebpf add program droppacket.o xdp_test
    ```
 
 ## Tests in Ebpf-For-Windows
@@ -333,7 +333,7 @@ Other useful options include:
 
 ### xdp_tests.exe
 
-This application tests various XDP functionalities. These tests require two hosts to run. There are three variations of the XDP tests.
+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
 
@@ -343,7 +343,7 @@ This tests the XDP_TX functionality.
    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
+      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.
@@ -362,7 +362,7 @@ This uses `bpf_xdp_adjust_head` helper function to encapsulate an outer IP heade
    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
+      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.
@@ -379,12 +379,12 @@ This uses `bpf_xdp_adjust_head` helper function to decapsulate an outer IP heade
 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
+   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
+      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):

diff --git a/docs/debugging.md b/docs/debugging.md
@@ -20,8 +20,8 @@ is compiled as part of building eBPF for Windows, as it is used in the unit test
 
              Section       Type  # Maps    Size
 ====================  =========  ======  ======
-               .text        xdp       1       3
-                 xdp        xdp       1      20
+               .text   xdp_test       1       3
+            xdp_test   xdp_test       1      20
 ```
 
 **Step 2)** Let's try to verify each section:
@@ -41,7 +41,7 @@ Verification report:
 
 2 errors
 
-> netsh ebpf show ver droppacket_unsafe.o xdp
+> netsh ebpf show ver droppacket_unsafe.o xdp_test
 Verification failed
 
 Verification report:
@@ -271,14 +271,14 @@ ntohs(uint16_t us)
 ```
 
 Clearly the .text section was not intended to be an actual eBPF program, but it did serve
-to illustrate some basic steps.  So now let's move on to the real program in the xdp section.
+to illustrate some basic steps.  So now let's move on to the real program in the xdp_test section.
 
 
 **Step 6)** Let's first look at the disassembly output from netsh:
 
 ```
 
-> netsh ebpf show disassembly droppacket_unsafe.o xdp
+> netsh ebpf show disassembly droppacket_unsafe.o xdp_test
 ; C:\your\path\ebpf-for-windows\tests\sample/unsafe/droppacket_unsafe.c:22
 ; DropPacket(xdp_md_t* ctx)
        0:       r0 = 1
@@ -328,10 +328,10 @@ The destination of jumps are shown after the goto.  For example, instruction
 3 will jump to instruction 19 if the condition is true.
 
 
-**Step 7)** Let's now look at the verification failures of xdp using level=verbose:
+**Step 7)** Let's now look at the verification failures of xdp_test using level=verbose:
 
 ```
-> netsh ebpf show ver droppacket_unsafe.o xdp level=verbose
+> netsh ebpf show ver droppacket_unsafe.o xdp_test level=verbose
 ...
 Pre-invariant : [
     instruction_count=3,
@@ -506,7 +506,7 @@ it dereferenced a pointer without knowing whether the packet is at least one byt
 Again we can see the source lines involved using llvm-objdump:
 
 ```
-> llvm-objdump -l -S droppacket_unsafe.o --section=xdp
+> llvm-objdump -l -S droppacket_unsafe.o --section=xdp_test
 ...
 0000000000000000 DropPacket:
 ; C:\your\path\ebpf-for-windows\tests\sample\unsafe/droppacket_unsafe.c:23
@@ -599,7 +599,7 @@ which is passed as the map_key to `bpf_map_lookup_elem`.  Let's see how the veri
 understands this.
 
 ```
-> netsh ebpf show ver droppacket_unsafe.o xdp level=verbose
+> netsh ebpf show ver droppacket_unsafe.o xdp_test level=verbose
 ...
 Pre-invariant : [
     instruction_count=28,

diff --git a/docs/eBpfExtensions.md b/docs/eBpfExtensions.md
@@ -99,9 +99,9 @@ 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 program types, the context data structure is as follows:
+For example, for the XDP_TEST program types, the context data structure is as follows:
 ```
-// XDP hook.  We use "struct xdp_md" for cross-platform compatibility.
+// XDP_TEST hook.  We use "struct xdp_md" for cross-platform compatibility.
 typedef struct xdp_md
 {
     void* data;         ///< Pointer to start of packet data.
@@ -232,7 +232,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 hook, the network interface index can be passed via this parameter. This tells the extension
+being attached to an XDP_TEST 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:
 ```
@@ -358,8 +358,8 @@ The parameter and return types for these helper functions must adhere to the `eb
 
 ### 2.7 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"` implies that the corresponding
-program type is `EBPF_PROGRAM_TYPE_XDP`.
+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`.
 
 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.
 When an eBPF extension is installed, it must update the eBPF store with the program types it implements along with the associated section prefixes.

diff --git a/docs/tutorial.md b/docs/tutorial.md
@@ -256,7 +256,7 @@ things out for readability, but feel free to abbreviate to save typing.
 **Step 2)** Run the verifier on our sample program
 
 ```
-> netsh ebpf show verification bpf.o type=xdp
+> netsh ebpf show verification bpf.o type=sample_ext
 
 Verification succeeded
 Program terminates within 6 instructions
@@ -268,7 +268,7 @@ as the eBPF program to verify.  If we try the same on an object file with
 multiple such sections, we get this:
 
 ```
-> netsh ebpf show verification bpf2.o type=xdp
+> netsh ebpf show verification bpf2.o type=sample_ext
 
 Verification succeeded
 Program terminates within 6 instructions
@@ -279,12 +279,12 @@ which was "myprog" in the section listing.  We can explicitly
 specify the section to use as follows:
 
 ```
-> netsh ebpf show verification bpf2.o myprog type=xdp
+> netsh ebpf show verification bpf2.o myprog type=sample_ext
 
 Verification succeeded
 Program terminates within 6 instructions
 
-> netsh ebpf show verification bpf2.o another type=xdp
+> netsh ebpf show verification bpf2.o another type=sample_ext
 
 Verification succeeded
 Program terminates within 6 instructions
@@ -330,7 +330,7 @@ verification process, using the "level=verbose" option to "show section":
 > netsh ebpf show section bpf.o .text verbose
 
 Section      : .text
-Program Type : xdp
+Program Type : sample_ext
 # Maps       : 0
 Size         : 2 instructions
 adjust_head  : 0
@@ -362,7 +362,7 @@ We can view verbose output to see what the verifier is actually doing,
 using the "level=verbose" option to "show verification":
 
 ```
-> netsh ebpf show verification bpf.o type=xdp level=verbose
+> netsh ebpf show verification bpf.o type=sample_ext level=verbose
 
 Pre-invariant : [
     instruction_count=0,
@@ -475,8 +475,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" is meant
-as an XDP layer program.  This is a convenient default, but can be
+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
 overridden by an app asking to load an eBPF program, such as when the eBPF program is simply in the
 ".text" section.
 
@@ -491,7 +491,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" hook point has the following prototype in `ebpf_nethooks.h`:
+The "xdp_test" hook point has the following prototype in `ebpf_nethooks.h`:
 
 ```
 typedef struct xdp_md
@@ -518,10 +518,10 @@ A sample eBPF program might look like this:
 #include "bpf_helpers.h"
 #include "ebpf_nethooks.h"
 
-// Put "xdp" in the section name to specify XDP as the hook.
+// Put "xdp_test" in the section name to specify XDP_TEST as the hook.
 // The SEC macro below has the same effect as the
 // clang pragma used in section 2 of this tutorial.
-SEC("xdp")
+SEC("xdp_test")
 int my_xdp_parser(xdp_md_t* ctx)
 {
     int length = (char *)ctx->data_end - (char *)ctx->data;
@@ -575,10 +575,10 @@ sockops                        ProgramType   : {77, 34, 251, 67...}
                                AttachType    : {205, 2, 125, 131...}
                                BpfProgType   : 4
                                BpfAttachType : 7
-xdp                            ProgramType   : {133, 42, 131, 241...}
-                               AttachType    : {239, 216, 224, 133...}
-                               BpfProgType   : 1
-                               BpfAttachType : 1
+xdp_test                       ProgramType   : {248, 206, 140, 206...}
+                               AttachType    : {93, 193, 204, 13...}
+                               BpfProgType   : 5
+                               BpfAttachType : 9
 ```
 
 With the above, our sample program will pass verification:
@@ -593,7 +593,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 instead had a different struct
+verifier is the same as above but XDP_TEST instead had a different struct
 definition:
 
 ```
@@ -718,7 +718,7 @@ and the return value.
 ;     return result;
        5:       exit
 
-> netsh ebpf show verification helpers.o type=xdp
+> netsh ebpf show verification helpers.o type=sample_ext
 Verification failed
 
 Verification report:
@@ -950,7 +950,7 @@ To see it installed:
 
     ID  Pins  Links  Mode       Type           Name
 ======  ====  =====  =========  =============  ====================
- 65568     1      1  JIT        xdp            my_xdp_parser
+ 65568     1      1  JIT        xdp_test       my_xdp_parser
 ```
 
 And remove it by the id, which we saw above is 65568:

diff --git a/include/ebpf_nethooks.h b/include/ebpf_nethooks.h
@@ -6,8 +6,8 @@
 // This file contains APIs for hooks and helpers that are
 // exposed by netebpfext.sys for use by eBPF programs.
 
-// XDP hook.  We use "struct xdp_md" for cross-platform compatibility.
-typedef struct xdp_md
+// XDP_TEST hook.  We use "struct xdp_md" for cross-platform compatibility.
+typedef struct xdp_md_
 {
     void* data;               ///< Pointer to start of packet data.
     void* data_end;           ///< Pointer to end of packet data.
@@ -28,7 +28,7 @@ typedef enum _xdp_action
 /**
  * @brief Handle an incoming packet as early as possible.
  *
- * Program type: \ref EBPF_PROGRAM_TYPE_XDP
+ * Program type: \ref EBPF_PROGRAM_TYPE_XDP_TEST
  *
  * @param[in] context Packet metadata.
  * @retval XDP_PASS Allow the packet to pass.
@@ -38,7 +38,7 @@ typedef enum _xdp_action
 typedef xdp_action_t
 xdp_hook_t(xdp_md_t* context);
 
-// XDP helper functions.
+// XDP_TEST helper functions.
 #define XDP_EXT_HELPER_FN_BASE 0xFFFF
 
 #ifndef __doxygen
@@ -51,9 +51,9 @@ typedef enum
 } ebpf_nethook_helper_id_t;
 
 /**
- * @brief Adjust XDP context data pointer.
+ * @brief Adjust XDP_TEST context data pointer.
  *
- * @param[in] ctx XDP context.
+ * @param[in] ctx XDP_TEST context.
  * @param[in] delta Number of bytes to move the data pointer by.
  *
  * @retval 0 The operation was successful.