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
| ||
|
Message-ID: <CAK-6q+g4xhqY-5HOBdYc_s4sHgZxtpZjfoN0_wXeDTKC6LmBPQ@mail.gmail.com> Date: Thu, 8 Sep 2022 21:02:29 -0400 From: Alexander Aring <aahringo@...hat.com> To: Miquel Raynal <miquel.raynal@...tlin.com> Cc: Alexander Aring <alex.aring@...il.com>, Stefan Schmidt <stefan@...enfreihafen.org>, linux-wpan@...r.kernel.org, "David S. Miller" <davem@...emloft.net>, Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>, Eric Dumazet <edumazet@...gle.com>, netdev@...r.kernel.org, David Girault <david.girault@...vo.com>, Romuald Despres <romuald.despres@...vo.com>, Frederic Blain <frederic.blain@...vo.com>, Nicolas Schodet <nico@...fr.eu.org>, Thomas Petazzoni <thomas.petazzoni@...tlin.com> Subject: Re: [PATCH wpan/next v3 8/9] net: mac802154: Ensure proper general purpose frame filtering Hi, On Thu, Sep 8, 2022 at 9:00 PM Alexander Aring <aahringo@...hat.com> wrote: > > Hi, > > On Mon, Sep 5, 2022 at 4:35 PM Miquel Raynal <miquel.raynal@...tlin.com> wrote: > > > > Most of the PHYs seem to cope with the standard filtering rules by > > default. Some of them might not, like hwsim which is only software, and > > yes, as I said before hwsim should pretend to be like all other > hardware we have. > > > in this case advertises its real filtering level with the new > > "filtering" internal value. > > > > The core then needs to check what is expected by looking at the PHY > > requested filtering level and possibly apply additional filtering > > rules. > > > > Signed-off-by: Miquel Raynal <miquel.raynal@...tlin.com> > > --- > > include/net/ieee802154_netdev.h | 8 ++++ > > net/mac802154/rx.c | 78 +++++++++++++++++++++++++++++++++ > > 2 files changed, 86 insertions(+) > > > > diff --git a/include/net/ieee802154_netdev.h b/include/net/ieee802154_netdev.h > > index d0d188c3294b..1b82bbafe8c7 100644 > > --- a/include/net/ieee802154_netdev.h > > +++ b/include/net/ieee802154_netdev.h > > @@ -69,6 +69,14 @@ struct ieee802154_hdr_fc { > > #endif > > }; > > > > +enum ieee802154_frame_version { > > + IEEE802154_2003_STD, > > + IEEE802154_2006_STD, > > + IEEE802154_STD, > > + IEEE802154_RESERVED_STD, > > + IEEE802154_MULTIPURPOSE_STD = IEEE802154_2003_STD, > > +}; > > + > > struct ieee802154_hdr { > > struct ieee802154_hdr_fc fc; > > u8 seq; > > diff --git a/net/mac802154/rx.c b/net/mac802154/rx.c > > index c43289c0fdd7..bc46e4a7669d 100644 > > --- a/net/mac802154/rx.c > > +++ b/net/mac802154/rx.c > > @@ -52,6 +52,84 @@ ieee802154_subif_frame(struct ieee802154_sub_if_data *sdata, > > mac_cb(skb)->type); > > goto fail; > > } > > + } else if (sdata->required_filtering == IEEE802154_FILTERING_4_FRAME_FIELDS && > > We switch here from determine that receive path, means way we are - way > going from interface type to the required filtering value. Sure there > is currently a 1:1 mapping for them now but I don't know why we are > doing that and this is in my opinion wrong. The receive path should > depend on interface type as it was before and for scanning there is > some early check like: > > if (wpan_phy_is_in_scan_mode_state(local)) { > do_receive_scanning(...) > /* don't do any other delivery because they provide it to upper layer */ In the assumption we know if the condition above is true we have address filtering disabled. - Alex
Powered by blists - more mailing lists