111-2專題研究筆記 Week 11-12

Problem Specification

This week I was planning to reproduce the result from a Paper on packet filtering performance comparison. The paper focuses on three different levels of packet filtering, Driver level(via XDP), Kernel Level(via Iptables) and user space level(via a github project). I have already roughly analyzed the driver level and the kernel level, but have not yet started the user space part.

This picture above shows the level of the three filters.

The method used in the paper to implement user space filtering is using systemd and libpcap to create a socket with some filtering rules. This allows application developers to ship packet filtering rules that can be deployed together with their application, which not only makes every applications can have its own packet rules, also simplifies the central policy.

Task specification

The github project is from AlexanderKurtz's alfwrapper, application level firewall. It consists of three parts, systemd function for spawning ready-to-use socket to daemon, bpf virtual machine to determine if a packet should pass, and bcc project to compilng c program to bpf bytecode.

I planned to deploy this project directly on an Ubuntu 20.04 virtual machine, set up a record point with XDP dump project to record the timestamp, a userspace program to show the recieving time, just like what I did in this note. By doing so, I can observe the delay of user space packet filtering, and compare it with the delay of the other 2 method I tried in this note.

The above painting was the datapath I construct. A packet will first go through the XDPdump hook on the driver, and a timestamp was marked. Then the packet will be send to the network stack but instead of finishing filtering path in the stack, it will be send out from the stack by libpcap, it's next stop will be the socket hooked a bpf vm filter. If it pass the filtering, UDP program will marked another timestamp, which can let us know the delay of this whole datapath.

Result

The biggest problem with this project is that it does not provide detailed documentations about the installation, which makes it hard to prepare dependencies and deal with errors.

The first error I encounter is something about missing header file, which says:

lib/bcc.c:6:10: fatal error: bcc/bpf_common.h: No such file or directory

It's quickly sovled by making it include the correct header file from correct path, from:

#include <bcc/bpf_common.h>

to

#include <bcc/compat/linux/bpf_common.h> 

and then a bunch of errors occurs, something like this:

/usr/include/linux/bpf.h:3577:8: error: redefinition of ‘struct bpf_func_info’
 3577 | struct bpf_func_info {
      |        ^~~~~~~~~~~~~

Looks like some function is redefinded by some header file, I checked the bcc update log and found out its library changed 1 year ago, which made this project from 2017 emerged a lot of problems.

So I tried to remove some header files it include, such like:

#include <bcc/libbpf.h>

to

//#include <bcc/libbpf.h>

Also, the origin Makefile add a flag "-werror" to gcc compiler, which makes gcc treat every warning as error, I wonder why?

After all of this above, the compiling finally completed, but when I ran the script provided by the author, the segmentation fault(core dumped) was occured.

3 warnings generated.
Segmentation fault (core dumped)
run-parts: tests/subnets.sh exited with return code 139
make: *** [Makefile:15: tests] Error 1

Facing that kind of mistake, I realize that it can't be simply dealed with changing a few lines of the code, so I wonder if it's because the problem with the platform I used at the time.

I decided to build another vitual machine, with ubuntu 16.07 linux on it, check if that helps.

Update

Another linux version won't help, I even tried centos7. Looks like it's not a problem about the version, it's the problem about the code itself. I think the paper author(this paper) didn't actualy use the project at that time, they probably just took examples from the code. I think that's what I supposed to do next.