Differences
This shows you the differences between two versions of the page.
|
ep:labs:061:contents:tasks:ex3 [2019/09/27 06:35] andreea.alistar created |
ep:labs:061:contents:tasks:ex3 [2026/04/07 02:13] (current) radu.mantu |
||
|---|---|---|---|
| Line 1: | Line 1: | ||
| - | ==== 03. [10p] Stats ==== | + | ==== 03. [30p] Packets, where are you? ==== |
| - | Datafile: {{:ep:labs:health.txt|}} | + | Earlier in Ex. 1, we mentioned that eBPF is used for more than traffic filtering. Some of you may have heard of the [[https://dl.acm.org/doi/pdf/10.1145/3281411.3281443|eXpress Data Path (XDP)]] or the more recent [[https://www.usenix.org/system/files/osdi22-zhong_1.pdf|eXpress Resubmission Path (XRP)]]. Both of these are eBPF-powered shunts of kernel data paths that are used to optimize the system for //very// specific types of workloads. We'll return to these in a future lecture (and maybe a lab as well) since they can be considered advanced topics. For now, we'll focus on the third purpose eBPF can serve: execution tracing. |
| - | Use Gnuplot to generate the following graphs: | + | [[https://github.com/cilium/pwru|pwru]] is a tool created by Cilium to help trace network packets in the kernel's network stack and debug network connectivity issues. It does this by attaching simple eBPF programs to certain function entry points. These programs can report back to a userspace process different kinds of information, including the function that was reached, the arguments that were passed, and a CPU clock timestamp. The method used for instrumenting kernel code is based on [[https://www.kernel.org/doc/html/latest/trace/kprobes.html|kprobes]]. Ask your assistant for more information. |
| - | * Using the 'stats' command, find out the mean and standard deviation value for the “Temperature” and “Heart Rate” columns. | + | |
| - | * Create a rectangle that contains all the data points considered to be in the average normal values (assume that the “normal” values should be in the interval [mean-stddev, mean+stddev]). | + | === [10p] Task A - A packet's journey === |
| - | * Create a multiplot containing 3 plots using the “Temperature” and “Heart Rate” columns: one for all genders, one for males and one for females. | + | |
| - | * The graphs should be as complete as possible (title, axes names, etc.) | + | **Installation — build from source** |
| + | |||
| + | Pre-built packages are no longer maintained for most distributions, so you'll build ''pwru'' from source. All you need is a Go compiler and ''make''. | ||
| - | <solution -hidden> | ||
| <code bash> | <code bash> | ||
| - | reset #flush all variables | + | # Install Go if you don't have it |
| + | $ sudo apt install golang-go # Ubuntu/Debian | ||
| + | # or follow https://go.dev/dl/ for the latest version | ||
| - | set size 1, 1 | + | # Clone and build |
| - | set multiplot layout 2,2 rowsfirst | + | $ git clone https://github.com/cilium/pwru.git |
| + | $ cd pwru | ||
| + | $ make | ||
| + | $ sudo mv pwru /usr/local/bin/ | ||
| - | stats 'health.txt' using 2:4 nooutput | ||
| - | set object 1 rect from STATS_mean_x -STATS_stddev_x,STATS_mean_y - STATS_stddev_y to STATS_mean_x + STATS_stddev_x, STATS_mean_y + STATS_stddev_y lw 2 | + | The build takes about a minute on first run (Go downloads dependencies). The result is a statically linked binary with no runtime dependencies. |
| - | set title 'All genders' | + | **Minimum requirements** (check before running): |
| - | set xlabel 'Temperature(F)' | + | |
| - | set ylabel 'Heart Rate' | + | |
| - | unset key | + | |
| - | plot 'health.txt' using 2:4 | + | |
| - | set title 'Male' | + | * Linux kernel ≥ 5.5 (for BTF support): ''uname -r'' |
| - | set xlabel 'Temperature(F)' | + | * BTF enabled: ''ls /sys/kernel/btf/vmlinux'' — file must exist |
| - | set ylabel 'Heart Rate' | + | * ''bpf'' filesystem mounted: ''mount | grep bpf'' |
| - | unset key | + | |
| - | plot 'health.txt' using (strcol(3) eq "male" ? $2: 1/0):4 | + | |
| - | set title 'Female' | + | If BTF is missing, ''pwru'' will fail immediately with a clear error message.</code> |
| - | set xlabel 'Temperature(F)' | + | |
| - | set ylabel 'Heart Rate' | + | Now, trace all outgoing DNS queries to the Google DNS (i.e.: ''8.8.8.8'') and perform one using **dig**. Add relative timestamps to the individual trace entries, to get an idea of the computational cost of each operation. |
| - | unset key | + | |
| - | plot 'health.txt' using (strcol(3) eq "female" ? $2: 1/0):4 | + | Finally, insert an **iptables** rule on the //OUTPUT// chain that drops DNS queries to ''8.8.8.8'' and redo the experiment. Check where the packet's path is cut short (the reason should be obvious :p). |
| + | |||
| + | <note important> | ||
| + | **Ubuntu users:** local DNS caching via ''systemd-resolved'' may intercept your query before it reaches the network. If ''pwru'' shows nothing, try: | ||
| + | <code bash> | ||
| + | $ sudo systemd-resolve --flush-caches | ||
| + | </code> | ||
| + | or target ''127.0.0.53'' to confirm caching is the issue. | ||
| + | </note> | ||
| + | |||
| + | <solution -hidden> | ||
| + | Some [[https://wiki.linuxfoundation.org/networking/kernel_flow|extra info]] (partial to TCP). | ||
| + | |||
| + | The commands: | ||
| + | <code bash> | ||
| + | $ sudo iptables -I OUTPUT -p udp -d 8.8.8.8 --dport 53 -j DROP | ||
| + | $ sudo pwru 'dst host 8.8.8.8 && dst port 53' | ||
| + | $ dig +short ocw.cs.pub.ro @8.8.8.8 | ||
| </code> | </code> | ||
| </solution> | </solution> | ||
| + | |||
| + | === [20p] Task B - Interpreting the call path === | ||
| + | |||
| + | Analyze the call path in the kernel network stack for the first scenario (when the packet actually made it out). __Explain__ each step of the packet's journey. | ||
| + | |||
| + | <note tip> | ||
| + | Check out this [[https://makelinux.github.io/kernel/map/|map of the kernel subsystems]], but note that the best source of information is always [[https://elixir.bootlin.com/linux/latest/source|RTFS]]. | ||
| + | </note> | ||
| + | |||
| + | To structure your analysis, answer these questions in order: | ||
| + | |||
| + | - **Where does the packet originate?** Which function is the first to appear in the trace? What layer of the network stack does it correspond to? | ||
| + | - **How does it reach the IP layer?** Identify the transition from the socket/transport layer to the IP layer. Which function marks this boundary? | ||
| + | - **What does Netfilter do here?** Identify ''nf_hook_slow'' in the trace. Which Netfilter hook point does it correspond to (refer back to Figure 1 from Task 01)? | ||
| + | - **How does it leave the machine?** Identify the function responsible for handing the packet to the network device driver. What happens after this point? | ||
| + | - **What changed with the DROP rule?** Compare the two traces side by side. At which function does the path diverge? | ||
| + | |||
| + | |||
| + | |||
