Differences
This shows you the differences between two versions of the page.
|
ep:labs:03:contents:tasks:ex6 [2023/10/21 11:21] andrei.mirciu [04. [30p] Perf & fuzzing] |
ep:labs:03:contents:tasks:ex6 [2023/10/21 17:43] (current) andrei.mirciu [04. [30p] Perf & fuzzing] |
||
|---|---|---|---|
| Line 9: | Line 9: | ||
| </note> | </note> | ||
| - | === [15p] Task A - Fuzzing with AFL === | + | === [10p] Task A - Fuzzing with AFL === |
| First, let's compile AFL and all related tools. We initialize / update a few environment variables to make them more accessible. Remember that these are set only for the current shell. | First, let's compile AFL and all related tools. We initialize / update a few environment variables to make them more accessible. Remember that these are set only for the current shell. | ||
| Line 66: | Line 66: | ||
| * **crashes/** : files that generate crashes. If you want to search for bugs and not just test for coverage increase, you should compile your binary with a sanitizer (e.g.: [[https://clang.llvm.org/docs/AddressSanitizer.html|asan]]). Under normal circumstances, an out-of-bounds access can go undetected unless the accessed address is unmapped, thus creating a #PF (page fault). Different sanitizers give assurances that these bugs actually get caught, but also reduce the execution speed of the tested programs, meaning slower code coverage increase. | * **crashes/** : files that generate crashes. If you want to search for bugs and not just test for coverage increase, you should compile your binary with a sanitizer (e.g.: [[https://clang.llvm.org/docs/AddressSanitizer.html|asan]]). Under normal circumstances, an out-of-bounds access can go undetected unless the accessed address is unmapped, thus creating a #PF (page fault). Different sanitizers give assurances that these bugs actually get caught, but also reduce the execution speed of the tested programs, meaning slower code coverage increase. | ||
| - | === [15p] Task B - Profile AFL === | + | === [10p] Task B - Profile AFL === |
| Next, we will analyze the performance of **afl**. Using **perf**, we are able to specify one or more events (see ''man perf-list(1)'') that the kernel knows to record only when our program under test (in this case **afl**) is running. When the internal event counter reaches a certain value (see the ''-c'' and ''-F'' flags in ''man perf-record(1)''), a sample is taken. This sample can contain different kinds of information; for example, the ''-g'' option requires the inclusion of a backtrace of the program with every sample. | Next, we will analyze the performance of **afl**. Using **perf**, we are able to specify one or more events (see ''man perf-list(1)'') that the kernel knows to record only when our program under test (in this case **afl**) is running. When the internal event counter reaches a certain value (see the ''-c'' and ''-F'' flags in ''man perf-record(1)''), a sample is taken. This sample can contain different kinds of information; for example, the ''-g'' option requires the inclusion of a backtrace of the program with every sample. | ||
| Line 81: | Line 81: | ||
| <code bash> | <code bash> | ||
| $ sudo su | $ sudo su | ||
| - | # echo -1 > /proc/sys/kernel/perf_event_paranoid | + | $ echo -1 > /proc/sys/kernel/perf_event_paranoid |
| - | # exit | + | $ exit |
| </code> | </code> | ||
| Line 88: | Line 88: | ||
| </note> | </note> | ||
| - | Leave the process running for a minute or so; then kill it with //<Ctrl + C>//. **perf** will take a few moments longer to save all collected samples in a file named //perf.data//. Don't mess with it! | + | Leave the process running for a minute or so; then kill it with //<Ctrl + C>//. **perf** will take a few moments longer to save all collected samples in a file named //perf.data//, which are read by **perf script**. Don't mess with it! |
| Let's see some raw trace output first. Then look at the perf record. The record aggregates the raw trace information and identifies stress areas. | Let's see some raw trace output first. Then look at the perf record. The record aggregates the raw trace information and identifies stress areas. | ||
| Line 100: | Line 100: | ||
| Make sure to include plenty of screenshots and explanations for this task :p | Make sure to include plenty of screenshots and explanations for this task :p | ||
| + | |||
| + | === [10p] Task C - Flame Graph === | ||
| + | |||
| + | A [[https://www.brendangregg.com/flamegraphs.html|Flame Graph]] is a graphical representation of the stack traces captured by the **perf** profiler during the execution of a program. It provides a visual depiction of the call stack, showing which functions were active and how much time was spent in each one of them. By analyzing the flame graph generated by //perf//, we can identify performance bottlenecks and pinpoint areas of the code that may need optimization or further investigation. | ||
| + | |||
| + | When analyzing flame graphs, it's crucial to focus on the width of each stack frame, as it directly indicates the number of recorded events following the same sequence of function calls. In contrast, the height of the frames does not carry significant implications for the analysis and should not be the primary focus during interpretation. | ||
| + | |||
| + | Using the samples previously obtained in //perf.data//, generate a corresponding Flame Graph in SVG format and analyze it. | ||
| + | |||
| + | <note> | ||
| + | How to do: | ||
| + | - Clone the following git repo: https://github.com/brendangregg/FlameGraph. | ||
| + | - Use the **stackcollapse-perf.pl** Perl script to convert the //perf.data// output into a suitable format (it folds the perf-script output into one line per stack, with a count of the number of times each stack was seen). | ||
| + | - Generate the Flame Graph using **flamegraph.pl** (based on the folded data) and redirect the output to an SVG file. | ||
| + | - Open in any browser the interactive SVG graph obtained and inspect it. | ||
| + | |||
| + | More details can also be found [[https://www.brendangregg.com/FlameGraphs/cpuflamegraphs.html|here]] and [[https://gitlab.com/gitlab-com/runbooks/-/blob/v2.220.2/docs/tutorials/how_to_use_flamegraphs_for_perf_profiling.md|here]]. | ||
| + | </note> | ||
| + | |||
| + | |||
| + | |||
