| Message ID | 20201009170202.103512-1-a.nogikh@gmail.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | net, mac80211, kernel: enable KCOV remote coverage collection for 802.11 frame handling | expand |
On 9 October 2020 19:01:59 CEST, Aleksandr Nogikh <a.nogikh@gmail.com> wrote: >This patch series conflicts with another proposed patch >http://lkml.kernel.org/r/223901affc7bd759b2d6995c2dbfbdd0a29bc88a.1602248029.git.andreyknvl@google.com >One of these patches needs to be rebased once the other one is merged. Maybe that other patch shouldn't do things that way though, and add new API (which the existing one could call with some kind of "all contexts" argument) instead, so it's only necessary to specify the context (mask?) where its actually needed (the few places in usb or e whatever)? Surely that would also look less tedious in the mac80211 code, for example. And if you ever fix the nesting issue you'd have fewer places to modify again. johannes
On Fri, Oct 9, 2020 at 7:13 PM Johannes Berg <johannes@sipsolutions.net> wrote: > > > > On 9 October 2020 19:01:59 CEST, Aleksandr Nogikh <a.nogikh@gmail.com> wrote: > > >This patch series conflicts with another proposed patch > >http://lkml.kernel.org/r/223901affc7bd759b2d6995c2dbfbdd0a29bc88a.1602248029.git.andreyknvl@google.com > >One of these patches needs to be rebased once the other one is merged. > > > Maybe that other patch shouldn't do things that way though, and add new API (which the existing one could call with some kind of "all contexts" argument) instead, so it's only necessary to specify the context (mask?) where its actually needed (the few places in usb or e whatever)? > > Surely that would also look less tedious in the mac80211 code, for example. > > And if you ever fix the nesting issue you'd have fewer places to modify again. Hi Johannes, I initially hesitated to do that, as it would multiply the number of kcov callbacks. But perhaps you're right and a clean API look outweighs the rest. I will do this in v3. Thanks!
On 11 October 2020 12:37:29 CEST, Andrey Konovalov <andreyknvl@google.com> wrote: >I initially hesitated to do that, as it would multiply the number of >kcov callbacks. But perhaps you're right and a clean API look >outweighs the rest. I will do this in v3. Yeah, OK, dunno. You can always make it an inline calling the "full" API so after compiling it's equivalent. But if course that still has the two APIs. It just seemed to the common case wouldn't worry really (have to) about these things, especially if you plan on changing it again later. johannes
On Fri, 2020-10-09 at 17:01 +0000, Aleksandr Nogikh wrote: > From: Aleksandr Nogikh <nogikh@google.com> > > 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. Btw, it occurred to me that I don't know at all - is this related to syzkaller? Or is there some other fuzzing you're working on? Can we get the bug reports from it if it's different? :) Also, unrelated to that (but I see Dmitry CC'ed), I started wondering if it'd be helpful to have an easier raw 802.11 inject path on top of say hwsim0; I noticed some syzbot reports where it created raw sockets, but that only gets you into the *data* plane of the wifi stack, not into the *management* plane. Theoretically you could add a monitor interface, but right now the wifi setup (according to the current docs on github) is using two IBSS interfaces. Perhaps an inject path on the mac80211-hwsim "hwsim0" interface would be something to consider? Or simply adding a third radio that's in "monitor" mode, so that a raw socket bound to *that* interface can inject with a radiotap header followed by an 802.11 frame, getting to arbitrary frame handling code, not just data frames. Any thoughts? johannes
On Sun, Oct 11, 2020 at 8:50 PM Johannes Berg <johannes@sipsolutions.net> wrote: > > On Fri, 2020-10-09 at 17:01 +0000, Aleksandr Nogikh wrote: > > From: Aleksandr Nogikh <nogikh@google.com> > > > > 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. > > Btw, it occurred to me that I don't know at all - is this related to > syzkaller? Or is there some other fuzzing you're working on? Can we get > the bug reports from it if it's different? :) Yes, all this is for syzkaller :) > > Also, unrelated to that (but I see Dmitry CC'ed), I started wondering if > it'd be helpful to have an easier raw 802.11 inject path on top of say > hwsim0; I noticed some syzbot reports where it created raw sockets, but > that only gets you into the *data* plane of the wifi stack, not into the > *management* plane. Theoretically you could add a monitor interface, but > right now the wifi setup (according to the current docs on github) is > using two IBSS interfaces. > > Perhaps an inject path on the mac80211-hwsim "hwsim0" interface would be > something to consider? Or simply adding a third radio that's in > "monitor" mode, so that a raw socket bound to *that* interface can > inject with a radiotap header followed by an 802.11 frame, getting to > arbitrary frame handling code, not just data frames. I'll let Aleksandr address this part.
On Sun, 11 Oct 2020 at 21:50, Johannes Berg <johannes@sipsolutions.net> wrote: [...] > Also, unrelated to that (but I see Dmitry CC'ed), I started wondering if > it'd be helpful to have an easier raw 802.11 inject path on top of say > hwsim0; I noticed some syzbot reports where it created raw sockets, but > that only gets you into the *data* plane of the wifi stack, not into the > *management* plane. Theoretically you could add a monitor interface, but > right now the wifi setup (according to the current docs on github) is > using two IBSS interfaces. > > Perhaps an inject path on the mac80211-hwsim "hwsim0" interface would be > something to consider? Or simply adding a third radio that's in > "monitor" mode, so that a raw socket bound to *that* interface can > inject with a radiotap header followed by an 802.11 frame, getting to > arbitrary frame handling code, not just data frames. > > Any thoughts? > > johannes > *sending it again as I forgot to include Cc list* Hi Johannes, Thank you for sharing these ideas. Currently we're injecting frames via mac80211_hwsim (by pretenting to be wmediumd - https://github.com/google/syzkaller/blob/4a77ae0bdc5cd75ebe88ce7c896aae6bbf457a29/executor/common_linux.h#L4922). Injecting via RAW sockets would definitely be a much cleaner way, but to do that we need to keep a separate monitor interface. That's pretty hard as the fuzzer is constantly trying to break things, and direct injection via mac80211_hwsim seems to be a much more robust way - it will work as long as the virtual device is alive. hwsim0 is unfortunately not available as fuzzer processes are run in separate network namespaces, while this one is created during mac80211_hwsim initialization. The current approach seems to work fine for management frames - I was able to create seed programs that inject valid management frames and these frames have the expected effect on the subsystem (e.g. injecting AP responses during scan/authentication/authorization forces a station to believe that it has successfully connected to an AP). -- Best Regards, Aleksandr
On Mon, 2020-10-12 at 14:18 +0300, Aleksandr Nogikh wrote: > > Currently we're injecting frames via mac80211_hwsim (by pretenting to > be wmediumd - > https://github.com/google/syzkaller/blob/4a77ae0bdc5cd75ebe88ce7c896aae6bbf457a29/executor/common_linux.h#L4922). Ah, ok, of course that works too :-) > Injecting via RAW sockets would definitely be a much cleaner way, but > to do that we need to keep a separate monitor interface. That's pretty > hard as the fuzzer is constantly trying to break things, and direct > injection via mac80211_hwsim seems to be a much more robust way - it > will work as long as the virtual device is alive. hwsim0 is > unfortunately not available as fuzzer processes are run in separate > network namespaces, while this one is created during mac80211_hwsim > initialization. Oh, OK. I guess we _could_ move that also to the new namespace or something, but if the wmediumd approach works then I think it's not worth it. > The current approach seems to work fine for management frames - I was > able to create seed programs that inject valid management frames and > these frames have the expected effect on the subsystem (e.g. injecting > AP responses during scan/authentication/authorization forces a station > to believe that it has successfully connected to an AP). Great! johannes
From: Aleksandr Nogikh <nogikh@google.com> 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. 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() This patch series conflicts with another proposed patch http://lkml.kernel.org/r/223901affc7bd759b2d6995c2dbfbdd0a29bc88a.1602248029.git.andreyknvl@google.com One of these patches needs to be rebased once the other one is merged. v2: * Moved KCOV annotations from ieee80211_tasklet_handler to ieee80211_rx. * Updated kcov_common_handle() to return 0 if it is called in interrupt context. * Updated the cover letter. v1: https://lkml.kernel.org/r/20201007101726.3149375-1-a.nogikh@gmail.com Aleksandr Nogikh (3): kernel: make kcov_common_handle consider the current context net: store KCOV remote handle in sk_buff mac80211: add KCOV remote annotations to incoming frame processing include/linux/skbuff.h | 21 +++++++++++++++++++++ include/net/mac80211.h | 2 ++ kernel/kcov.c | 2 ++ net/core/skbuff.c | 1 + net/mac80211/iface.c | 2 ++ 5 files changed, 28 insertions(+) base-commit: a804ab086e9de200e2e70600996db7fc14c91959