Creating test harness for OPENED tools extracted functions

[sdsen]

Is your feature request related to a problem? Please describe.

1. We will create a test harness for OPENED extracted modules from monoliths by testing that the modules run.
   Describe the solution you'd like
2. For creating test harness one possible approach will be:
   Given a module to be extracted, put in prints/capture the input and output packets when running the module as part of larger monolith. Craft similar packet in scapy and run through extracted module to show equivalence. Specifically:
3. Write a scapy function to generate the same input packet
4. Pass the crafted packet in previous step, to input of extracted function
5. Print the output packet inside extracted function
6. Compare the outputs of original and extracted functions
7. Use bpftool-prog to pass the same input to the extracted module and then check the generated output.
8. Report success/failure depending on whether the outputs match.

[dushyantbehl]

An example which shows how to generate scapy packets can be found at: 1

For a slighly detailed example which shows specific TCP packet generation see: 2

[palanik1]

@Theophilusbenson @sebymiano @LCastanheira-1 For creating the test harness (Steps 4-10) for extracted modules, wanted to get your thoughts if it would make sense to re-use the klee based machinery Sebastiano and Lucas have been working on.

[Theophilusbenson]

The Klee-based tool would be helpful in "generating the important" input packets that would provide high confidence. Right now, workflow doest not specify how the input packets should be generated.

@sebymiano I believe you have some insights on how to run an eBPF program in isolation without running the whole kernel! can you provide some pointers?

[sebymiano]

@Theophilusbenson yes, that's correct.
Basically, if we have a script that generates the input packets to be passed to the extracted function, we can reuse the same code that I have written for the equivalence checking to test the function and compare the outputs of the original and extracted function.

The code is here.

What we need to do specifically for this is to modify in this code the way it reads the input packet (here), since right now it reads the KLEE generated file to get the input packet.

[sdsen]

@sebymiano the code snippets are in private repo, can we share the same for others to check ?

[sebymiano]

@sebymiano the code snippets are in private repo, can we share the same for others to check ?

@sdsen the repo is public now, the others should be able to check it out.

[sebymiano]

@sdsen I have a question regarding the approach you proposed.
What you want to do is to show equivalance between extracted function/module and the original one when running as part of a larger monolith.

From the technical point of view, this can be done using the bpf_prog_test_run for both modules, injecting a specifically crafted input packet to both functions and compare their outputs. This can be done in the same way I did it in the link sent in the previous reply.

The question I have is, when running the original function which is part of a larger monolith, you should run the entire monolith, which in turn calls your target function. The entire program can perform other tasks, and potentially modify the input packet. How do you check the equivalence of that specific function, without extracting it before?

[sdsen]

@dushyantbehl please track test harness work in this issue.