linux-kernel - 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]

Message-ID: <20220106201516.6a48154a@xps13>
Date:   Thu, 6 Jan 2022 20:15:16 +0100
From:   Miquel Raynal <miquel.raynal@...tlin.com>
To:     Alexander Aring <alex.aring@...il.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 Alexander,

alex.aring@...il.com wrote on Wed, 5 Jan 2022 19:38:12 -0500:

> Hi,
> 
> 
> On Wed, 5 Jan 2022 at 15:55, Miquel Raynal <miquel.raynal@...tlin.com> wrote:
> ...
> > > rest in software is a bigger task here...  
> >
> > On the symbol duration side I feel I'm close to a working PoC.
> >  
> 
> oh, ok.

I think it's ready, I'll soon send two series:
- the symbol duration update
- v2 for this series, which will not apply without the symbol duration
  update.

> > So there is 'only' this item left in my mind. Could you please clarify
> > what you expect from me exactly in terms of support for the promiscuous
> > filters we discussed so far?
> >  
> 
> I think for now it's okay to set the device into promiscuous mode and
> enable the flag which checks for bad FCS... we can still implement the
> filter modes later (and I think it should work on all supported
> transceivers (except that SoftMAC/HardMAC thing)).

I considered the following options in order to do that:
1- Hack all ->set_promiscuous() driver implementations to set
   IEEE802154_HW_RX_DROP_BAD_CKSUM as long as it was not already set
   initially.
2- Set the above flag at scan level, ie. in
   scan.c:mac802154_set_promiscuous_mode(). But this would be a bit
   ugly and I'd need to add a persistent field somewhere in the
   wpan_dev structure to remember how the flags settings where before
   the scan code hacked it.
3- Add more code in hwsim to handle checksum manually instead of
   by default setting the above flag to request the core to do the
   job. This way no driver would actually set this flag. We can then
   consider it "volatile" and would not need to track its state.
4- We know that we are in a scan thanks to a mac802154 internal
   variable, we can just assume that all drivers are in promiscuous
   mode and that none of them actually checks the FCS. This is
   certainly the simplest yet effective solution. In the worst case, we
   are just doing the check twice, which I believe does not hurt as
   long as the checksum is not cut off. If the checksum is cut, then
   the core is buggy because it always remove the two last bytes.

I picked 4 for now, but if you think this is unreliable, please
tell me what do you prefer otherwise.

> One point to promiscuous mode, currently we have a checking for if a
> phy is in promiscuous mode on ifup and it would forbid to ifup a node
> interface if the phy is in promiscuous mode (because of the missing
> automatic acknowledgement). I see there is a need to turn the phy into
> promiscuous mode during runtime... so we need somehow make sure the
> constraints are still valid here.

Yes, the code (rx.c) currently drops everything that is not a beacon
during a scan.

> Maybe we even forbid multiple devs
> on a phy if the transceiver/driver/firmware is poor and this is
> currently all transceivers (except hwsim? But that doesn't use any ack
> handling anyway).

Thanks,
Miquèl