linux-kernel - Re: [PATCH v4 3/3] mac80211: add KCOV remote annotations to incoming frame processing

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 28 Oct 2020 20:24:36 +0100
From:   Johannes Berg <johannes@...solutions.net>
To:     Aleksandr Nogikh <aleksandrnogikh@...il.com>, davem@...emloft.net,
        kuba@...nel.org
Cc:     edumazet@...gle.com, andreyknvl@...gle.com, dvyukov@...gle.com,
        elver@...gle.com, linux-kernel@...r.kernel.org,
        netdev@...r.kernel.org, linux-wireless@...r.kernel.org,
        willemdebruijn.kernel@...il.com,
        Aleksandr Nogikh <nogikh@...gle.com>
Subject: Re: [PATCH v4 3/3] mac80211: add KCOV remote annotations to
 incoming frame processing

On Wed, 2020-10-28 at 18:20 +0000, Aleksandr Nogikh wrote:
> From: Aleksandr Nogikh <nogikh@...gle.com>
> 
> Add KCOV remote annotations to ieee80211_iface_work and
> ieee80211_rx. This will enable coverage-guided fuzzing of
> mac80211 code that processes incoming 802.11 frames.
> 
> Signed-off-by: Aleksandr Nogikh <nogikh@...gle.com>
> ---
> v1 -> v2:
> * The commit now affects ieee80211_rx instead of
>   ieee80211_tasklet_handler.
> ---
>  include/net/mac80211.h | 2 ++
>  net/mac80211/iface.c   | 2 ++
>  2 files changed, 4 insertions(+)
> 
> diff --git a/include/net/mac80211.h b/include/net/mac80211.h
> index e8e295dae744..f4c37a1b381e 100644
> --- a/include/net/mac80211.h
> +++ b/include/net/mac80211.h
> @@ -4499,7 +4499,9 @@ void ieee80211_rx_napi(struct ieee80211_hw *hw, struct ieee80211_sta *sta,
>   */
>  static inline void ieee80211_rx(struct ieee80211_hw *hw, struct sk_buff *skb)
>  {
> +	kcov_remote_start_common(skb_get_kcov_handle(skb));
>  	ieee80211_rx_napi(hw, NULL, skb, NULL);
> +	kcov_remote_stop();
>  }

Wouldn't it make more sense to push that a layer down
into ieee80211_rx_napi(), or actually now perhaps even
better ieee80211_rx_list(), so we get it even if the driver called that
API in the first place?

You might only care about hwsim at this point, but perhaps hwsim would
get optimised ..


johannes