netdev - Re: [PATCH net-next v1 7/7] netlink: specs: wireless: add a spec for nl80211

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: <cc0a13f9674238d3b7607e9d9b58ee6e5cc4aa5c.camel@sipsolutions.net>
Date: Wed, 04 Dec 2024 14:28:42 +0100
From: Johannes Berg <johannes@...solutions.net>
To: Donald Hunter <donald.hunter@...il.com>
Cc: netdev@...r.kernel.org, Jakub Kicinski <kuba@...nel.org>, "David S.
 Miller" <davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>, Paolo
 Abeni <pabeni@...hat.com>, Simon Horman <horms@...nel.org>, 
 linux-wireless@...r.kernel.org, donald.hunter@...hat.com
Subject: Re: [PATCH net-next v1 7/7] netlink: specs: wireless: add a spec
 for nl80211

On Wed, 2024-12-04 at 13:12 +0000, Donald Hunter wrote:
> My main motivation is coverage, for 2 reasons: firstly to flush out
> any feature gaps in YNL such as the ones I fixed in this series

Yeah, OK, though I'm not sure YNL is really meant to be feature complete
for everything netlink may be doing, rather than for what's needed - and
some of the things we did may even be things that are not meant to be
done any more (e.g. nested array vs. multi-attr arrays.)

> and
> secondly to achieve a critical mass of YNL specs that encourages
> people to build more tooling around the specs.

OK, fair :)

> YNL is already used for
> in-tree test automation and documentation generation. There is
> potential for generating strace dumpers and people are starting to use
> generated user space code.

Right.

> > Also, I don't know how we will maintain this if it's not tied to any
> > kernel code. What do you suggest? Do you want to just maintain it
> > following the nl80211.h spec all the time?
> 
> It's a good question. I am okay with maintaining it alongside the
> nl80211.h file, which will likely motivate me to write some automation
> at least for notifying any divergence. There might come a time when it
> becomes desirable to generate some of nl80211.h from the spec, as
> Stanislav Fomichev is doing for ethtool here:
> 
> https://lore.kernel.org/netdev/20241202162936.3778016-1-sdf@fomichev.me/

I think I wouldn't mind that - I'm hoping it'll also generate policies
etc.? Though on that front we probably have weird quirks too ...

But until then I guess someone's going to have to maintain it, and I'm
not sure I want that to be me right now :)

> > > +      name: get-wiphy
> > > +      doc: Get information about a wiphy or dump a list of all wiphys
> > > +      attribute-set: nl80211-attrs
> > > +      do:
> > > +        request:
> > > +          value: 1
> > > +          attributes:
> > > +            - wiphy
> > > +        reply:
> > > +          value: 3
> > > +      dump:
> > > +        request:
> > > +          attributes:
> > > +            - wiphy
> > > 
> > 
> > This already seems wrong - dump wiphy really should unconditionally
> > include NL80211_ATTR_SPLIT_WIPHY_DUMP these days.
> 
> Yes, the valid parameter attributes should be wiphy, wdev, ifindex and
> split-wiphy-dump by the look of it.

Well there's that about valid parameters, but also no (new) tools today
should ever *not* include the split-wiphy-dump attribute. I guess that
can't be expressed here, but it's a gotcha for implementers that just
follow the YNL spec?

johannes