On Thu, 29 Oct 2020 17:36:17 +0000 Aleksandr Nogikh wrote: > From: Aleksandr Nogikh <nogikh@xxxxxxxxxx> > > This patch series enables remote KCOV coverage collection during > 802.11 frames processing. These changes make it possible to perform > coverage-guided fuzzing in search of remotely triggerable bugs. > > Normally, KCOV collects coverage information for the code that is > executed inside the system call context. It is easy to identify where > that coverage should go and whether it should be collected at all by > looking at the current process. If KCOV was enabled on that process, > coverage will be stored in a buffer specific to that process. > Howerever, it is not always enough as handling can happen elsewhere > (e.g. in separate kernel threads). > > When it is impossible to infer KCOV-related info just by looking at > the currently running process, one needs to manually pass some > information to the code that should be instrumented. The information > takes the form of 64 bit integers (KCOV remote handles). Zero is the > special value that corresponds to an empty handle. More details on > KCOV and remote coverage collection can be found in > Documentation/dev-tools/kcov.rst. > > The series consists of three commits. > 1. Apply a minor fix to kcov_common_handle() so that it returns a > valid handle (zero) when called in an interrupt context. > 2. Take the remote handle from KCOV and attach it to newly allocated > SKBs as an skb extension. If the allocation happens inside a system > call context, the SKB will be tied to the process that issued the > syscall (if that process is interested in remote coverage collection). > 3. Annotate the code that processes incoming 802.11 frames with > kcov_remote_start()/kcov_remote_stop(). Applied, thanks.
