netdev - Re: [net-next 12/18] net: mac802154: Handle scan requests

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:   Mon, 10 Jan 2022 12:17:00 -0500
From:   Alexander Aring <alex.aring@...il.com>
To:     Miquel Raynal <miquel.raynal@...tlin.com>
Cc:     Stefan Schmidt <stefan@...enfreihafen.org>,
        Nicolas Schodet <nico@...fr.eu.org>,
        "David S. Miller" <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>,
        "open list:NETWORKING [GENERAL]" <netdev@...r.kernel.org>,
        linux-wpan - ML <linux-wpan@...r.kernel.org>,
        David Girault <david.girault@...vo.com>,
        Romuald Despres <romuald.despres@...vo.com>,
        Frederic Blain <frederic.blain@...vo.com>,
        Thomas Petazzoni <thomas.petazzoni@...tlin.com>,
        kernel list <linux-kernel@...r.kernel.org>
Subject: Re: [net-next 12/18] net: mac802154: Handle scan requests

Hi,

On Fri, 7 Jan 2022 at 06:02, Miquel Raynal <miquel.raynal@...tlin.com> wrote:
>
...
> > >
> >
> > Okay, I will look at this code closely regarding whenever multiple
> > wpan_devs are running.
>
> The "scanning" boolean is stored as a wpan_phy member (IIRC) so we
> should be good on this regard (now that I have a clearer picture of the
> dependencies).
>

ok.

> > You should also check for possible stop of all possible wpan dev
> > transmit queues, if it's not already done.
>
> I forgot about this path. Indeed I'll add a check in the transmit path
> as well, of course.
>

What I mean is look into the functions "ieee802154_stop_queue()" and
"ieee802154_wake_queue()".

> > I suppose a scan can take a
> > long time and we should not send some data frames out. I am thinking
> > about the long time scan operation... if we stop the queue for a long
> > time I think we will drop a lot, however the scan can only be
> > triggered by the right permissions and the user should be aware of the
> > side effects. Proper reliable upper layer protocols will care or non
> > reliable will not care about this.
> >
> > There still exists the driver "ca8210" which is the mentioned HardMAC
> > transceiver in SoftMAC. There should somehow be a flag that it cannot
> > do a scan and the operation should not be allowed as the xmit callback
> > allows dataframes only.
>
> So it cannot do an active scan, but a passive scan would be allowed
> (there is no transmission, and the beacons are regular valid frames,
> I suppose they should not be filtered out by the hardware).
>
> So we actually need these hooks back :-) Because the right thing to do
> here is to use the "FYI here is the scan op that is starting" message
> from the mac to the drivers and this driver should return "nope,
> -ENOTSUPP". The mac would react in this case by canceling the
> operation and returning an error to the caller. Same when sending
> beacons if we consider beacons as !dataframes.
>

I believe that a HardMAC transceiver will handle a lot of the scan
process on the transceiver side and is only capable of dumping what
it's stored and start/stop scan? This is one reason why the
scan/dump/etc cfg802154 interface  should be close to the standard
(MLME). At the end it should from userspace make no difference if at
the end is a HardMAC or SoftMAC. Although there will always be a
limitation and a SoftMAC is probably always "more" powerful than a
HardMAC, but at some point there is a "minimum" of capable
functionality... and SoftMAC transceivers might always have "some"
things which they might offload to the hardware.

- Alex