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: <20221012155828.5a5cade8@xps-13> Date: Sat, 15 Oct 2022 10:59:28 +0200 From: Miquel Raynal <miquel.raynal@...tlin.com> To: Alexander Aring <aahringo@...hat.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 v4 5/8] ieee802154: hwsim: Implement address filtering Hi Alexander, aahringo@...hat.com wrote on Mon, 10 Oct 2022 21:21:17 -0400: > Hi, > > On Mon, Oct 10, 2022 at 9:13 PM Alexander Aring <aahringo@...hat.com> wrote: > > > > Hi, > > > > On Mon, Oct 10, 2022 at 9:04 PM Alexander Aring <aahringo@...hat.com> wrote: > > > > > > Hi, > > > > > > On Fri, Oct 7, 2022 at 4:53 AM Miquel Raynal <miquel.raynal@...tlin.com> wrote: > > > > > > > > We have access to the address filters being theoretically applied, we > > > > also have access to the actual filtering level applied, so let's add a > > > > proper frame validation sequence in hwsim. > > > > > > > > Signed-off-by: Miquel Raynal <miquel.raynal@...tlin.com> > > > > --- > > > > drivers/net/ieee802154/mac802154_hwsim.c | 111 ++++++++++++++++++++++- > > > > include/net/ieee802154_netdev.h | 8 ++ > > > > 2 files changed, 117 insertions(+), 2 deletions(-) > > > > > > > > diff --git a/drivers/net/ieee802154/mac802154_hwsim.c b/drivers/net/ieee802154/mac802154_hwsim.c > > > > index 458be66b5195..84ee948f35bc 100644 > > > > --- a/drivers/net/ieee802154/mac802154_hwsim.c > > > > +++ b/drivers/net/ieee802154/mac802154_hwsim.c > > > > @@ -18,6 +18,7 @@ > > > > #include <linux/netdevice.h> > > > > #include <linux/device.h> > > > > #include <linux/spinlock.h> > > > > +#include <net/ieee802154_netdev.h> > > > > #include <net/mac802154.h> > > > > #include <net/cfg802154.h> > > > > #include <net/genetlink.h> > > > > @@ -139,6 +140,113 @@ static int hwsim_hw_addr_filt(struct ieee802154_hw *hw, > > > > return 0; > > > > } > > > > > > > > +static void hwsim_hw_receive(struct ieee802154_hw *hw, struct sk_buff *skb, > > > > + u8 lqi) > > > > +{ > > > > + struct ieee802154_hdr hdr; > > > > + struct hwsim_phy *phy = hw->priv; > > > > + struct hwsim_pib *pib; > > > > + > > > > + rcu_read_lock(); > > > > + pib = rcu_dereference(phy->pib); > > > > + > > > > + if (!pskb_may_pull(skb, 3)) { > > > > + dev_dbg(hw->parent, "invalid frame\n"); > > > > + goto drop; > > > > + } > > > > + > > > > + memcpy(&hdr, skb->data, 3); > > > > + > > > > + /* Level 4 filtering: Frame fields validity */ > > > > + if (hw->phy->filtering == IEEE802154_FILTERING_4_FRAME_FIELDS) { > > > > I see, there is this big if handling. But it accesses the > > hw->phy->filtering value. It should be part of the hwsim pib setting > > set by the driver callback. It is a question here of mac802154 layer > > setting vs driver layer setting. We should do what the mac802154 tells > > the driver to do, this way we do what the mac802154 layer is set to. > > > > However it's a minor thing and it's okay to do it so... > > * whereas we never let the driver know at any time of what different > filter levels exist _currently_ we have only the promiscuous mode > on/off switch which is do nothing or 4_FRAME_FIELDS. > It will work for now, changing anything in the mac802154 filtering > fields or something will end in probably breakage in this handling. In > my point of view as the current state is it should not do that, as > remember that hwsim will "simulate" hardware it should not be able to > access mac802154 fields (especially when doing receiving of frames) as > other hardware will only set register bits (as hwsim pib values is > there for)... > > Still I think it's fine for now. I see your point, indeed I could have added another PIB attribute instead of accessing the PHY state. I am fine doing it in a followup patch if this what you prefer. Shall I do it? Thanks, Miquèl
Powered by blists - more mailing lists