Received-SPF: pass (google.com: domain of linux-wireless-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
MIME-Version: 1.0
References: <20201009170202.103512-1-a.nogikh@gmail.com> <5d71472dcef4d88786ea6e8f30f0816f8b920bb7.camel@sipsolutions.net>
In-Reply-To: <5d71472dcef4d88786ea6e8f30f0816f8b920bb7.camel@sipsolutions.net>
From:   Aleksandr Nogikh <a.nogikh@gmail.com>
Date:   Mon, 12 Oct 2020 14:18:47 +0300
Message-ID: <CADpXja8NZDZ_3AMHUMnj90nbQbW2pA_aP=_Y2w2tSfy8EcRZkw@mail.gmail.com>
Subject: Re: [PATCH v2 0/3] [PATCH v2 0/3] [PATCH v2 0/3] net, mac80211,
 kernel: enable KCOV remote coverage collection for 802.11 frame handling
To:     Johannes Berg <johannes@sipsolutions.net>
Cc:     davem@davemloft.net, kuba@kernel.org, akpm@linux-foundation.org,
        Eric Dumazet <edumazet@google.com>,
        Andrey Konovalov <andreyknvl@google.com>,
        Dmitry Vyukov <dvyukov@google.com>,
        Marco Elver <elver@google.com>, linux-kernel@vger.kernel.org,
        netdev@vger.kernel.org, linux-wireless@vger.kernel.org,
        nogikh@google.com
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

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