linux-kernel - Re: [net-next 01/18] ieee802154: hwsim: Ensure proper channel selection at probe time

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, 5 Jan 2022 09:14:41 +0100
From:   Miquel Raynal <miquel.raynal@...tlin.com>
To:     Alexander Aring <alex.aring@...il.com>
Cc:     "David S. Miller" <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>,
        "open list:NETWORKING [GENERAL]" <netdev@...r.kernel.org>,
        Stefan Schmidt <stefan@...enfreihafen.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 01/18] ieee802154: hwsim: Ensure proper channel
 selection at probe time

Hi Alexander,

alex.aring@...il.com wrote on Tue, 4 Jan 2022 18:10:44 -0500:

> Hi,
> 
> On Tue, 4 Jan 2022 at 18:08, Alexander Aring <alex.aring@...il.com> wrote:
> >
> > Hi,
> >
> > On Tue, 4 Jan 2022 at 10:44, Miquel Raynal <miquel.raynal@...tlin.com> wrote:  
> > >
> > > Hi Alexander,
> > >
> > > alex.aring@...il.com wrote on Tue, 28 Dec 2021 16:05:43 -0500:
> > >  
> > > > Hi,
> > > >
> > > > On Wed, 22 Dec 2021 at 10:57, Miquel Raynal <miquel.raynal@...tlin.com> wrote:  
> > > > >
> > > > > A default channel is selected by default (13), let's clarify that this
> > > > > is page 0 channel 13. Call the right helper to ensure the necessary
> > > > > configuration for this channel has been applied.
> > > > >
> > > > > So far there is very little configuration done in this helper but we
> > > > > will soon add more information (like the symbol duration which is
> > > > > missing) and having this helper called at probe time will prevent us to
> > > > > this type of initialization at two different locations.
> > > > >  
> > > >
> > > > I see why this patch is necessary because in later patches the symbol
> > > > duration is set at ".set_channel()" callback like the at86rf230 driver
> > > > is doing it.
> > > > However there is an old TODO [0]. I think we should combine it and
> > > > implement it in ieee802154_set_channel() of "net/mac802154/cfg.c".
> > > > Also do the symbol duration setting according to the channel/page when
> > > > we call ieee802154_register_hw(), so we have it for the default
> > > > settings.  
> > >
> > > While I totally agree on the background idea, I don't really see how
> > > this is possible. Every driver internally knows what it supports but
> > > AFAIU the core itself has no easy and standard access to it?
> > >  
> >
> > I am a little bit confused here, because a lot of timing related
> > things in the phy information rate points to "x times symbols". If  
> 
> s/rate/base/

Yes indeed, but I bet it works because the phy drivers set the symbol
duration by themselves. You can see that none of them does something
clever like:

switch (phy.protocol) {
	case XXXXX:
		symbol_duration = y;
		break;
	...

Instead, they all go through the page/channel list in a quite hardcoded
way because the phy driver knows internally that protocol X is used on
{page, channel}, but the protocol id, while not being totally absent
from drivers, is always provided as a comment.

So getting rid of the core TODO you mentioned earlier means:
- Listing properly the PHY protocols in the core (if not already done)
- For each PHY protocol knowing the possible base frequencies
- For each of these base frequencies knowing the symbol duration
- Having the possibility to add more information such as the PRF in
  order to let the core pick the right symbol duration when there is
  more than one possibility for a {protocol, base frequency} couple
- Convert the phy drivers (at least hwsim) to fill these new fields
  correctly and expect the core to set the symbol duration properly.

Two side notes as well:
- I was not able to find all the the corresponding protocol from the
  hwsim driver in the spec (these channels are marked "unknown")
- The symbol duration in a few specific UWB cases is below 1us while
  the core expects a value in us. Should we change the symbol duration
  to ns?

I believe all this is doable in a reasonable time frame provided that
I only focus on the few protocols supported by hwsim which I already
"addressed" and perhaps a couple of simple drivers. On the core side,
the logic might be: "is the driver providing information about the phy
protocols used? if yes, then set the symbol duration if we have enough
data, otherwise let the driver handle it by itself". Such logic would
allow a progressive shift towards the situation where drivers do not
have to bother with symbol duration by themselves.

As this looks like a project on its own and my first goal was to be
able to use hwsim to demonstrate the different scan features, maybe we
can continue to discuss this and consider tackling it as a separate
series whish would apply on top of the current one, what do you think?

Thanks,
Miquèl