linux-kernel - Re: [PATCH RFC] cfg80211: add new command for reporting wiphy crashes

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]

Message-ID: <20190920140143.GA30514@w1.fi>
Date:   Fri, 20 Sep 2019 17:01:43 +0300
From:   Jouni Malinen <j@...fi>
To:     Rafał Miłecki <zajec5@...il.com>
Cc:     Johannes Berg <johannes@...solutions.net>,
        "David S . Miller" <davem@...emloft.net>,
        linux-wireless@...r.kernel.org, netdev@...r.kernel.org,
        linux-kernel@...r.kernel.org, hostap@...ts.infradead.org,
        openwrt-devel@...ts.openwrt.org,
        Rafał Miłecki <rafal@...ecki.pl>
Subject: Re: [PATCH RFC] cfg80211: add new command for reporting wiphy crashes

On Fri, Sep 20, 2019 at 03:37:08PM +0200, Rafał Miłecki wrote:
> Hardware or firmware instability may result in unusable wiphy. In such
> cases usually a hardware reset is needed. To allow a full recovery
> kernel has to indicate problem to the user space.

Why? Shouldn't the driver be able to handle this on its own since all
the previous configuration was done through the driver anyway. As far as
I know, there are drivers that do indeed try to do this and handle it
successfully at least for station mode. AP mode may be more complex, but
for that one, I guess it would be fine to drop all associations (and
provide indication of that to user space) and just restart the BSS.

> This new nl80211 command lets user space known wiphy has crashed and has
> been just recovered. When applicable it should result in supplicant or
> authenticator reconfiguring all interfaces.

For me, that is not really "recovered" if some additional
reconfiguration steps are needed.. I'd like to get a more detailed view
on what exactly might need to be reconfigured and how would user space
know what exactly to do. Or would the plan here be that the driver would
not even indicate this crash if it is actually able to internally
recover fully from the firmware restart?

> I'd like to use this new cfg80211_crash_report() in brcmfmac after a
> successful recovery from a FullMAC firmware crash.
> 
> Later on I'd like to modify hostapd to reconfigure wiphy using a
> previously used setup.

So this implies that at least something would need to happen in AP mode.
Do you have a list of items that the driver cannot do on its own and why
it would be better to do them from user space?

> I'm OpenWrt developer & user and I got annoyed by my devices not auto
> recovering after various failures. There are things I cannot fix (hw
> failures or closed fw crashes) but I still expect my devices to get
> back to operational state as soon as possible on their own.

I fully agree with the auto recovery being important thing to cover for
this, but I'm not yet convinced that this needs user space action. Or if
it does, there would need to be more detailed way of indicating what
exactly is needed for user space to do. The proposed change here is just
saying "hey, I crashed and did something to get the hardware/firmware
responding again" which does not really tell much to user space other
than potentially requiring full disable + re-enable for the related
interfaces. And that is something that should not actually be done in
all cases of firmware crashes since there are drivers that handle
recovery in a manner that is in practice completely transparent to user
space.

-- 
Jouni Malinen                                            PGP id EFC895FA